Network Working Group A. Barbir Internet-Draft Nortel Networks Expires: August 13, 2005 M. Stecher CyberGuard Corporation February 9, 2005 OPES SMTP Use Cases draft-ietf-opes-smtp-use-cases-00 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. 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 August 13, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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 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: 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 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). 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 recipient): o R: 220 mail.example.com 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 mail.example.com Hello [192.168.0.138] o S: MAIL FROM: steve@sender.com o R: 250 2.1.0 steve@sender.com....Sender OK o S: RCPT TO: paul@example.com o R: 250 2.1.5 paul@example.com o S: DATA o R: 354 Start mail input; end with "CRLF"."CRLF" o S: From: steve@sender.com o S: To: sandra@example.com o S: Subject: Test o S: o S: Hi, this is a test! o S: . o R: 250 2.6.0 "MAILYwekrt0Goqm4bVS00005b1f@mail.example.com" Queued mail for delivery o S: QUIT o R: 221 2.0.0 mail.example.com 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: steve@sender.com o To: sandra@example.com 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 "paul@example.com") which is different from the "sandra@example.com" 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 points: 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 peer. 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 dialog. 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 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. 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 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 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 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 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 HTTP. 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 expectations." 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 message. 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 point. 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, RCPTTO)) or (result = OPES_DATA(IP,HELO/ECHO,MAILFROM, RCPTTO, PAYLOAD)). 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 MTA) 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 TBD 8.2.2 Bypass considerations TBD 8.2.3 Notification considerations TBD 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 2001. [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 Canada Phone: +1 613 763 5229 Email: abbieb@nortelnetworks.com Martin Stecher CyberGuard Corporation Vattmannstr. 3 Paderborn, DE 33100 Germany Email: martin.stecher@webwasher.com 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 (Nokia) 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 http://www.ietf.org/ipr. 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 ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Barbir & Stecher Expires August 13, 2005 [Page 21]