Representation of Non-ASCII Text in Internet Message Headers
obsoleted by
- rfc-1522 — MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text
Extracted elements (22)
The 75-character limit per encoded-word and 76-character limit per header line were chosen to ease interoperability through internetwork mail gateways and to limit the amount of lookahead a header parser must employ when deciding whether a token is an encoded-word.
The encoding scheme was intentionally designed to use only ordinary printable ASCII characters rather than relying on infrequently-used RFC 822 features such as backslash-quoting, because many deployed mail relaying and reading programs fail to correctly handle those features, and breaking them would cause severe operational problems.
The 'Q' encoding is recommended for Latin character sets because it allows text containing mostly ASCII characters to remain decipherable on an ASCII terminal without decoding, while 'B' (BASE64) is recommended for non-Latin sets where this property is less valuable.
The underscore '_' in 'Q' encoding always represents hexadecimal 20 (SPACE), chosen to greatly enhance readability of Q-encoded data on mail readers that do not support this encoding, even though it may not pass through some internetwork mail gateways.
When multiple character sets could represent the required text, ISO-8859-* series are recommended in the absence of private agreements, with the lowest-numbered set that contains all required characters preferred, to maximize interoperability.
An encoded-word is recognized by beginning with '=?', ending with '?=', containing exactly four '?' characters, and being followed by a SPACE or newline. If a token does not meet these tests, it should be displayed as-is rather than decoded.
An encoded-word must be separated from an adjacent encoded-word, 'word', 'text', 'ctext', or 'special' by a linear white-space character or a newline, preserving compatibility with RFC 822 tokenization rules.
If a mail reader does not support the character set used in an encoded-word, it may either display the encoded-word as ordinary text (verbatim as it appears in the header) or substitute an appropriate message indicating the decoded text could not be displayed.
A conforming mail reading program must be able to display unencoded text if the charset is 'US-ASCII'. For ISO-8859-* character sets, it must at least be able to display characters that are also in the ASCII set.
A mail composing program claiming compliance MUST ensure that any string of printable ASCII characters in a message header beginning with '=?' and ending with '?=' is a valid encoded-word, to avoid ambiguous constructs.
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 recommended for that character set.
A 'Q'-encoded encoded-word appearing inside a comment (delimited by parentheses) MUST NOT contain the characters '(', ')' or '\', since these are special within RFC 822 comments.
An encoded-word MUST NOT appear in any portion of an 'address'. Additionally, an encoded-word MUST NOT be used in a Received header field.
An encoded-word MUST NOT be more than 75 characters long including charset, encoding, encoded-text, and delimiters. Message header lines containing one or more encoded-words SHOULD be no more than 76 characters long.
In a 'phrase' context (e.g., display name before an address), the set of characters permitted in a 'Q'-encoded encoded-word is restricted to: upper/lower-case ASCII letters, decimal digits, '!', '*', '+', '-', '/', '=', and '_'.
When displaying a header field containing encoded-words, an unencoded SPACE immediately following an encoded-word MUST NOT be displayed, and a newline immediately following an encoded-word MUST NOT be displayed unless it is the last token in that field.
An 'encoded-word' is a sequence of printable ASCII characters beginning with '=?', ending with '?=', containing exactly four '?' characters including delimiters. It encodes non-ASCII text in message headers by specifying a charset, an encoding method ('B' or 'Q'), and the encoded text.
Encoded-words may replace 'text' tokens in Subject or Comments header fields, extension message header fields, user-defined header fields, or RFC 1341 body part header fields whose body contains only 'text'. They may also appear within comments or as replacements for 'word' in a 'phrase'.
The 'B' encoding is identical to the BASE64 encoding defined in RFC 1341. It is recommended for non-Latin character sets and automatically satisfies all character restrictions for encoded-text.
The 'Q' encoding is similar to RFC 1341 Quoted-Printable: any 8-bit value may be represented as '=' followed by two hex digits; the underscore '_' always represents hexadecimal 20 (SPACE); other printable ASCII characters (excluding '=', '?', '_', SPACE) may be used literally. It is recommended for Latin character sets.
The RFC explicitly states that security issues are not discussed in this memo. Implementers should nonetheless note that decoding arbitrary 8-bit values and displaying them could cause unwanted side-effects on the recipient's terminal; the document advises mail readers to guard against this.
The encoded-word EBNF grammar is: encoded-word = '=' '?' charset '?' encoding '?' encoded-text '?' '=', where charset is a token (valid RFC 1341 charset), encoding is 'B' or 'Q', and encoded-text is printable ASCII excluding '?' and SPACE.