Network Working Group A. Barbir Internet-Draft Nortel Networks Expires: July 13, 2005 M. Stecher CyberGuard Corporation January 12, 2005 OPES SMTP Use Cases draft-ietf-opes-smtp-use-cases-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. 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 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 13, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document describes OPES SMTP use cases and deployment scenarios. Barbir & Stecher Expires July 13, 2005 [Page 1] Internet-Draft OPES SMTP Use Cases January 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Breif overview of SMTP Architecture . . . . . . . . . . . . . 5 4. OPES SMTP deployment scenarios . . . . . . . . . . . . . . . . 7 5. OPES SMTP based services . . . . . . . . . . . . . . . . . . . 8 6. Mail sender and recipients . . . . . . . . . . . . . . . . . . 10 7. Types of SMTP bases OPES services . . . . . . . . . . . . . . 11 7.1 Services that exclusively act on the mail message content . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.2 Services that log or modify SMTP commands/replies . . . . 11 7.3 Services that trigger side effects on the mail delivery . 12 8. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 13 8.1 Tracing considerations . . . . . . . . . . . . . . . . . . 13 8.2 Bypass considerations . . . . . . . . . . . . . . . . . . 13 8.3 Notification considerations . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 11.2 Informative References . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19 Barbir & Stecher Expires July 13, 2005 [Page 2] Internet-Draft OPES SMTP Use Cases January 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. RFC 3752 describes use cases for Open Puggable Edge Services (OPES) with a focus on HTTP messages. This work focus on OPES for SMTP use cases, whereby, additional use caseses and enhancements to the types of OPES services defined in RFC 3752 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). The document is organized as follows: Section 2 discusses the various types of SMTP based OPES services. Section 3 introduces SMTP OPES deployment scenarios. Section 4 discusses failure cases and service notification. Section 5 discusses security considerations. Barbir & Stecher Expires July 13, 2005 [Page 3] Internet-Draft OPES SMTP Use Cases January 2005 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [5]. 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 July 13, 2005 [Page 4] Internet-Draft OPES SMTP Use Cases January 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 relayed. 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: o Mail User Agent (MUA): This is the client program in which the user sends and receives mail. o 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. o Mail Submission Agent (MSA): This is the component of an MTA which accepts new mail messages from an MUA, using SMTP. o 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 July 13, 2005 [Page 5] Internet-Draft OPES SMTP Use Cases January 2005 MTA. 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). Barbir & Stecher Expires July 13, 2005 [Page 6] Internet-Draft OPES SMTP Use Cases January 2005 4. OPES SMTP deployment scenarios This section discusses OPES SMTP depolyment scenarios (eg. how it relates to administrative domains, trust issues etc.) Barbir & Stecher Expires July 13, 2005 [Page 7] Internet-Draft OPES SMTP Use Cases January 2005 5. OPES SMTP based services RFC 3752 provided on overview of OPES HTTP based services. From RFC 3752, in Figure 2, 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 2: Service Activation Points In contrast to the four different service activation points that have been defined above an OPES SMTP MTA only 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 3. +----------------------------------------------+ | +-------------+-------------+ | | | Service Application | | | +---------------------------+ | SMTP | Data Dispatcher | SMTP dialog when +---------------------------+ dialog when Receiving Mails | SMTP | Sending Mails ============1=> +---------------------------+ ==2==========> | OPES Processor | +----------------------------------------------+ Figure 3: 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 Barbir & Stecher Expires July 13, 2005 [Page 8] Internet-Draft OPES SMTP Use Cases January 2005 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 July 13, 2005 [Page 9] Internet-Draft OPES SMTP Use Cases January 2005 6. 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. Barbir & Stecher Expires July 13, 2005 [Page 10] Internet-Draft OPES SMTP Use Cases January 2005 7. Types of SMTP bases OPES services There are three types of OPES services for SMTP. 7.1 Services that exclusively act on the mail message content 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 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 HTTP: 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. 7.2 Services that log or modify SMTP commands/replies 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 TO" 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 July 13, 2005 [Page 11] Internet-Draft OPES SMTP Use Cases January 2005 "HELO" command. 7.3 Services that trigger side effects on the mail delivery 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 condition 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 - Additional notification messages (e.g. virus alerts) Barbir & Stecher Expires July 13, 2005 [Page 12] Internet-Draft OPES SMTP Use Cases January 2005 8. IAB Considerations This section TBD 8.1 Tracing considerations TBD 8.2 Bypass considerations TBD 8.3 Notification considerations TBD Barbir & Stecher Expires July 13, 2005 [Page 13] Internet-Draft OPES SMTP Use Cases January 2005 9. Security Considerations This section TBD Barbir & Stecher Expires July 13, 2005 [Page 14] Internet-Draft OPES SMTP Use Cases January 2005 10. IANA Considerations This section TBD Barbir & Stecher Expires July 13, 2005 [Page 15] Internet-Draft OPES SMTP Use Cases January 2005 11. References 11.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] Barbir et. al, A., "Security Threats and Risks for OPES", RFC 3837, August 2004. [4] Barbir et. al, A., "Security Threats and Risks for OPES", RFC 3752, April 2004. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 11.2 Informative References [6] 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 3198, November 2001. [7] 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. Authors' Addresses Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb(_at_)nortelnetworks(_dot_)com Barbir & Stecher Expires July 13, 2005 [Page 16] Internet-Draft OPES SMTP Use Cases January 2005 Martin Stecher CyberGuard Corporation Vattmannstr. 3 Paderborn, DE 33100 Germany EMail: martin(_dot_)stecher(_at_)webwasher(_dot_)com Barbir & Stecher Expires July 13, 2005 [Page 17] Internet-Draft OPES SMTP Use Cases January 2005 Appendix A. Acknowledgements Many thanks to Andreas Terzis, L. Rafalow (IBM), L. Yang (Intel), M. Condry (Intel), Randy Presuhn (Mindspring) and B. Srinivas (Nokia) Barbir & Stecher Expires July 13, 2005 [Page 18] Internet-Draft OPES SMTP Use Cases January 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2005). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Barbir & Stecher Expires July 13, 2005 [Page 19] Internet-Draft OPES SMTP Use Cases January 2005 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Barbir & Stecher Expires July 13, 2005 [Page 20]