Protocol Action: SMTP Service Extension for Delivery Status Notifications to Draft Standard

[The IESG <[e-mail]>]

The IESG has approved publication of the following Internet-Drafts as
Draft Standards:

 o SMTP Service Extension for Delivery Status Notification
   <draft-moore-rfc1891bis-02.txt> replacing RFC1891, currently a
   Proposed Standard.

 o The Multipart/Report Content Type for the Reporting of Mail System
   Administrative Messages <draft-vaudreuil-1892bis-02.txt> replacing
   RFC1892, currently a Proposed Standard.

 o An Extensible Message Format for Delivery Status Notifications
   <draft-vaudreuil-1894bis-02.txt> replacing RFC1894, currently a
   Proposed Standard.

 o Enhanced Mail System Status Codes <draft-vaudreuil-1893bis-03.txt>
   replacing RFC1893, currently a Proposed Standard.

  The original documents were products of the NOTARY working group. 
  These revised documents have been reviewed in the IETF but are not 
  the product of an active IETF Working Group. The IESG contact persons 
  are Ned Freed and Patrik Faltstrom.

Technical Summary

  This package of documents provides a standardized mechanism for
  requesting and returning notifications of mail delivery (sometimes
  called acknowledgements) to the user's mailbox using standard internet
  mail mechanisms (Extended SMTP and MIME). The first document specifies
  the SMTP extension for requesting delivery notifications, the second 
  and third specify formats for notifications, and the fourth provides 
  an extended (relative to RFC821/RFC2821) set of error/reporting codes 
  for use with these mechanisms.

Working Group Summary

  These documents are revisions of the original documents produced by 
  the NOTARY working group in 1995.

Protocol Quality

  These facilities were first defined in RFCs 1891-1893. Since then they
  have been widely and successfully deployed. The protocol and formats
  have not changed in current documents.

  Ned Freed reviewed these specifications for the IESG.


Submitted Implementation Report can be viewed at
http://www.ietf.org/IESG/Implementations/DSN.txt


RFC Editor note:

Please add the following security considerations section to
    draft-moore-rfc1891bis-02.txt before section 10:

    The SMTP extension described in this document does not change the 
    fundamental nature of the SMTP service and hence does not create any 
    new security exposures in and of itself. It necessarity adds 
    complexity to implementations, however, and with added complexity 
    comes an increased risk of implementation errors.

    Previous ad-hoc delivery notification mechanisms sometimes produced 
    a storm of receipts due to unanticipated interactions with mailing 
    list expansion software. In this specification notification of 
    sucessful delivery is carefully designed so if properly implemented 
    it cannot interact with a list expander in this way.
   
    The security considerations section in [9] describes security issues
    associated with multipart/report objects in general and the security
    considerations section in [5] describes security issues with DSNs in
    particular.

The fact that a security considerations section was added should be
added to the appendix of draft-moore-rfc1891bis-02.txt listing changes
made since the previous version.

Please add the following sentence to the security considerations section 
of draft-vaudreuil-1892bis-02.txt:

     A signature covering the entire multipart/report structure could be 
     used to prevent such forgeries; such a signature scheme is, however, 
     beyond the scope of this document.

There are several problems with the ABNF in draft-vaudreuil-1894bis-02.txt
that need to be fixed.

The line:

                     delivery-status-content = per-message-fields 1* 
	                     ( CRLF per-recipient-fields ) 

in section 2.1 should be changed to:

                     delivery-status-content = per-message-fields
                            1*( CRLF per-recipient-fields ) 

The line:

                     dsn-gateway field = "DSN

in section 2.2.3 should be changed to:

                     dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name
   
The line:

                     remote-mta field = "Remote

in section 2.3.5 should be changed to:

                     remote-mta-field = "Remote-MTA" ":" mta-name-type ";" mta-name

The lines:

                                 [ last-attempt-date-field CRLF ] 
                                 [ final-log-id CRLF ] 
                                 [ will-retry-until-field CRLF ] 

should be changed to:

                                 [ last-attempt-date-field CRLF ] 
                                 [ final-log-id-field CRLF ] 
                                 [ will-retry-until-field CRLF ] 

in both section 2.3 and appendix A.

The text in the simple DSN in Appendix E should be changed from:

                   ----- Transcript of session follows ----- 
           <[e-mail]>... Deferred: Connection timed out with 
           larry.slip.umd.edu. Message could not be delivered for 5 days Message 
           will be deleted from queue 

to:

                 ----- Transcript of session follows -----
           <[e-mail]>... Deferred: Connection timed out
                       with larry.slip.umd.edu.
           Message could not be delivered for 5 days
           Message will be deleted from queue

The text in the second DSN in Appendix E should be changed from:

                   ----- The following addresses had delivery problems ----- 
           <[e-mail]> (unrecoverable error) <[e-mail]> 
           (unrecoverable error) 

to:

                   ----- The following addresses had delivery problems ----- 
           <[e-mail]> (unrecoverable error)
           <[e-mail]> (unrecoverable error) 

The MIME-Version header field in the DSN from gateway to foreign system
example in Appendix E should be changed from:

           MIME-version: 1.0 content-type: multipart/report; 
               report-type=delivery-status; boundary="84229080704991.122306.SYS30" 

to:

           MIME-version: 1.0
           content-type: multipart/report; 
               report-type=delivery-status;
               boundary="84229080704991.122306.SYS30" 

The text in that same example should be changed from:

           Invalid address - nair_s %DIR-E-NODIRMTCH, No matching Directory Entry 

to:

           Invalid address - nair_s
           %DIR-E-NODIRMTCH, No matching Directory Entry 


The Received header field in the Delayed DSN example in Appendix E
should be changed to read:

           Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk 
                   id: <[e-mail]>; 

           Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk
                   id <[e-mail]>;
                   Sun, 10 Jul 1994 00:36:51 +0100

Finally, the text:

           UA-ID: Reliable PC (... Q-ID: sun2.nsf:77/msg.11820-0 has not been 
           delivered to the intended recipient: [e-mail] despite 
           repeated delivery attempts over the past 24 hours. 

in the Delayed DSN example in Appendix E should be changed to read:

           UA-ID: Reliable PC (...
           Q-ID: sun2.nsf:77/msg.11820-0

           has not been delivered to the intended recipient:

               [e-mail]

           despite repeated delivery attempts over the past 24 hours.