Network Working Group                                          A. Barbir
Internet-Draft                                           Nortel Networks
Expires: August 13, 2005                                      M. Stecher
                                                  CyberGuard Corporation
                                                        February 9, 2005

                          OPES SMTP Use Cases

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 13, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   This document describes OPES SMTP use cases and deployment scenarios.

Barbir & Stecher         Expires August 13, 2005                [Page 1]

Internet-Draft             OPES SMTP Use Cases             February 2005

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Breif overview of SMTP Architecture  . . . . . . . . . . . . .  5
     3.1   Operation Flow of an OPES SMTP System  . . . . . . . . . .  6
       3.1.1   OPES SMTP Example  . . . . . . . . . . . . . . . . . .  7
   4.  OPES SMTP based services . . . . . . . . . . . . . . . . . . .  9
   5.  Mail sender and recipients . . . . . . . . . . . . . . . . . . 12
   6.  Examples of SMTP bases OPES services . . . . . . . . . . . . . 13
     6.1   SMTP command modification  . . . . . . . . . . . . . . . . 13
     6.2   SMTP command satisfaction  . . . . . . . . . . . . . . . . 13
     6.3   OPES mail delivery side effects  . . . . . . . . . . . . . 14
   7.  Mail List Tracker  . . . . . . . . . . . . . . . . . . . . . . 15
   8.  Future Sections  . . . . . . . . . . . . . . . . . . . . . . . 17
     8.1   OPES SMTP deployment scenarios . . . . . . . . . . . . . . 17
     8.2   IAB Considerations . . . . . . . . . . . . . . . . . . . . 17
       8.2.1   Tracing considerations . . . . . . . . . . . . . . . . 17
       8.2.2   Bypass  considerations . . . . . . . . . . . . . . . . 17
       8.2.3   Notification  considerations . . . . . . . . . . . . . 17
     8.3   Security Considerations  . . . . . . . . . . . . . . . . . 17
     8.4   IANA Considerations  . . . . . . . . . . . . . . . . . . . 17
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     9.1   Normative References . . . . . . . . . . . . . . . . . . . 18
     9.2   Informative References . . . . . . . . . . . . . . . . . . 18
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
   A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
       Intellectual Property and Copyright Statements . . . . . . . . 21

Barbir & Stecher         Expires August 13, 2005                [Page 2]

Internet-Draft             OPES SMTP Use Cases             February 2005

1.  Introduction

   The Open Pluggable Edge Services (OPES)[1] architecture enables
   cooperative application services (OPES services) between a data
   provider, a data consumer, and zero or more OPES processors.  The
   application services under consideration analyze and possibly
   transform application-level messages exchanged between the data
   provider and the data  consumer.  The OPES processor can distribute
   the responsibility of service execution by communicating and
   collaborating with one or more remote callout servers.

   The execution of such services is governed by a set of rules
   installed on OPES processor.  The rule evaluation can trigger the
   execution of service applications local to the OPES processor or on a
   remote callout server.

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

   In SMTP the OPES processor may be any agent participate in SMTP
   exchanges, 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
   systems either operate at SMTP time or they operate on messages after
   reception either on the MTA's queue or by being handed from the MTA
   to a mail filter and back again.

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

   The document is organized as follows: TBD.

Barbir & Stecher         Expires August 13, 2005                [Page 3]

Internet-Draft             OPES SMTP Use Cases             February 2005

2.  Terminology

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [7].  When used with
   the normative meanings, these keywords will be all uppercase.
   Occurrences of these words in lowercase comprise normal prose usage,
   with no normative implications.

Barbir & Stecher         Expires August 13, 2005                [Page 4]

Internet-Draft             OPES SMTP Use Cases             February 2005

