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

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

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.

Abstract

   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",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

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