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.

Table of contents

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 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 RFC 1521 [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:

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.

2. The Text/RFC822-Headers MIME 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, they may be encoded in quoted-printable.
          Security considerations: see section 4 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. References

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

5. Author's Address

Gregory M. Vaudreuil
Octel Network Services
17060 Dallas Parkway
Dallas, TX 75248-1905

Phone: +1-214-733-2722