Subject: RE: WG Last Call: draft-ietf-opes-smtp-use-cases-02.txt

From: Tony Hansen <[email-masked]>
Date: Thu, 07 Jul 2005 14:40:29 -0400

The following are a large number of minor points with the use-cases
document. It is presented as a context diff off of the posted -02 document.

	Tony

*** draft-ietf-opes-smtp-use-cases-02.txt Wed Jul  6 16:06:40 2005
- --- draft-ietf-opes-smtp-use-cases-02-comments.txt Thu Jul  7 14:34:32
2005
***************
*** 130,141 ****
     remote callout server.

     HTTP [9] based use cases for Open Puggable Edge Services (OPES) are
!    described in [2].  This work focus on OPES for SMTP [8] use cases,
     whereby, additional use cases and enhancements to the types of OPES
     services defined in [2] are provided.

     In SMTP the OPES processor may be any agent participating in SMTP
!    exhanges, including MSA, MTA, MDA, and MUA.  This document focues on
     use cases in which the OPES processor is a mail transfer agent (MTA).

     SMTP is a store and forward protocol.  Current email filtering
- --- 130,143 ----
     remote callout server.

     HTTP [9] based use cases for Open Puggable Edge Services (OPES) are
!    described in [2].  This work focuses on OPES for SMTP [8] use cases,
     whereby, additional use cases and enhancements to the types of OPES
     services defined in [2] are provided.

     In SMTP the OPES processor may be any agent participating in SMTP
!    exhanges, including a Mail Submission Agent (MSA), a Mail Transfer
!    Agent (MTA), a Mail Delivery Agent (MDA), and a Mail
!    User Agent (MUA).  This document focuses on
     use cases in which the OPES processor is a mail transfer agent (MTA).

     SMTP is a store and forward protocol.  Current email filtering
***************
*** 146,153 ****
     This work focuses on SMTP based services that want to modify command
     values and those that want to block commands by defining an error
     response that the MTA should send in response to the response it
!    received.  OPES MTA will be involved in SMTP command modification and
!    command satisfaction, analog to request modification and request
     satisfaction from HTTP [9].

- --- 148,155 ----
     This work focuses on SMTP based services that want to modify command
     values and those that want to block commands by defining an error
     response that the MTA should send in response to the response it
!    received.  An OPES MTA will be involved in SMTP command
modification and
!    command satisfaction, analogous to request modification and request
     satisfaction from HTTP [9].

***************
*** 264,272 ****
     systems.  SMTP clients and servers exchange commands and responses
     and eventually the mail message body.

     In this work the OPES processor may be any agent that is
!    participating in SMTP exchanges, including MSA, MTA, MDA, and MUA.
!    However, this document focues on use cases in which the OPES
     processor is a mail transfer agent (MTA).

  3.1  Operation Flow of an OPES SMTP System
- --- 266,286 ----
     systems.  SMTP clients and servers exchange commands and responses
     and eventually the mail message body.

+    Figure 2 expands on the mail flow in an SMTP system. Further
information
+    on the architecture of email in the internet may be found in [x].
+ (NB. [x] is a reference to the email architecture document.)
+
+    +-------+  +---------+      +---------+      +--------+  +-------+
+    |mail  M|  |M mail  M| SMTP |M mail  M| SMTP |M mail M|  |M mail |
+    |clnt  U|--|S srvr  T|------|T gway  T|------|T srvr D|--|U clnt |
+    |      A|  |A       A|      |A       A|      |A      A|  |A      |
+    +-------+  +---------+      +---------+      +--------+  +-------+
+
+                          Figure 2: Expanded SMTP Flow
+
     In this work the OPES processor may be any agent that is
!    participating in SMTP exchanges, including an MSA, MTA, MDA, and MUA.
!    However, this document focuses on use cases in which the OPES
     processor is a mail transfer agent (MTA).

  3.1  Operation Flow of an OPES SMTP System
***************
*** 289,295 ****
     server there is an MSA (mail submission agent) that is waiting to
     receive email from the user.  The MSA uses an MTA (mail transfer
     agent) within the same server to forward the user email to other
!    domains.(Communication between the MUA and MSA may be via SMTP or
     something else such as MAPI).

     The MTA in the user email server may directly contact the email
- --- 303,309 ----
     server there is an MSA (mail submission agent) that is waiting to
     receive email from the user.  The MSA uses an MTA (mail transfer
     agent) within the same server to forward the user email to other
!    domains. (Communication between the MUA and MSA may be via SMTP or
     something else such as MAPI).

     The MTA in the user email server may directly contact the email
***************
*** 315,323 ****
                |  server  |     |  server  |     |  server  |
                +----------+     +----------+     +----------+

