Internet Draft Dan Wing August 26, 1997 Neil Joffe Expires February 1998 Cisco Systems, Inc. Larry Masinter Xerox Corporation Immediate Delivery over SMTP draft-wing-smtp-session-00.txt Status of this memo This document is an Internet-Draft. 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 1. Abstract This memo defines an extension to SMTP [RFC821] which provides a mechanism for immediate message delivery over ESMTP, bypassing SMTP's normal store-and-forward behavior. 2. Introduction Historically, SMTP [RFC821, RFC822] and [SMTP-EXT] have been used for store and forward delivery of messages. This draft defines a new transport mode for ESMTP delivery known as SESSION. When SESSION is used, the ESMTP server delivers the message before the ESMTP client disconnects from it. This feature allows for 'priority' delivery of mail if all MTAs in the SMTP "path" support SESSION delivery. If any MTA does not support SESSION, automatic fallback to normal store and forward delivery occurs. Wing, Joffe, Masinter Expires February 1998 [Page 1] Internet Draft Immediate Delivery over ESMTP August 1997 Such priority delivery may be useful in certain business environments, or to more closely emulate behavior of other office equipment (such as fax machines). This memo uses the mechanism described in [SMTP-EXT] to define an extension to the SMTP protocol for immediate delivery. 2.1. Discussion of this draft This draft is being discussed on the "ietf-fax" mailing list. To subscribe, send a message to: ietf-fax-request@imc.org with the line: subscribe in the body of the message. Archives are available from http://www.imc.org/ietf-fax. 2.2. Requirements notation This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of these terms appears in [REQ]. 3. Framework for immediate delivery support The immediate message delivery is defined as follows: (1) The name of the immediate extension is Session; (2) the EHLO keyword value associated with the immediate extension is SESSION; (3) no parameter is used with the SESSION EHLO keyword; (4) one new SMTP verb, STAT, (used to query the status of each Session recipient), is defined with this extension, and is described in section 4; (5) one optional parameter is added to the RCPT command, using the esmtp-keyword SESSION, and is described in section 4, no parameters are added to the MAIL FROM command; (6) the esmtp-keyword SESSION changes the meaning of the terminating Wing, Joffe, Masinter Expires February 1998 [Page 2] Internet Draft Immediate Delivery over ESMTP August 1997 "." as described in section 4.2; (7) the maximum length of a RCPT TO is increased by 8 characters. 4. Behavior of RCPT TO: SESSION A RCPT command issued by a client may also contain the esmtp-keyword SESSION. This keyword causes the ESMTP server to attempt immediate delivery of the message to the local user, or immediate connection with the next MTA in the ESMTP path. The ESMTP server SHOULD only respond after it has successfully connected to the next MTA in the ESMTP path and received the remote ESMTP server's response to the RCPT command. 4.1. Response to esmtp-keyword SESSION Upon receiving a RCPT command with the esmtp-keyword SESSION, an ESMTP server MUST respond with a 250 only if: a) the SMTP server is able to connect to the "next hop" in the SMTP "path" and after it has received a 250 reply to its RCPT command (with the esmtp-keyword SESSION) with that "next hop" ESMTP server, or b) the SMTP server is delivering to a local user's mailbox. If SESSION isn't available for this recipient and the recipient is valid in all other respects, then the ESMTP server MUST respond with 251 and deliver the message using normal store-and-forward. The ESMTP server returns 450 if SESSION mode isn't available due to resource constraints. The ESMTP client may attempt to send the message without Session in this transaction, or the ESMTP client may retry sending the message with Session as a new transaction later. 4.2. Meaning of "250" reply to terminating "." with SESSION The ESMTP server's response to the end of mail data indication ("." or BDAT LAST if using [CHUNKING]) only indicates successful receipt of the mail data -- as with [RFC821] the data could still be spooling to the recipient(s). However, with SESSION, the ESMTP client MUST use the STAT verb to determine the success (or failure) of the delivery to each of the forward-path(s) that used the esmtp-keyword SESSION. If the ESMTP server has responded with a "250" reply to the end of mail data indication, but has not successfully completed delivery before the Wing, Joffe, Masinter Expires February 1998 [Page 3] Internet Draft Immediate Delivery over ESMTP August 1997 ESMTP client disconnects from the ESMTP server (either by a QUIT command or a TCP FIN or RST), the ESMTP server SHOULD attempt to continue deliverying the message(s). 4.3. SESSION-only ESMTP servers that cannot relay mail A legacy SMTP client (which doesn't support SESSION) may connect to an ESMTP server that only supports SESSION and cannot relay mail (such as a printer or fax machine). As the ESMTP client isn't SESSION aware and won't send STAT commands for each recipient, the ESMTP server cannot indicate which of several recipients has succeeded or failed. Thus, only one recipient is permitted. If a SESSION-only ESMTP server receives a RCPT TO without the esmtp-keyword SESSION, the ESMTP server MUST: (1) allow only one valid forward-path, as there is no way to indicate delivery success/failure to multiple recipients. If the SMTP client sends more than one valid forward-path in a single SMTP transaction, the ESMTP server should reject them with a "421" response. (2) only respond to the terminating "." after the message has been successfully or unsuccessfully received by the recipient. 4.4. Behavior of esmtp-keyword SESSION with DSN If an ESMTP server supports Delivery Status Notification [DSN] and SESSION, and a RCPT command contains both SESSION and a DSN request for either SUCCESS or FAILURE, then one of the following scenerios is possible: (1) SESSION is successful, in which case a DSN MUST NOT be generated; (2) SESSION is unsuccessful, and fallback to store and forward occurred, then the DSN MUST be handled normally (by requesting DSN from the remote MTA); (3) SESSION is unsuccessful, and fallback to store and forward did not occur, and the ESMTP client is informed (in a reply to a STAT command) that fallback to store and forward did not occur, a DSN MUST NOT be generated; (4) SESSION is unsuccessful, and fallback to store and forward did not occur, and the ESMTP client is not informed (in a reply to a STAT command, perhaps due to the ESMTP client disconnecting Wing, Joffe, Masinter Expires February 1998 [Page 4] Internet Draft Immediate Delivery over ESMTP August 1997 or improperly sending a QUIT command), a DSN MUST be generated by this MTA. 5. New SMTP verb STAT One new SMTP verb is introduced with the Session extension. The STAT verb allows a client to query the success, failure, and progress of message transmission to any Session mode recipient. 5.1. Usage and syntax of STAT verb The STAT verb MUST be used by the ESMTP client to determine the success or failure of a RCPT command that included the esmtp-keyword SESSION. An ESMTP client MUST NOT send a "STAT " command unless both of the following conditions are true: 1. the RCPT command for that forward-path included the esmtp-keyword SESSION, and 2. the ESMTP server responded to that forward-path with a 2xx (success) reply code. If the ESMTP client violates one of the above restrictions, the ESMTP server SHOULD respond with a 501 error code. The syntax of the STAT verb, using the format described in [ABNF], is: stat-cmd = "STAT" SP CR LF 5.2. Server reply to STAT The ESMTP server's reply to STAT must be parsable by the ESMTP client for possible presentation to the user via a progress indicator. The replies must adhere to the following [ABNF] format: stat-int-rsp = rsp-code SP [status-code SP] SP cmpl-seconds ";" total-bytes ";" bytes-sent ";" pages-sent [SP 1*text] rsp-code = "250" / "251" / "550" / "450" cmpl-seconds = 1*DIGIT ; estimated seconds to complete, ; 0=completed or fallback occurred total-bytes = 1*DIGIT Wing, Joffe, Masinter Expires February 1998 [Page 5] Internet Draft Immediate Delivery over ESMTP August 1997 bytes-sent = 1*DIGIT pages-sent = 1*DIGIT ; pages sent. If this is not a ; printable document (where pages ; make sense), the value MUST be 0. text = status-code = <`status-code' from section 4 of [ENH-RET]> If the ESMTP server has completed mail data transfer (either successfully or unsucessfully), is zero. In no other cases shall be zero. If fallback to store-and-forward occurred, the ESMTP server MUST respond with a 251 reply code, and is 0, is the number of bytes that the server intended to send in session mode, and is the number of bytes that were actually sent by the server when the session delivery failed. and should both be equal to the number of bytes that will be sent by the server. If the attempt at SESSION delivery failed and store and forward did not occur, the ESMTP server MUST respond with a 550 or 450 reply code. Note that , , and are all determined by the server. The number of bytes sent by the ESMTP client may be different than the number of bytes being sent by the ESMTP server, especially if the ESMTP server is performing any data conversion. Example responses: Transmission not yet complete: 250 2.5.0 30;782732;5567;0 250 2.5.0 20;5321;78275;0 250 <+1-303-555-1212@gw.xerox.com> 3;3210;100;0 Transmission complete: 250 0;7828;7828;0 250 2.5.0 <+1-303-555-1212@gw.xerox.com> 0;8891;8891;10 251 0;2131;30158;0 fallback occured Transmission errors: 550 5.2.0 0;72194;0;0 unable to lock user's mailbox 550 0;81731;0;0 infinite forwarding detected 550 5.2.1 0;87287;0;0 busy 550 5.4.1 <+1-303-555-1212@gw.xerox.com> 0;72831;0;0 no answer 450 4.4.2 <+1-303-555-1212@gw.xerox.com> 0;87513;0;0 no carrier Wing, Joffe, Masinter Expires February 1998 [Page 6] Internet Draft Immediate Delivery over ESMTP August 1997 450 <+1-303-555-1212@xerox.com> 0;878821;830131;4 no page confirmation 450 0;893121;830141;0 lost Session connection 6. Examples 6.1. SESSION delivery 6.1.1. Two recipients S: 220 foo.cisco.com ESMTP service ready C: EHLO pc.cisco.com S: 250-foo.cisco.com says hello S: 250 SESSION C: MAIL FROM: S: 250 Sender ok C: RCPT TO: SESSION S: 250 and options ok C: RCPT TO: SESSION S: 250 and options ok C: DATA S: 354 Enter your data C: <... message ...> C: . S: 250 message accepted; use STAT to query delivery C: STAT S: 250 0;88991;88991;0 completed C: STAT S: 250 3;5613;88991;10 still sending data C: STAT S: 250 0;88991;88991;12 completed C: QUIT S: 221 Goodbye 6.1.2. Two recipients, one doesn't support SESSION S: 220 foo.cisco.com ESMTP service ready C: EHLO pc.cisco.com S: 250-foo.cisco.com says hello S: 250 SESSION C: MAIL FROM: S: 250 Sender ok C: RCPT TO: SESSION S: 250 and options ok C: RCPT TO: SESSION Wing, Joffe, Masinter Expires February 1998 [Page 7] Internet Draft Immediate Delivery over ESMTP August 1997 S: 251 and options ok; non-SESSION intermediate MTA C: DATA S: 354 Enter your data C: <... message ...> C: . S: 250 message accepted; use STAT to query delivery C: STAT S: 250 0;891;891;0 completed C: STAT S: 251 0;891;891;0 store and forward at gw.cisco.com C: QUIT S: 221 Goodbye 6.2. SESSION with insufficient resources The client attempts a SESSION delivery, but the ESMTP server has exceeded its maximum simultaneous Session delivery limit. The ESMTP client responds by requesting a normal (store-and-forward) delivery for the same recipient, which is accepted by the ESMTP server. S: 220 foo.cisco.com ESMTP service ready C: EHLO pc.cisco.com S: 250-foo.cisco.com says hello S: 250 SESSION C: MAIL FROM: S: 250 Sender ok C: RCPT TO: SESSION S: 450 try later - exceeded maximum Session count C: RCPT TO: S: 250 Recipient ok C: DATA S: 354 Enter your data C: <... message ...> C: . S: 250 message accepted C: QUIT S: 221 Goodbye 6.3. SESSION-only ESMTP servers that cannot store and forward mail 6.3.1. Successful transmission (one recipient) S: 220 gizmo.cisco.com FAX offramp ESMTP server ready C: HELO sendmail.cisco.com S: 250 gizmo.cisco.com; Hi there, sendmail.cisco.com Wing, Joffe, Masinter Expires February 1998 [Page 8] Internet Draft Immediate Delivery over ESMTP August 1997 C: MAIL FROM: S: 250 Sender ok C: RCPT TO:<+14084575208@gizmo.cisco.com> S: 250 <+14084575208@gizmo.cisco.com> Okay C: DATA S: 354 Enter your data C: <... message ...> C: . (SMTP server doesn't respond until delivery to <+14084575208@gizmo.cisco.com> is complete) S: 250 successful delivery to <+14084575208@gizmo.cisco.com> C: QUIT S: 221 Goodbye 6.3.2. ESMTP server cannot relay mail S: 220 gizmo.cisco.com FAX offramp ESMTP server ready C: HELO sendmail.cisco.com S: 250 gizmo.cisco.com; Hi there, sendmail.cisco.com C: MAIL FROM: S: 250 Sender ok C: RCPT TO:<+14084575208@gw.xerox.com> S: 550 <+14084575208@gw.xerox.com> relaying not permitted C: QUIT S: 221 Goodbye 6.3.3. Only one recipient allowed S: 220 gizmo.cisco.com FAX offramp ESMTP server ready C: HELO sendmail.cisco.com S: 250 gizmo.cisco.com; Hi there, sendmail.cisco.com C: MAIL FROM: S: 250 Sender ok C: RCPT TO:<+14084575208@gizmo.cisco.com> S: 250 <+14084575208@gizmo.cisco.com> Okay C: RCPT TO:<+14158124333@gizmo.xerox.com> S: 450 <+14158124333@gizmo.xerox.com> Try again later C: DATA S: 354 Enter your data C: <... message ...> C: . (SMTP server doesn't respond until fax is delivered) S: 250 fax delivered to <+14084575208@gizmo.cisco.com> C: QUIT S: 221 Goodbye Wing, Joffe, Masinter Expires February 1998 [Page 9] Internet Draft Immediate Delivery over ESMTP August 1997 The SMTP client would be responsible for retrying <+14158124333@gizmo.xerox.com> per its normal retry interval. 7. Security Considerations Denial of service attacks are possible with SESSION. [%% more verbage] 8. Implementation notes 8.1. ESMTP server response to STAT To prevent excessive network activity by an ESMTP client querying the status of a forward-path "too often", the ESMTP server may delay responding to a client's STAT command. Such a delay should not exceed 10 seconds or any previously indicated . 8.2. SESSION and PIPELINING Due to the delays inherent with establishing connections with each MTA in the ESMTP path, ESMTP servers that implement SESSION SHOULD also implement [PIPELINING]. 8.3. ESMTP client pipelining STAT commands The ESMTP client may use [PIPELINING] for its STAT commands. The group of STAT commands for each of the forward-paths in this transaction may be considered a pipelined command group. The ESMTP client should wait for the response to the last STAT for that pipelined command group before sending other commands. 9. Acknowledgments Much of this document was produced by work begun in the Internet FAX Working Group of the IETF. The authors would like to thank Graham Klyne (Integralis Ltd.) for his contributions to this work. 10. References [ABNF] Wing, Joffe, Masinter Expires February 1998 [Page 10] Internet Draft Immediate Delivery over ESMTP August 1997 D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications: ABNF", Internet Draft, Work in Progress, draft-ietf-drums-abnf-03.txt, July 1997. [CHUNKING] G. Vaudreuil, "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 1830 (Experimental), August 1995. [DSN] K. Moore, "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996. [ENH-RET] N. Freed, "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996. [PIPELINING] N. Freed, A. Cargille, "SMTP Service Extension for Command Pipelining", RFC 1854, October 1995. N. Freed, "SMTP Service Extension for Command Pipelining", Internet Draft, Work in Progress, draft-freed-smtp-pipeline-02.txt, July 1997. [REQ] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP-14, RFC 2119, March 1997. [RFC821] J. Postel, "Simple Mail Transfer Protocol", STD-10, RFC 821, August 1982. [RFC822] D. Crocker, "Standard for the Format of ARPA Internet Text Messages", STD-11, RFC 822, August 1982. [SMTP-EXT] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP Service Extensions", STD-10, RFC 1869, November 1995. 11. Authors' Addresses Dan Wing Cisco Systems, Inc. 101 Cooper Street Santa Cruz, CA 95060 USA Wing, Joffe, Masinter Expires February 1998 [Page 11] Internet Draft Immediate Delivery over ESMTP August 1997 Phone: +1 408 457 5200 Fax: +1 408 457 5208 EMail: dwing@cisco.com Neil Joffe Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 526 4000 Email: njoffe@cisco.com Larry Masinter Xerox Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, CA 94304 USA Phone: +1 415 812 4365 Fax: +1 415 812 4333 EMail: masinter@parc.xerox.com X1. Notes and unresolved issues X1.1. More verbage needed for security section X1.2. RFC1123 timeouts may cause problems (5 minutes to the third MTA hop is greater than 5 minutes for the first MTA hop, so first MTA hop could timeout) X1.3. Add example showing DSN in conjunction with SESSION Wing, Joffe, Masinter Expires February 1998 [Page 12]