]> ICANN

6 Rond Point Schumann, Bd. 1 Brussels 1040 Belgium arnt@gulbrandsen.priv.no

CNNIC

No.4 South 4th Zhongguancun Street Beijing 100190 China yaojk@cnnic.cn

Applications EXTRA email This document specifies rules for email addresses that are flexible enough to express the addresses typically used with SMTPUTF8, while avoiding confusing or risky elements. NOTE: The term 'nice' is not ideal here, and must be reconsidered or replaced before this is issued as an RFC. "Well-formed" is a candidate. "Nice" will do for now: better to argue about substance than wording.

Introduction - and - extend various aspects of the email system to support non-ASCII both in localparts and domain parts. In addition, some email software supports unicode in domain parts by using encoded domain parts in the SMTP transaction ("RCPT TO:info@xn--dmi-0na.fo") and presenting the unicode version (dømi.fo in this case) in the user interface. The email address syntax extension is in , and allows almost all UTF8 strings as localparts. While this certainly allows everything users want to use, it is also flexible enought to allow many things that users and implementers find surprising and sometimes worrying. The flexibility has caused considerable reluctance to support the full syntax in contexts such as web form address validation. This document attempts to describe rules that:

1. includes the addresses that users generally want to use for themselves and organizations want to provision for their employees.
2. includes the addresses that have been used significantly, even if not exactly what users wanted.
3. excludes confusable things.
4. excludes things that have been described as security risks.
5. Looks safe at first glance to implementers (including ones with little unicode expertise).

These goals are somewhat aspirational. For example, lower-case L and upper-case i are confusable and cannot realistically be disallowed, the Protocol PoLIce would arrest us all.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology Script, in this document, refers to the unicode script property (see ). Each code point is assigned to one script ("a" is Latin), except that some are assigned to "Common" or a few other special values. Fraktur and /etc/rc.local aren't scripts in this document, but Latin is. Latin refers those code points that have the script property "Latin" in Unicode. Orléans in France and Münster in Germany both have Latin names in this document. It also refers to combinations of those code points and combining characters, and to strings that contain no code points from other scripts. Han, Cyrillic etc. refer to those code points that have the respective script property in Unicode, as well as to strings that contain no code points from other scripts. ASCII refers to the first 128 code points within unicode, which includes the letters A-Z but not É or Ü. It also refers to strings that contain only ASCII code points. Non-ASCII refers to unicode code points except the first 128, and also to strings that contain at least one such code point. By way of example, the address info@dømi.fo is latin and non-ASCII, its localpart is latin and ASCII, and its domain part is latin and non-ASCII. 中国 is a Han string in this document, but 阿Q正传 is neither a Latin string nor a Han string, because it contains a Latin Q and three Han code points.

An oversimplified description of current SMTPUTF8 email addresses This section is informative. In the countries the author has visited, the norm is that some users and organizations want to use their daily script(s), but not others. An Indian student in Japan or an Indian immigrant in an Arabic country will generally have his/her name spelt with either Latin letters or the host country's script, because that's how the university or company works. While the syntax defined in technically supports addresses with an Indic localpart and a Japanese or Arabic domain part, organizations such as a university or a company don't want to use that kind of naming: The script that's used for the organization's domain is the one it wants to use when provisioning email addresses. Note that even when an organization emphatically doesn't want to provision localparts from scripts other than its own, that organization generally wants the ability to correspond worldwide. There are a few countries in which ASCII localparts are used with non-ASCII domains (reputedly because of email software that supports / but not ). So far, the author has only seen this in countries that use left-to-right scripts such as Cyrillic and Han. In some countries, ASCII non-letters is used together with non-Latin scripts. Arabic is an example: the Arabic digits 0-9 are used often (more so in some countries than others). Chinese domain names use the ASCII dot instead of the Chinese full-width dot. ASCII punctuation (notably the hyphen) is used with several scripts. In the author's experience, left-to-right and right-to-left writing is mixed in only a few cases (that are relevant to email addresses):

• ASCII digits (123) and right-to-left letters
• Arabic Indic digits (١٢٣) and Arabic letters
• Testcase domains/addresses
• single punctuation characters (often neutral in direction)

An oversimplified description of IDNs and the domain name system This section is informative. The use of non-ASCII in domain names is restricted by several factors: IDNA2008 rules, registry rules and web browsers. For a domain such as example.com, IDNA2008 restricts both labels (slightly), ICANN policy restricts "com" and the .com registry's policy restricts "example", and the browsers' rules apply to both. For a domain such as e1.example.com, IDNA2008 and the browsers' rules apply to "e1" as well. Neither ICANN's nor the .com registry's rules apply to "e1".

IDNA2008 Using non-ASCII more or less requires IDNA2008, ie. if a the domain name is to be practically usable, it needs to be usable with IDNA2008, which restricts the set of code points slightly.

