It is frequently desirable, in sending mail, to encapsulate another
mail message. For this common operation, a special Content-Type,
"message", is defined. The primary subtype, message/rfc822, has no
required parameters in the Content-Type field. Additional subtypes,
"partial" and "External-body", do have required parameters. These
subtypes are explained below.
NOTE: It has been suggested that subtypes of message might be
defined for forwarded or rejected messages. However, forwarded
and rejected messages can be handled as multipart messages in
which the first part contains any control or descriptive
information, and a second part, of type message/rfc822, is the
forwarded or rejected message. Composing rejection and forwarding
messages in this manner will preserve the type information on the
original message and allow it to be correctly presented to the
recipient, and hence is strongly encouraged.
As stated in the definition of the Content-Transfer-Encoding field,
no encoding other than "7bit", "8bit", or "binary" is permitted for
messages or parts of type "message". Even stronger restrictions
apply to the subtypes "message/partial" and "message/external-body",
as specified below. The message header fields are always US-ASCII in
any case, and data within the body can still be encoded, in which
case the Content-Transfer-Encoding header field in the encapsulated
message will reflect this. Non-ASCII text in the headers of an
encapsulated message can be specified using the mechanisms described
in [RFC-1522].
Mail gateways, relays, and other mail handling agents are commonly
known to alter the top-level header of an RFC 822 message. In
particular, they frequently add, remove, or reorder header fields.
Such alterations are explicitly forbidden for the encapsulated
headers embedded in the bodies of messages of type "message."
