opes wg 62 th ietf, minneapolis, mn, usa

2005-03-08 OPES SMTP Use CasesOPES WG at 62th IETF in Minneapolis

1

OPES WG 62th IETF, Minneapolis, MN, USA

OPES SMTP Use Cases draft-ietf-opes-smtp-use-cases-00.txt

Martin Stecher ([email protected])Abbie Barbir ([email protected])

Presented by

Paul Knight ([email protected])


2

Table of Contents

• What is OPES/SMTP?• SMTP Use Cases Draft and Status• Operation Flow of an OPES SMTP System• Activation Points / Callout Modes• Use Cases• Future Work


3

What is OPES/SMTP?

• From OPES charter:

– The OPES [WG] has previously [...] developed a protocol suite for invocation and tracking of OPES services inside the net. The protocol suite includes a generic, application-agnostic protocol core (OCP Core) that is supplemented by profiles specific to the application-layer protocol used between the endpoints. So far, the WG has specified an OCP profile for HTTP, which supports OPES services that operate on HTTP messages.

– In a next step, the WG will specify one or more OCP profiles that will support OPES services operating on SMTP


4

What is OCP?

OCP = OPES Callout Protocol

Client

Server

OPES processor

pre-processing

post-processing

Callout server

OCP-Client OCP-Server

adaptation

OCP wrapped application dataOCP control messages

OCP scope


5

Current Focus is on OCP/SMTP

OCP Core

HTTPprofile

RTSPprofile

FTPprofile

SMTPprofile

MIMEprofile

...

TCP/IP OtherTransports

Applicationprotocolagnostic

Applicationprotocolbinding

assumesTCP as transport

done

done

new focus


6

Use Cases Draft

• First step to get a use cases draft for OPES/SMTP done• From OPES charter:

– [OCP/SMTP] profile to be specified will enable an SMTP server (the OPES processor) to encapsulate and forward SMTP data and metadata to a callout server for additional processing

– Several kinds of agents participate in SMTP exchanges:• MSA – Mail Submission Agent• MTA – Mail Transfer Agent• MDA – Mail Delivery Agent• MUA – Mail User Agent

– The first OCP/SMTP profile will address the needs of the MTAMTA


7

Status

• Collected use cases

• Compiled and published –00 draft

– Available since Feb 10

– Included important discussion points from the mailing list


8

Operation Flow of an OPES SMTP System

Mail Client

MUA

Mail Server

MSA MTA

Mail Gateway

MTA MTA

Mail Server

MTA MDA

Mail Client

MUA

Callout server Callout server

Callout server Callout server

OCP/SMTPOCP/SMTPOCP/SMTPOCP/SMTP

PossibleActivation Points

MSA – Mail Submission AgentMTA – Mail Transfer AgentMDA – Mail Delivery AgentMUA – Mail User Agent


9

Theoretical Activation Points1. Receiving email

• Do a SMTP dialog with the peer, receiving email from it, usually storing the emails in a queue and maybe sending on later

2. Stored email in queue• Operate on an email that has been received earlier.

There is no current SMTP dialog going on3. Sending email

• Do a SMTP dialog with a peer, send email to it.4. Proxy (receive and forward)

• Having two SMTP dialogs at the same time. Mostly forwarding commands and replies; often no own email queue

yes

yes

no

no


10

Activation Points

• Activation Points 1 and 3 are very similar from an OPES view and needed

• Activation Point 2 is out of scope for OPES/SMTP and can be handled in future OPES/MIME scope

• Activation Point 4 can be seen as a combination of 1 and 3. Not in focus as standalone activation point. SMTP proxies without queues are in some conflict with RFC 2821 section 4.5.4.1 "Sending Strategy" anyway


11

Callout modes

• SMTP command modification– Command / Command value is modified by the

callout server– Example: Rewrite RCPT TO address– Example: Change email message body

• SMTP command satisfaction– Callout server responds with a SMTP reply– Usually an error message, e.g. forbid a given RCPT

TO recipient


12

More callout modes ?

• SMTP reply modification

– Probably not needed.

– Very few use cases

– May make sense at activation point 4 that is not in our focus

• Email message body modification

– We will incorporate this into the command modification mode (handle as DATA command value)


13

Use Cases

• Three groups:

– SMTP command modification

– SMTP command satisfaction

– OPES mail delivery side effects

• Full list at http://www.martin-stecher.de/opes/smtpusecases.html


14

SMTP command modification samples

• For email message content modification these use cases are very similar to the services listed in section 2.2 of the “OPES Use Cases” RFC 3752 - "Services performed on (HTTP) responses".

• Plus more SMTP/Email related:

– Virus scanning (replacing infected attachments of a mail message)

– Spam filtering (mark a message if it supposed to contain spam)

– Verify mail signatures

– Rewrite SMTP recipients


15

SMTP command satisfaction samples

• Logging or validating “MAIL FROM” addresses

• Validate “RCPT TO” addresses

– For example: Lookup addresses in an LDAP directory.


16

OPES mail delivery side effects

• These may be side effects on the current SMTP dialog or on other operations that the MTA performs on the mail message or it may split the mail message into multiple messages or create additional messages

• Examples:– Reject a message whose content violates a possible

trigger condition– Delay a message, put it in a special queue for further

processing or reroute it to other recipients– Generate additional notification messages (e.g.

virus alerts)


17

Current Issues ..1

• OPES is supposed to enable new services – There are some situations in which an SMTP server

may wish to call forward to another server in order to validate a user's address

– could be implemented in the OPES service application

– wouldn't have been a hack if it had been done as part of an OPES service

• using the same architectural model that we used for HTTP


18

Current Issues ..2

• Every request satisfaction could also be implemented as a response modification by ignoring the original response. Can we ?

• Look at legal conflict with US ECPA delivery expectations of accepted data. Once the message is accepted by SMTP, the responsibility moves to the operator on how it is he/she wishes to handle/process the stored message

• Even with a PROXY concept there is still a need to follow the current SMTP design expectations. If the OPES device is implemented at the DATA stage, this falls in line with the "instant notification" concept satisfying the user expectation.

– If the OPES device accepts the message, then it is now the SMTP operator responsibility (ISP) on what he will do with the message


19

Current Issues ..3

• If an OPES service is applied to POST SMTP, then how is this reflected back into the SMTP process? Is it as a bounce? Any errant drop of mail will be attributed to the system operator (sysop) post filtering policy

• OPES MTA cascade on the mail path, as such the end to end finishes at the last MTA

• All use cases deal with SMTP commands. Need to document exactly what we mean by the value of a DATA command

• Timeout Prevention– Use of: 1yz* Positive Preliminary reply– Do we need for the OPES specifications to provide an 2821

Update provision to make timeouts work.

* The command has been accepted, but the requested action is being held in abeyance, pending confirmation of the information in this reply. The sender-SMTP should send another command specifying whether to continue or abort the action.


20

Current Issues ..4

• Deployment scenarios

– Discusses how it relates to administrative domains, trust issues etc.)

• IAB Considerations

– Tracing considerations

– Bypass considerations

– Notification considerations

• Privacy Considerations


21

Next Steps

• Update the Draft after this meeting

• Address current issues

• Need SMTP experts to get involved

• Need to synchronize with Sieve WG

• Please get involved

opes wg 62 th ietf, minneapolis, mn, usa

Documents