Registry rules The LGR, Label Generation Rules, are a set of rules largely developed by per-language and per-script committees and collected by ICANN. Most notably, a script or language has to be used by a current community in order to get an LGR. An LGR contains that which is currently used by the community. Registering a domain name in a public TLD requires adhering to the registry's policy, which is generally either an LGR, a small registry-chosen set of code points, or restricted by rules outside the DNS (such as for .bank, which is effectively restricted by what names banking regulators accept). The merged repertoire of all code points in all LGRs is called the Common LGR, and contains more than 30,000 code points at the time of writing.

Web browser rules The main browsers have rules for which domains are displayed in a human-readable manner in the address bar. (One author has a runic domain, all of the main browsers display xn--something in the address bar.) Each of the three big browser vendors maintains its own rule set. At the time of writing, all three may be described as broadly similar to the Common LGR and different in detail.

Rules for nice email addresses Based on the above descriptions, the following rules are formulated for nice email addresses.

1. A nice address MUST NOT contain an a-label (e.g. xn--dmi-0na).
2. If the address matches the grammar in , then in order to be nice it MUST also match the grammar specified by the W3C WHATWG spec.
3. A nice address MUST contain only code points within the Common LGR (plus @ and .). The Common LGR also contains rules about what is allowed where. Those rules are not included here, to allow simpler implementations.
4. A nice address MUST consist entirely of a sequence of composite characters, ZWJ and ZWNJ. ("c" followed by "combining hook below" is an example of a composite character, "d" is another example; see for the definition.)
5. If an address contains any right-to-left code points, then it MAY contain ASCII digits and MUST NOT contain any other left-to-right code points.
6. If an address contains any non-ASCII code point, then one of the following conditions MUST apply: 6.1. All code points share one unicode script property, or have the script property Common, or are ASCII digits (or ./@). 6.2. The localpart consists entirely of ASCII, and the domain part consists of code points that share one unicode script property, or have the script property Common, or are ASCII digits (or ./@). 6.3. All code points are have the script properties Han or Common, or are ASCII.

Examples The address example@example.com is nice, because 1) it does not contain any a-label, 2) it matches the WHATWG spec, 3) it consists entirely of permissible code points, 4) it consists of 19 composite characters, and the last two conditions do not apply. The address dømi@dømi.fo is nice, because 1) it does not contain any a-label, 2) does not apply, 3) it consists entirely of permissible code points, 4) it consists of 12 composite characters, 5) does not apply and 6) it consists entirely of 'Latin' and 'Common' code points (and ./@). The address U+200E '@' U+200F '.' U+200E is not nice, because 4) U+200E and U+200F are not parts of composite characters. The address U+627 '1' '@' U+627 '2' '.' U+627 '3' is nice. (U+627 is an arabic letter, written right-to-left.) It is nice because 1) it does not contain any a-label, 2) does not apply, 3) it consists entirely of permissible code points, 4) it consists of 8 composite characters, 5) the only right-to-left code points used are ASCII digits and 6) all code points are 'Arabic' or ASCII digits (or @/). (Note that it's nice even though top-level domain used does not exist, because '3' is not permitted by the current top-level domain name rules. Checking domain existence is simple if one assumes that internet access is available and the address is valid at the time, but this document does not assume assume either of those.) The address info@xn--dmi-0na.fo is not nice, because 1) it contains the a-label xn--dmi-0na. The address 名字@例子.中国 is nice, because 1) it does not contain any a-label, 2) does not apply, 3) it consists entirely of permissible code points, 4) it consists of 8 composite characters, 5) does not apply and 6) it consists entirely of 'Han' code points (and ./@). The address info@例子.中国 is nice, because 1) it does not contain any a-label, 2) does not apply, 3) it consists entirely of permissible code points, 4) it consists of 8 composite characters, 5) does not apply and 6) the localpart is ASCII and the domain part consists entirely of 'Han' code points (and .). The address dømi@例子.中国 is not nice, because 6) it contains both 'Latin' and 'Han' code points and the localpart is non-ASCII. The address 阿Q@阿Q正传@.中国 is nice, because 1) it does not contain any a-label, 2) does not apply, 3) it consists entirely of permissible code points, 4) it consists of composite characters, 5) does not apply and 6) the consists entirely of ASCII and Han code points (and .).

IANA Considerations This document does not require any actions from the IANA.

Security Considerations When a program renders a unicode string on-screen or audibly and includes a substring supplied by a potentially malevolent source, the included substring can affect the rendering of a surprisingly large part of the overall string. This document describes rules that make it difficult for an attacker to use email addresses for such an attack. Implementers should be aware of other possible vectors for the same kind of attack, such as subject fields and email address display-names. If an address is signed using DKIM and (against the rules of this document) mixes left-to-right and right-to-left writing, parts of both the localpart and the domain part can be rendered on the same side of the '@'. This can create the appearance that a different domain signed the message. The rules in this document permit a number of code points that

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK] This document provides a list of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. This memo documents an Internet Best Current Practice. 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 set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is a replacement for RFC 4952; it reflects additional issues identified since that document was published. [STANDARDS-TRACK] Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. However, full internationalization of electronic mail requires additional enhancements to allow the use of Unicode, including characters outside the ASCII repertoire, in mail addresses as well as direct use of Unicode in header fields like "From:", "To:", and "Subject:", without requiring the use of complex encoded-word constructs. This document specifies an enhancement to the Internet Message Format and to MIME that allows use of Unicode in mail addresses and most header field content. This specification updates Section 6.4 of RFC 2045 to eliminate the restriction prohibiting the use of non-identity content-transfer- encodings on subtypes of "message/". [STANDARDS-TRACK] Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3464, RFC 6522) are presently limited to ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. This document extends RFC 3461, RFC 3464, RFC 3798, and RFC 6522. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism called Internationalizing Domain Names in Applications (IDNA) for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using only the ASCII characters already allowed in so-called host names today. This backward-compatible representation is required in existing protocols like DNS, so that IDNs can be introduced with no changes to the existing infrastructure. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK] This document is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK] The Internet Message Format (RFC 5322) allows "group" syntax in some email header fields, such as "To:" and "CC:", but not in "From:" or "Sender:". This document updates RFC 5322 to relax that restriction, allowing group syntax in those latter fields, as well as in "Resent-From:" and "Resent-Sender:", in certain situations. This document specifies a method for IMAP and POP servers to serve internationalized messages to conventional clients. The specification is simple, easy to implement, and provides only rudimentary results. n.d. n.d. n.d.