3.  Breif overview of SMTP Architecture

   In RFC 282, the SMTP design is given in  Figure 1.  In the figure,
   When an SMTP client has a message to transmit, it establishes a two-
   way transmission channel to an SMTP server.  The responsibility of an
   SMTP client is to transfer mail messages to one or more SMTP servers,
   or report its failure to do so.

                  +----------+                +----------+
      +------+    |          |                |          |
      | User |<-->|          |      SMTP      |          |
      +------+    |  Client  |Commands/Replies| Server   |
      +------+    |   SMTP   |<-------------->|  SMTP    |    +------+
      | File |<-->|          |    and Mail    |          |<-->| File |
      |System|    |          |                |          |    |System|
      +------+    +----------+                +----------+    +------+
                   SMTP client                SMTP server

                         Figure 1: SMTP Design

   In some cases, the domain name(s) transferred to, or determined by,
   an SMTP client will identify the final destination(s) of the mail
   message.  In other cases, the domain name determined will identify an
   intermediate destination through which all mail messages are to be

   An SMTP server may be either the ultimate destination or an
   intermediate "relay" or "gateway" (that is, it may transport the
   message further using some protocol other than SMTP).  SMTP commands
   are generated by the SMTP client and sent to the SMTP server.  SMTP
   replies are sent from the SMTP server to the SMTP client in response
   to the commands.  SMTP message transfer can occur in a single
   connection between the original SMTP-sender and the final
   SMTP-recipient, or can occur in a series of hops through intermediary
   systems.  SMTP clients and servesr exchange commands and replies and
   eventually the mail message body.

   The most important logical elements of the Internet mail system are:
   1.  Mail User Agent (MUA): This is the client program in which the
       user sends and receives mail.
   2.  Mail Transfer Agent (MTA): A program which enables email
       transfers from one machine to another.  MTAs do not deliver mail
       themselves.  MTAs call a Mail Delivery Agent to physically
       transport the messages.
   3.  Mail Submission Agent (MSA): This is the component of an MTA
       which accepts new mail messages from an MUA, using SMTP.
   4.  Mail Delivery Agent (MDA): A program used by the  MTA to deliver
       messages into a user's mailbox or to transport mail to another

Barbir & Stecher         Expires August 13, 2005                [Page 5]

Internet-Draft             OPES SMTP Use Cases             February 2005


   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

   In this work an MTA is the OPES processor device that sits in the
   data stream of the SMTP protocol.  The OPES processor gets enhanced
   by an OCP client that allows it to vector out data to the callout
   server.  The filtering functionality is on the callout server.

   A client (a mail user) starts with an email client program (MUA).
   The user sends email to an outgoing email server.  In the email
   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
   server of the recipient or may use other intermediate email gateways.
   The sending email server, the destination email server and all
   intermediate gateways MTAs communicate using SMTP.

   In the destination email server a mail delivery agent (MDA) may
   deliver the email to the recipient's mailbox.  The email client
   program of the recipient might use a different protocol (such as POP3
   or IMAP) to access the mailbox and retrieve/read the messages.

Barbir & Stecher         Expires August 13, 2005                [Page 6]

Internet-Draft             OPES SMTP Use Cases             February 2005

   +-------+  +---------+      +---------+      +--------+  +-------+
   |mail  M|  |M mail  M| SMTP |M mail  M| SMTP |M mail M|  |M mail |
   |clnt  U|--|S srvr  T|------|T g-way T|------|T srvr D|--|U clnt |
   |      A|  |A       A|      |A        A|     |A      A|  |A      |
   +-------+  +---------+      +---------+      +--------+  +-------+
                   |                |                |
                   | OCP            | OCP            | OCP
                   |                |                |
              +----------+     +-----------+     +----------+
              |  callout |     |  callout  |     |  callout |
              |  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
   belongs to which authoritative domain is an important question but
   different from deployment to deployment).

