Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


Network Working Group G. Vaudreuil Request for Comments: 3462 Lucent Technologies Obsoletes: 1892 January 2003 Category: Standards Track

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

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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


 The Multipart/Report Multipurpose Internet Mail Extensions (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 Simple Mail
 Transfer Protocol (SMTP) extensions to request delivery status
 reports, a MIME content for the reporting of delivery reports, an
 enumeration of extended status codes, and a multipart container for
 the delivery report, the original message, and a human-friendly
 summary of the failure.

Vaudreuil Standards Track [Page 1] RFC 3462 Multipart/Report January 2003

Table of Contents

 Document Conventions................................................2
 1. The Multipart/Report Content Type................................2
 2. The Text/RFC822-Headers..........................................4
 3. Security Considerations..........................................4
 4. Normative References.............................................5
 Appendix A - Changes from RFC 1893..................................6
 Author's Address....................................................6
 Full Copyright Statement............................................7

Document Conventions

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 document are to be interpreted as described in BCP 14, RFC 2119

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

Vaudreuil Standards Track [Page 2] RFC 3462 Multipart/Report January 2003

 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 a 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].
 (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 8-bit or binary data not encoded in a 7 bit form is to be
 returned, and the return path is not guaranteed to be 8-bit or binary
 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.

Vaudreuil Standards Track [Page 3] RFC 3462 Multipart/Report January 2003

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

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

Vaudreuil Standards Track [Page 4] RFC 3462 Multipart/Report January 2003

4. Normative References

 [SMTP]     Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
            821, August 1982.
 [DSN]      Moore, K., and G. Vaudreuil, "An Extensible Message Format
            for Delivery Status Notifications", RFC 3464, January
 [RFC822]   Crocker, D., "Standard for the format of ARPA Internet
            Text Messages", STD 11, RFC 822, August 1982.
 [MIME]     Borenstein, N. and N. Freed, "Multipurpose Internet Mail
            Extensions (MIME) Part Two: Media Types", RFC 2046,
            November 1996.
 [DRPT]     Moore, K., "SMTP Service Extension for Delivery Status
            Notifications", RFC 3461, January 2003.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

Vaudreuil Standards Track [Page 5] RFC 3462 Multipart/Report January 2003

Appendix A - Changes from RFC 1892

 Changed Authors contact information
 Updated required standards boilerplate
 Edited the text to make it spell-checker and grammar checker

Author's Address

 Gregory M. Vaudreuil
 Lucent Technologies
 7291 Williamson Rd
 Dallas Tx, 75214
 Phone: +1 214 823 9325

Vaudreuil Standards Track [Page 6] RFC 3462 Multipart/Report January 2003

Full Copyright Statement

 Copyright (C) The Internet Society (2003).  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
 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


 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Vaudreuil Standards Track [Page 7]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3462.txt · Last modified: 2003/01/21 18:32 (external edit)