]> 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 and Real-Time mailmaint email RFC 6532 extends the internet email format to allow UTF8 in many contexts. This document restricts the set of allowed addresses in header fields slightly, and thereby simplifies use of these addresses. This is one of a pair of documents. This one is simple to implement and contains only globally viable rules. Its companion has more complex rules, takes regional usage into account, and describes addresses that can be read by some community and cut-and-pasted in some locale. Discussion Venues Discussion of this document takes place on the Mail Maintenance Working Group mailing list (mailmaint@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

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 enough to allow many things that users and implementers find surprising and sometimes worrying. For example, the domain extracted by code may not match that shown to users on-screen.

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 to 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. The term a-label is defined in section 2.3.2.1. PRECIS is described in , and the IdentifierClass in section 4.2 of that document.

Rules The following three rules apply to the mailbox production, as indirectly extended by .

1. An atom in an address MUST NOT be an a-label (e.g. xn--dmi-0na).
2. An address MUST contain only code points that the PRECIS IdentifierClass treats as valid, and " ". Where the IdentifierClass requires a contextual rule, the address MUST satisfy that rule ( Appendix A).
3. An address MUST NOT contain more than one script, when ASCII is disregarded. (For example: In the word Orléans, Orl and ans are ASCII and é is non-ASCII. The single é is in a single script, so the word contains only one script.)

Examples example@example.com is permitted, because 1) it does not contain any a-label, 2) it consists entirely of permissible code points and 3) it contains no non-ASCII code points at all. The address dømi@dømi.fo is permitted, because 1) it does not contain any a-label, 2) the IdentifierClass permits every code point in it and 3) it consists entirely of 'Latin' and 'Common' code points (and ./@). The address U+200E '@' U+200F '.' U+200E is not permitted, because 2) the IdentifierClass disallows U+200E and U+200F as ignorable code points. The address 'admin' U+3164 '@example.com' is not permitted for the same reason. U+3164 HANGUL FILLER renders as nothing at all, so the address looks exactly like admin@example.com. U+0640 ARABIC TATWEEL is disallowed too, although it is a letter by category: it only elongates the preceding letter, and would let one address be spelled in any number of ways. 阿Q正传@阿Q正传.example is permitted because it contains ASCII and Han, dømi@dømi.fo is legal because it contains ASCII and Latin, but 阿Q正传@dømi.fo is not, because it contains both Han (阿) and Latin non-ASCII (ø).

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

Security Considerations When a program renders a non-ASCII email address string on-screen or stores it as a string (e.g. in a system log file), the address shown to the eventual human may not be as intended. One possible way to diminish the risk is to replace impermissible code points with U+FFFD, REPLACEMENT CHARACTER. There are also other options. The rules in this document permit a number of code points that can make an address difficult to cut and paste.

References Normative References Episteme Technology Consulting LLC 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) 5322, itself a revision of Request For Comments (RFC) 2822, all of which supersede 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. This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK] This document specifies rules for deciding whether a code point, considered in isolation or in context, is a candidate for inclusion in an Internationalized Domain Name (IDN). It is part of the specification of Internationalizing Domain Names in Applications 2008 (IDNA2008). [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] Application protocols using Unicode code points in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode code points and thus is more agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known as Stringprep (RFC 3454). This document obsoletes RFC 7564. 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. 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] 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] 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.

Testing This is a set of test addresses in JSON format. Below is a verbatim copy of https://github.com/arnt/mailmaint-smtputf8/tests.json as it was on (date here). It contains a number of strange and unusual code points, so cutting and pasting this may not work. Rather, it is recommended to either use the rfcstrip tool or download the tests using a command such as curl https://github.com/arnt/mailmaint-smtputf8/tests.json > tests.json. Note to IETF reviewers: The tests will be included here shortly before publication (and after IETF Last Call).

Acknowledgments The authors wish to thank John C. Klensin, (your name here, please) (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.

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. Wording to identify destiny; I think this should probably become a proposed standard and modify a couple of RFCs, but I'm uncertain about some details and left that open now.
2. More words on the relationship between this and the companion. There are several parallel differences, maybe this warrants a section of its own.
3. Should this even mention the requirements placed on domains by IDNA, ICANN, web browsers and others?
4. SHOULD or MUST not contain a-labels?