Acknowledgments The authors wish to thank John C. Klensin, [your name here, please] [oh wow, the ack section is already outdated] Dømi.fo and 例子.中国 are reserved by nic.fo and CNNIC for use in examples and documentation. 阿Q正传@ is a famous Chinese novella, 阿Q is the main character.

Rationales for each condition This section is informative. Each of the six conditions has a separate rationale.

1. A-labels are confusing for many readers, and can potentially be used to confuse and attack readers. Being visibly safe is one of the five goals.
2. Many existing address validators use the WHATWG rules; if this specification is exactly compatible with WHATWG for all the addresses that WHATWG covers, then it's possible to extend a WHATWG-compliant validator without risk of accidentally rejecting formerly accepted addresses.
3. Each LGR contains a single writing system, with the smallest reasonable number of confusable code points. If an address is restricted to a single writing system, then the scope for confusing code points is small, since readers are generally good at distinguishing the letters in their everyday writing system. This restriction is not possible, since some users use e.g. ASCII@Cyrillic addresses. However, it's possible to get close to that. Condition 3 constrains addresses to the set of code points that users use, and condition 6 further constrains addresses to the few combinations of scripts that users use.
4. Unicode contains many code points that could perhaps be used for attacks. Whether they could be used for attacks is not important, since one of the goals is to be safe at first glance even to implementers with limited knowledge of unicode. By constraining the repertoire to the plainest code points, the specification gains safety at first glance.
5. Mixed-direction text can be confusing, and confusion has been used to attack users before. This rule tries to gain safety at first glance by constraining mixed-direction text in addresses to that which is known to be necessary.
6. This rule permits addresse that are e.g. all-Chinese or all-Thai, and rejects addresses that mix e.g. Thai and Chinese. This restricts the scope for visually confusable code points. Since some communities are known to mix ASCII localparts with IDNs, combining left-to-right text with ASCII is allowed, at least in the way that's currently used.

Note that metal umlauts ("Mötley Crüe") are allowed (see ). This is an unintentional feature.

Instructions to the RFC editor Please remove all mentions of the Protocol Police before publication (including this sentence). Please remove the Open Issues section.

Open issues

1. The use of the Common MSR is not ideal. It does allow a fairly good similarity between what's allowed in a domain name and in localparts, and it is a set of codepoints that includes most of what should be included and excludes most of what should be excluded. However, it was designed for the DNS, not for localparts. Ten thousand working hours have gone into it, none of the 10k into considering whether the use for localparts has particular problems.
2. The term "nice" is vague and inappropriate.
3. The relationship with RFC 8265 needs to be explained somewhere. A starting point: This document tries to guard against confusing addresses, in the sense that they confuse humans. Computers can also be confused; this document relies on RFC 8265 to make two confusable addresses practically equal. If two addresses look confusable, but test as identical according to 8264/5, then the confusability shouldn't be a problem.
4. Metal umlauts might be a problem. Accents are used sometimes with non-latin, but ver seldom and might be seen as surprising to native users of e.g. cyrillic, even if Åквариум exists. https://krebsonsecurity.com/2022/11/disneyland-malware-team-its-a-puny-world-after-all/ is worth considering. Not entirely clear how to subdivide the Common script so it can be used with some scripts, not with others.