Individual E. Burger Internet-Draft Brooktrout Technology, Inc. Expires: February 24, 2005 August 26, 2004 SMTP Service Extension for Detached Operation draft-burger-smtp-deta-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 February 24, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract The normal operation for the Simple Mail Transfer Protocol (SMTP) is for the submitting device to wait for all processing to complete and for the server to return a positive acknowledgement to the client. However, some devices have very intermittent connectivity, such as wireless mobile terminals. For such devices, a means to have processing continue in the case of a dropped connection is desirable. To this end, this SMTP service extension enables a client to submit a message and reliably detach from the session, indicating to the Burger Expires February 24, 2005 [Page 1] Internet-Draft SMTP DETA August 2004 server to continue in the absence of a connection to the client. Conventions used in this document RFC2119 [1] provides the interpretations for the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" found in this document. Table of Contents 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 2. Formal Description of the Extension . . . . . . . . . . . . . 3 2.1 Extension Definition . . . . . . . . . . . . . . . . . . . 3 2.2 Extension Operation . . . . . . . . . . . . . . . . . . . 4 2.2.1 Server Behavior . . . . . . . . . . . . . . . . . . . 4 2.2.2 Client Behavior . . . . . . . . . . . . . . . . . . . 4 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1 Detached Submit . . . . . . . . . . . . . . . . . . . . . 5 4.2 Piplined Submit . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 7 6.2 Informative References . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 9 Burger Expires February 24, 2005 [Page 2] Internet-Draft SMTP DETA August 2004 1. Introduction and Overview There is a class of SMTP [2] clients that have intermittent IP connectivity. This is a particular problem for devices that wish to submit objects that have a long processing time requirement at the server. For example, the object may have be physically large or have a large number of recipients, both of which may result in a relatively long processing time at the server. The RDLV [3] SMTP service extension provides a mechanism for servers to periodically inform a client that processing on a long delivery item is in progress. This mechanism periodically emits 120 responses to the client, to which the client issues the CONT verb to tell the server that the client is still alive and the server should continue processing the message. The Detached Operation SMTP service extension builds upon the RDLV mechanism, adding the DETA verb as an answer to the 120 response. When the server receives the DETA verb, it terminates the connection to the client yet continues processing the message. This enables the client to definitively know the server has begun working on the message. Likewise, it lets the server definitively know the client is aware the server is working on the message. Of course, the client will not know the immediate disposition of the message. In particular, the client will not know if the message submission succeeded. To address this problem, the server has to support the message disposition notification service extension [6]. If the client needs to know if the submission fails, the client asks for a DSN. The server issues a DSN in the event of submission failure, per the rules of RFC3464. 2. Formal Description of the Extension 2.1 Extension Definition 1. The text name of this SMTP service extension is DETA. 2. The EHLO keyword associated with this SMTP service extension is DETA. 3. The DETA keyword has no parameters. 4. This document defines a new SMTP verb, DETA. The DETA verb indicates that the server terminates the current session yet continues the in-process command execution. 5. Servers implementing the Detached Operation SMTP service extension MUST also support and advertise the following extensions in addition to other extensions in their EHLO response the RDLV [3] and DSN [4] service extensions. Burger Expires February 24, 2005 [Page 3] Internet-Draft SMTP DETA August 2004 6. This SMTP service extension does not introduce any new parameters to existing SMTP verbs. 2.2 Extension Operation 2.2.1 Server Behavior Servers implementing this specification MUST support the RDLV [3] and DSN [4] SMTP service extensions. Servers MUST advertise RDLV, DSN, and DETA in their EHLO response. Upon receiving a RDLV verb followed by another verb, the server MAY issue a 120 response, per RDLV [3]. Instead of receiving a CONT verb from the client, the server may receive a DETA verb from the client. In this case, the server MUST continue processing the request. In addition, the server MUST issue a 221 response and close the connection, as if it received a QUIT verb. DISCUSSION POINT: An alternative to having the server shut down the session is to let the session continue, so the client could do other SMTP stuff while the server processes the message. However, this raises a few problems. The biggest one is the slippery slope of clients wanting asynchronous notification of submission completion. If we can punt that issue, then I do not have a problem with allowing it. Input from server developers appreciated here. If the client requested a DSN, and the server is unable to complete processing the request, the server MUST issue a DSN following the procedures of RFC3461. 2.2.2 Client Behavior The client issues a RDLV verb before issuing the submission verb. This enables the server to return control to an in-process command to the client. The client then issues the submission verb. When the server responds with a 120 response after the timeout, the client MAY issue the DETA verb to instruct the server to continue processing and detach the session. The client SHOULD request a DSN so the user can know if the submission succeeded. The client MAY use command pipelining [5] if supported and advertised by the server. Burger Expires February 24, 2005 [Page 4] Internet-Draft SMTP DETA August 2004 3. IANA Considerations Please register the DETA service extension in the Simple Mail Transfer Protocol (SMTP) Service Extensions table as follows. Service Extension Keyword: DETA Description: Detached Operation Reference: RFCXXXX Extension Parameters: none 4. Examples These examples are informative in nature. For any discrepancies between behavior here and the normative behavior, the normative behavior is correct. 4.1 Detached Submit The client submits a message using BURL [7] and detaches from the session. Burger Expires February 24, 2005 [Page 5] Internet-Draft SMTP DETA August 2004 S: 220 example.net SMTP XYZ Ready C: EHLO example.com S: 250-example.net greets example.com S: 250-8BITMIME S: 250-BURL imap S: 250-RDLV mintimer=30 S: 250-DETA S: 250-DSN S: 250 HELP C: MAIL FROM: S: 250 OK C: RCPT TO: S: 250 OK C: RDLV maxtimer=30 S: 200 OK C: DATA S: 354 Start mail input; end with . C: [... lots and lots of data ...] C: . [about 30 seconds pass] S: 120 DATA processing in progress C: DETA S: 221 example.net Service closing transmission channel 4.2 Piplined Submit A client can pipeline the submission commands. Burger Expires February 24, 2005 [Page 6] Internet-Draft SMTP DETA August 2004 S: 220 example.net SMTP XYZ Ready C: EHLO example.com S: 250-example.net greets example.com S: 250-8BITMIME S: 250-PIPELINING S: 250-BURL imap S: 250-RDLV mintimer=30 S: 250-DSN S: 250 HELP C: MAIL FROM: RET=HDRS ENV=A123bzq C: RCPT TO: NOTIFY=FAILURE ORCPT=rfc822;jones@example.com C: RDLV maxtimer=30 C: BURL imap://handset@host.example.com/outbox ;uidvalidity=a9j230r932/;uid=32 ;authid=fred;urlauth=submit+handset :internal:91354a473744909de610943775f92038 LAST S: 250 sender OK S: 250 recipient OK S: 200 reliable delivery OK [about 30 seconds passes] S: 120 DATA processing in progress C: DETA S: 221 example.net Service closing transmission channel 5. Security Considerations Malicious clients can amplify server load by issuing a large number of detached requests. Servers SHOULD implement reasonable policies to limit the number of concurrent submissions on behalf of a given sender. 6. References 6.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [3] Burger, E., "SMTP Service Extension for Reliable Submission", August 2004. [4] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, Burger Expires February 24, 2005 [Page 7] Internet-Draft SMTP DETA August 2004 January 2003. [5] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, September 2000. 6.2 Informative References [6] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. [7] Newman, C., "Message Submission BURL Extension", Internet Draft draft-ietf-lemonade-burl-00.txt, July 2004. Author's Address Eric Burger Brooktrout Technology, Inc. 18 Keewaydin Dr. Salem, NH 03079 USA EMail: e.burger@ieee.org Burger Expires February 24, 2005 [Page 8] Internet-Draft SMTP DETA August 2004 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. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 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 (2004). 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. Burger Expires February 24, 2005 [Page 9] Internet-Draft SMTP DETA August 2004 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Burger Expires February 24, 2005 [Page 10]