Network Working Group J. Yao Internet-Draft X. Lee Intended status: Informational CNNIC Expires: April 22, 2010 E. Dainow Afilias Canada October 19, 2009 EAI downgrading tests and analysis draft-yao-eai-downgrade-tests-analysis-00.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 April 22, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Yao, et al. Expires April 22, 2010 [Page 1] Internet-Draft Problems October 2009 This document is subject to BCP 78 and the IETF Trust's Legal 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 The protocols specified in current EAI documents such as RFC5335, RFC5336 and RFC5504 are in experimental category. Many organizations have implemented and tested the internationalized email systems. Recently, many discussions focus on the issues of downgrading implementation and testing. This memo provides some analysis in depth about downgrade testing, which will help us deploy the EAI system and the re-charter work of the working group in the near future. Yao, et al. Expires April 22, 2010 [Page 2] Internet-Draft Problems October 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Role of this specification . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Initial Implementation and Downgrade Test . . . . . . . . . . 5 3.1. One i18mail user sends to one ASCII user . . . . . . . . . 5 3.2. An i18mail user sends to one ASCII user and one i18mail user . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Downgrade Headers . . . . . . . . . . . . . . . . . . . . 5 4. Downgrade Options . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Full downgrade . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Simple downgrade . . . . . . . . . . . . . . . . . . . . . 6 4.3. No downgrade . . . . . . . . . . . . . . . . . . . . . . . 7 5. ALT-ADDRESS . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. User preferred address . . . . . . . . . . . . . . . . . . 7 5.2. Algorithmic address . . . . . . . . . . . . . . . . . . . 7 5.2.1. Prefix . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2.2. Algorithm . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. draft-yao-eai-downgrade-tests-analysis: Version 00 . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Yao, et al. Expires April 22, 2010 [Page 3] Internet-Draft Problems October 2009 1. Introduction The IETF has published five RFCs [RFC4952] [RFC5335] [RFC5336] [RFC5337] [RFC5504] about internationalized email addresses. CNNIC and many organizations have implemented these RFCs, do some tests. This document will mainly focus on the downgrade tests and analysis. 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. The document reports some downgrading test result, summarizes the discussion in the IMA@ietf.org list, will help us understand the downgrade issue, and help the re-charter work. 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 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. Problem statement The EAI WG is moving to re-charter work. The tests and analysis of EAI downgrade will help to decide our work in the next step. For downgrading, the WG has discussed 3 options: full downgrade, simple downgrade and no downgrade. Whether the alt-address in the form of "prefix+algorithm" SHOULD be used is also discussed. Clear definition of the problem and good analysis will give some help to the WG's future work. Yao, et al. Expires April 22, 2010 [Page 4] Internet-Draft Problems October 2009 3. Initial Implementation and Downgrade Test As far as we know, CNNIC, TWNIC, AFILIAS, JPRS and NIDA have implemented the [RFC5335], [RFC5336], [RFC5504]. CNNIC updates the Postfix source code to support EAI. Both TWNIC and AFILIAS update Sendmail. JPRS uses C language to implement EAI. NIDA uses python to implement it. CNNIC and AFILIAS have published some downgrade test results in ima@ietf.org list. 3.1. One i18mail user sends to one ASCII user We use the UTF8SMTP address via alt-address to send the message to the following address: o * echo@generic-nic.net o * echo@nic.fr o * Echo@TU-Berlin.DE o * echo@tu-chemnitz.de o * echo@ouain.com o * repondsmoi@crdp.ac-versailles.fr o * echo@cnam.fr o * ping@stamper.itconsult.co.uk o * ping@oleane.net o * check-auth@verifier.port25.com These ten addresses are echo addresses. CNNIC tests these addresses several times. Last time, **ALL get nice echo, meaning that the downgrading sending gets the success**. AFILIAS tests these addresses too. The messages to echo@cnam.fr is bounced on all tests AFILIAS ran. The return message from this test is: 5.1.0 - Unknown address error 550-': Recipient address rejected: User unknown in local recipient table' **All tests on other addresses got successful echo**. 3.2. An i18mail user sends to one ASCII user and one i18mail user We use the UTF8SMTP address via alt-address to send the message to both the ASCII address and the UTF8SMTP address with alt-address. The UTF8SMTP address via alt-address going to the ASCII address will do the downgrade and the receiver receives it successfully. The receiver of the UTF8SMTP address with alt-address will get the message without the downgrading. 3.3. Downgrade Headers In the current test, all the downgrade header fields can have the possibility to survive the test. In some rare cases, the message with the downgrade headers may be regarded as the rubbish by the spam Yao, et al. Expires April 22, 2010 [Page 5] Internet-Draft Problems October 2009 filters and be discarded. But without other interference such as the spam filters, the header with the downgrade works well. 4. Downgrade Options There are 3 options for downgrading: Full downgrade, Simple downgrade and No downgrade at all. Every downgrade option has its own advantages and disadvantages. Which method is used in the future Standard track document depends on the alt-address selection and downgrade scenarios. 4.1. Full downgrade Full downgrade is a downgrade of both senders and receivers. The full downgrade is specified in the current document [RFC5504]. If all ASCII addresses for the UTF8SMTP addresses are provided, the full downgrade can happen. According to the [RFC5336], if any alt-address for the UTF8SMTP address is not provided, downgrade operation will fail. In practice, the i18mail sender is unlikely to provide all the alt-addresses when sending the messages. If you know both the UTF8SMTP address and the ASCII address of the receiver, you may select either the UTF8SMTP address or the ASCII address as the receiver address, but not both. If you input two, it is inconvenient for you. Most likely, the i18mail sender will just provide his own alt-address and input either the UTF8SMTP address or the ASCII address as the receiver address. So in most cases, the full downgrade will become into the simple downgrade discussed below. 4.2. Simple downgrade The simple downgrade is a downgrade which only downgrade the sender information or the "from" fields. The simple downgrade can be regarded as the special case of the full downgrade. If the alt- address of the sender UTF8SMTP address is provided, the downgrade can happen. The simple downgrade does not include the case that the sender is the ASCII sender while the receiver is the i18nmail user. It is based on the following assumption: if the sender does not support EAI, the sender's submission server or MUA can not recognize the UTF8SMTP address, the downgrade operation is unlikely to happen because the server or MUA will regard the UTF8SMTP address as illegal one and refuse to do any sending. In many cases, the full downgrade will turn into simple downgrade. So for most downgrade scenarios, the simple downgrade is most useful. According to the [RFC5336], if the alt-address for the sender UTF8SMTP address is not provided, downgrade operation will fail when the downgrade happens. From this view, the simple downgrade is also not fully reliable mechanism to transport every message to the receiver. Yao, et al. Expires April 22, 2010 [Page 6] Internet-Draft Problems October 2009 4.3. No downgrade No downgrade will do nothing about the downgrade, rejecting or bouncing. No downgrade means that if any non-EAI-capability server is encountered, the sender will get a notification which says that "Sorry, we can not send the UTF8SMTP message, please try to use the ASCII address." No downgrade is based on the assumption that if the user gets too many failure sending messages, the user will push the email service providers or implementers to support EAI. No downgrade may cause too many email messages bouncing or jecting, which lead to the inconvenience of the email users. 5. ALT-ADDRESS There are two kinds of alt-addresses, user preferred address and algorithmic address. The WG has already a lot of discussions about this issue. 5.1. User preferred address If user preferred address is selected, the users have to input both the senders' and receivers' alt-address if there is one. It is necessary for the user to remember every alt-address for the relative UTF8SMTP address. The advantage is that user preferred address is often the user friendly address. If you have to input every alt- address, you may simply use the ASCII address or simple downgrading. After all, inputting both UTF8SMTP address and its alt-address is boring to users. So the user will choose the convenient way to send the email: just using the ASCII address or simple downgrading. 5.2. Algorithmic address Algorithmic address is a raw ACE (ASCII Compatible Encoding) address plus some special prefix, which is the result of encoding of the non- ASCII local part. Since the current document [RFC5336] does not specify which kind of address can be regarded as the alt-address, many implementers will choose the algorithmic address as the alt- address. Algorithmic address may solve the message failure sending when full downgrade or simple downgrade is applied, but there are some significant problems and risks in some algorithmic addresses which have resulted in being rejected by earlier discussions in the working group 5.2.1. Prefix In order to distinguish the algorithmic address and the normal ASCII address, the good prefix for raw ACE is necessary. Many characters Yao, et al. Expires April 22, 2010 [Page 7] Internet-Draft Problems October 2009 of local part may have special use. The selection of local part should avoid such characters. It will be better if the prefix is never used in the local part of any normal email address. For the local parts of the special domain, we can check whether some specific prefix has been used as the prefix of the local part of this email domain. So we can find some specific string as the prefix, which has never been used as the the local part of this domain and will not be used in the future through some registration policy of the email accounts. 5.2.2. Algorithm The good algorithm for the non-ASCII local part may help the use of UTF8SMTP address. The possible algorithms for ACE might be punycode [RFC3492], base64 [RFC4648] or any other algorithm. As far as we know, all the possible ACE of the non-ASCII local part with the algorithm are ugly. The ACE is not easily remembered by the user, and the user will hate to see it. The algorithm address may help the transition from ASCII email address world to EAI world to avoid the possible email bouncing or rejecting. The ugly ACE address may bring more phishing incidents because the internet users can not easily distinguish the ugly address from its similar ugly address, for example, xn--adqweradsasdfasfdf VS xn--adqweradasdfasfdf. 6. IANA Considerations There is no IANA consideration. 7. Security Considerations See the extended security considerations discussion in the framework document [RFC4952]. 8. Acknowledgements Many ideas are from the discussion in the list ima@ietf.org. 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. 9. Change History [[anchor19: RFC Editor: Please remove this section.]] Yao, et al. Expires April 22, 2010 [Page 8] Internet-Draft Problems October 2009 9.1. draft-yao-eai-downgrade-tests-analysis: Version 00 o downgrade tests and analysis" 10. References 10.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. [DeploymentGuidelines] Yao, J. and X. Lee, "Guidelines for Internationalized Email Deployment", draft-yao-eai-deployment-03.txt (work in progress), September 2009. [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. [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. [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. [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006. Yao, et al. Expires April 22, 2010 [Page 9] Internet-Draft Problems October 2009 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 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. 10.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. Authors' Addresses Jiankang YAO CNNIC No.4 South 4th Street, Zhongguancun Beijing Phone: +86 10 58813007 Email: yaojk@cnnic.cn Yao, et al. Expires April 22, 2010 [Page 10] Internet-Draft Problems October 2009 Xiaodong LEE CNNIC No.4 South 4th Street, Zhongguancun Beijing Phone: +86 10 58813020 Email: lee@cnnic.cn Ernie Dainow Afilias Canada 4141 Yonge Street, Suite 204 Toronto, Ontario Canada M2P 2A8 Email: edainow@ca.afilias.info Yao, et al. Expires April 22, 2010 [Page 11]