INTERNET-DRAFT Eric A. Hall Document: draft-hall-inline-dsn-01.txt May 2004 Expires: December, 2004 Category: Standards-Track SMTP Service Extension for Inline DSNs Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo describes a mechanism for the negotiation and transfer of per-recipient notification responses in SMTP. Internet Draft draft-hall-inline-dsn-01.txt May 2004 Table of Contents 1. Introduction..............................................2 2. Prerequisites and Terminology.............................3 3. The INLINE-DSN SMTP Service Extension.....................3 4. The INLINE-DSN Keyword....................................4 5. The INLINE-DSN Command Extension..........................4 6. The End-of-Data Response Codes............................4 6.1. The 352 Response Code..................................4 6.2. The 353 Response Code..................................5 6.3. The Per-Recipient Response Codes.......................5 6.4. The Final Response Code................................6 6.5. Failure and Timing Considerations......................7 7. Usage Examples............................................8 7.1. One Failure, One Success...............................8 7.2. Total Failure..........................................8 7.3. Mixed-Mode.............................................9 8. Security Considerations...................................9 9. Normative References.....................................10 10. Informative References...................................10 Author's Address..............................................10 Acknowledgments...............................................10 Full Copyright Statement......................................10 1. Introduction The Simple Mail Transfer Protocol (SMTP) [RFC2821] currently uses a single response code to indicate whether or not an email message [RFC2822] has been successfully transferred. This response code applies to the message data specifically, and therefore applies to all of the message's recipients collectively, regardless of the number of recipients which may have been specified in the envelope or their individual preferences. However, it has become common practice for different recipients to have their own content filters, and a single response code is not sufficiently granular to accurately reflect these differences. For example, some users may suffer under policy rules which require them to refuse email messages that contain certain words, while other users may be required to accept all messages regardless of content. But since the current SMTP model only allows a single response code to apply to any given message transfer, the only legitimate way to accommodate these differences is for a message to be accepted so that it can be examined off-line, with one or Hall I-D Expires: December 2004 [page 2] Internet Draft draft-hall-inline-dsn-01.txt May 2004 more failure notification messages being returned to the original sender if the message content later proves to be unacceptable. This process model introduces a significant burden on both the sender and recipient servers. The original recipient system must create, queue, and transfer each of the notification messages, and the original sender system must map these individual notifications back to an original message. Simply put, it would be much more efficient for the recipient system to simply refuse certain email messages on a per-recipient basis immediately, while the transfer session was still active. This would alleviate recipient systems from needing to generate notification messages after-the-fact, and would also allow the sending system to generate and return a single notification message immediately. This specification is intended to provide just that service. This is achieved through the definition of an SMTP service extension which advertises support for the service defined herein, a command extension to the MAIL verb which indicates that a client wishes to use the service, a set of unique response codes for use when the service is active, and behavioral rules which implementations are required to follow when the service has been activated. 2. Prerequisites and Terminology Readers of this document are expected to be familiar with the specifications for SMTP (RFC 2821), command pipelining (STD 60) [STD60], and enhanced status codes (RFC 2034) [RFC2034]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. The INLINE-DSN SMTP Service Extension The extension is defined as follows: a. the name of the SMTP service extension is INLINE-DSN; b. the EHLO keyword value associated with the extension is INLINE-DSN; c. the INLINE-DSN EHLO keyword has no parameters; Hall I-D Expires: December 2004 [page 3] Internet Draft draft-hall-inline-dsn-01.txt May 2004 d. an INLINE-DSN extension is defined for the MAIL FROM command; e. the INLINE-DSN extension to the MAIL FROM command has no parameters; f. no additional commands are extended; g. no new verbs are defined by this extension; h. the 352 and 353 response codes are defined for use when the INLINE-DSN extension has been activated; and, i. the next section specifies how support for the extension affects the behavior of a server and client SMTP. 4. The INLINE-DSN Keyword The presence of the INLINE-DSN keyword in the EHLO greeting response indicates that the server supports this extension. No parameters are defined for this keyword. Servers which offer this service MUST support the command pipelining extension defined in STD 60 [STD60], and SHOULD support the extended status codes defined in RFC 2034 [RFC2034]. 5. The INLINE-DSN Command Extension Clients indicate that they wish to use the INLINE-DSN extension by providing INLINE-DSN as an extension to the MAIL FROM command. Clients MUST NOT transmit this command extension unless the server has advertised support for the INLINE-DSN service extension in the EHLO greeting response. No parameters are defined for this command extension. 6. The End-of-Data Response Codes 6.1. The 352 Response Code The 352 response code is used by a server to indicate that the mailbox address specified in the associated RCPT TO command appears to be valid, but its validity will not be confirmed until after the message data has been transferred. Hall I-D Expires: December 2004 [page 4] Internet Draft draft-hall-inline-dsn-01.txt May 2004 Servers MUST NOT generate the 352 response code for this purpose unless the client has used the INLINE-DSN command extension to the MAIL FROM command during the current envelope exchange. Clients which receive the 352 response code in response to a RCPT TO command MUST be prepared for the corresponding recipient to be rejected after the message data is transferred. 6.2. The 353 Response Code The 353 response code is used by a server to indicate that the message appears to be valid, but that one or more of the recipients may refuse the message. When this response code is returned, absolute response codes for each of the recipients which were earlier acknowledged with a 352 response code during the envelope exchange MUST be provided, and must be provided in the order in which they were originally accepted (see section 6.3). Servers MUST NOT use the 353 response code for this purpose unless the server has already used the 352 response code in response to a RCPT TO command for the current message. If the message is accepted or refused by every recipient, the 353 response code and the subsequent responses MAY be substituted with a single response code which reflects the global outcome. For example, if all of the recipients accepted the email message, then a single 250 response code MAY be returned in lieu of the 353 response code, the per-recipient response codes, and the final response code. See section 6.4 for considerations about these final response codes. 6.3. The Per-Recipient Response Codes Clients which receive the 353 response code MUST be prepared to receive recipient-specific response codes for each of the recipients which had earlier returned 352 response codes during the current envelope exchange. The per-recipient response codes indicate whether or not the message content was acceptable for each particular recipient. If the 353 response code (as described in the preceding section) was received, the per-recipient response codes MUST be used by the SMTP client to generate any notification messages. Hall I-D Expires: December 2004 [page 5] Internet Draft draft-hall-inline-dsn-01.txt May 2004 Any response code which is valid for the RCPT TO command is valid for any per-recipient response code. Each of the recipient- specific responses MUST use the syntax rules associated with the canonical definition of that response code. For example, if a server needs to use the 551 response code to indicate that a recipient has relocated to another address, that particular response MUST include the destination mailbox address, as per the syntax rules defined in RFC 2821. Servers SHOULD include the appropriate enhanced status code with each of the per-recipient responses, as defined in RFC 2034 [RFC2034]. Each of these response codes MUST be returned as independent responses (one per line, or one per multi-line response, as necessary). Once all of the recipient-specific response codes have been returned, a final response code MUST be transmitted which indicates the overall completion result (see section 6.4 for more information on this final response code). Note that the per-recipient response codes DO NOT indicate that the server has accepted responsibility for delivering the message to that recipient, but instead only indicate whether or not the recipient is valid. Acceptance for delivery only occurs if and when the final response code is issued. 6.4. The Final Response Code Once all of the recipient-specific response codes have been returned (as described in section 6.2), a final response code MUST be returned which indicates the actual disposition of the message transfer operation. This response code MUST reflect the transfer as a whole, and MUST NOT reflect any particular recipient. As a rule, if the server has accepted the message for any recipients, then it MUST return a positive final response. But if the server has refused to accept the message for all of the recipients, it MUST return a negative final response, and SHOULD use a response code which is globally applicable if available. In those cases where a temporary condition is causing some recipients to reject the message, then a temporary failure final response code (4xx) MUST be used. For example, if the message transfer succeeded but some recipients were rejected, the transfer will still have succeeded, and would therefore need to be acknowledged with a positive response code. Hall I-D Expires: December 2004 [page 6] Internet Draft draft-hall-inline-dsn-01.txt May 2004 Conversely, if a shortage of disk space had caused the server to reject the message for all of the recipients (irregardless of any of their individual quota restrictions), then the final response code would need to indicate that condition. If all of the recipients had rejected the message on permanent grounds, then the server should return a permanent failure response code as well. When the server issues the final response code, it accepts responsibility for delivery of the message to the acknowledged recipients. The server MUST NOT begin processing the message until the final response code has been issued. 6.5. Failure and Timing Considerations There are a handful of scenarios where the client may be unable to read all of the response codes from the server, resulting in a state of confusion as to which system actually owns the message. For example, the connection between the client and server may be lost while the server is enumerating the per-recipient responses, with the client having an incomplete view of the actual disposition. Similarly, the client may time-out while waiting for the server to enumerate all of the per-recipient response codes. RFC 1047 [RFC1047] discusses similar scenarios which have occurred in the past, and which are somewhat more applicable to the proposed mechanisms described herein. Clients MUST retain ownership of the message until a final response code has been received. Servers MUST NOT issue a final response code until they have enumerated all of the recipients or are able to apply a global response to all of the recipients. Once the server has issued the final response, it MUST take ownership of the message for subsequent processing. Clients MUST wait 10 minutes for any of the per-recipient and final response codes to arrive before giving up the transfer. Each response code received from the server MUST reset the timer. Servers MUST generate each of the post-data response codes within one minute of the prior post-data response codes. If a server is unable to determine an accurate response code during that period, it MUST return a temporary failure code of some kind, and exit the subroutine as orderly as possible. Clients which have an excessive number of problems with a specific server are generally encouraged to make note of it, and to avoid Hall I-D Expires: December 2004 [page 7] Internet Draft draft-hall-inline-dsn-01.txt May 2004 using the INLINE-DSN extension with subsequent queuing operations for that server. 7. Usage Examples 7.1. One Failure, One Success The following dialog illustrates a message with two recipients, one of which refuses the content, the other of which accepts: S: C: S: 220 server.example.net C: EHLO client.example.com S: 250-server.example.net Hello there S: 250-INLINE-DSN S: 250-PIPELINING S: 250 ENHANCEDSTATUSCODES C: MAIL FROM: INLINE-DSN S: 250 okay C: RCPT TO: S: 352 recipient looks okay but wait for confirmation C: RCPT TO: S: 352 recipient looks okay but wait for confirmation C: DATA S: 354 go ahead C: C: . S: 353 data looks okay but wait for confirmation S: 550 5.6.0 refuses the content S: 250 2.1.5 accepts the content S: 250 data accepted by some recipients 7.2. Total Failure The following dialog illustrates a message with two recipients, both of which refuse to accept the message (note that this example only shows the envelope and data exchange): C: MAIL FROM: INLINE-DSN S: 250 okay C: RCPT TO: S: 352 recipient looks okay but wait for confirmation C: RCPT TO: Hall I-D Expires: December 2004 [page 8] Internet Draft draft-hall-inline-dsn-01.txt May 2004 S: 352 recipient looks okay but wait for confirmation C: DATA S: 354 go ahead C: C: . S: 550 5.6.0 data refused by all recipients Since the message contents were refused by all of the recipients, the data transfer was simply rejected, and it was unnecessary for the server to generate per-recipient responses. 7.3. Mixed-Mode The following dialog illustrates a transfer that incorporates historical response codes as well as the 352 response code (note that this example only shows the envelope and data exchange): C: MAIL FROM: INLINE-DSN S: 250 okay C: RCPT TO: S: 250 this recipient accepts all messages C: RCPT TO: S: 352 recipient looks okay but wait for confirmation C: RCPT TO: S: 352 recipient looks okay but wait for confirmation C: RCPT TO: S: 550 this recipient no longer exists C: DATA S: 354 go ahead C: C: . S: 353 data looks okay but wait for confirmation S: 550 5.6.0 refuses the content S: 250 2.1.5 accepts the content S: 250 data accepted by some users Note that the postmaster and old-user mailboxes were not itemized in the deferred responses, since they were not deferred during the envelope exchange. 8. Security Considerations TBD Hall I-D Expires: December 2004 [page 9] Internet Draft draft-hall-inline-dsn-01.txt May 2004 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, December 1996. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [STD60] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, September 2000. 10. Informative References [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC1047] Partridge, C., "DUPLICATE MESSAGES AND SMTP", RFC 1047, February 1988. Author's Address Eric A. Hall ehall@ehsco.com Acknowledgments Funding for the RFC editor function is currently provided by the Internet Society. Portions of this document were funded by VeriSign Labs. The first version of this specification was co-authored by Andrew Newton of VeriSign Labs, and subsequent versions continue to be developed with his active participation. Edward Lewis and Peter Gietz also contributed significant feedback to this specification in the later stages of its developments. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. Hall I-D Expires: December 2004 [page 10] Internet Draft draft-hall-inline-dsn-01.txt May 2004 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 assigns. 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Hall I-D Expires: December 2004 [page 11]