idnits 2.17.1 draft-yao-eai-downgrade-tests-analysis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 19, 2009) is 5303 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ASCII' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'DeploymentGuidelines' is defined on line 343, but no explicit reference was found in the text == Unused Reference: 'RFC1652' is defined on line 348, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 352, but no explicit reference was found in the text == Unused Reference: 'RFC2979' is defined on line 355, but no explicit reference was found in the text == Unused Reference: 'RFC3461' is defined on line 358, but no explicit reference was found in the text == Unused Reference: 'RFC3463' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'RFC3490' is defined on line 365, but no explicit reference was found in the text == Unused Reference: 'RFC3629' is defined on line 373, but no explicit reference was found in the text == Unused Reference: 'RFC4409' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'DeploymentTests' is defined on line 403, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1652 (Obsoleted by RFC 6152) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 4409 (Obsoleted by RFC 6409) ** Obsolete normative reference: RFC 4952 (Obsoleted by RFC 6530) ** Obsolete normative reference: RFC 5335 (Obsoleted by RFC 6532) ** Obsolete normative reference: RFC 5336 (Obsoleted by RFC 6531) ** Obsolete normative reference: RFC 5337 (Obsoleted by RFC 6533) -- No information found for draft-yao-eai-tests - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 5504 (Obsoleted by RFC 6530) Summary: 8 errors (**), 0 flaws (~~), 14 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Yao 3 Internet-Draft X. Lee 4 Intended status: Informational CNNIC 5 Expires: April 22, 2010 E. Dainow 6 Afilias Canada 7 October 19, 2009 9 EAI downgrading tests and analysis 10 draft-yao-eai-downgrade-tests-analysis-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on April 22, 2010. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 The protocols specified in current EAI documents such as RFC5335, 59 RFC5336 and RFC5504 are in experimental category. Many organizations 60 have implemented and tested the internationalized email systems. 61 Recently, many discussions focus on the issues of downgrading 62 implementation and testing. This memo provides some analysis in 63 depth about downgrade testing, which will help us deploy the EAI 64 system and the re-charter work of the working group in the near 65 future. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 1.1. Role of this specification . . . . . . . . . . . . . . . . 4 71 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Initial Implementation and Downgrade Test . . . . . . . . . . 5 74 3.1. One i18mail user sends to one ASCII user . . . . . . . . . 5 75 3.2. An i18mail user sends to one ASCII user and one 76 i18mail user . . . . . . . . . . . . . . . . . . . . . . . 5 77 3.3. Downgrade Headers . . . . . . . . . . . . . . . . . . . . 5 78 4. Downgrade Options . . . . . . . . . . . . . . . . . . . . . . 6 79 4.1. Full downgrade . . . . . . . . . . . . . . . . . . . . . . 6 80 4.2. Simple downgrade . . . . . . . . . . . . . . . . . . . . . 6 81 4.3. No downgrade . . . . . . . . . . . . . . . . . . . . . . . 7 82 5. ALT-ADDRESS . . . . . . . . . . . . . . . . . . . . . . . . . 7 83 5.1. User preferred address . . . . . . . . . . . . . . . . . . 7 84 5.2. Algorithmic address . . . . . . . . . . . . . . . . . . . 7 85 5.2.1. Prefix . . . . . . . . . . . . . . . . . . . . . . . . 7 86 5.2.2. Algorithm . . . . . . . . . . . . . . . . . . . . . . 8 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 89 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 90 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 8 91 9.1. draft-yao-eai-downgrade-tests-analysis: Version 00 . . . . 9 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 94 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 97 1. Introduction 99 The IETF has published five RFCs [RFC4952] [RFC5335] [RFC5336] 100 [RFC5337] [RFC5504] about internationalized email addresses. CNNIC 101 and many organizations have implemented these RFCs, do some tests. 102 This document will mainly focus on the downgrade tests and analysis. 104 1.1. Role of this specification 106 The framework document specifies the requirements for, and describes 107 components of, full internationalization of email address. The EAI 108 SMTP extension document [RFC5336] specifies the SMTP extension to use 109 the internationalized email address. The EAI header document 110 [RFC5335] allows the internationalized email address headers. The 111 EAI downgrade document [RFC5504] addresses how to downgrade to be 112 compatible with the current non-EAI-system. The document reports 113 some downgrading test result, summarizes the discussion in the 114 IMA@ietf.org list, will help us understand the downgrade issue, and 115 help the re-charter work. 117 1.2. Terminology 119 All the specialized terms used in this specification are defined in 120 the framework document [RFC4952], the EAI SMTP extension document 121 [RFC5336], the EAI header document [RFC5335] and the base Internet 122 email specifications [RFC5321] [RFC5322]. In particular, the terms 123 "ASCII user", and "i18mail user" are used in this document according 124 to the definitions in the framework one. 126 [[anchor3: NOTE TO RFC EDITOR: Please remove the following text 127 before publication.]] 128 Some ideas of this specification is being discussed on the EAI 129 mailing list. See https://www1.ietf.org/mailman/listinfo/ima for 130 information about subscribing. The list's archive is at 131 http://www1.ietf.org/mail-archive/web/ima/index.html. 133 2. Problem statement 135 The EAI WG is moving to re-charter work. The tests and analysis of 136 EAI downgrade will help to decide our work in the next step. For 137 downgrading, the WG has discussed 3 options: full downgrade, simple 138 downgrade and no downgrade. Whether the alt-address in the form of 139 "prefix+algorithm" SHOULD be used is also discussed. Clear 140 definition of the problem and good analysis will give some help to 141 the WG's future work. 143 3. Initial Implementation and Downgrade Test 145 As far as we know, CNNIC, TWNIC, AFILIAS, JPRS and NIDA have 146 implemented the [RFC5335], [RFC5336], [RFC5504]. CNNIC updates the 147 Postfix source code to support EAI. Both TWNIC and AFILIAS update 148 Sendmail. JPRS uses C language to implement EAI. NIDA uses python 149 to implement it. CNNIC and AFILIAS have published some downgrade 150 test results in ima@ietf.org list. 152 3.1. One i18mail user sends to one ASCII user 154 We use the UTF8SMTP address via alt-address to send the message to 155 the following address: 156 o * echo@generic-nic.net 157 o * echo@nic.fr 158 o * Echo@TU-Berlin.DE 159 o * echo@tu-chemnitz.de 160 o * echo@ouain.com 161 o * repondsmoi@crdp.ac-versailles.fr 162 o * echo@cnam.fr 163 o * ping@stamper.itconsult.co.uk 164 o * ping@oleane.net 165 o * check-auth@verifier.port25.com 166 These ten addresses are echo addresses. CNNIC tests these addresses 167 several times. Last time, **ALL get nice echo, meaning that the 168 downgrading sending gets the success**. AFILIAS tests these 169 addresses too. The messages to echo@cnam.fr is bounced on all tests 170 AFILIAS ran. The return message from this test is: 172 5.1.0 - Unknown address error 550-': 173 Recipient address rejected: User unknown in local recipient table' 175 **All tests on other addresses got successful echo**. 177 3.2. An i18mail user sends to one ASCII user and one i18mail user 179 We use the UTF8SMTP address via alt-address to send the message to 180 both the ASCII address and the UTF8SMTP address with alt-address. 181 The UTF8SMTP address via alt-address going to the ASCII address will 182 do the downgrade and the receiver receives it successfully. The 183 receiver of the UTF8SMTP address with alt-address will get the 184 message without the downgrading. 186 3.3. Downgrade Headers 188 In the current test, all the downgrade header fields can have the 189 possibility to survive the test. In some rare cases, the message 190 with the downgrade headers may be regarded as the rubbish by the spam 191 filters and be discarded. But without other interference such as the 192 spam filters, the header with the downgrade works well. 194 4. Downgrade Options 196 There are 3 options for downgrading: Full downgrade, Simple downgrade 197 and No downgrade at all. Every downgrade option has its own 198 advantages and disadvantages. Which method is used in the future 199 Standard track document depends on the alt-address selection and 200 downgrade scenarios. 202 4.1. Full downgrade 204 Full downgrade is a downgrade of both senders and receivers. The 205 full downgrade is specified in the current document [RFC5504]. If 206 all ASCII addresses for the UTF8SMTP addresses are provided, the full 207 downgrade can happen. According to the [RFC5336], if any alt-address 208 for the UTF8SMTP address is not provided, downgrade operation will 209 fail. In practice, the i18mail sender is unlikely to provide all the 210 alt-addresses when sending the messages. If you know both the 211 UTF8SMTP address and the ASCII address of the receiver, you may 212 select either the UTF8SMTP address or the ASCII address as the 213 receiver address, but not both. If you input two, it is inconvenient 214 for you. Most likely, the i18mail sender will just provide his own 215 alt-address and input either the UTF8SMTP address or the ASCII 216 address as the receiver address. So in most cases, the full 217 downgrade will become into the simple downgrade discussed below. 219 4.2. Simple downgrade 221 The simple downgrade is a downgrade which only downgrade the sender 222 information or the "from" fields. The simple downgrade can be 223 regarded as the special case of the full downgrade. If the alt- 224 address of the sender UTF8SMTP address is provided, the downgrade can 225 happen. The simple downgrade does not include the case that the 226 sender is the ASCII sender while the receiver is the i18nmail user. 227 It is based on the following assumption: if the sender does not 228 support EAI, the sender's submission server or MUA can not recognize 229 the UTF8SMTP address, the downgrade operation is unlikely to happen 230 because the server or MUA will regard the UTF8SMTP address as illegal 231 one and refuse to do any sending. In many cases, the full downgrade 232 will turn into simple downgrade. So for most downgrade scenarios, 233 the simple downgrade is most useful. According to the [RFC5336], if 234 the alt-address for the sender UTF8SMTP address is not provided, 235 downgrade operation will fail when the downgrade happens. From this 236 view, the simple downgrade is also not fully reliable mechanism to 237 transport every message to the receiver. 239 4.3. No downgrade 241 No downgrade will do nothing about the downgrade, rejecting or 242 bouncing. No downgrade means that if any non-EAI-capability server 243 is encountered, the sender will get a notification which says that 244 "Sorry, we can not send the UTF8SMTP message, please try to use the 245 ASCII address." No downgrade is based on the assumption that if the 246 user gets too many failure sending messages, the user will push the 247 email service providers or implementers to support EAI. No downgrade 248 may cause too many email messages bouncing or jecting, which lead to 249 the inconvenience of the email users. 251 5. ALT-ADDRESS 253 There are two kinds of alt-addresses, user preferred address and 254 algorithmic address. The WG has already a lot of discussions about 255 this issue. 257 5.1. User preferred address 259 If user preferred address is selected, the users have to input both 260 the senders' and receivers' alt-address if there is one. It is 261 necessary for the user to remember every alt-address for the relative 262 UTF8SMTP address. The advantage is that user preferred address is 263 often the user friendly address. If you have to input every alt- 264 address, you may simply use the ASCII address or simple downgrading. 265 After all, inputting both UTF8SMTP address and its alt-address is 266 boring to users. So the user will choose the convenient way to send 267 the email: just using the ASCII address or simple downgrading. 269 5.2. Algorithmic address 271 Algorithmic address is a raw ACE (ASCII Compatible Encoding) address 272 plus some special prefix, which is the result of encoding of the non- 273 ASCII local part. Since the current document [RFC5336] does not 274 specify which kind of address can be regarded as the alt-address, 275 many implementers will choose the algorithmic address as the alt- 276 address. Algorithmic address may solve the message failure sending 277 when full downgrade or simple downgrade is applied, but there are 278 some significant problems and risks in some algorithmic addresses 279 which have resulted in being rejected by earlier discussions in the 280 working group 282 5.2.1. Prefix 284 In order to distinguish the algorithmic address and the normal ASCII 285 address, the good prefix for raw ACE is necessary. Many characters 286 of local part may have special use. The selection of local part 287 should avoid such characters. It will be better if the prefix is 288 never used in the local part of any normal email address. For the 289 local parts of the special domain, we can check whether some specific 290 prefix has been used as the prefix of the local part of this email 291 domain. So we can find some specific string as the prefix, which has 292 never been used as the the local part of this domain and will not be 293 used in the future through some registration policy of the email 294 accounts. 296 5.2.2. Algorithm 298 The good algorithm for the non-ASCII local part may help the use of 299 UTF8SMTP address. The possible algorithms for ACE might be punycode 300 [RFC3492], base64 [RFC4648] or any other algorithm. As far as we 301 know, all the possible ACE of the non-ASCII local part with the 302 algorithm are ugly. The ACE is not easily remembered by the user, 303 and the user will hate to see it. The algorithm address may help the 304 transition from ASCII email address world to EAI world to avoid the 305 possible email bouncing or rejecting. The ugly ACE address may bring 306 more phishing incidents because the internet users can not easily 307 distinguish the ugly address from its similar ugly address, for 308 example, xn--adqweradsasdfasfdf VS xn--adqweradasdfasfdf. 310 6. IANA Considerations 312 There is no IANA consideration. 314 7. Security Considerations 316 See the extended security considerations discussion in the framework 317 document [RFC4952]. 319 8. Acknowledgements 321 Many ideas are from the discussion in the list ima@ietf.org. Many 322 friends and experts in the EAI WG help us to produce the valuable 323 ideas. Many organizations including CNNIC, TWNIC, JPRS, NIDA, AND 324 AFFLILIAS have implemented EAI systems. These organizations have 325 already done a lot of inter-operating testing. 327 9. Change History 329 [[anchor19: RFC Editor: Please remove this section.]] 331 9.1. draft-yao-eai-downgrade-tests-analysis: Version 00 333 o downgrade tests and analysis" 335 10. References 337 10.1. Normative References 339 [ASCII] American National Standards Institute (formerly United 340 States of America Standards Institute), "USA Code for 341 Information Interchange", ANSI X3.4-1968, 1968. 343 [DeploymentGuidelines] 344 Yao, J. and X. Lee, "Guidelines for Internationalized 345 Email Deployment", draft-yao-eai-deployment-03.txt (work 346 in progress), September 2009. 348 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 349 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 350 RFC 1652, July 1994. 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, March 1997. 355 [RFC2979] Freed, N., "Behavior of and Requirements for Internet 356 Firewalls", RFC 2979, October 2000. 358 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 359 Extension for Delivery Status Notifications (DSNs)", 360 RFC 3461, January 2003. 362 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 363 RFC 3463, January 2003. 365 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 366 "Internationalizing Domain Names in Applications (IDNA)", 367 RFC 3490, March 2003. 369 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 370 for Internationalized Domain Names in Applications 371 (IDNA)", RFC 3492, March 2003. 373 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 374 10646", RFC 3629, November 2003. 376 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 377 RFC 4409, April 2006. 379 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 380 Encodings", RFC 4648, October 2006. 382 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for 383 Internationalized Email", RFC 4952, July 2007. 385 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 386 October 2008. 388 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 389 October 2008. 391 [RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, 392 September 2008. 394 [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized 395 Email Addresses", RFC 5336, September 2008. 397 [RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery 398 Status and Disposition Notifications", RFC 5337, 399 September 2008. 401 10.2. Informative References 403 [DeploymentTests] 404 YAO, J., YEE, J., KAO, M., and D. KIM, "Discussion, Test 405 and Evaulation for EAI deployment", 406 draft-yao-eai-tests-00.txt (work in progress), 407 August 2009. 409 [RFC5504] YONEYA, Y., Ed. and K. Fujiwara, Ed., "Downgrading 410 mechanism for Internationalized eMail Address", RFC 5504, 411 3 2009. 413 Authors' Addresses 415 Jiankang YAO 416 CNNIC 417 No.4 South 4th Street, Zhongguancun 418 Beijing 420 Phone: +86 10 58813007 421 Email: yaojk@cnnic.cn 422 Xiaodong LEE 423 CNNIC 424 No.4 South 4th Street, Zhongguancun 425 Beijing 427 Phone: +86 10 58813020 428 Email: lee@cnnic.cn 430 Ernie Dainow 431 Afilias Canada 432 4141 Yonge Street, Suite 204 433 Toronto, Ontario 434 Canada M2P 2A8 436 Email: edainow@ca.afilias.info