RFC 6522 removes the constraint from RFC 3462 that multipart/report must be used only as the outermost MIME type of a message. That restriction prevented forwarding a report as part of another multipart MIME message and limited transmission of multiple administrative reports within a single container.

email

Removing the outermost-MIME-type constraint (present in RFC 3462) is the key interoperability change. Other documents may update or establish constraints on use of multipart/report in contexts where restrictions are needed; RFC 6522 itself imposes none beyond what individual report-type registrations may specify.

email

In the absence of an explicit request for level of return of content (such as that provided in DSN-SMTP), the agent that generated the delivery service report SHOULD return the full message content in the optional third body part.

email

Registration of new media types for creating a new report format SHOULD note in the Intended Usage section that the type being registered is suitable for use as a report-type (i.e., the second body part) in the context of this specification.

email, registry

The first body part of multipart/report MUST be human-readable and provide an easily understood description of the condition(s) that caused the report, for readers whose user agents cannot interpret the second section. Any IANA-registered MIME media type, charset, or language MAY be used.

email

The header returned in a text/rfc822-headers body part SHOULD NOT be returned using the message/rfc822 media type, as it is not the complete message. It includes all header fields prior to the first blank line, including MIME-Version and MIME content description fields.

email

The text/rfc822-headers body part SHOULD contain all the mail header fields from the message that caused the report, including all fields prior to the first blank line.

email

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 media type MAY be used to return only the original message headers.

email

Where a description of the error is desired in several languages or media, a multipart/alternative construct MAY be used in the first body part. This body part MAY also be used to send detailed information that cannot be easily formatted into the second body part.

email

multipart/report contains two or three sub-parts in order: (1) REQUIRED human-readable message, (2) REQUIRED machine-parsable body part describing the reported event, and (3) OPTIONAL body part containing the returned message or a portion thereof.

email

The multipart/report MIME media type is a general container type for electronic mail reports. Required parameters are 'boundary' and 'report-type'; the report-type parameter identifies the MIME subtype of the second body part. Syntax is identical to multipart/mixed.

email

The text/rfc822-headers media type provides a mechanism to label and return only the RFC 5322 header of a failed message. Required parameters: none. Optional parameters: none. Encoding: 7-bit is sufficient for normal mail headers; quoted-printable MAY be used if headers require encoding.

email

IANA updated the Media Type Registry to indicate RFC 6522 contains the current definitions of multipart/report and text/rfc822-headers, obsoleting RFC 3462. Both registrations reference RFC 6522 as the published specification.

email, registry

Automated use of report types without authentication enables forging of negative reports, creating opportunity for denial-of-service attacks when reports are used for automated maintenance of directories or mailing lists.

email, security

Forging positive delivery reports can cause the sender to incorrectly believe a message was delivered when it was not. A signature covering the entire multipart/report structure could prevent such forgeries, but such a scheme is outside the scope of this document.

email, security