3.1.1  OPES SMTP Example

   A typical (minimum) SMTP dialog between two OPES SMTP processors
   (MTA) will consist of the following (S: means sender, R: means
   o  R: 220 Sample ESMTP MAIL Service, Version:
      5.0.2195.6713 ready at  Thu, 20 Jan 2005 11:24:40 +0100
   o  S: HELO ThatsMe
   o  R: 250 Hello []
   o  S: MAIL FROM:
   o  R: 250 2.1.0 OK
   o  S: RCPT TO:
   o  R: 250 2.1.5
   o  S: DATA
   o  R: 354 Start mail input; end with "CRLF"."CRLF"
   o  S: From:
   o  S: To:
   o  S: Subject: Test
   o  S:
   o  S: Hi, this is a test!
   o  S: .
   o  R: 250 2.6.0 "" Queued
      mail for delivery
   o  S: QUIT
   o  R: 221 2.0.0 Service closing transmission channel

Barbir & Stecher         Expires August 13, 2005                [Page 7]

Internet-Draft             OPES SMTP Use Cases             February 2005

   The sender is generating commands and the recipient is generating
   replies.  All Replies start with a status code and then some text.
   At minimum 4 commands are needed to send an email.  All commands and
   replies to send a single email message together form "the dialog".
   The mail message body is the data sent after the "DATA" command.  To
   an OPES processor it can be seen as command modification.

   If a callout service wants to adapt the email message body, it is
   mainly interested in this part of the dialog:
   o  From:
   o  To:
   o  Subject: Test
   o  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 "") which is
   different from the "" that the email client
   displays in the visible "To" field.  That might be an important fact
   for some filters such as Spam Filters.

Barbir & Stecher         Expires August 13, 2005                [Page 8]

Internet-Draft             OPES SMTP Use Cases             February 2005

4.  OPES SMTP based services

   RFC 3752 [4] provided on overview of OPES HTTP based services.  From
   RFC 3752, in  Figure 3, four service activation points for an OPES
   processor are depicted.  The data dispatcher examines OPES rules,
   enforces policies, and invokes service applications (if applicable)
   at each service activation point.

              |         +-------------+-------------+          |
              |         |   Service Application     |          |
              |         +---------------------------+          |
         Responses      |       Data Dispatcher     |     Responses
       <============4== +---------------------------+ <=3===========
         Requests       |           HTTP            |      Requests
       =============1=> +---------------------------+ ==2==========>
              |                  OPES Processor                |

                  Figure 3: Service Activation Points

   For SMTP OPES based services.  There are four theoretical activation
   1.  Receiving email: Perform an SMTP dialog with the peer MTA,
       receiving email from it, usually storing the emails in a queue
       and maybe sending them on later.
   2.  Stored email in queue: Operate on an email that has been received
       earlier.  At this stage there is no current SMTP dialog with the
   3.  Sending email: Perform an SMTP dialog with the peer MTA by
       sending email to it.
   4.  Proxy (receive and forward): Having two SMTP dialogs at the same
       time (mostly forwarding commands and replies).

   In addition an OPES MTA can have the following modes of operations:
      A: SMTP command modification:  Here, SMTP commands are sent to the
      callout server to be modified.
      B: SMTP command satisfaction: Here, the callout server responds
      back with a SMTP reply (usually an error message).
      C: SMTP reply modification: The SMTP reply is modified by the
      callout server
      D: Email message body modification

   Activation point 2 involves operating on stored emails.  It only

Barbir & Stecher         Expires August 13, 2005                [Page 9]

