OPES SMTP Use Cases OPES WG at 62th IETF in Minneapolis

1
OPES WG 62th IETF, Minneapolis, MN, USA

• OPES SMTP Use Cases draft-ietf-opes-smtp-use-case
  s-00.txt
• Martin Stecher (martin.stecher_at_webwasher.com)Abbi
  e Barbir (abbieb_at_nortel.com)
• Presented by
• Paul Knight (paul.knight_at_nortel.com)

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

Server
pre-processing
OCP scope
OCP wrapped application dataOCP control messages
OCP-Client
OCP-Server
post-processing
adaptation
OPES processor
Callout server
Client
5
Current Focus is on OCP/SMTP
new focus
R done
HTTP profile
RTSP profile
FTP profile
SMTP profile
MIME profile
Application protocol binding
...
OCP Core
Application protocolagnostic
R done
TCP/IP
Other Transports
assumes TCP as transport
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 MTA

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
OCP/SMTP
OCP/SMTP
OCP/SMTP
Possible Activation Points
OCP/SMTP
MSA Mail Submission Agent MTA Mail Transfer
Agent MDA Mail Delivery Agent MUA Mail User
Agent
9
Theoretical Activation Points

• 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
• Stored email in queue
• Operate on an email that has been received
  earlier. There is no current SMTP dialog going on
• Sending email
• Do a SMTP dialog with a peer, send email to it.
• Proxy (receive and forward)
• Having two SMTP dialogs at the same time. Mostly
  forwarding commands and replies often no own
  email queue

R yes
T no
R yes
T 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/smt
  pusecases.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