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.

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
2.  Profile Definition
    2.1.  Applicability
    2.2.  Normalisation
        2.2.1.  RFC 5321 Format Addresses
        2.2.2.  RFC 5322 Format Addresses
    2.3.  Validation
3.  Relation to other Specifications
    3.1.  Email Address Internationalisation
    3.2.  Mailbox Names for Common Services
4.  IANA Considerations
5.  Security Considerations
6.  References
    6.1.  Normative References
    6.2.  Informative References
Appendix A.  Examples
§  Author's Address

1.  Introduction

The X-IDNA base specification ([I‑D.teint‑xidna‑base] (Teint, N., “Extending IDNA to Other Protocols (X-IDNA),” February 2010.)) 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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Profile Definition

2.1.  Applicability

This X-IDNA Profile applies to to email addresses defined in [RFC5321] (Klensin, J., “Simple Mail Transfer Protocol,” October 2008.) and [RFC5322] (Resnick, P., Ed., “Internet Message Format,” October 2008.), i.e. to the following syntax elements:

• the "Mailbox" symbol defined in Section 4.1.2 of [RFC5321] (Klensin, J., “Simple Mail Transfer Protocol,” October 2008.)
• the "addr-spec" symbol defined in Section 3.4.1 of [RFC5322] (Resnick, P., Ed., “Internet Message Format,” October 2008.)

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] (Klensin, J., “Simple Mail Transfer Protocol,” October 2008.) follows the following procedure:

• 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] (Klensin, J., “Simple Mail Transfer Protocol,” October 2008.). The definition of "ALPHA" and "DIGIT" is from Section B.2 of [RFC4234] (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” October 2005.).

2.2.2.  RFC 5322 Format Addresses

Normalisation of email addresses from [RFC5322] (Resnick, P., Ed., “Internet Message Format,” October 2008.) follows the following procedure:

• 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.
• 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 "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] (Resnick, P., Ed., “Internet Message Format,” October 2008.). The definition of "ALPHA" and "DIGIT" is from Section B.2 of [RFC4234] (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” October 2005.).

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] (Klensin, J., “Internationalized Domain Names in Applications (IDNA): Protocol,” January 2010.).

Validation of the "local-part" is the responsibility of whoever defines the "local-part" for a specific domain.

Mail Delivery Agents (MDAs, see [RFC5598] (Crocker, D., “Internet Mail Architecture,” July 2009.)) 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] (Crocker, D., “Internet Mail Architecture,” July 2009.)) MUST NOT validate addresses.

3.  Relation to other Specifications

3.1.  Email Address Internationalisation

Email Address Internationalisation (EAI), the framework of which is described in [RFC5336] (Yao, J. and W. Mao, “SMTP Extension for Internationalized Email Addresses,” September 2008.), 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 (Validation) in this specification as well as the syntax for "mailbox" defined in Section 4.4 of [RFC5335] (Abel, Y., “Internationalized Email Headers,” September 2008.).
2. Message Handling Service Actors (MHS Actors, see [RFC5598] (Crocker, D., “Internet Mail Architecture,” July 2009.)) MUST follow the rules laid out in Number 2 of Section 3.1 in [I‑D.teint‑xidna‑base] (Teint, N., “Extending IDNA to Other Protocols (X-IDNA),” February 2010.) 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] (Yao, J. and W. Mao, “SMTP Extension for Internationalized Email Addresses,” September 2008.), 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] (Fujiwara, K. and Y. Yoneya, “Downgrading Mechanism for Email Address Internationalization,” March 2009.), 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] (Crocker, D., “MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS,” May 1997.) 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] (Crocker, D., “MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS,” May 1997.) is amended as follows:

For a mailing list the submission mailbox name of which is:

<LIST@DOMAIN>

where "LIST" contains an address that contains extended characters or A-Labels (starting with "xn--"), there MUST be an administrative mailbox name:

<LIST+REQUEST@DOMAIN>

(Note the use of "+" instead of "-".)

In addition, there MAY be additional administrative mailbox names derived by:

<A-LIST-REQUEST@DOMAIN>

<U-LIST-REQUEST@DOMAIN>

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:

<LIST@DOMAIN>

where "LIST" contains an address that does not contain extended characters or A-Labels, there MUST be an administrative mailbox name:

<LIST-REQUEST@DOMAIN>

In addition, there MAY be the an administrative mailbox name:

<LIST+REQUEST@DOMAIN>

Future specifications may phase out the form using "-" and make the form using "+" mandatory for all types of list addresses.

4.  IANA Considerations

This memo includes no request to IANA.

5.  Security Considerations

For the "domain" part of an email address, the Security Considerations of [I‑D.ietf‑idnabis‑defs] (Klensin, J., “Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework,” January 2010.) and [I‑D.ietf‑idnabis‑bidi] (Alvestrand, H. and C. Karp, “Right-to-left scripts for IDNA,” January 2010.) 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.

6.  References

6.1. Normative References

6.2. Informative References

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\üller"@example.net

Normalised:

lieselotte.müller@example.net

Extracted:

L:"lieselotte" S:"." L:"müller" 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:

-αλφα-βῆτα-γάμμα@example.com

Normalised:

-αλφα-βῆτα-γάμμα@example.com

Extracted:

S:"-" L:"αλφα-βῆτα-γάμμα" S:"@" L:"example" S:"." L:"com"

Converted:

S:"-" L:"xn-----x8brabcel8esaa2hya7368h" S:"@" L:"example" S:"." L:"com"

Re-Assembled:

-xn-----x8brabcel8esaa2hya7368h@example.com

Unicode:

-αλφα-βῆτα-γάμμα@例え。テスト

Normalised:

-αλφα-βῆτα-γάμμα@例え.テスト

Extracted:

S:"-" L:"αλφα-βῆτα-γάμμα" S:"@" L:"テスト" 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:

-αλφα-βῆτα-γάμμα%例え。テスト@gateway.example.net

Normalised:

-αλφα-βῆτα-γάμμα%例え.テスト@gateway.example.net

Extracted:

S:"-" L:"αλφα-βῆτα-γάμμα" S:"%" L:"テスト" 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.)

Author's Address