!                          Figure 2: OPES SMTP Flow

!    From Figure 2, the MTA (the OPES processor) is either receiving or
     sending an email (or both) within an email server/gateway.  An OPES
     processor might be the sender's SMTP server, the destination SMTP
     server or any intermediate SMTP gateway.  (Which building block
- --- 329,337 ----
                |  server  |     |  server  |     |  server  |
                +----------+     +----------+     +----------+

!                          Figure 3: OPES SMTP Flow

!    From Figure 3, the MTA (the OPES processor) is either receiving or
     sending an email (or both) within an email server/gateway.  An OPES
     processor might be the sender's SMTP server, the destination SMTP
     server or any intermediate SMTP gateway.  (Which building block
***************
*** 341,349 ****
        ready at Thu, 20 Jan 2005 11:24:40+0100
        C: HELO ThatsMe
        S: 250 mail.example.com Hello [192.168.0.138]
!       C: MAIL FROM: [email-masked]
        S: 250 2.1.0 [email-masked]....Sender OK
!       C: RCPT TO: [email-masked]
        S: 250 2.1.5 [email-masked]
        C: DATA
        S: 354 Start mail input; end with "CRLF"."CRLF"
- --- 355,363 ----
        ready at Thu, 20 Jan 2005 11:24:40+0100
        C: HELO ThatsMe
        S: 250 mail.example.com Hello [192.168.0.138]
!       C: MAIL FROM:<[email-masked]>
        S: 250 2.1.0 [email-masked]....Sender OK
!       C: RCPT TO:<[email-masked]>
        S: 250 2.1.5 [email-masked]
        C: DATA
        S: 354 Start mail input; end with "CRLF"."CRLF"
***************
*** 358,364 ****
        C: QUIT
        S: 221 2.0.0 mail.example.com Service closing transmission channel

!    The client (C:) is issueing SMTP commands and the server (S:) is
     generating responses.  All responses start with a status code and
     then some text.  At minimum 4 commands are needed to send an email.
     All commands and responses to send a single email message together
- --- 372,378 ----
        C: QUIT
        S: 221 2.0.0 mail.example.com Service closing transmission channel

!    The client (C:) is issuing SMTP commands and the server (S:) is
     generating responses.  All responses start with a status code and
     then some text.  At minimum 4 commands are needed to send an email.
     All commands and responses to send a single email message together
***************
*** 375,381 ****
        Hi, this is a test!

     The callout service may need to examine values of previous commands
!    of the same dialog.  For example, callout service needs to examine
     the value of the RCPT command (it is "[email-masked]") which is
     different from the "[email-masked]" that the email client
     displays in the visible "To" field.  That might be an important fact
- --- 389,395 ----
        Hi, this is a test!

     The callout service may need to examine values of previous commands
!    of the same dialog.  For example, the callout service needs to examine
     the value of the RCPT command (it is "[email-masked]") which is
     different from the "[email-masked]" that the email client
     displays in the visible "To" field.  That might be an important fact
***************
*** 393,402 ****
  Internet-Draft             OPES SMTP Use Cases                 July 2005

! 4.  OEPS/SMTP usecases

!    In principle all filtering that is deployed at SMTP gateways today
!    and tomorrow defines use cases for OPES callout filtering.  An OCP/
     SMTP callout protocol will enable an SMTP gateway to vector out
     (parts of) an SMTP message or parts of the SMTP dialog to a callout
     server that is then performing actions on behalf of the gateway.
- --- 407,416 ----
  Internet-Draft             OPES SMTP Use Cases                 July 2005

! 4.  OPES/SMTP Use Cases

!    In principle, all filtering that is deployed at SMTP gateways today
!    and tomorrow define use cases for OPES callout filtering.  An OCP/
     SMTP callout protocol will enable an SMTP gateway to vector out
     (parts of) an SMTP message or parts of the SMTP dialog to a callout
     server that is then performing actions on behalf of the gateway.
***************
*** 428,437 ****
     o  The incident is reported to other tools such as intrusion
        detection applications

!    These kinds of filters do usually not require to work with elements
     of the SMTP dialog other than the email message body.  An exception
     to this is the need to map email senders and recipients to different
!    security sub policies that are used for a particular message.  A
     security filter may therefore require receiving the information of
     the RCPT TO and MAIL FROM commands as meta data with the email
     message body it examines.
- --- 442,451 ----
     o  The incident is reported to other tools such as intrusion
        detection applications

!    These kinds of filters usually do not require working with elements
     of the SMTP dialog other than the email message body.  An exception
     to this is the need to map email senders and recipients to different
!    security subpolicies that are used for a particular message.  A
     security filter may therefore require receiving the information of
     the RCPT TO and MAIL FROM commands as meta data with the email
     message body it examines.
***************
*** 438,444 ****

  4.2  Spam Filter

!    Next to security filters probably the most wanted filtering
     application today.  Spam filters use several methods.  They
     concentrate most on the email message body (that also includes the

- --- 452,458 ----

  4.2  Spam Filter

!    Next to security filters, spam filters are probably the most wanted
filtering
     application today.  Spam filters use several methods.  They
     concentrate most on the email message body (that also includes the

***************
*** 471,477 ****
  4.3  Logging and reporting filters

     The nature of this kind of filters is not to modify the email
!    message.  Depending on what is being logged or reported on the filter
     may need access to any part of the SMTP dialog.  Most wanted are the
     sender and recipient information.  Depending on the ability of the
     OPES processor to pre-calculate and transfer information about the
- --- 485,491 ----
  4.3  Logging and reporting filters

     The nature of this kind of filters is not to modify the email
!    message.  Depending on what is being logged or reported on, the filter
     may need access to any part of the SMTP dialog.  Most wanted are the
     sender and recipient information.  Depending on the ability of the
     OPES processor to pre-calculate and transfer information about the
***************
*** 488,494 ****
     These filters operate on the values of the MAIL FROM and RCPT TO
     commands of the SMTP dialog.  They run an access control policy to
     determine whether a sender is currently allowed to send a message to
!    the given recipients.  The result of this filter has a direct
     influence on the SMTP response that the OPES processor has to send to
     its peer for the filtered SMTP command.

- --- 502,510 ----
     These filters operate on the values of the MAIL FROM and RCPT TO
     commands of the SMTP dialog.  They run an access control policy to
     determine whether a sender is currently allowed to send a message to
!    the given recipients.
!    The values of HELO/EHLO, AUTH and STARTTLS commands may also be
applied.
!    The result of this filter has a direct
     influence on the SMTP response that the OPES processor has to send to
     its peer for the filtered SMTP command.

***************
*** 496,502 ****

     Filters of this kind can support an email gateway to centrally encode
     and decode email, and to set and to verify email signatures.  They
!    will therefore modify the email message body to encrypt, decrypt or

- --- 512,518 ----

     Filters of this kind can support an email gateway to centrally encode
     and decode email, and to set and to verify email signatures.  They
!    will therefore modify the email message body to encrypt, decrypt,
verify or

***************
*** 505,516 ****
  Internet-Draft             OPES SMTP Use Cases                 July 2005

!    sign the message or use an action as specified in the "Security
     Filter" (Section 4.1) section if the decryption or signature
     verification fails.

     Sending the SMTP sender and recipient information as meta data to
!    these filters is mission critical because these filters must not
     trust the information found in the header section of the email
     message body.

- --- 521,532 ----
  Internet-Draft             OPES SMTP Use Cases                 July 2005

!    sign the message, or use an action as specified in the "Security
     Filter" (Section 4.1) section if the decryption or signature
     verification fails.

     Sending the SMTP sender and recipient information as meta data to
!    these filters is mission critical because these filters may not
     trust the information found in the header section of the email
     message body.

***************
*** 549,556 ****
     In a first step the callout server will check the sender and
     recipient information that was transmitted in the SMTP dialog; that
     information again maps to a policy that will either deny all messages
!    from that sender or to that recipient to be sent.  Or it checks the
!    body of the email and classifies it (maybe just be looking for some
     words in the subject or by doing in-depth content analysis), which
     can then also lead to the decision to deny the message.

- --- 565,572 ----
     In a first step the callout server will check the sender and
     recipient information that was transmitted in the SMTP dialog; that
     information again maps to a policy that will either deny all messages
!    from that sender or to that recipient.  Or it checks the
!    body of the email and classifies it (maybe just by looking for some
     words in the subject or by doing in-depth content analysis), which
     can then also lead to the decision to deny the message.

***************
*** 561,567 ****
  Internet-Draft             OPES SMTP Use Cases                 July 2005

!    This use case other than previous examples, wants to deny the email
     while the SMTP dialog is still active, i.e. before the OPES processor
     finally accepted the message.  Depending on the exact policy the
     error response should then be sent in reply to the MAIL FROM, RCPT TO
- --- 577,583 ----
  Internet-Draft             OPES SMTP Use Cases                 July 2005

!    Unlike previous examples, this use case wants to deny the email
     while the SMTP dialog is still active, i.e. before the OPES processor
     finally accepted the message.  Depending on the exact policy the
     error response should then be sent in reply to the MAIL FROM, RCPT TO

---

From: "Martin Stecher" <[email-masked]>
Date: Thu, 7 Jul 2005 21:37:44 +0200

> 
> what is the intended status of this document?

Informational