Internet-Draft             OPES SMTP Use Cases             February 2005

   operates on the message body as there is no SMTP dialog going on.
   Certainly an implementation can use an OCP client and pretend that
   there is an SMTP dialog in order to get a callout server to work on a
   stored email.  This has more to do with a MIME profile for OCP rather
   than with an SMTP profile.  Hence, the more natural profile for this
   option is an OCP/MIME as opposed to OCP/SMTP profile.

   Some discussions on the mailing list did not see a use case for this
   activation point.  However, most use cases listed so far do either
   work at activation points 1 or 3.  There might even be specific
   callout services that make much more sense when sending the email
   (for example: add footer to the email that contains a current time
   stamp, when a condition is satisfied, such as a stock price etc.).
   Or there may be a corporate email gateway that uses SMTP outbound and
   wants to do filtering there but emails are not delivered to that
   device via SMTP but some other mail protocol, so that there is no
   activation point 1 in the authoritative domain.Activation point 4
   involves a proxy like functionality of the MTA.  A sender MTA does a
   dialog with the proxy and the proxy is doing a dialog with another
   MTA at the same time.  Forwarding the RCPT command to the next MTA
   and sending back the response.  This scenario involves response
   modification, for example, if the next MTA returns an error (such as
   address unknown).  The response could be "modified", if the proxy
   selects another address and tries that one again in a RCPT command to
   the next proxy.  On success it sends back the positive response.  The
   callout server is determining the other address, maybe even other
   next MTA.  So it tells the proxy MTA to send another command to the
   same or a different next MTA.

   Editor Note: Current discussions on the list have not nailed down the
   relationship of this activation point to current accepted SMTP
   deployments.  As such, the current version of the work will not
   support it.

   Regarding modes of operation, option C SMTP reply modification
   applies to scenarios that involve logging services and can be used in
   activation point 4, when commands and replies are proxied.  Option D,
   can be seen as command modification and is basically covered in
   option A.

   In this work, an OPES SMTP MTA acts on two activation points within
   the MTA: Receiving and sending mail messages using SMTP.  When
   receiving a mail message, the MTA is acting as a SMTP server and when
   sending a message it is acting as a SMTP client.  This situation is
   depiiected in Figure 4.

Barbir & Stecher         Expires August 13, 2005               [Page 10]

Internet-Draft             OPES SMTP Use Cases             February 2005

                 |         +-------------+-------------+        |
                 |         |   Service Application     |        |
                 |         +---------------------------+        |
                SMTP       |       Data Dispatcher     |       SMTP
            dialog when    +---------------------------+   dialog when
           Receiving Mails |           SMTP            |  Sending Mails
           ============1=> +---------------------------+  ==2==========>
                 |                  OPES Processor              |

             Figure 4: OPES SMTP Service Activation Points

   While we could see the SMTP commands and replies analogously to the
   HTTP requests and responses  and by that getting to the same four
   service activation points as in RFC 3752, it is important to handle
   the command and reply dialog that is necessary to transfer a mail
   message as a unit within the OPES context and not as individual and
   independend messages as HTTP messages are.  One reason for this is
   that a service that runs on mail message content (i.e.  the data
   transferred with a DATA command) may need to know the content of the
   previous MAIL FROM and RCPT TO commands of the same dialog in order
   to know the "real" recipients of the mail message and not to rely on
   the information given in the mail message header (which is part of
   the data in the DATA command).

   Still there are usecases in which callout services want to adapt
   single commands of the SMTP dialog so that we cannot restrict
   OPES/SMTP to only handle the mail message content with some meta
   information from the SMTP dialog and reduce the possible callout
   protocol to a single request to the callout server and a single
   response; OPES for SMTP means to find a callout protocol equation to
   the SMTP dialog happening between SMTP client and server.

Barbir & Stecher         Expires August 13, 2005               [Page 11]

Internet-Draft             OPES SMTP Use Cases             February 2005

5.  Mail sender and recipients

   OPES/HTTP only deals with a single client and single server between
   which the HTTP message is exchanged.  (In addition an OPES processor
   may include a concept for OPES message caching for which it needs to
   decide whether a response of the callout server for a special HTTP
   message remains unchanged if the request is repeated for a different
   user and/or a different time).  In SMTP a mail message is originating
   from a single sender but may be sent to multiple recipients.  Message
   adaptation of a mail message may produce different results for the
   different recipients.  OPES/SMTP has to anticipate this.

   The commands and replies in the SMTP dialog are always just between
   each hop.  In SMTP a mail message is originating from a single sender
   but may be sent to multiple recipients.  Message adaptation of a mail
   message may produce different results for the different recipients.
   While we see the need to involve the callout server on a per-command
   basis, the commands and replies of one dialog belong together and
   services may have the need to refer to earlier commands of the same

Barbir & Stecher         Expires August 13, 2005               [Page 12]

Internet-Draft             OPES SMTP Use Cases             February 2005

