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]