Internet Engineering Task Force N. Teint Internet-Draft March 23, 2010 Updates: 2142, 5336, 5504 (if approved) Intended status: Experimental Expires: September 24, 2010 An X-IDNA Profile for Electronic Mail Addresses draft-teint-xidna-email-00 Abstract Traditional mail systems handle only ASCII characters in SMTP envelope and mail header address fields. This memo defines an extension to allow Internationalised Email Adresses, the characters of which can be drawn from the large Unicode repertoire, based on the Extending IDNA to Other Protocols (X-IDNA) base specification. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 24, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Teint Expires September 24, 2010 [Page 1] Internet-Draft X-IDNA Profile for Email Addresses March 2010 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Profile Definition . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Normalisation . . . . . . . . . . . . . . . . . . . . . . 4 2.2.1. RFC 5321 Format Addresses . . . . . . . . . . . . . . 4 2.2.2. RFC 5322 Format Addresses . . . . . . . . . . . . . . 4 2.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Relation to other Specifications . . . . . . . . . . . . . . . 6 3.1. Email Address Internationalisation . . . . . . . . . . . . 6 3.2. Mailbox Names for Common Services . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Teint Expires September 24, 2010 [Page 2] Internet-Draft X-IDNA Profile for Email Addresses March 2010 1. Introduction The X-IDNA base specification ([I-D.teint-xidna-base]) provides a generic framework for internationalisation of addresses, based on IDNA. This memo defines an X-IDNA Profile for use with Netnews newsgroup names. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Teint Expires September 24, 2010 [Page 3] Internet-Draft X-IDNA Profile for Email Addresses March 2010 2. Profile Definition 2.1. Applicability This X-IDNA Profile applies to to email addresses defined in [RFC5321] and [RFC5322], i.e. to the following syntax elements: o the "Mailbox" symbol defined in Section 4.1.2 of [RFC5321] o the "addr-spec" symbol defined in Section 3.4.1 of [RFC5322] It also applies to other specifications based on these definitions (or their precedessors) if the elements are to be used as email addresses. 2.2. Normalisation The exact steps for normalisation depend on the way the address is embedded in higher-level syntax elements. 2.2.1. RFC 5321 Format Addresses Normalisation of email addresses from [RFC5321] follows the following procedure: o In "Quoted-string", remove the quote character ("\") from all instances of "quoted-pairSMTP" the second character of which is a "ALPHA", "DIGIT", HYPHEN-MINUS (U+002D) or extended character (U+0080 and above). The definitions of "Quoted-string" and "qutoted-pairSMTP" are taken from Section 4.1.2 of [RFC5321]. The definition of "ALPHA" and "DIGIT" is from Section B.2 of [RFC4234]. 2.2.2. RFC 5322 Format Addresses Normalisation of email addresses from [RFC5322] follows the following procedure: o In "quoted-string", "atom", "dot-atom" and "domain-literal", remove all instances of "FWS" that do not appear between "qcontent", "atext" or "dtext" elements and all instances of "CFWS". Replace all other instances of "FWS" with a single "SP" (U+0020) character. Instead, an application MAY choose to treat them as opaque separators, which results in these elements bypassing the label validation and conversion. o In "quoted-string" and "obs-dtext", remove the quote character ("\") from all instances of "quoted-pair" the second character of which is a "ALPHA", "DIGIT", HYPHEN-MINUS (U+002D) or extended character (U+0080 and above). The definition of "quoted-pair" is found in Section 3.2.1, the definitions of "FWS" and "CFWS" in Section 3.2.2, the definitions of Teint Expires September 24, 2010 [Page 4] Internet-Draft X-IDNA Profile for Email Addresses March 2010 "atom", "dot-atom" and "atext" in Section 3.2.3, the definitions of "quoted-string" and "qcontent" in Section 3.2.4, the definitions of "domain-literal" and "dtext" in Section 3.4.1 and the definition of "obs-dtext" in Section 4.4 of [RFC5322]. The definition of "ALPHA" and "DIGIT" is from Section B.2 of [RFC4234]. 2.3. Validation For the "domain" part of an email address, validation is already handled by the Registration Protocol described in Section 4 of [I-D.ietf-idnabis-protocol]. Validation of the "local-part" is the responsibility of whoever defines the "local-part" for a specific domain. Mail Delivery Agents (MDAs, see [RFC5598]) MAY validate addresses read from a local configuration file and alert the operator if any invalid addresses are found. Other than that, Message Handling Service Actors (MHS Actors, see [RFC5598]) MUST NOT validate addresses. Teint Expires September 24, 2010 [Page 5] Internet-Draft X-IDNA Profile for Email Addresses March 2010 3. Relation to other Specifications 3.1. Email Address Internationalisation Email Address Internationalisation (EAI), the framework of which is described in [RFC5336], provides an alternative approach to the internationalisation of email addresses, based on allowing UTF-8 characters in SMTP envelopes and mail header fields. EAI and X-IDNA for Mail complement each other and are interoperable if the following rules are followed: 1. When defining email addresses, operators SHOULD follow the requirements of Section 2.3 in this specification as well as the syntax for "mailbox" defined in Section 4.4 of [RFC5335]. 2. Message Handling Service Actors (MHS Actors, see [RFC5598]) MUST follow the rules laid out in Number 2 of Section 3.1 in [I-D.teint-xidna-base] when comparing addresses. That is, UTF-8 addresses (in EAI terms) or U-Addresses (in X-IDNA terms) and their equivalent A-Addresses must match. 3. In addition to Number 4 of Section in [RFC5336], an UTF8SMTP- aware server MAY also downgrade the message to an all-ASCII by converting the UTF-8 addresses (in EAI terms) or U-Addresses (in X-IDNA terms) to their A-Address counterparts. In the context of EAI, this is known as "algorithmic downgrade". If ASCII addresses are available via the ALT-ADDRESS parameter, the downgrading server SHOULD always use this address. That is, an ALT-ADDRESS parameter SHOULD take precedence over algorithmically determined A-Addresses. 4. Instead of the second method of MAILBOX Downgrading defined in Section 5.1.7 of [RFC5504], a server SHOULD rewrite an "Utf-8- addr-spec" in the absence of an corresponding "Addr-spec" as: [ Display-Name ] "<" A-Address ">" where "A-Address" is the ACE form of "Utf-8-addr-spec" (i.e. encoded according to this X-IDNA profile). 3.2. Mailbox Names for Common Services Section 6 of [RFC2142] defines a required administrative mailbox name for mailing lists, which is constructed by adding the string "-REQUEST" to the local part. The use of "-" as a delimiter yields inconsistent results when the list address is an internationalised address. Therefore, the requirement in Section 6 of [RFC2142] is amended as follows: For a mailing list the submission mailbox name of which is: Teint Expires September 24, 2010 [Page 6] Internet-Draft X-IDNA Profile for Email Addresses March 2010 where "LIST" contains an address that contains extended characters or A-Labels (starting with "xn--"), there MUST be an administrative mailbox name: (Note the use of "+" instead of "-".) In addition, there MAY be additional administrative mailbox names derived by: where "A-LIST" is the ACE form of "LIST", potentially yielding a fake A-Label "A-LIST-REQUEST", and where "U-LIST" is the Unicode form of "LIST", yielding a (usually) different ACE encoding when converted to ASCII. For a mailing list the submission mailbox name of which is: where "LIST" contains an address that does not contain extended characters or A-Labels, there MUST be an administrative mailbox name: In addition, there MAY be the an administrative mailbox name: Future specifications may phase out the form using "-" and make the form using "+" mandatory for all types of list addresses. Teint Expires September 24, 2010 [Page 7] Internet-Draft X-IDNA Profile for Email Addresses March 2010 4. IANA Considerations This memo includes no request to IANA. Teint Expires September 24, 2010 [Page 8] Internet-Draft X-IDNA Profile for Email Addresses March 2010 5. Security Considerations For the "domain" part of an email address, the Security Considerations of [I-D.ietf-idnabis-defs] and [I-D.ietf-idnabis-bidi] apply directly. For the "local part" of an email address, the security issues may be less virulent if a central authority chooses email addresses for individual users. However, if a domain allows public registration of email addresses, the local part is subject to the same Security Considerations as those for domain names. Operators of such domains ought to adapt policies for local parts that are similar to those of domain registries. Teint Expires September 24, 2010 [Page 9] Internet-Draft X-IDNA Profile for Email Addresses March 2010 6. References 6.1. Normative References [I-D.ietf-idnabis-bidi] Alvestrand, H. and C. Karp, "Right-to-left scripts for IDNA", draft-ietf-idnabis-bidi-07 (work in progress), January 2010. [I-D.ietf-idnabis-defs] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", draft-ietf-idnabis-defs-13 (work in progress), January 2010. [I-D.teint-xidna-base] Teint, N., "Extending IDNA to Other Protocols (X-IDNA)", draft-teint-xidna-base (work in progress), February 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997. [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, September 2008. [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008. [RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for Email Address Internationalization", RFC 5504, March 2009. [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. Teint Expires September 24, 2010 [Page 10] Internet-Draft X-IDNA Profile for Email Addresses March 2010 6.2. Informative References [I-D.ietf-idnabis-protocol] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", draft-ietf-idnabis-protocol-18 (work in progress), January 2010. Teint Expires September 24, 2010 [Page 11] Internet-Draft X-IDNA Profile for Email Addresses March 2010 Appendix A. Examples In the plain text version of this memo, the sequence "&#nnnn;" denotes the literal Unicode character number nnnn (decimal). Unicode: "lieselotte\.m\ueller"@example.net Normalised: lieselotte.mueller@example.net Extracted: L:"lieselotte" S:"." L:"mueller" S:"@" L:"example" S:"." L:"net" Converted: L:"lieselotte" S:"." L:"xn--mller-kva" S:"@" L:"example" S:"." L:"net" Re-Assembled: lieselotte.xn--mller-kva@example.net Unicode: -αλφα-βῆτα-&# 947;άμμα@example.com Normalised: -αλφα-βῆτα-&# 947;άμμα@example.com Extracted: S:"-" L:"αλφα-βῆτ&# 945;-γάμμα" S:"@" L:"example" S:"." L:"com" Converted: S:"-" L:"xn-----x8brabcel8esaa2hya7368h" S:"@" L:"example" S:"." L:"com" Re-Assembled: -xn-----x8brabcel8esaa2hya7368h@example.com Unicode: -αλφα-βῆτα-&# 947;άμμα@例え。テ&# 12473;ト Normalised: -αλφα-βῆτα-&# 947;άμμα@例え.テス&# 12488; Extracted: S:"-" L:"αλφα-βῆτ&# 945;-γάμμα" S:"@" L:"テス&# 12488;" S:"." L:"テスト" Converted: S:"-" L:"xn-----x8brabcel8esaa2hya7368h" S:"@" L:"xn-- r8jz45g" S:"." L:"xn--zckzah" Re-Assembled: -xn-----x8brabcel8esaa2hya7368h@xn--r8jz45g.xn--zckzah This example uses the obsolete percent hack: Unicode: -αλφα-βῆτα-&# 947;άμμα%例え。テ&# 12473;ト@gateway.example.net Normalised: -αλφα-βῆτα-&# 947;άμμα%例え.テス&# 12488;@gateway.example.net Teint Expires September 24, 2010 [Page 12] Internet-Draft X-IDNA Profile for Email Addresses March 2010 Extracted: S:"-" L:"αλφα-βῆτ&# 945;-γάμμα" S:"%" L:"テス&# 12488;" S:"." L:"テスト" S:"@" L:"gateway" S:"." L:"example" S:"." L:"net" Converted: S:"-" L:"xn-----x8brabcel8esaa2hya7368h" S:"%" L:"xn-- r8jz45g" S:"." L:"xn--zckzah" S:"@" L:"gateway" S:"." L:"example" S:"." L:"net" Re-Assembled: -xn-----x8brabcel8esaa2hya7368h%xn--r8jz45g.xn-- zckzah@gateway.example.net (Note that the conversion of the embedded domain name is identical to the previous example and identical to IDN.) Teint Expires September 24, 2010 [Page 13] Internet-Draft X-IDNA Profile for Email Addresses March 2010 Author's Address Nick Teint Email: nick.teint@googlemail.com Teint Expires September 24, 2010 [Page 14]