6.  Examples of SMTP bases OPES services

   This section provides some examples of OPES based services.

6.1  SMTP command modification

   Use cases of this type are very similar to the services listed in
   section 2.2 of RFC 3752 "Services performed on (HTTP) responses".
   They may or may not modify the an SMTP message content:
   o  Content adaptation: Changing the mail message content within a
      callout server to transcode it into a format appropriate for the
      device that will receive the mail message
   o  Language translation of the content
   o  Logging, monitoring and accounting as the known examples for
      services that do not intend to modify the message content

   In addition there are more services acting on message content that
   may  even be more typical for SMTP while they could also be used for
   o  Virus scanning (replacing infected attachments of a mail message)
   o  Applying other security policies such as stripping of unwanted
      MIME sections (forbidden attachment types)
   o  Spam filtering (mark a message if it supposed to contain spam)
   o  Encrypt mail message
   o  Verify mail signatures
   o  Verify message format (e.g.  correct illegal MIME formats)
   o  Convert attachments into HTTP links (stripping large attachments
      from emails, putting them on a web server and replace the
      attachment with a URL to that server.

   The example of the Spam filter is typical for a service which may
   need data of other SMTP commands of the mail dialog in order to
   provide an accurate rating.

6.2  SMTP command satisfaction

   o  Logging or validating "MAIL FROM": These may services which intend
      or not intend to change the command or reply to this command.  A
      callout service may just log the information (not change
      something), it may change the command by rewriting the mail sender
      or it may change/determine the reply by denying a sender address
      that could not be validated.
   o  Similar use cases acting on other single commands such as "RCPT
   o  Services may also need to get access to data of previous SMTP
      commands, for example a service acting on "RCPT TO" may want to
      know about the data that has been sent with the "MAIL FROM" and/or

Barbir & Stecher         Expires August 13, 2005               [Page 13]

Internet-Draft             OPES SMTP Use Cases             February 2005

      "HELO" command.

6.3  OPES mail delivery side effects

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

   o  Reject a message whose content violates a possible trigger
   o  Delay a message, put it in a special queue for further processing
      or reroute it to other recipients.
   o  Out of office replies
   o  Generate additional notification messages (e.g.  virus alerts)

   There is a number of side effects that a callout service may want to
   trigger that influences the next steps within the email server or
   gateway.  Not all of that is a pure MTA role but typical things that
   an email intermediary can do, for example:
   1.  Delay the email, don't forward immediately
   2.  Send an additional notification
   3.  Exchange the recipients
   4.  Don't forward but store email in quarantine
   5.  Use another next hop MTA (routing)

   None of the above can be done by only modifying the email message
   body.  For example, sending an additional notification can be
   achieved by generating another OCP response.  Similarly, exchanging
   recipients can be achieved by exchanging the RCPT command value (but
   that command has been handled already before; how to get back?).

   Editor Note: Do we need some negotiations between OPES processor and
   callout servers about which side effects are allowed/supported and a
   way to trigger them through special parameters in the OCP response.

Barbir & Stecher         Expires August 13, 2005               [Page 14]

Internet-Draft             OPES SMTP Use Cases             February 2005

7.  Mail List Tracker

   This section is a place holder for some important discussion points
   from the list that we need to decide on as the draft progress.

   1.  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.  This call-forward function could perhaps be
        implemented in the OPES service application.
   2.  OPES is supposed to enable new services.  The call-forward
        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
   3.  Every request satisfaction could also be implemented as a
        response modification by ignoring the original response.
   4.  The expectation of deliver or the reasons for rejection is
        naturally expected by the user.  This is legal precedence for
        this covered by provisions in US ECPA governing "user
   5.  Look at legal conflict with US EPCA 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.
   6.  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
   7.  If an OPES service is applied 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.
   8.  Responce Modification: Need to discuss how to cover it with
        activation points.  Take a closer look at Proxied activation
   9.  Above is dependent on the OPES device and its required input
        process parameters.  In some cases only transport information is
        required: (e.g.  result = OPES_RCPT (IP, HELO/ECHO, MAILFROM,
   10.  Is it worthwhile noting a particular kind of non-symmetry that
        is common today.  Most people run SMTP on their local machine in
        order to send messages, but they do not run SMTP to receive
        messages; that is done by a remote server, and the user runs a
        different protocol (a Mail Retrieval Client?) to fetch the mail.
        That means that and OPES server that is closest to the user will

Barbir & Stecher         Expires August 13, 2005               [Page 15]

Internet-Draft             OPES SMTP Use Cases             February 2005

        probably be acting as an SMTP relay, while that same server will
        be an SMTP endpoint for messages destined to that user.
   11.  OPES MTA cascade on the mail path, as such the end to end
        finishes at the last MTA.
   12.  All use cases deal with SMTP commands.  Need to document exactly
        what we mean by the value of a DATA command.
   13.  Revisit how queues are maintained (callout server versus OPES
   14.  Timeout Prevention: Use of: 1yz Positive Preliminary reply
   15.  Do we need for the OPES specifications to provide an 2821 Update
        provision to make timeouts work.

Barbir & Stecher         Expires August 13, 2005               [Page 16]

Internet-Draft             OPES SMTP Use Cases             February 2005

8.  Future Sections

8.1  OPES SMTP deployment scenarios

   This section discusses OPES SMTP depolyment scenarios (eg.  how it
   relates to administrative domains, trust issues etc.)

8.2  IAB Considerations

   This section TBD

8.2.1  Tracing considerations


8.2.2  Bypass  considerations


8.2.3  Notification  considerations


8.3  Security Considerations

   This section TBD

8.4  IANA Considerations

   This section TBD

Barbir & Stecher         Expires August 13, 2005               [Page 17]

Internet-Draft             OPES SMTP Use Cases             February 2005

9.  References

9.1  Normative References

   [1]  A. Barbir et. al, "An Architecture for Open Pluggable Edge
        Services (OPES)", RFC 3835, August  2004.

   [2]  Floyd, S. and L. Daigle, "IAB Architectural and Policy
        Considerations for Open Pluggable Edge Services", RFC 3238,
        January 2002.

   [3]  A. Barbir et. al, "Security Threats and Risks for OPES",
        RFC 3837, August  2004.

   [4]  A. Barbir et. al, "Open Pluggable Edge Services (OPES) Use Cases
        and Deployment Scenarios", RFC 3752, April  2004.

   [5]  A. Rousskov et. al, "HTTP adaptation with OPES",
        draft-ietf-opes-http-02 , January  2004.

   [6]  Rousskov , A., "OPES Callout Protocol Core",
        draft-ietf-opes-ocp-core-05 , May 2004.

   [7]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, March   1997.

9.2  Informative References

   [8]   Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
         Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
         Waldbusser, "Terminology for Policy-Based Management",
         RFC 2821, November 2001.

   [9]   Klensin, J., "Simple Mail Transfer Protocol", RFC 3198, April

   [10]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
         Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
         HTTP/1.1", RFC 2616, June 1999.

Barbir & Stecher         Expires August 13, 2005               [Page 18]

Internet-Draft             OPES SMTP Use Cases             February 2005

Authors' Addresses

   Abbie Barbir
   Nortel Networks
   3500 Carling Avenue
   Nepean, Ontario  K2H 8E9

   Phone: +1 613 763 5229

   Martin Stecher
   CyberGuard Corporation
   Vattmannstr. 3
   Paderborn, DE  33100


Barbir & Stecher         Expires August 13, 2005               [Page 19]

Internet-Draft             OPES SMTP Use Cases             February 2005

Appendix A.  Acknowledgements

   Many thanks to Andreas Terzis, L.  Rafalow (IBM), L.  Yang (Intel),
   M.  Condry (Intel), Randy Presuhn (Mindspring) and B.  Srinivas

Barbir & Stecher         Expires August 13, 2005               [Page 20]

Internet-Draft             OPES SMTP Use Cases             February 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Barbir & Stecher         Expires August 13, 2005               [Page 21]