Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
obsoletes
- rfc-1521 — MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies
- rfc-1522 — MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text
- rfc-1590 — Media Type Registration Procedure
updated by
Extracted elements (30)
In 'multipart/alternative', the plainest format is placed first (not last) to maximize friendliness when viewed by non-MIME-conformant readers, even though this imposes a burden on conformant MIME viewers. Interoperability with older mail readers was deemed more important.
'message/partial' is restricted to 7bit encoding because binary fragments passing through a 7bit gateway cannot be re-encoded without waiting for all fragments—and different fragments may traverse different gateways, making reassembly-then-encoding impractical.
The multipart boundary mechanism was chosen over RFC 934 encapsulation because RFC 934 quoting causes lines to grow with each level of nesting. Combined with SMTP implementations that wrap long lines, RFC 934 was unsuitable for deeply-nested multipart structures.
Multipart messages are NOT completely compatible with RFC 934 encapsulations; in particular, they do not obey RFC 934 quoting conventions for embedded lines beginning with hyphens. Implementations must not assume RFC 934 compatibility.
Unrecognized subtypes of 'text' should be treated as subtype 'plain' as long as the charset is known. Unrecognized subtypes that also specify an unrecognized charset should be treated as 'application/octet-stream'.
Any 'multipart' subtype that an implementation does not recognize must be treated as being equivalent to 'multipart/mixed'. All subtypes of 'multipart' must use the identical syntax defined for the type.
Composers MUST NOT generate non-zero length transport padding after boundary delimiter lines, but receivers MUST be able to handle padding added by message transports. Trailing whitespace on a boundary line must be presumed gateway-added and deleted.
During reassembly of 'message/partial' fragments: header fields from the initial enclosing message (except Content-* and Subject/Message-ID/Encrypted/MIME-Version) are copied to the new message; Content-* and the named fields from the enclosed message are appended; all headers from subsequent enclosing messages are discarded.
Encapsulated headers in ALL 'message/external-body' entities MUST include a Content-ID header field to provide a unique identifier for caching and mail-server receipt recognition. The ACCESS-TYPE parameter is unconditionally mandatory and MUST be present on every 'message/external-body'.
Entities of type 'message/external-body' MUST have a content-transfer-encoding of 7bit. Use of '8bit' or 'binary' is explicitly prohibited even in environments that support such transport.
Entities of type 'message/partial' must always have a content-transfer-encoding of 7bit. Even in environments that support binary or 8bit transport, use of '8bit' or 'binary' encoding is explicitly prohibited for 'message/partial'.
For 'message/rfc822', at least one of 'From', 'Subject', or 'Date' must be present (relaxing RFC 822's requirement for From, Date, and a destination header). No encoding other than '7bit', '8bit', or 'binary' is permitted for the body.
Fragmentation agents must split messages at line boundaries only, because many transports cannot preserve the semantics of messages that do not end with a CRLF sequence. Splits at non-line-boundary points are explicitly forbidden.
Implementations must ignore anything that appears before the first boundary delimiter line (preamble) or after the last one (epilogue). No encoding other than '7bit', '8bit', or 'binary' is permitted for entities of type 'multipart'.
Mail gateways, relays, and other agents are explicitly forbidden from altering, adding, removing, or reordering header fields of RFC 822 messages encapsulated in 'message' type bodies.
MIME implementations are required to recognize outer-level boundary markers at ANY level of inner nesting when handling nested messages and multiparts. It is not sufficient to check only for the next expected marker or terminating condition.
MIME implementations must at a minimum treat any unrecognized subtypes of 'application' as being equivalent to 'application/octet-stream'. Similarly, unrecognized subtypes of 'image', 'audio', and 'video' should at a minimum be treated as 'application/octet-stream'.
MIME implementations must ignore any parameters whose names they do not recognize. This ensures forward compatibility as new parameters are defined.
The boundary delimiter MUST NOT appear inside any of the encapsulated parts, on a line by itself or as the prefix of any line. The composing agent must choose a unique boundary parameter value that does not contain the boundary of any enclosing multipart as a prefix.
The canonical form of any MIME 'text' subtype MUST always represent a line break as a CRLF sequence. Similarly, any occurrence of CRLF in MIME 'text' MUST represent a line break. Use of CR and LF outside of line break sequences is forbidden.
The default character set for 'text' content, which must be assumed in the absence of a charset parameter, is US-ASCII. The charset parameter values are NOT case sensitive. No character set name other than defined ones may be used without IANA registration or private agreement (prefixed 'X-').
In 'multipart/alternative', body parts appear in order of increasing faithfulness to the original content (plainest first, richest last). Receiving agents should pick and display the last format they are capable of displaying, and must not automatically show the user multiple versions.
In 'multipart/digest', the default Content-Type for body parts is changed from 'text/plain' to 'message/rfc822', allowing digest formats largely compatible with RFC 934 while retaining MIME structure.
The 'message/partial' type requires three Content-Type parameters: 'id' (unique identifier matching fragments), 'number' (integer fragment sequence position, starting at 1), and 'total' (required on the final fragment, optional on earlier ones).
IANA serves as the central registry for MIME media types (top-level types, subtypes), character sets, access-types for 'message/external-body', and content-transfer-encodings. New values for these areas must be registered per the procedures described in RFC 2048.
Executing PostScript bodies poses serious security risks. Dangerous operators include 'deletefile', 'renamefile', 'filenameforall', 'file', 'exitserver', 'startjob', 'setsystemparams', and 'setdevparams'. Receiving software should completely disable these operators or ensure their operation is treated as being by an outside agency.
It is strongly recommended that implementations NOT implement a path-search mechanism whereby an arbitrary program named in a Content-Type parameter (e.g., an 'interpreter=' parameter) is found and executed using the message body as input, to reduce the danger of transmitting rogue programs.
PostScript programs can consume unbounded system resources or loop indefinitely, constituting a denial-of-service threat. Message receiving software should provide mechanisms to abort processing after a reasonable time and limit resource consumption by PostScript interpreters.
A multipart body consists of an optional preamble, followed by one or more dash-boundary/body-part sequences, and a close-delimiter. The boundary delimiter MUST occur at the beginning of a line (following a CRLF); the preceding CRLF is considered attached to the boundary, not the prior part.
The multipart boundary parameter consists of 1 to 70 characters from the set of bchars (alphanumeric plus "'()+_,-./:=?") and space, but must NOT end with whitespace. The dash-boundary is '--' followed by the boundary value. The close-delimiter appends '--' after the final boundary.