MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text
obsoleted by
- rfc-2045 — Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
- rfc-2046 — Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
- rfc-2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text
- rfc-2048 — Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures
- rfc-2049 — Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples
obsoletes
- rfc-1342 — Representation of Non-ASCII Text in Internet Message Headers
Extracted elements (24)
In the absence of private agreements, ISO-8859-* character sets are recommended over other charsets when multiple options could represent the same text, to maximize interoperability across the installed base of mail readers.
The 75-character limit per encoded-word was chosen both to ease interoperability through internetwork mail gateways and to bound the lookahead required by a header parser searching for a final '?=' delimiter before deciding whether a token is an encoded-word.
The encoded-word mechanism uses only 'ordinary' printable ASCII characters and deliberately avoids relying on infrequently-used RFC 822 features (e.g., backslash-quoting) because existing mail relaying programs are known to delete, reorder, or rewrap headers and misparse rare RFC 822 constructs. Breaking those programs would cause severe operational problems.
The 'Q' encoding is recommended when most characters are ASCII (leaving the text largely readable without decoding), while 'B' (BASE64) is recommended otherwise. This distinction reflects the different readability trade-offs for human inspection of raw headers.
The underscore '_' in Q encoding represents hex 20 (SPACE) to greatly enhance readability of Q-encoded data on mail readers that do not support this encoding, even though the underscore may not pass through some internetwork mail gateways.
The design explicitly accommodates known deficiencies in deployed mail software: programs that delete some header fields, rearrange To/Cc addresses, reorder header fields vertically, or wrap headers at different column positions than the original. Encoded-words are designed to survive these transformations intact.
When a mail reader does not support the encoding or character set used in an encoded-word, it may display the raw encoded-word as ordinary text, make a best-effort display, or substitute an explanatory message — no single fallback behavior is mandated.
A compliant mail reading program MUST support both 'B' and 'Q' encodings for every character set it supports, MUST be able to display unencoded text when the charset is 'US-ASCII', and for ISO-8859-* charsets must at least display characters also present in ASCII.
A mail composing program claiming compliance MUST ensure that any string within '*text' or '*ctext' that begins with '=?' and ends with '?=' is a valid encoded-word. Any 'word' within a 'phrase' matching that pattern must also be valid.
A mail reader MUST NOT prevent the display or handling of a message solely because an encoded-word is incorrectly formed. A mail reader need not attempt to display the text of a malformed encoded-word, but must not block the entire message.
A mail reader that claims to recognize encoded-words MUST be able to accept either the 'B' or 'Q' encoding for any character set it supports, regardless of which encoding is preferred for that character set.
A 'Q'-encoded encoded-word appearing inside a comment MUST NOT contain the characters '(', ')', or '\'.
An encoded-word in a 'text' header field MUST be separated from any adjacent encoded-word or 'text' by linear-white-space. Similarly, encoded-words within 'phrase' and 'comment' contexts must be separated from adjacent tokens by linear-white-space.
An encoded-word MUST NOT appear in any portion of an 'addr-spec', and MUST NOT be used in a Received header field. These are the only explicitly prohibited locations.
An encoded-word MUST NOT be more than 75 characters long, including charset, encoding, encoded-text, and delimiters. Each line of a header field containing one or more encoded-words is limited to 76 characters.
Each encoded-word MUST encode an integral number of octets, and the encoded-text must be well-formed within a single encoded-word — encoding cannot be continued in the next encoded-word. Additionally, a multi-octet character MUST NOT be split across adjacent encoded-words.
Encoded-words are permitted in exactly three locations: (1) replacing a 'text' token in Subject, Comments, extension, or X- header fields; (2) within a 'comment' (wherever 'ctext' is allowed); (3) as a replacement for a 'word' within a 'phrase' (e.g., before an address in From/To/Cc).
The 'B' encoding is identical to the BASE64 encoding defined by RFC 1521. It is recommended when most characters to be encoded are not in the ASCII character set.
The charset field of an encoded-word may be any character set name permitted in an RFC 1521 'text/plain' charset parameter or any IANA-registered MIME text/plain charset. If a charset uses code-switching, the encoded-word must end with control codes that restore ASCII mode.
The 'Q' encoding is similar to Quoted-Printable from RFC 1521. Any 8-bit value may be represented as '=' followed by two uppercase hexadecimal digits; the underscore '_' always represents hexadecimal 20 (SPACE), regardless of SPACE's code position in the character set in use.
When displaying a header field containing multiple encoded-words, any linear-white-space separating a pair of adjacent encoded-words is ignored, allowing long unencoded strings to be represented across multiple encoded-words without introducing spurious spaces.
Within a 'phrase' context, the set of characters usable in a Q-encoded encoded-word is restricted to upper and lower case ASCII letters, decimal digits, '!', '*', '+', '-', '/', '=', and '_' (underscore).
The RFC explicitly states that security issues are not discussed. However, section 5 notes that mail readers implementing decoding must ensure display of decoded data on the recipient's terminal will not cause unwanted side-effects, implicitly flagging the risk of terminal escape sequences or other hostile content embedded in encoded-words.
An encoded-word has the form '=?' charset '?' encoding '?' encoded-text '?=', where charset and encoding are tokens (no whitespace, no especials), and encoded-text is printable ASCII excluding '?' and SPACE. Both charset and encoding names are case-independent.