Internet DRAFT - draft-hall-deferrals

draft-hall-deferrals





  INTERNET-DRAFT                                             Eric A. Hall 
  Document: draft-hall-deferrals-00.txt                      January 2007 
  Expires: August, 2007                                                  
  Category: Standards-Track                                               
      
      
                  SMTP Service Extension for Deferred RCPT 
      
      
     Status of this Memo 
      
     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 becomes aware will be disclosed, in
     accordance with Section 6 of BCP 79.

     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 (2007).  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-deferrals-00.txt        January 2007 
   
   
      
     Table of Contents 
      
     1.   Introduction..............................................2 
     2.   Prerequisites and Terminology.............................3 
     3.   The DEFERRALS SMTP Service Extension......................3 
     4.   The DEFERRALS Keyword.....................................4 
     5.   The DEFERRALS 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:   August 2007             [page 2] 
  Internet Draft       draft-hall-deferrals-00.txt        January 2007 
   
   
     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 DEFERRALS SMTP Service Extension 
      
     The extension is defined as follows: 
      
        a.  the name of the SMTP service extension is DEFERRALS; 
      
        b.  the EHLO keyword value associated with the extension is 
            DEFERRALS; 
      
        c.  the DEFERRALS EHLO keyword has no parameters; 
      
   
  Hall                  I-D Expires:   August 2007             [page 3] 
  Internet Draft       draft-hall-deferrals-00.txt        January 2007 
   
   
        d.  a DEFERRALS extension is defined for the MAIL FROM 
            command; 
      
        e.  the DEFERRALS 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 
            DEFERRALS 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 DEFERRALS Keyword 
      
     The presence of the DEFERRALS 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 DEFERRALS Command Extension 
      
     Clients indicate that they wish to use the DEFERRALS extension by 
     providing DEFERRALS as an extension to the MAIL FROM command. 
      
     Clients MUST NOT transmit this command extension unless the server 
     has advertised support for the DEFERRALS service extension in the 
     EHLO greeting response. 
      
     No parameters are defined for this command extension. 
      
  6.      The DEFERRALS 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:   August 2007             [page 4] 
  Internet Draft       draft-hall-deferrals-00.txt        January 2007 
   
   
     Servers MUST NOT generate the 352 response code for this purpose 
     unless the client has used the DEFERRALS 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. 
      
     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. 
      
     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 
     received from the SMTP client. 
      
     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:   August 2007             [page 5] 
  Internet Draft       draft-hall-deferrals-00.txt        January 2007 
   
   
     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:   August 2007             [page 6] 
  Internet Draft       draft-hall-deferrals-00.txt        January 2007 
   
   
     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:   August 2007             [page 7] 
  Internet Draft       draft-hall-deferrals-00.txt        January 2007 
   
   
     using the DEFERRALS 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: <waits for connection on TCP port 25> 
        C: <opens connection> 
        S: 220 server.example.net 
        C: EHLO client.example.com 
        S: 250-server.example.net Hello there 
        S: 250-DEFERRALS 
        S: 250-PIPELINING 
        S: 250 ENHANCEDSTATUSCODES 
         
        C: MAIL FROM:<sender@example.com> DEFERRALS 
        S: 250 okay 
        C: RCPT TO:<fighter@example.net> 
        S: 352 recipient looks okay but wait for confirmation 
        C: RCPT TO:<lover@example.net> 
        S: 352 recipient looks okay but wait for confirmation 
         
        C: DATA 
        S: 354 go ahead 
        C: <sends data> 
        C: <crlf>.<crlf> 
        S: 353 data looks okay but wait for confirmation 
        S: 550 5.6.0 <fighter@example.net> refuses the content 
        S: 250 2.1.5 <lover@example.net> 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:<sender@example.com> DEFERRALS 
        S: 250 okay 
        C: RCPT TO:<fighter@example.net> 
        S: 352 recipient looks okay but wait for confirmation 
        C: RCPT TO:<lover@example.net> 
   
  Hall                  I-D Expires:   August 2007             [page 8] 
  Internet Draft       draft-hall-deferrals-00.txt        January 2007 
   
   
        S: 352 recipient looks okay but wait for confirmation 
         
        C: DATA 
        S: 354 go ahead 
        C: <sends data> 
        C: <crlf>.<crlf> 
        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:<sender@example.com> DEFERRALS 
        S: 250 okay 
        C: RCPT TO:<postmaster@example.net> 
        S: 250 this recipient accepts all messages 
        C: RCPT TO:<fighter@example.net> 
        S: 352 recipient looks okay but wait for confirmation 
        C: RCPT TO:<lover@example.net> 
        S: 352 recipient looks okay but wait for confirmation 
        C: RCPT TO:<old-user@example.net> 
        S: 550 this recipient no longer exists 
         
        C: DATA 
        S: 354 go ahead 
        C: <sends data> 
        C: <crlf>.<crlf> 
        S: 353 data looks okay but wait for confirmation 
        S: 550 5.6.0 <fighter@example.net> refuses the content 
        S: 250 2.1.5 <lover@example.net> 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:   August 2007             [page 9] 
  Internet Draft       draft-hall-deferrals-00.txt        January 2007 
   
   
      
  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. 
      
      
  Hall                  I-D Expires:   August 2007            [page 10] 
  Internet Draft       draft-hall-deferrals-00.txt        January 2007 
   

  Full Copyright Statement 
      
     Copyright (C) The Internet Society (2007). 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 assigns. 
      
     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, (THE IETF TRUST) 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.
      
     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.
   
  Hall                  I-D Expires:   August 2007            [page 11]