MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies
obsoleted by
- rfc-1521 — MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies
Extracted elements (28)
Nested Content-Transfer-Encodings are prohibited for multipart and message types to prevent data from being passed through encoding algorithms multiple times, which adds complexity to user agents and can obscure the basic structure of a message by requiring multiple decoding operations to determine its content types.
The Base64 alphabet was chosen as a 65-character subset of US-ASCII because it is represented identically in all versions of ISO 646 and all versions of EBCDIC, meeting the portability requirement for a binary mail transport encoding. Other encodings such as uuencode and base85 do not share this property.
Two Content-Transfer-Encodings (Quoted-Printable and Base64) are defined rather than one because there is an inherent tradeoff: QP remains human-readable for mostly-ASCII data while Base64 is more compact and reliable for binary data. A single mechanism cannot satisfy both needs.
As of publication, no standardized Internet transports support unencoded 8-bit or binary data in mail bodies; thus '8bit' and 'binary' Content-Transfer-Encoding values are not actually legal on the Internet at the time of this specification but are defined prospectively for future 8-bit-capable transports.
The creation of new Content-Transfer-Encoding values is explicitly and strongly discouraged as likely to hinder interoperability with little benefit. Their use is allowed only by agreement between cooperating user agents and must use the 'X-' prefix convention.
A subtype specification in the Content-Type field is MANDATORY; there are no default subtypes. New non-standard top-level Content-Types must use names starting with 'X-' to indicate non-standard status and avoid conflict with future official names.
For entities of type 'multipart' or 'message', the Content-Transfer-Encoding is not permitted to have any value other than a bit-width token (7bit, 8bit, etc.) or 'binary'. Encoding of content within multipart or message bodies must be done at the innermost level by encoding the actual nested body.
In Quoted-Printable encoding, TAB (HT) and SPACE characters MUST NOT appear at the end of an encoded line because some MTAs pad or strip trailing whitespace. When decoding, any trailing whitespace on a line must be deleted as it may have been added by intermediate transport agents.
Messages composed in accordance with MIME MUST include a MIME-Version header field with the verbatim value '1.0'. This field is required at the top level of a message but not for individual body parts of a multipart entity; it is required for embedded message headers only if the embedded message is itself claimed to be MIME-compliant.
The character set name 'ASCII' is reserved and MUST NOT be used for any purpose; 'US-ASCII' (referring specifically to ANSI X3.4-1986) must be used instead. National use variations of ISO 646 are NOT ASCII and their use in Internet mail is explicitly discouraged.
When no Content-Type header is present the default is 'text/plain; charset=us-ascii'. When a mail reader encounters an unknown Content-Type value, it should generally treat it as equivalent to 'application/octet-stream'.
Seven standard top-level Content-Types are defined: text, multipart, message, image, audio, video, and application. This set is intended to be substantially complete; extensions to supported types should generally be accomplished by creating new subtypes rather than new top-level types.
The 'application/octet-stream' subtype is the primary type for uninterpreted binary data. The recommended default action on receipt is to offer to write the data to a file. Optional parameters include 'type', 'padding', 'name', and 'conversions'.
The Content-Transfer-Encoding header field specifies the encoding transformation applied to the body for transport. Defined values are BASE64, QUOTED-PRINTABLE, 8BIT, 7BIT, and BINARY; the default when the field is absent is 7BIT. Values are case-insensitive.
The 'message/External-body' subtype specifies large body content by reference to an external data source. The required 'access-type' parameter indicates the retrieval mechanism; defined access types include ftp, anon-ftp, tftp, local-file, afs, and mail-server.
The 'message/partial' subtype enables fragmented transmission of large message bodies. It requires 'id', 'number', and 'total' parameters identifying the fragment group, sequence position, and total count; fragments must be reassembled in 'number' order before the body is presented.
The 'multipart' Content-Type combines multiple body parts of independent data types using a boundary delimiter. Four subtypes are defined: mixed (default), alternative (same data in multiple formats), parallel (simultaneous display), and digest (each part is of type message).
The optional Content-Description header field associates descriptive free-text with a body part. Its value is '*text', presumed to be US-ASCII; the RFC 1342 encoded-word mechanism may be used for non-ASCII values.
The optional Content-ID header field, syntactically identical to the RFC 822 Message-ID field, labels a body part so that other bodies may reference it. Values must be generated to be as unique as possible.
The 'text/plain' subtype with 'charset' parameter is the default Internet mail body type, representing unformatted text. The charset parameter default is US-ASCII and is case-insensitive. Defined charset values include US-ASCII and ISO-8859-1 through ISO-8859-9.
The 'text/richtext' subtype defines a simple SGML-compatible markup format using angle-bracket formatting commands such as <bold>, <italic>, <nl>, and <np>. Commands must be properly balanced and nested; implementations MUST treat any unrecognized command as equivalent to 'No-op' to facilitate extensibility.
IANA serves as the central registry for MIME Content-Type/subtype values, character set names, access-type values, and Content-Transfer-Encoding names. New standard subtypes must be documented, registered with, and approved by IANA; private extensions must use the 'X-' prefix. All Content-Transfer-Encoding namespace not beginning with 'X-' is explicitly reserved to IANA.
Active (computational) email types such as application subtypes that execute programs entail security risks including unauthorized file access, arbitrary resource consumption, and sending of forged mail on the user's behalf. User agents must inform users before executing such content.
The application/PostScript type poses significant security risks because PostScript is a full Turing-complete programming language capable of reading, writing, and deleting files. Implementations should provide appropriate sandboxing or user warnings before executing PostScript received from untrusted sources.
Base64 encodes 24-bit input groups as 4-character output strings using a 65-character alphabet (A–Z, a–z, 0–9, '+', '/', and '=' for padding). Output lines must not exceed 76 characters. Fewer than 24 trailing input bits are zero-padded and output positions not representing actual data are set to '='.
Multipart body parts are delimited by lines of the form '--<boundary>' and the final boundary is '--<boundary>--'. The 'boundary' parameter in the Content-Type is case-sensitive and MUST NOT appear within any body part. A preamble before the first boundary and an epilogue after the last are allowed and must be ignored by decoders.
Quoted-Printable encoding represents non-printable octets as '=' followed by two uppercase hexadecimal digits (e.g., '=0C' for form feed). Octets 33–60 and 62–126 MAY be represented as their literal ASCII characters. Lines MUST NOT exceed 76 characters; a trailing '=' on a line indicates a soft (non-significant) line break.
The Content-Type header field is defined as 'type "/" subtype *(";", parameter)' where type is one of the seven standard types or an x-token, subtype is a token, and parameters are attribute=value pairs. Type, subtype, and parameter names are case-insensitive; parameter values are case-sensitive unless otherwise specified for the specific parameter.