[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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-'<echo@copernic.cnam.fr>:
    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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/