Overview and Framework for Internationalized Email
Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document s
Replaces RFC 4952: Overview and Framework for Internationalized Email, RFC 5504: Downgrading Mechanism for Email Address Internationalization, RFC 5825: Displaying Downgraded Messages for Email Address Internationalization.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 6 must, 5 should, 5 may.
4.2 Address Character Sets
- MAYSuch addresses MAY be restricted in other ways, but those restrictions are not relevant to this definition.
4.7 Undeliverable Messages, Notification, and Delivery Receipts
- MAYA sender MAY also explicitly request message receipts [RFC3461] that raise the same issues for these internationalization extensions as NDNs.
7.1 SMTP Extension for Internationalized Email Address
- MUSTIf the message cannot be forwarded because the next-hop system cannot accept the extension, it MUST be rejected or a non- delivery message MUST be generated and sent.
- MUSTIf the system implements IMAP or POP, it MUST conform to the internationalized IMAP [RFC5738bis-IMAP] or POP [RFC5721bis-POP3] specifications respectively.
7.2 Transmission of Email Header Fields in UTF-8 Encoding
- SHOULDWhen email local parts are internationalized, they SHOULD be accompanied by arrangements for the message headers to be in the fully internationalized form.
- SHOULDThat form SHOULD use UTF-8 rather than ASCII as the base character set for the contents of header fields (protocol elements such as the header field names themselves are unchanged and remain entirely in ASCII).
7.3 SMTP Service Extension for DSNs
- MUSTIf 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 [RFC3461].
8 Downgrading before and after SMTP Transactions
- MAYBut, when systems that support these extensions send mail, they MAY include non-ASCII addresses for senders, receivers, or both and might also provide non-ASCII header information other than addresses.
- SHOULDIf the extension is not supported by the first-hop system (i.e., the SMTP server accessed by the submission server acting as an SMTP client), message-originating systems SHOULD be prepared to either send conventional envelopes and message headers or to return the message to the originating user so the message may be manually downgraded to the traditional form, possibly using encoded words [RFC2047] in the message headers.
- SHOULD NOTIt is important to note that most cases of that situation with forward-pointing addresses will be the result of configuration errors: especially if it hosts non-ASCII addresses, a final delivery MTA that accepts these extensions SHOULD NOT be configured with lower-preference MX hosts that do not.
8.2 Downgrading or Other Processing after Final SMTP Delivery
- MAYSince the final delivery MTA (or, to be more specific, its corresponding mail storage agent) cannot safely assume that agents accessing email storage will always be capable of handling the extensions proposed here, it MAY downgrade internationalized emails, specially identify messages that utilize these extensions, or both.
- SHOULDdelivery MTA SHOULD include a mechanism to preserve or recover the original internationalized forms without information loss.
9 Downgrading in Transit
- MUSTThe base SMTP specification (Section 2.3.11 of RFC 5321 [RFC5321]) states that "due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address".
10.1 Choices of Mailbox Names and Unicode Normalization
- MAYThe local parts of those addresses MAY be made up of any ASCII characters except the control characters that RFC 5321 prohibits, although some of them MUST be quoted as specified there.
- MUST NOTBecause RFC 5321 (and its predecessor, RFC 2821) prohibit the use of this character in ASCII mailbox names and it is even more problematic (for canonicalization and normalization reasons) in non-ASCII strings, backspace MUST NOT appear in SMTPUTF8 mailbox names.
- MUSTFor the particular case of mailbox names that contain non-ASCII characters in the local part, domain part, or both, special attention MUST be paid to Unicode normalization [Unicode-UAX15], in part because Unicode strings may be normalized by other processes independent of what a mail protocol specifies (this is exactly analogous to what may happen with quoting and dequoting in traditional addresses).