RFC 1892 (rfc1892) - Page 2 of 4
The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages
Alternative Format: Original Text Document
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
Multipart/Report.
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/RFC 822-Headers content-type MAY be used to
return only the origional message headers.
Vaudreuil Standards Track