Overview and Framework for Internationalized Email
obsoletes
Extracted elements (27)
ASCII-compatible encoding (ACE/Punycode) in the domain part is discouraged when the local part of an address includes non-ASCII characters, in order to promote consistent processing of characters throughout the entire address and avoid user confusion from mixed encoding forms.
In-transit downgrading of local parts is architecturally prohibited because a relay has no way to distinguish whether a local part such as 'user%foo@example.com' encodes routing information or is simply a local address. Only the final delivery server can safely interpret local-part semantics.
In-transit downgrading was eliminated from the standards-track specifications after experimentation revealed that the earlier mechanism (RFC 5504) caused interoperability problems among initial implementations and was more complex and less necessary than assumed. Requiring each non-ASCII address to be accompanied by an all-ASCII equivalent also raised unauthenticated address-pairing security concerns.
Supporting Unicode NFC normalization (and preferably NFKC) is recommended for mailbox names, and servers should support aliases or normalization for variant forms rather than depending on senders to supply normalized strings, because client-side processes outside MUA control may cause normalization regardless of user intent.
The SMTPUTF8 extension now requires a client announcement when the extension is needed, unlike the experimental version where only a server announcement was necessary. This change reflects the lesson from experimentation that explicit client opt-in is required for reliable interoperability.
Applications using mbox-format or similar encapsulations that assume all stored messages have ASCII message headers (message/rfc822 with ASCII) are not ready for SMTPUTF8 extensions and may require special measures to detect and process internationalized messages.
Email addresses used as identifiers in contexts such as X.509 certificates and web commerce systems will encounter difficulties when internationalized addresses are first used, because many such systems cannot handle even the full range of addresses permitted by existing ASCII-only email standards.
Message parts that are cryptographically signed (S/MIME or PGP) or encrypted cannot be upgraded from RFC 2047 encoded-word form to normal UTF-8 without breaking the signature or requiring cryptographic key access. MUAs and mail filtering software must continue to accept and decode RFC 2047 encoded words indefinitely.
A final delivery MTA that accepts SMTPUTF8 SHOULD NOT be configured with lower-preference MX hosts that do not support the extension, as this creates configuration errors that prevent delivery of messages with non-ASCII forward-pointing addresses.
An SMTP relay that receives a message with non-ASCII addresses MUST either explicitly recognize the internationalized format by agreeing via an ESMTP option, or reject the message (or, if necessary, return a non-delivery notification) so the sender can make another plan.
Backspace MUST NOT appear in SMTPUTF8 mailbox names. Backspace was permitted by RFC 821 but prohibited by RFC 5321 for ASCII addresses; its prohibition is extended to non-ASCII strings because it is even more problematic for canonicalization and normalization.
If a final delivery MTA downgrades internationalized emails or specially identifies messages utilizing extensions, it SHOULD include a mechanism to preserve or recover the original internationalized forms without information loss, to support access by SMTPUTF8-aware agents.
If a message cannot be forwarded because the next-hop system cannot accept the SMTPUTF8 extension, the message MUST be rejected or a non-delivery message MUST be generated and sent.
If a system implements IMAP or POP, it MUST conform to the internationalized IMAP or POP specifications respectively when supporting SMTPUTF8.
If an SMTP server advertises both the SMTPUTF8 and the DSN extension, that server MUST implement internationalized DSNs including support for the ORCPT parameter specified in RFC 3461.
If the SMTPUTF8 extension is not supported by the first-hop system, message-originating systems SHOULD be prepared to either send conventional envelopes and message headers or to return the message to the originating user so it may be manually downgraded.
In the interest of interoperability, charsets other than UTF-8 are prohibited in mail addresses and message headers transmitted over the Internet. There is no practical way to identify multiple charsets properly without introducing great complexity.
Special attention MUST be paid to Unicode normalization for mailbox names containing non-ASCII characters, because Unicode strings may be normalized by processes independent of what the mail protocol specifies, analogously to quoting/dequoting in traditional addresses.
The local part of an email address MUST be interpreted and assigned semantics only by the host specified in the domain part of the address. This rule — unchanged since RFC 1123 (1989) — means that in-transit downgrade mechanisms that transform local parts cannot be used in relay.
When email local parts are internationalized, they SHOULD be accompanied by arrangements for the message headers to be in fully internationalized form. That form SHOULD use UTF-8 rather than ASCII as the base character set for header field contents.
A 'conventional message' is one strictly conformant to RFC 5322 that uses no extensions from RFC 6531 or RFC 6532. An 'internationalized message' utilizes one or more of those extensions and is no longer conformant to the traditional email message specification or its transport.
The 'final delivery MTA' is the SMTP server that controls the format of local parts and is the only entity permitted to inspect and interpret them. It receives messages from the network for delivery to mailboxes or other local processing; local delivery arrangements such as message stores and IMAP/POP access are 'behind' it and outside SMTP transport.
The SMTPUTF8 extension is the umbrella term for email address internationalization defined by this framework and its companion documents. It permits UTF-8 strings in email address local parts and domain names, selective UTF-8 in message headers, and requires 8BITMIME support. All-ASCII addresses and non-ASCII (i18n) addresses are mutually exclusive sets; SMTPUTF8 permits their union.
Any downgrading mechanism must not assume authenticated bindings between internationalized and ASCII addresses. This risk is mitigated by performing transformations prior to final delivery at systems under the administrative control of the sending user, rather than in transit by uncontrolled intermediaries.
DKIM and other signed-header mechanisms will need coordination with SMTPUTF8 internationalization. S/MIME and PGP body-part signatures are largely unaffected, but downgrading of signed messages must be performed with extreme care because even subtle changes may invalidate signatures on primary or MIME body part headers.
IDN homograph attacks (look-alike character spoofing) apply to the local part of internationalized email addresses just as they do to domain names in URLs. The fix of forcing displayed elements to normalized lowercase that works for domain names does not apply to email local parts, which are case-sensitive.
New UTF-8 header and message formats may create filter-evasion attacks: a malformed or 'invalid' internationalized message may be interpreted differently by a spam/security filter than by the recipient's MUA, allowing content to bypass filtering. Analogous attacks already exist for invalid MIME syntax, HTML markup, and image encodings.