The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages
obsoleted by
- rfc-6522 — The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages
obsoletes
- rfc-1892 — The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages
updated by
- rfc-5337 — Internationalized Delivery Status and Disposition Notifications
Extracted elements (16)
A single Multipart/Report content-type is defined for all kinds of mail system reports so that mail processing programs can benefit from uniform handling, even though this memo defines its use only for delivery status reports.
Text/RFC822-Headers was defined specifically because returning the full 8-bit or binary original message over non-8-bit-capable return paths is problematic; returning only headers provides identification and diagnostic value without the encoding burden.
The third (optional) body part containing the returned message is intended to help human experts diagnose problems. The envelope-id and original-recipient-address in the machine-parsable body part are expected to replace the traditional use of returned content for message identification.
The Text/RFC822-Headers body part returns only the RFC 822 headers and is not the complete message; it must not be returned as a Message/RFC822 type. The returned headers are useful for identifying the failed message and for diagnostics based on received lines.
In the absence of an explicit request for level of return of content, the agent that generated the delivery service report should return the full message content.
The first body part (human-readable message) is required and may be in any MIME standards-track content-type, charset, or language; Multipart/Alternative may be used when descriptions in several languages or media are desired.
The second body part (machine-parsable) is required and must provide a machine-readable description of the condition(s) that caused the report, along with details not present in the first body part.
The Text/RFC822-Headers body part should contain all the RFC 822 header lines from the message that caused the report, including all lines prior to the blank line, the 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 8-bit or binary data not encoded in 7-bit form is to be returned and the return path is not guaranteed to be 8-bit or binary capable, 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.
When used to send a report, the Multipart/Report content-type must be the top-level MIME content type for any report message, enabling auto-processors to detect it by parsing RFC 822 headers.
Multipart/Report is a MIME container type for electronic mail reports of any kind. Required parameters are 'boundary' and 'report-type'; the report-type parameter identifies the MIME content sub-type of the second body part. Encoding considerations indicate 7-bit should always be adequate.
Text/RFC822-Headers is a MIME content type (type: Text, subtype: RFC822-Headers) that provides a mechanism to label and return only the RFC 822 headers of a failed message. No required or optional parameters are defined; 7-bit encoding is sufficient for normal RFC 822 headers.
The Multipart/Report body contains either two or three sub-parts in order: (1) required human-readable description, (2) required machine-parsable account of the reported event, and (3) optional returned message or portion thereof.
A signature covering the entire multipart/report structure could prevent report forgeries, but such a scheme is beyond the scope of this document.
Automated use of report types without authentication enables forgery of negative reports, creating opportunity for denial-of-service attacks when reports drive automated maintenance of directories or mailing lists. Forging positive reports may cause senders to incorrectly believe a message was delivered.