MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text
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 (26)
'Q' encoding is recommended when most characters are ASCII (preserving readability without decoding), while 'B' (BASE64) is recommended otherwise. Mandating that readers accept both encodings for any supported charset prevents sender-choice lock-in and interoperability failures.
The 75-character per encoded-word and 76-character per line limits were chosen to ease interoperability through internetwork mail gateways and to bound the lookahead a header parser must perform before deciding whether a token is an encoded-word.
The encoded-word scheme uses sequences of ordinary printable ASCII (=?...?=) rather than raw 8-bit characters or obscure RFC 822 features, because existing mail relays are known to delete fields, reorder addresses, wrap headers, and misparse backslash-quoted characters — making 8-bit or non-atom approaches operationally dangerous.
The 'Q' encoding uses '_' (underscore) to represent SPACE to greatly enhance readability on ASCII terminals that do not support encoded-word decoding. The underscore always means 0x20 regardless of the code position of SPACE in the charset, even though it may not survive all mail gateways.
A MIME-Version header field is NOT required to be present for encoded-words to be interpreted per this specification. This allows mail readers to decode encoded-words in displayed fields without first parsing the entire message header.
It is NOT generally possible to translate a message header containing encoded-words into an unencoded form parseable by a plain RFC 822 reader. Decoding occurs after structured field parsing, so encoded-words can conceal 'special' characters indistinguishable from those in surrounding text.
This specification explicitly does not define any translation between '8-bit headers' and pure ASCII headers, and no such translation is assumed to be possible. Implementations must not conflate encoded-word headers with 8-bit header schemes.
Within a 'comment', the RFC 822 ABNF is amended so that 'encoded-word' is a valid alternative to 'ctext' or 'quoted-pair'. However, this rule does NOT apply to '*text' fields, where '(' and ')' are treated as ordinary characters rather than comment delimiters.
A conformant mail reading program must support both 'B' and 'Q' encodings for any character set it supports, must be able to display unencoded text when charset is US-ASCII, and must display at least the ASCII-range characters for ISO-8859-* charsets.
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 this pattern must also be a valid encoded-word.
A mail reader claiming 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 charset.
A mail reader MUST NOT prevent the display or handling of a message because an encoded-word is incorrectly formed. The reader need not attempt to display the text of a malformed encoded-word, but must not block the entire message.
An encoded-word in a '*text' header field MUST be separated from any adjacent encoded-word or text by linear-white-space. The same separation requirement applies within 'comment' and 'phrase' contexts.
An 'encoded-word' may not be more than 75 characters long, including charset, encoding, encoded-text, and delimiters. Each line of a header field that contains one or more encoded-words is limited to 76 characters.
An encoded-word MUST NOT appear in any portion of an 'addr-spec', within a 'quoted-string', in a Received header field, or in a parameter of a MIME Content-Type or Content-Disposition field (except within a 'comment' or 'phrase').
If a charset uses code-switching techniques to leave ASCII mode, the encoded-word MUST contain additional control codes so that ASCII mode is restored at the end of that encoded-word. This rule applies separately to each encoded-word, including adjacent ones in the same field.
In a 'phrase' context (preceding an address), Q-encoded text is restricted to upper/lower ASCII letters, decimal digits, and the characters '!', '*', '+', '-', '/', '=', and '_'. Other characters including RFC 822 specials are not permitted.
Only printable and white space character data should be encoded using encoded-words. Mail readers SHOULD ensure that display of decoded data will not cause unwanted side-effects on the recipient's terminal, since the encoding allows arbitrary octet values.
The encoded-text in an encoded-word MUST be self-contained and MUST NOT be continued across encoded-words. Each encoded-word MUST encode an integral number of octets and represent an integral number of characters; a multi-octet character may not be split across adjacent encoded-words.
When displaying a header containing multiple adjacent encoded-words, any linear-white-space separating them MUST be ignored (not displayed), allowing long strings to span multiple encoded-words without introducing spurious spaces.
White space characters (SPACE and HTAB) are FORBIDDEN within an encoded-word; they must be encoded (e.g., SPACE as '=20' in Q encoding). An encoded-word must appear as an 'atom' to an RFC 822 parser, so unencoded white space breaks parsing.
Encoded-words are permitted in exactly three contexts: (1) replacing 'text' tokens in Subject, Comments, extension, or MIME body part header fields; (2) within 'comment' delimiters wherever 'ctext' is allowed; (3) as a 'word' within a 'phrase' preceding an address in From, To, or Cc headers.
The 'B' encoding is identical to the BASE64 encoding defined in RFC 2045. The encoded-text portion of a 'B' encoded-word will always be a multiple of 4 characters long.
The 'Q' encoding is similar to Quoted-Printable (RFC 2045): any 8-bit value may be encoded as '=' followed by two uppercase hex digits; '_' (underscore, ASCII 95) always represents hexadecimal 20 (SPACE); other printable ASCII characters except '=', '?', and '_' MAY be used as-is. SPACE and TAB MUST NOT appear literally.
The RFC states that security issues are not discussed. However, Section 6.2 identifies an implicit risk: since decoding of encoded-words occurs after structured field parsing, special characters can be hidden inside encoded-words that, when displayed, are visually indistinguishable from structural characters in surrounding text — a potential header-spoofing vector.
An 'encoded-word' has the syntax: '=?' charset '?' encoding '?' encoded-text '?='. The charset and encoding are case-independent tokens; encoded-text is 1 or more printable ASCII characters excluding '?' and SPACE. White space MUST NOT appear between components.