Network Working Group J. Yao
Internet-Draft X. Lee
Intended status: Informational CNNIC
Expires: January 14, 2010 July 13, 2009
Guidelines for Internationalized Email Deployment
draft-yao-eai-deployment-03.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 January 14, 2010.
Copyright Notice
Copyright (c) 2009 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
Yao & Lee Expires January 14, 2010 [Page 1]
Internet-Draft EAI Deployment July 2009
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
Key RFCs for internationalized email address have been published,
specifying the basic protocols for using it. This document provides
some guidelines for implementing the email systems that support Email
Address Internationalization (EAI). Its aim is to give some
suggestions and help the engineers to implement these protocols.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Role of this specification . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. From non-EAI world to EAI world . . . . . . . . . . . . . 4
2.2. SMTP client . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Relay Server . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. SMTP Server . . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Email Filter . . . . . . . . . . . . . . . . . . . . . . . 5
2.6. Firewall . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.7. Mail User Agent . . . . . . . . . . . . . . . . . . . . . 6
2.8. Full Support of EAI Protocols . . . . . . . . . . . . . . 6
3. Alternate ASCII Address . . . . . . . . . . . . . . . . . . . 6
4. Internationalized Email Domains . . . . . . . . . . . . . . . 6
5. Converting Local Character Codes To UTF-8 encoding . . . . . . 7
6. Restrictions on Characters in Local Part . . . . . . . . . . . 7
7. Local Part Interpretations . . . . . . . . . . . . . . . . . . 8
8. Lookup in DNS . . . . . . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
12. Change History . . . . . . . . . . . . . . . . . . . . . . . . 8
12.1. draft-yao-eai-deployment: Version 01 . . . . . . . . . . . 9
12.2. draft-yao-eai-deployment: Version 02 . . . . . . . . . . . 9
12.3. draft-yao-eai-deployment: Version 03 . . . . . . . . . . . 9
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
13.1. Normative References . . . . . . . . . . . . . . . . . . . 9
13.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Yao & Lee Expires January 14, 2010 [Page 2]
Internet-Draft EAI Deployment July 2009
1. Introduction
The IETF has published five RFCs [RFC4952] [RFC5335] [RFC5336]
[RFC5337] [RFC5504] about internationalized email addresses. The
goal of this document is to provide guidelines for Internationalized
Email Address (EAI) implementations. It highlights areas which EAI
implementors may find valuable. This document discusses potential
choices that can be made in an attempt to help to foster
interoperability between components that use the EAI protocols. EAI
extends the current base email standards [RFC5321] [RFC5322]. It is
important for EAI implementors to carry out a thorough analysis of
all of the base email standards to understand the relationships
between those standards and the current EAI protocols. A great deal
of the advice for making the EAI protocols more practical is
available to those who want to deploy the EAI protocols. More
discussions related to deployment reports on the prototype
implementation and the interoperability test results, as well as the
evaluation will be disscused in other document [DeploymentTests].
1.1. Role of this specification
The framework document specifies the requirements for, and describes
components of, full internationalization of email address. The EAI
SMTP extension document [RFC5336] specifies the SMTP extension to use
the internationalized email address. The EAI header document
[RFC5335] allows the internationalized email address headers. The
EAI downgrade document [RFC5504] addresses how to downgrade to be
compatible with the current non-EAI-system. A thorough understanding
of the information in all these documents and in the base Internet
email specifications [RFC5321] [RFC5322] is necessary to understand
and implement this specification.
This document emphasizes some points in the EAI protocols and gives
some suggestions and advice for the usage, implementation and
deployment of internationalized email address.
1.2. Terminology
All the specialized terms used in this specification are defined in
the framework document [RFC4952], the EAI SMTP extension document
[RFC5336], the EAI header document [RFC5335] and the base Internet
email specifications [RFC5321] [RFC5322]. In particular, the terms
"ASCII user", and "i18mail user" are used in this document according
to the definitions in the framework one.
[[anchor3: NOTE TO RFC EDITOR: Please remove the following text
before publication.]]
Some ideas of this specification is being discussed on the EAI
Yao & Lee Expires January 14, 2010 [Page 3]
Internet-Draft EAI Deployment July 2009
mailing list. See https://www1.ietf.org/mailman/listinfo/ima for
information about subscribing. The list's archive is at
http://www1.ietf.org/mail-archive/web/ima/index.html.
2. Deployment
2.1. From non-EAI world to EAI world
An i18mail user normally uses the EAI-capability sending server which
his internationalized email address resides in. It is very unlikely
that the i18mail user use the non-EAI-capability server to send its
i18mail message. If that situations occures, the sending server will
reject the message or report it as an error. EAI Protocols are used
to exchange the message between at least 2 SMTP servers. If only one
SMTP server supports the EAI protocols, that is meaningless. When
one email service provider implements the EAI service, it can provide
registration of EAI account. The EAI user can exchange the email
within the domain. When another email service provider supports EAI
protocols, the EAI users within these 2 domains can exchange the EAI
message. When the demands for internationalized email address
increase, more and more email service providers will support EAI.
Although it is not possible to support EAI protocol within one night,
it is very possible that the EAI protocol will become more popular
with the time being. From non-EAI world to EAI world, it is
procedure of step by step. More issuses about this topic will be
discussed in other document[DeploymentTests].
2.2. SMTP client
The SMTP client is used to send the message. It should implement the
specifications in the [RFC5335] and [RFC5336]. Since many SMTP
servers are still not ready to accept EAI messages, it is very
important to implement the mechanisms specified in the section 3.2 in
[RFC5336]. EAI messages can only be transferred to SMTP servers that
support EAI. If an alt-address is provided, it is easier for the
sender to reach the receiver as the downgrading mechanism spcified in
the [RFC5504] can be used. If the SMTP client has binded the EAI
account to the ASCII one specified in the section 3 of this document,
the SMTP client should find the ASCII address corresponding to the
EAI one and do some downgrading when encountering some non-EAI-aware
SMTP server. In other situations, the message can either be rejected
during the SMTP transaction or the SMTP server can accept the message
and then generate a notification of non-delivery.
Yao & Lee Expires January 14, 2010 [Page 4]
Internet-Draft EAI Deployment July 2009
2.3. Relay Server
It is possible that the relay server does not support EAI protocols.
If an EAI-aware SMTP client sends the message to a non-EAI-capable
relay server, the relay server should adopt one of the 4 methods
specified in section 3.2 in RFC 5336 [RFC5336]. If the relay server
is under the control of one organization which is in charge of both
the sending systems and relay servers, it is suggested that this
organization should update all its servers to support EAI protocols.
2.4. SMTP Server
If the SMTP server does not support EAI protocols, it will be not
accept the EAI message. If the EAI-aware SMTP server receiving the
EAI message is the the final delivery system, the message will be
delivered to the message store. If the EAI-capability server
receives the EAI message, the serve will distribute the message to
the message store.
2.5. Email Filter
Many email receivers have installed the email filters. Because EAI
messages may have some "non-ASCII" addresses, it is very strange to
email filters. Sometimes the internationalized domain names will be
transformed into punycode form when they arrived at the filters.
These forms are ugly and often get special processing from the filter
which suspects that the domain name with this form is randomly
created and is used for the spam mail. If the mail filters are not
updated to support EAI protocols, some may regard EAI messages as the
rubbish and drop them immediately; some may need more time to process
the message and delay it. It is suggested that the email filter
should be updated to accept EAI messages too when email server is
updatd.
2.6. Firewall
Firewall document [RFC2979] requires to perform extensive protocol
validity checks. Specially, in section 3.1.2 of RFC 2979 [RFC2979]
The firewall will scan the list of EHLO responses and only allow the
ones the firewalls understands through. The traditional fireall will
not understand the keyword "UTF8SMTP", lead to unnecessary protocol
failures, and cut off the SMTP connection. Some firewalls will be
acted as the SMTP relay or agent. These firewalls should be updated
to support EAI protocols.
Yao & Lee Expires January 14, 2010 [Page 5]
Internet-Draft EAI Deployment July 2009
2.7. Mail User Agent
The IETF has defined the protocols required to exchange EAI messages
between SMTP senders and SMTP receivers. If you want to use
internationalized email addresses, it is very vital that other parts
such as the Mail User Agent (MUA) supports EAI protocols. Since most
MUAs do not support internationalized email addresses, the MUA may
not be able to send EAI messages on behalf of the email user and
fetch EAI messages from the message store. For better use of EAI,
MUAs should be upgraded to support EAI protocols.
2.8. Full Support of EAI Protocols
The email system is very complex. Many parts of the email system
will use the email address. It is suggested that all parts of the
email system should be upgraded to support EAI protocols.
3. Alternate ASCII Address
There are millions email servers and clients. They cannot be updated
to support EAI protocols within a night. EAI protocols specify a
transitional mechanism which allows the EAI-capable SMTP clients to
talk with the non-EAI SMTP servers. During the deployment of EAI, it
is impossible to upgrade all SMTP clients and SMTP servers to support
EAI. The SMTPext document [RFC5336] specifies an ALT-ADDRESS
parameter for use when downgrading is required. Only EAI users may
require the Alternate ASCII Addresses, ASCII users has no need for
it. It is recommended that Alternate ASCII Addresses should not be
used by ASCII users as a general-purpose second-chance email address.
When the email user signs up for an internationalized email account,
it is better that the system automatically binds it with an Alternate
ASCII Address. This email account's name may be selected by email
account applicant. The Alternate ASCII Address is used for the ALT-
ADDRESS parameter. It can be an alias of the EAI account. Both the
internationalized email address and Alternate ASCII Address refer to
the same message store. This method has an advantage: When the EAI
user sends an email to other user, he or she does not need to fill in
an ASCII email address for the ALT-ADDRESS parameter when the
receiver does not support EAI. The EAI-capable SMTP system
automatically provides the Alternate ASCII Address which was prepared
in advance when the user signed up for an internationalized email
account.
4. Internationalized Email Domains
The email service provider could have both an internationalized email
Yao & Lee Expires January 14, 2010 [Page 6]
Internet-Draft EAI Deployment July 2009
domain and an ASCII email domain. The ASCII domain can be regarded
as the alias of the internationalized domain. The MX records for
both domains point to the same target host.
5. Converting Local Character Codes To UTF-8 encoding
Some systems, operating in local environments, will use local
character codes no matter what we specify. In many countries, there
are local national standards for character encoding. For example, in
China, GB2312 and GB18000 is the national standards. Japan has also
its own national character encoding standards. So there are some
reasons for permitting local-parts to be written in locally-used
character codes other than the UTF-8 encoding of UNICODE. On the
other hand, having an application presented with an octet (or bit)
string and not knowing what charset is involved would block the
attempt to intelligently display local parts. The EAI protocol
allows only UTF-8 encoding in the local part in the email header and
envelop. The MUA may display the message information with the local
character codes. But when the email address information is
transferred on the wire, it must use the UTF-8 encoding other than
local character encodings. Use of local coding also implies an
encoding for the local part different from that for the domain part.
The domain part of the internationalized email address will support
IDNA [RFC3490] and uses the UTF-8 encodings. If local codings can be
avoided entirely, it will considerably reduce complexity and
"opportunities" for systems to not interoperate.
6. Restrictions on Characters in Local Part
The EAI specification is extremely liberal about what can be included
in a UTF-8 string that represents a local-part. It prohibits the use
of quoted strings, or quoted characters, in non-ASCII local parts.
Quoted strings and characters in local parts have, in general, been
nothing but trouble and there appears to be no reason to carry that
trouble forward into an internationalized world. It is suggested
that applying restrictions by use of a stringprep [RFC3454] profile
that would eliminate particularly problematic characters is
suggested. IDNAbis label check may be used for local parts. Some
languages characters has some special features. For example, Chinese
characters has some varants. When registering the email account, the
technique specified in the RFC 3743 may be used for the possible
confusion. ASCII local-parts are inherently case sensitive. The
local systems are encouraged to not take advantage of that feature.
All internationalized email local part are suggested to be case
insensitive.
Yao & Lee Expires January 14, 2010 [Page 7]
Internet-Draft EAI Deployment July 2009
7. Local Part Interpretations
In the Internet email context, the interpretation and permitted
syntax for an email local-part is entirely the responsibility of the
receiving system. The general advice to system designers still
include "treat addresses in a case-independent fashion" and "do not
use addresses that require quoting". Senders should continue to be
conservative about what they send, and relays should continue to
avoid presumptions about their understanding of the content of local-
parts. Receiving systems that have reason to adopt more restricted
syntax rules, or interpretations of matching, should continue to be
able to do so.
8. Lookup in DNS
The domain part of the email address is used to route the message to
the proper destination. The domain part must be processed into the
punycode form specified in RFC 3490 [RFC3490] before DNS lookup.
9. IANA Considerations
There is no IANA consideraton.
10. Security Considerations
See the extended security considerations discussion in the framework
document [RFC4952].
11. Acknowledgements
Many ideas are from the discussion in the list ima@ietf.org. John C
Klensin has done a lot of reasearch on ASCII email address and
internationalized email address. I got many significant words or
ideas from him. Many friends and experts in the EAI WG help us to
produce the valuable ideas. Many organizations including CNNIC,
TWNIC, JPRS, NIDA, AND AFFLILIAS have implemented EAI systems. These
organizations have already done a lot of inter-operating testing. S.
Moonesamy gives many kind comments to draft version 01. Thanks John
C Klensin for his comments to Draft version 02.
12. Change History
[[anchor12: RFC Editor: Please remove this section.]]
Yao & Lee Expires January 14, 2010 [Page 8]
Internet-Draft EAI Deployment July 2009
12.1. draft-yao-eai-deployment: Version 01
o update the section "Sending Server"
o add the new section "From non-EAI world to EAI world"
o update and refine the texts of this document
12.2. draft-yao-eai-deployment: Version 02
o rename the section "Sending Server" to "SMTP client"
o rename the section "Recieve Server" to "SMTP server"
o add the new section "Internationalized email domain"
o move and refine the section "Firewall"
o update and refine the texts of this document
12.3. draft-yao-eai-deployment: Version 03
o rename the draft title from "eai deployment practise" to
"Guidelines for Internationalized Email Deployment"
o remove the section "Test Scenarios"
o remove the section "Test Results and Experiences"
o update and refine the texts of this document
13. References
13.1. Normative References
[ASCII] American National Standards Institute (formerly United
States of America Standards Institute), "USA Code for
Information Interchange", ANSI X3.4-1968, 1968.
[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
RFC 1652, July 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2979] Freed, N., "Behavior of and Requirements for Internet
Firewalls", RFC 2979, October 2000.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)",
RFC 3461, January 2003.
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
RFC 3463, January 2003.
Yao & Lee Expires January 14, 2010 [Page 9]
Internet-Draft EAI Deployment July 2009
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, November 2003.
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail",
RFC 4409, April 2006.
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for
Internationalized Email", RFC 4952, July 2007.
[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.
[RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery
Status and Disposition Notifications", RFC 5337,
September 2008.
13.2. Informative References
[DeploymentTests]
YAO, J., YEE, J., KAO, M., and D. KIM, "Discussion, Test
and Evaulation for EAI deployment",
draft-yao-eai-tests-00.txt (work in progress),
August 2009.
[RFC5504] YONEYA, Y., Ed. and K. Fujiwara, Ed., "Downgrading
mechanism for Internationalized eMail Address", RFC 5504,
3 2009.
Yao & Lee Expires January 14, 2010 [Page 10]
Internet-Draft EAI Deployment July 2009
Authors' Addresses
Jiankang YAO
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
Phone: +86 10 58813007
Email: yaojk@cnnic.cn
Xiaodong LEE
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
Phone: +86 10 58813020
Email: lee@cnnic.cn
Yao & Lee Expires January 14, 2010 [Page 11]