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

Document Type RFC - Proposed Standard (January 1996; No errata)
Obsoleted by RFC 3462
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1892 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                       G. Vaudreuil
Request for Comments: 1892                        Octel Network Services
Category: Standards Track                                   January 1996

                   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.

1. The Multipart/Report MIME 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 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.

Vaudreuil                   Standards Track                     [Page 1]
RFC 1892                    Multipart/Report                January 1996

   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

       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) which 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 which 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 origional message MAY be reencoded into a legal 7 bit
   MIME message or the Text/RFC822-Headers content-type MAY be used to
   return only the origional message headers.
Show full document text