Internet Draft Jiankang Yao, Editor Draft-Lee-JET-IMA-00.txt CNNIC June 27, 2005 Jeff Yeh Editor Expires: December 27,2005 TWNIC Internationalized eMail Address (IMA) < draft-lee-jet-ima-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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft expires on December 27, 2005. Abstract An email address has two parts - local part and domain part - separated by "@" sign. This document describes a basic solution to internationalized email address (IMA) and includes some preliminary survey results. The proposed solution enables SMTP servers to support IMA. The solution discussed in this document is immediately deployable by interested parties without affecting or breaking any other existing systems. Document Conventions JET Expires - December 2005 [Page 1] Internet draft IMA June 2005 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]. 1. Introduction to IMA In order to use internationalized email addresses, we need to internationalize both domain part and local part of email address. Domain part of email addresses had been internationalized through IDNA [RFC3490]. But the local part of email address still remains as non internationalized. At present, the use of Internet email address is restricted to a subset of 7-bit ASCII [RFC2821][RFC2822]. The MIME extensions provides a mechanism for the transmission of non-ASCII data that were previously unsupported in Internet mail. But it does not provide the mechanism for internationalized email address. [RFC2047] defines the message header extension for non ASCII 8-bit MIME messages. However, it does not address the issue if email addresses include non-ASCII characters. Anticipating the need to use the internationalized email address, the SMTP protocol should be extended to provide the transport mechanism for the internationalized email address. The length restrict to the local part in the section of RFC 2822 may need to be updated. 2. Problem statement Internationalized Domain Name (IDN) was standardized 2 years ago (2003) and several registries started to accept IDN registrations and the name resolutions. While the take-up of IDN varies, there is a strong demand for IDN in the regions where English is not their native language. Particularly in the CJK community, we noticed that registrants of IDN often enquired about if they could use Internationalized eMail Address (IMA) too. Unfortunately, while the domain name portion of the Email address could use IDN standards, there are no standards to internationalize the local-part (left hand side of the "@" mark). On the other hand, we envisage strong demands for IMA when IDN becomes popular. IMA will also promote the deployment of IDN. Several solutions for IMA have been deployed, e.g.,in China (35.com, zzy.cn, bizcn.com, ce.net.cn, dns.com.cn and topbiz.cn), but the lack of open and interoperable standards means that users of one system could not (reliably) communicate with users of another system. Therefore, the Internet community would benefit from the development of an open and interoperable IETF IMA standard. JET Expires - December 2005 [Page 2] Internet draft IMA June 2005 3. Requirements Any IMA solution should qualify the following requirements: 3.1 Short term (2-5 years) solution The solution should not extend too long, so that IMA can be adopted as soon as possible by interested companies. The solution also should be easily deployable, so that IMA can be easily deployed by most interested organizations during 2-5 years if they wish to. 3.2 Backward compatible with the existing standards The email service is one of the most important Internet services. Any updating to Internet protocols should not interfere with the operation of the Internet. The IMA solution should not break the base of the email service and be backward with the existing email standards. 3.3 Internationalized solution (over localized solution) The solution should be an internationalized one rather than localized one. 4. Architecture Solving the problem of IMA is not easy. We should divide it into two phases. In the first phase, we consider the ACE@ACE solution, which is easy to implement, backward compatible, short-term and internationalized solution. In the next phase, we may consider other mechanisms such as UTF-8@ACE. In the ACE@ACE solution, the local part of the IMA will be converted to ASCII Compatible Encoding; IDNA (RFC3490) will be applied to the domain part of the IMA. In this draft, we mainly focus on the ACE@ACE solution. 4.1 Encoding A good ACE converting algorithm should be considered according to the following criteria: Popularity Length of the encoded name Implementation easiness Produce valid email address Case sensitivity Impact on existing protocol 4.2 Normalization (IMAprep) JET Expires - December 2005 [Page 3] Internet draft IMA June 2005 There are profiles for Stringprep such as Nameprep[RFC3491] dealing with the IDN preparation and Nodeprep[RFC3920] for internationalized node identifiers. IMAprep is introduced to prepare the local part of IMA. IMAprep is a profile of Stringprep [RFC3454]. IMAprep [Appendix A] is used to process only the local part of IMA, not the whole email address. In IMAprep, no normalization and no case folding are needed. And there must be a prohibited list, but we will not discuss details of IMAprep in this draft. 4.3 Mail Delivery Agent (MDA) MDA is a part of mail servers, which are responsible for delivery of mails to local mail spool or sending out to another mail server. Usually, IMA is represented in the format of UTF-8 in a host while it should be converted into ACE format while being transported over the wire. There are various unofficial conventions for structured local parts, like owner-listname, user+tag, sublocal.local, path!user, etc. When internationalized local part being converted into ACE format, it actually causes some problems. Therefore, MDA may need to convert internationalized local part back to UTF8 (or original encoding) for further mailing processing. 4.4 Prefix Since the prefix "xn--" had been used for IDNA, it is better that other prefix such as "bq--" is used for the local part of IMA to avoid of potential confusion. 5. Deployment Email is an important and popular internet service. Any new deployments of SMTP servers which support IMA should not disturb the running of current email system. Since all the SMTP servers around the world can not support IMA immediately, ACE@ACE solution would be the most harmless solution to implement and deploy. 6. Potential problems 6.1 Impact to IRI The mailto: schema in IRI [RFC3987] may need to be modified when IMA is standardlized. 6.2 POP and IMAP While SMTP takes care of the transportation of messages and the header fields correspond to the display management by the clients, POP essentially handles the retrieval of mail objects from the server by a client. In order to use internationalized user names based on IMA for the retrieval of messages from a mail server using the POP JET Expires - December 2005 [Page 4] Internet draft IMA June 2005 protocol, a new capability should be introduced following the POP3 extension mechanism [RFC 2449]. IMAP uses the traditional user name which is based on ASCII. IMAP should be updated to support the internationalized user names based on IMA for the retrieval of messages from a mail server 7. Security Considerations There have been discussions on so called "IDN-spoofing". IDN homograph attacks allow an attacker/phisher to spoof the domain/URLs of businesses. The same kind of attack is also possible on the local part of internationalized email addresses. IMA can also introduce new email spamming. Many local parts of IMA will be the names of the person or company, which could easily be used by email spammer to guess the email address to produce the rubbish emails. Email spamming may combine with email spoofing and homograph attacks, making it more difficult to determine who actually sent the email. Any solution that meets the requirements in this document must not be less secure than the current Email Service. Specifying requirements for internationalized email addresses does not itself raise any new security issues. However, any change to the email service may affect the security of any protocol that uses the email address. A thorough evaluation of those protocols for security concerns will be needed when they are developed. 8. References [RFC1869] Klensin,J., Freed, N., Rose, M., Stefferud, E., Crocker, D., "SMTP Service Extensions", RFC 1869, November 1995. [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [RFC2449] R. Gellens, C. Newman, L. Lundblade, "POP3 Extension Mechanism" RFC2449 November 1998 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC3454] P. Hoffman, M. Blanchet, "Preparation of Internationalized Strings ("stringprep")" RFC3454 December 2002 [RFC3490] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing Domain Names in Applications (IDNA)",RFC 3490, March 2003. [RFC3491] P. Hoffman , M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names" RFC3491 March 2003 JET Expires - December 2005 [Page 5] Internet draft IMA June 2005 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003. [RFC3629] Yergeau, F.,"UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003. [RFC3920] P. Saint-Andre, "Extensible Messaging and Presence Protocol (XMPP): Core", RFC3920 October 2004 [RFC3987] M. Duerst, M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC3987 January 2005 9. Authors Xiaodong LEE (lee@cnnic.cn) China Internet Network Information Center (CNNIC) Nai-Wen Hsu (snw@twnic.net.tw) Taiwan Network Information Center (TWNIC) Yoshiro YONEYA yone@jprs.co.jp Japan Registry Services, Co. Ltd YangWoo Ko (yw@mrko.pe.kr) Korea Network Information Center James Seng (james@seng.cc) Former co-chair of IETF IDN Working Group Editors Jiankang YAO (yaojk@cnnic.cn) China Internet Network Information Center (CNNIC) Jeff Yeh (jeff@twnic.net.tw) Taiwan Network Information Center (TWNIC) 10. Acknowledgments Authors gratefully acknowledge the contributions of: * John C Klensin for his discussion with us in 62nd IETF meeting and his internet draft about IMA * Paul Hoffman and Adam M. Costello for their internet draft about IMA JET Expires - December 2005 [Page 6] Internet draft IMA June 2005 Appendix A: IMAprep Conclusion: no normalization, but there still prep needed, define our own prep for the email local part our own prep: no normalization no case folding prohibited list - ..... (discussed later after meeting ) local part ??problem: No RFC standards define this part The MDA must support internationalized local part, anyway No use of ACE deals the mail processing, so it should be converted back to UTF8, then be dealt with the mail processing JET Expires - December 2005 [Page 7] Internet draft IMA June 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. JET Expires - December 2005 [Page 8]