Network Working Group J. Yao Internet-Draft X. Lee Intended status: Informational X. Wu Expires: April 24, 2009 CNNIC October 21, 2008 EAI Deployment Practices draft-yao-eai-deployment-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 April 24, 2009. Abstract This document captures experience in implementing systems based on the EAI protocols. Its aim is to help the engineers to implement these protocols. This document gives some suggestions about implementaions and reports on the prototype implementation and the inter-operability test results, as well as the lessons and insights gained from this test. Yao, et al. Expires April 24, 2009 [Page 1] Internet-Draft EAI Deployment Practices Oct. 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Role of this specification . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Sending Server . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Relay Server . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Receiving Server . . . . . . . . . . . . . . . . . . . . . 4 2.4. MUA . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.5. Full Support of EAI Protocols . . . . . . . . . . . . . . 5 3. Formation of the Alternate Address . . . . . . . . . . . . . . 5 4. Converting Local Character Codes To UTF-8 encoding . . . . . . 5 5. Restrictions on Characters in Local Part . . . . . . . . . . . 6 6. Local part interpretations . . . . . . . . . . . . . . . . . . 6 7. Lookup in DNS . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Test Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Test Results and Experiences . . . . . . . . . . . . . . . . . 7 9.1. Test Results . . . . . . . . . . . . . . . . . . . . . . . 7 9.2. Firewall . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.3. Experiences . . . . . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 13.1. Normative References . . . . . . . . . . . . . . . . . . . 8 13.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Yao, et al. Expires April 24, 2009 [Page 2] Internet-Draft EAI Deployment Practices Oct. 2008 1. Introduction IETF EAI WG has published 4 RFCs [RFC4952] [RFC5335] [RFC5336] [RFC5337]. These RFCs specifie a protocol for internationalized email address. The goal of this document is to clarify the EAI protocols, give some suggestions and guide the implementations. It highlights areas where EAI implementers may think it is valuable. As well as clarifications to standards text, this document also mentions potential choices that can be made, in an attempt to help to foster interworking between components that use this protocol. EAI extends the current base email standards [RFC2821] [RFC2822]. It is important for EAI implementers to carry out a thorough analysis of all of the existing EMAIL standard documents to understand the relationships between the base email standards and the current EAI protocols. A great deal of the advice for making the protocol more practical is available to those who want to deploy the EAI protocols. 1.1. Role of this specification The framework document specifies the requirements for, and describes components of, full internationalization of electronic mail. The EAI SMTP extension document [RFC5336] specifys the SMTP extension to use the internationalized email address. The EAI header document [RFC5335] allows the internationalized email address headers. A thorough understanding of the information in all these documents and in the base Internet email specifications [RFC2821] [RFC2822] is necessary to understand and implement this specification. This document clarifys 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 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 RFC 2119 [RFC2119]. 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 [RFC2821] [RFC2822]. 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, et al. Expires April 24, 2009 [Page 3] Internet-Draft EAI Deployment Practices Oct. 2008 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. Sending Server 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 his 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 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. 2.2. Relay Server It is very possible that the relay server does not support EAI protocols. If EAI server sends the message to the non-EAI-capability server, the EAI server should adopt one of the 4 methods specified in RFC 5336[RFC5336]. If the relay server is under the control of one organization which is in charge of both the sending servers and relay servers, it is suggested that this organizaiton should update all his servers to support EAI protocols to make smooth operation. 2.3. Receiving Server If the reciving server does not support EAI protocols, it will be unlikely to accept the EAI message. If the EAI-capability server receives the EAI message, the serve will distribute the message to the message store. 2.4. MUA The EAI WG has clearly defined the protocol about how to exchange the message between 2 SMTP servers. If you want to use the internationalized email address, it is very vitail that the other Yao, et al. Expires April 24, 2009 [Page 4] Internet-Draft EAI Deployment Practices Oct. 2008 parts such as MUA (Mail User Agent) of the email system support EAI protocols. Since most MUA do not support internationalized email address, MUA can not send the internationalized email address and fetch the EAI message from the server. For better use of EAI, MUA should be upgraded to support EAI protocols. 2.5. 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. Formation of the Alternate Address There are millions email servers and clients, which can not be updated to support EAI protocols within a night. EAI protocols designs a transitional method, which allows the eai-capability smtp server to talk with the non-eai-capability smtp servers. During the deployment of EAI, it is impossible to make all of SMTP servers to upgrade to support EAI. The SMTPext document designs an alt-address parameter for use when downgrading is needed. Only EAI user may want to use the alt-address. ASCII user has no need to use the alt- address. The current email protocol also prohibits the use of alt- address used by ASCII user. The email service provider is suggested to build both the internationalized email domain and the ASCII email domain while creating the internationalized email domain. ASCII domain is regarded as the alias of internationalized domain. Both domains's MX record in DNS are resolved to the same MX record. When the email user apply the internationalized email account, it is better that the system automatically binds it with an ASCII email account. This email account's name may be selected by email account applicant. This ASCII email address is regarded as the alt-address name; it can be an alias aacount of the EAI account. Both internationalized email address and ASCII email address refer to the same email store. This method has an advantage: When the EAI user sending an email to other user using his own EAI account need not fill in his own alt-address when the receiver does not support EAI capability. The EAI-capablity server who creats the internationalized email account will help to fill the ALt-address. 4. Converting Local Character Codes To UTF-8 encoding Some systems, operating in local environments, will use local character codes no matter what we specify. 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 Yao, et al. Expires April 24, 2009 [Page 5] Internet-Draft EAI Deployment Practices Oct. 2008 intelligently display local parts: if one cannot know the character coding being used, then it is not possible to accurately decode the characters and display appropriate character glyphs. 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. 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. 5. 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. 6. 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 Yao, et al. Expires April 24, 2009 [Page 6] Internet-Draft EAI Deployment Practices Oct. 2008 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. 7. 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 before DNS lookup. 8. Test Scenarios We have test some scenarios described in scenario documents [Secnarios]. Testing between EAI system with the same implementation (postfix) 1. Scenario 1:Two i18mail users 2. Scenario 2:Three i18mail users 3. Scenario 3:An i18mail user sends to one ascii user Testing between EAI systems with different implementations 1. Test with NIDA (own implementation with python ) 2. Test with JPRS (own implementation with C ) 3. Test with AFILIAS (implementation based on sendmail) 4. Test with TWNIC (implementation based on sendmail) 9. Test Results and Experiences 9.1. Test Results From these tests, we get the following results: The implementation based on the EAI protocol is workable. We need more email service providers to implement and deploy EAI protocols. 9.2. Firewall During the test, we find that some firewall will block the EAI message and cut off the SMTP connection. It is suggested that the firwall should be updated to support EAI protocols too. Yao, et al. Expires April 24, 2009 [Page 7] Internet-Draft EAI Deployment Practices Oct. 2008 9.3. Experiences During the test, we find that many users are interested in using the internationaliezed email address. They prefer more email service providers to provide such services. During the implementation, different implementer may encounter different problems. If the implementers try to analysed the EAI protocols and the base protcols of RFC 2821 and RFC 2822 throughtly, it is still easy to implement it. Since many implementers have implemented EAI protocols based on different email source code such as Postfix and Sendmail and done a lot of inter-operating, it has already proved that the EAI protocols can be implemented and workable. 10. IANA Considerations There is no IANA consideraton. 11. Security Considerations See the extended security considerations discussion in the framework document [RFC4952]. 12. 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 CNNICGBP[not]TWNIC, JPRS, NIDA, AND AFFLILIAS have implemented EAI systems. These organizations have already done a lot of inter- operating testing. 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. Yao, et al. Expires April 24, 2009 [Page 8] Internet-Draft EAI Deployment Practices Oct. 2008 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [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. [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. [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 [EAI-downgrading] YONEYA, Y., Ed. and K. Fujiwara, Ed., "Downgrading mechanism for Internationalized eMail Address", draft-ietf-eai-downgrade-07 (work in progress), 3 2008. [RFC2821bis] Klensin, J., "Simple Mail Transfer Protocol", Yao, et al. Expires April 24, 2009 [Page 9] Internet-Draft EAI Deployment Practices Oct. 2008 draft-klensin-rfc2821bis-10 (work in progress), 4 2008. 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 Xiaodong WU CNNIC No.4 South 4th Street, Zhongguancun Beijing Phone: +86 10 58813229 Email: wuxiaodong@cnnic.cn Yao, et al. Expires April 24, 2009 [Page 10] Internet-Draft EAI Deployment Practices Oct. 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Yao, et al. Expires April 24, 2009 [Page 11]