Internationalized Email Headers
obsoletes
- rfc-5335 — Internationalized Email Headers
updates
- rfc-2045 — Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
Extracted elements (25)
Encoded-words (RFC 2047) are deprecated for this extension because they only work in a subset of header locations, require complex processing, allow arbitrary charsets, and create significant error opportunities; direct UTF-8 is now available on most systems and is simpler.
NFC is preferred over NFKC because the design goal of internationalization is to let people spell their names correctly; NFKC's compatibility decompositions can destroy distinctions needed for some names. Since mailbox local parts often reflect personal names, name-preserving normalization is load-bearing.
RFC 2045's prohibition on content-transfer-encodings for message/ subtypes is relaxed because message/global may need encoding when downgraded from 8-bit to 7-bit per RFC 6152. Allowing nested encodings was deemed less complex than alternative approaches even though multiple encoding levels may occur in practice.
This specification is based on a native, end-to-end UTF-8 model requiring an 8-bit-clean transport environment. Support for carriage across legacy 7-bit infrastructure and processing by 7-bit receivers is explicitly out of scope and requires separate mechanisms.
A MIME-compliant system that does not recognize message/global is specified to treat it as 'application/octet-stream' per RFC 2046 Section 5.2.4, meaning the structure is opaque rather than parsed as a nested message.
Implementers generating Message-IDs MAY prefer restricting output to ASCII to ease construction of 'In-reply-to:' and 'References:' threading headers in mailing lists where some senders use internationalized addresses and others do not.
When embedding or returning internationalized content, senders may choose message/global (preserve content) or down-convert to message/rfc822. Systems unaware of internationalized headers will treat message/global as an unknown attachment, while systems that understand it provide superior functionality.
An 8-bit or binary content-transfer-encoding SHOULD be used for message/global unless this media type is sent over a 7-bit-only transport.
Encoded-words (RFC 2047) SHOULD NOT be used when generating header fields for messages employing this extension; agents MAY convert encoded-word use to direct UTF-8 when incorporating material from another message.
Header field names themselves must consist of ASCII characters only; only the bodies of header fields are allowed to contain Unicode characters.
If a message/global object is sent to a 7-bit-only system, it MUST have an appropriate content-transfer-encoding applied.
Internationalized messages in message/global format MUST only be transmitted as authorized by RFC 6531 (SMTPUTF8 extension) or within a non-SMTP environment that supports these messages.
NFKC normalization SHOULD NOT be used because it may lose information needed to correctly spell some names in unusual circumstances.
Normalization form NFC SHOULD be used for UTF-8 content in header fields, to support correct spelling of personal names and mailbox local parts.
Processors that elect to decode encoded-words MUST NOT generate syntactically invalid fields, because replacing an encoded-word with its decoded UTF-8 equivalent may be syntactically invalid.
Section 2.1.1 of RFC 5322's line length limit is changed from 998 characters to 998 octets, since UTF-8 multi-byte characters make octets and characters non-equivalent.
RFC 5322 ABNF rules VCHAR, ctext, atext, qtext, text, and dtext are each extended with '=/ UTF8-non-ascii', allowing UTF-8 in unstructured text, atoms (including address local parts and Message-IDs), quoted strings, and domains.
The message/global media type is defined for Internet messages containing 8-bit UTF-8 header values or 8-bit UTF-8 values in body-part header fields. Its content is otherwise identical to message/rfc822. Any content-transfer-encoding is permitted; file extension '.u8msg' is suggested.
UTF8-non-ascii is defined as UTF8-2 / UTF8-3 / UTF8-4 (per Section 4 of RFC 3629), and is the terminal used throughout ABNF extensions to allow non-ASCII characters in header field values.
IANA updated the registration for the message/global MIME type using the registration form in Section 3.7. The subtype is 'global' under the 'message' type, with any content-transfer-encoding permitted and suggested file extension '.u8msg'.
Because UTF-8 multi-byte sequences make addresses and header values longer, MDA processes that parse, store, or handle email addresses or local parts must take extra care not to overflow buffers, truncate addresses, exceed storage allotments, or use partial lengths when comparing addresses.
The security impact of UTF-8 headers on email signature systems (DKIM, S/MIME, OpenPGP) is discussed in Section 14 of RFC 6530. Certificates for users with both non-ASCII and ASCII mailbox addresses may carry both as identities, which is supported by PKIX and OpenPGP but may introduce user-interface issues.
UTF-8 provides many ways to represent visually equivalent characters or sequences; the normalization process in Section 3.1 (NFC) is recommended to minimize spoofing and equivalence attacks. Implementers are directed to the security considerations in RFC 3629 for details.
Line length limit for internationalized email headers is 998 octets (excluding CRLF), changed from the RFC 5322 character-based limit. The 78-character soft limit remains defined in characters (display-width), not octets.
UTF-8 header field values are transmitted as raw 8-bit octets encoded per RFC 3629 (UTF8-2/3/4 sequences), requiring an 8-bit-clean channel; 7-bit downgrade requires wrapping the message/global part with a content-transfer-encoding.