Internet DRAFT - draft-vaudreuil-1892bis


     Internet Draft                                       Greg Vaudreuil 
     Obsoletes 1892                                  Lucent Technologies 
     Expires in six months                                August 8, 2002 

                       The Multipart/Report Content Type 
                              for the Reporting of 
                      Mail System Administrative Messages 



  Status of this Memo 

     This document is an Internet-Draft and is in full conformance with all 
     provisions of Section 10 of RFC 2026. 

     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 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 a "work in progress". 

     The list of current Internet-Drafts can be accessed at

     The list of Internet-Draft Shadow Directories can be accessed at

  Copyright Notice 

     Copyright (C) The Internet Society (2002).  All Rights Reserved. 

     This Internet-Draft is in conformance with Section 10 of RFC 2026. 


     Internet Draft          Multipart/Report             August 8, 2002 


     The Multipart/Report MIME content-type is a general "family" or 
     "container" type for electronic mail reports of any kind. Although 
     this memo defines only the use of the Multipart/Report content-type 
     with respect to delivery status reports, mail processing programs will 
     benefit if a single content-type is used to for all kinds of reports. 

     This document is part of a four document set describing the delivery 
     status report service.  This collection includes the SMTP extensions 
     to request delivery status reports, a MIME content for the reporting 
     of delivery reports, an enumeration of extended status codes, and this 
     document describing a multipart container for the delivery report, the 
     original message, and a human-friendly summary of the failure. 

  Working Group Summary 

     RFC 1892 was a product of the Notary working group.  This document is 
     a revision of that document providing clarifications as necessary to 
     advance to draft standard. 

  Document Conventions 

     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]. 

  Table of Contents 

     1. THE MULTIPART/REPORT CONTENT TYPE.................................3 
     2. THE TEXT/RFC822-HEADERS...........................................4 
     3. SECURITY CONSIDERATIONS...........................................5 
     4. REFERENCES........................................................5 
     5. COPYRIGHT NOTICE..................................................6 
     6. AUTHOR'S ADDRESS..................................................6 
     APPENDIX A - CHANGES FROM RFC1893....................................7 

     Vaudreuil                Expires 2/8/03                    [Page 2] 

     Internet Draft          Multipart/Report             August 8, 2002 

  1. The Multipart/Report Content Type 

     The Multipart/Report MIME content-type is a general "family" or 
     "container" type for electronic mail reports of any kind. Although 
     this memo defines only the use of the Multipart/Report content-type 
     with respect to delivery status reports, mail processing programs will 
     benefit if a single content-type is used to for all kinds of reports. 

     The Multipart/Report content-type is defined as follows:  

        MIME type name: multipart 
        MIME subtype name: report 
        Required parameters: boundary, report-type 
        Optional parameters: none 
        Encoding considerations: 7bit should always be adequate 
        Security considerations: see section 4 of this memo. 

     The syntax of Multipart/Report is identical to the Multipart/Mixed 
     content type defined in [MIME].  When used to send a report, the 
     Multipart/Report content-type must be the top-level MIME content type 
     for any report message.  The report-type parameter identifies the type 
     of report.  The parameter is the MIME content sub-type of the second 
     body part of the Multipart/Report. 

     User agents and gateways must be able to automatically determine    
     that a message is a mail system report and should be processed as    
     such.  Placing the Multipart/Report as the outermost content    
     provides a mechanism whereby an auto-processor may detect through    
     parsing the RFC 822 headers that the message is a report.  

     The Multipart/Report content-type contains either two or three sub- 
     parts, in the following order: 

     1) [Required] The first body part contains human readable message. The 
     purpose of this message is to provide an easily understood description 
     of the condition(s) that caused the report to be generated, for a 
     human reader who may not have an user agent capable of interpreting 
     the second section of the Multipart/Report. 

     The text in the first section may be in any MIME standards-track 
     content-type, charset, or language.  Where a description of the error 
     is desired in several languages or several media, a 
     Multipart/Alternative construct may be used. 

     This body part may also be used to send detailed information that 
     cannot be easily formatted into a Message/Report body part. 

     (2) [Required] A machine parsable body part containing an account of 
     the reported message handling event. The purpose of this body part is 
     to provide a machine-readable description of the condition(s) that 
     caused the report to be generated, along with details not present in 
     the first body part that may be useful to human experts.  An initial 
     body part, Message/delivery-status is defined in [DSN] 

     Vaudreuil                Expires 2/8/03                    [Page 3] 

     Internet Draft          Multipart/Report             August 8, 2002 

     (3) [Optional] A body part containing the returned message or a 
     portion thereof.  This information may be useful to aid human experts 
     in diagnosing problems.  (Although it may also be useful to allow the 
     sender to identify the message which the report was issued, it is 
     hoped that the envelope-id and original-recipient- address returned in 
     the Message/Report body part will replace the traditional use of the 
     returned content for this purpose.) 

     Return of content may be wasteful of network bandwidth and a variety 
     of implementation strategies can be used.  Generally the sender should 
     choose the appropriate strategy and inform the recipient of the 
     required level of returned content required.  In the absence of an 
     explicit request for level of return of content such as that provided 
     in [DRPT], the agent that generated the delivery service report should 
     return the full message content. 

     When data not encoded in 7 bits is to be returned, and the return path 
     is not guaranteed to be 8-bit capable, two options are available.  The 
     original message MAY be re-encoded into a legal 7-bit MIME message or 
     the Text/RFC822-Headers content-type MAY be used to return only the 
     original message headers.  

   2. The Text/RFC822-Headers content-type 

                 The Text/RFC822-Headers MIME content-type provides a 
                 mechanism to label and return only the RFC 822 headers of 
                 a failed message.  These headers are not the complete 
                 message and should not be returned as a Message/RFC822.  
                 The returned headers are useful for identifying the 
                 failed message and for diagnostics based on the received: 

      The Text/RFC822-Headers content-type is defined as follows: 

          MIME type name: Text 
          MIME subtype name: RFC822-Headers         
          Required parameters: None         
          Optional parameters: none         
          Encoding considerations: 7 bit is sufficient for normal RFC822 
                    headers, however, if the headers are broken and require 
                    encoding to make them legal 7 bit content, they may be 
                    encoded in quoted-printable.  
          Security considerations: see section 3 of this memo. 

     The Text/RFC822-headers body part should contain all the RFC822 header 
     lines from the message which caused the report.  The RFC822 headers 
     include all lines prior to the blank line in the message. They include 
     the MIME-Version and MIME Content- headers.  

     Vaudreuil                Expires 2/8/03                    [Page 4] 

     Internet Draft          Multipart/Report             August 8, 2002 

  3. Security Considerations 

     Automated use of report types without authentication presents several 
     security issues.  Forging negative reports presents the opportunity 
     for denial-of-service attacks when the reports are used for automated 
     maintenance of directories or mailing lists.  Forging positive reports 
     may cause the sender to incorrectly believe a message was delivered 
     when it was not 

  4. Normative References 

     [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 
     USC/Information Sciences Institute, August 1982. 

     [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for 
     Delivery Status Notifications", <draft-vaudreuil-1893bis-02.txt>, 
     University of Tennessee, Lucent Technology, Work-in-Progress 

     [RFC822] Crocker, D., "Standard for the format of ARPA Internet Text 
     Messages", STD 11, RFC 822, UDEL, August 1982. 

     [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail 
     Extensions (MIME) Part Two: Media Types", RFC 2046, First Virtual, 
     Innosoft, November 1996. 

     [DRPT] Moore, K., "SMTP Service Extension for Delivery Status 
     Notifications", <draft-moore-1891bis-01.txt>, University of Tennessee, 

     Vaudreuil                Expires 2/8/03                    [Page 5] 

     Internet Draft          Multipart/Report             August 8, 2002 

     5. Copyright Notice 

     "Copyright (C) The Internet Society (2002). 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 is provided on an 

  6. Author's Address 

     Gregory M. Vaudreuil  
     Lucent Technologies 
     17080 Dallas Parkway  
     Dallas, TX 75248-1905 
     Voice/Fax: +1-972-733-2722 

     Vaudreuil                Expires 2/8/03                    [Page 6] 

     Internet Draft          Multipart/Report             August 8, 2002 

  Appendix A - Changes from RFC1892 

     Changed Authors contact information 

     Updated required standards boilerplate 

     Edited the text to make it spell-checker and grammar checker compliant 


     Vaudreuil                Expires 2/8/03                    [Page 7]