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]