The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages
obsoleted by
- rfc-3462 — The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages
Extracted elements (17)
A single Multipart/Report content-type is used as a container for all kinds of mail system reports so that mail processing programs benefit from a unified detection mechanism. Placing it as the outermost content type enables auto-processors to detect a report through RFC 822 header parsing without understanding the specific report subtype.
The Text/RFC822-Headers content-type was introduced to provide a bandwidth-efficient alternative to returning full message content when the original message contains non-7-bit data that cannot be safely forwarded on 8-bit-uncertain return paths.
Text/RFC822-Headers must not be returned as Message/RFC822 because it contains only headers, not the complete message. Using the correct content-type prevents receivers from misinterpreting partial content as a full message.
The syntax of Multipart/Report is identical to the Multipart/Mixed content-type defined in RFC 1521. This means existing MIME parsers can handle the structure, with the report-type parameter providing the differentiator for automated processing.
In the absence of an explicit request for level of return of content (such as that provided in RFC 1891), the agent which generated the delivery service report should return the full message content.
The Multipart/Report content-type must be the top-level MIME content type for any report message.
The Text/RFC822-Headers body part should contain all the RFC 822 header lines from the message which caused the report, including all lines prior to the blank line, MIME-Version, and MIME Content- headers.
User agents and gateways must be able to automatically determine that a message is a mail system report and should be processed as such.
When data not encoded in 7 bits is to be returned on a path not guaranteed to be 8-bit capable, the original 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 original message headers.
A Multipart/Report message contains two or three sub-parts in order: (1) a required human-readable description of the condition causing the report, in any MIME content-type; (2) a required machine-parsable body part describing the reported event; and (3) an optional body part containing the returned message or a portion thereof.
The first body part provides a human-readable description for mail user agents that cannot interpret the machine-parsable section. It may be in any MIME standards-track content-type, charset, or language, and may use Multipart/Alternative for multilingual descriptions.
The Multipart/Report MIME content-type is defined with MIME type 'multipart', subtype 'report', required parameters 'boundary' and 'report-type', no optional parameters, and 7-bit encoding. The report-type parameter identifies the type of report and equals the MIME content sub-type of the second body part.
The optional third body part contains the returned message or a portion thereof to aid human experts in diagnosing problems. The envelope-id and original-recipient-address in the machine-parsable part are intended to eventually replace the need to return full content for message identification.
The second body part is a machine-parsable account of the reported message-handling event, providing information useful to automated processors and human experts. The initial defined subtype is Message/delivery-status (defined in RFC 1894).
The Text/RFC822-Headers MIME content-type is defined with MIME type 'Text', subtype 'RFC822-Headers', no required or optional parameters, and 7-bit encoding (quoted-printable allowed for broken headers). It is used to return only the RFC 822 headers of a failed message.
Automated use of report types without authentication enables denial-of-service attacks: forging negative delivery reports can corrupt automated maintenance of directories or mailing lists by causing spurious removals or error handling.
Forging positive delivery reports may cause the original sender to incorrectly believe a message was delivered when it was not, undermining reliable delivery semantics.