Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
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 (31)
Content-Transfer-Encoding is kept independent of Content-Type because encoding appropriateness varies by transport (e.g., 8bit transport needs no encoding for many charsets, while 7bit SMTP does), and different instances of the same media type may require different encodings.
Encoding of composite (multipart/message) body types is forbidden to prevent nested encodings, which add complexity, obscure message structure, and require multiple decode passes just to determine body types. Compatibility and robustness over elegance was the guiding principle of the working group.
The base64 alphabet was chosen because it is represented identically in all versions of ISO 646 and EBCDIC, meeting portability requirements for binary mail transport that alternatives like uuencode, binhex, and base85 do not satisfy.
Two transfer encodings are defined (quoted-printable and base64) because there is a tradeoff: quoted-printable preserves human readability for mostly-7bit data, while base64 provides compact uniform encoding for largely binary data. A single encoding cannot optimize for both.
Quoted-Printable encoded bodies will work reliably over most mail gateways but may not work perfectly over gateways involving EBCDIC translation. For higher reliability through EBCDIC gateways, additionally quoting '!"#$@[\]^`{|}~' per rule #1 is recommended; base64 offers yet higher confidence.
When checking MIME-Version values, any RFC 822 comment strings present must be ignored. For example, 'MIME-Version: 1.(produced by MetaSend Vx.x)0' is equivalent to 'MIME-Version: 1.0'.
A subtype specification is MANDATORY in a Content-Type header field; it may not be omitted. There are no default subtypes.
Any entity with an unrecognized Content-Transfer-Encoding MUST be treated as if it has a Content-Type of 'application/octet-stream', regardless of what the Content-Type header field actually says.
Base64-encoded output stream lines must be no more than 76 characters each. All line breaks and characters not in the base64 alphabet must be ignored by decoding software.
In Quoted-Printable, composers MUST NOT generate non-zero length transport padding (trailing LWSP before CRLF on encoded lines), but receivers MUST be able to handle such padding added by message transports.
In Quoted-Printable encoding, hexadecimal digits MUST be uppercase; lowercase letters in 'abcdef' are formally illegal. TAB and SPACE MUST NOT appear at the end of an encoded line; trailing whitespace must be deleted on decode.
In the absence of a Content-Type header field, or when a syntactically invalid Content-Type is encountered, the default media type is 'text/plain; charset=us-ascii'. This default SHOULD also be assumed for syntactically invalid Content-Type fields.
It is EXPRESSLY FORBIDDEN to use any Content-Transfer-Encoding other than '7bit', '8bit', or 'binary' with any composite media type (currently 'multipart' and 'message'). All desired encodings must be applied at the innermost body level.
Messages composed in accordance with RFC 2045 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 each body part of a multipart entity.
MIME implementations MUST ignore any Content-Type parameters whose names they do not recognize. This ensures forward compatibility with new parameters.
New standardized Content-Transfer-Encoding values must be specified by a standards-track RFC; all CTE namespace except 'X-' prefixed tokens is reserved to the IETF. Private CTEs must use an 'X-' prefix.
New top-level media type tokens not prefixed with 'X-' must be defined by a standards-track extension to the MIME standard and registered with IANA. Private experimental types must use an 'X-' prefix.
Text line breaks must be converted to CRLF sequences before base64 encoding when encoding text that has not been converted to canonical form. This may be done directly by the encoder rather than as a separate canonicalization step.
The Content-ID header field is generally optional but its use is MANDATORY in implementations that generate data of the 'message/external-body' media type; each such entity must have a Content-ID to permit caching.
The proper Content-Transfer-Encoding label MUST always be used. Labelling unencoded data containing 8bit characters as '7bit' is not allowed, nor is labelling non-line-oriented data as anything other than 'binary'.
When encoding binary data in Quoted-Printable, CR and LF MUST be encoded as '=0D' and '=0A' respectively; a CRLF in binary data must be encoded as '=0D=0A' to avoid incorrect decoding on platforms with different newline conventions.
The Content-Description header field ('Content-Description: *text') is always optional and provides a human-readable description of the body, presumed in US-ASCII. Non-ASCII values may use the RFC 2047 encoding mechanism.
The Content-ID header field is syntactically identical to the Message-ID field ('Content-ID: ' msg-id) and must be generated to be world-unique. It uniquely identifies MIME entities for reference and caching purposes.
MIME media types (top-level types and subtypes) are registered with IANA as specified in RFC 2048. New standard subtype values must be registered; private values use an 'X-' prefix and cannot be registered.
The Content-Transfer-Encoding namespace is reserved to the IETF except for 'X-' prefixed private tokens. New standardized CTE values must be specified by a standards-track RFC meeting requirements in RFC 2048.
Security issues for MIME are discussed in RFC 2046 (the second document in the MIME set). RFC 2045 itself defers security considerations to that companion document.
Base64 encodes 24-bit groups of input as 4 printable characters using a 65-character US-ASCII alphabet (A–Z, a–z, 0–9, '+', '/', '=' for padding). Output lines must be no more than 76 characters; padding uses '=' to complete the final quantum to a multiple of 4 characters.
In Quoted-Printable encoding, any octet may be represented as '=' followed by two uppercase hexadecimal digits (e.g., '=3D' for '='). Encoded lines must be no more than 76 characters long, not counting the trailing CRLF; soft line breaks are indicated by '=' as the last character.
The Content-Transfer-Encoding field value is a single case-insensitive token: one of '7bit', '8bit', 'binary', 'quoted-printable', 'base64', or an ietf-token or x-token. The default value when the field is absent is '7bit'.
The Content-Type header field syntax is 'Content-Type: type "/" subtype *(";", parameter)'. Type and subtype names are case-insensitive; parameter names are case-insensitive but parameter values are case-sensitive unless otherwise specified.
The MIME-Version field is encoded as 'MIME-Version: ' followed by two integer fields separated by a period (e.g., '1.0'). RFC 822 comment strings present in the value MUST be ignored when checking the version.