idnits 2.17.1 draft-yao-eai-deployment-03.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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 (July 13, 2009) is 5391 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3454' is mentioned on line 312, but not defined ** Obsolete undefined reference: RFC 3454 (Obsoleted by RFC 7564) == Unused Reference: 'ASCII' is defined on line 393, but no explicit reference was found in the text == Unused Reference: 'RFC1652' is defined on line 397, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 401, but no explicit reference was found in the text == Unused Reference: 'RFC3461' is defined on line 407, but no explicit reference was found in the text == Unused Reference: 'RFC3463' is defined on line 411, but no explicit reference was found in the text == Unused Reference: 'RFC3629' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'RFC4409' is defined on line 421, 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: 9 errors (**), 0 flaws (~~), 9 warnings (==), 4 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: January 14, 2010 July 13, 2009 7 Guidelines for Internationalized Email Deployment 8 draft-yao-eai-deployment-03.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on January 14, 2010. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 Key RFCs for internationalized email address have been published, 57 specifying the basic protocols for using it. This document provides 58 some guidelines for implementing the email systems that support Email 59 Address Internationalization (EAI). Its aim is to give some 60 suggestions and help the engineers to implement these protocols. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Role of this specification . . . . . . . . . . . . . . . . 3 66 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.1. From non-EAI world to EAI world . . . . . . . . . . . . . 4 69 2.2. SMTP client . . . . . . . . . . . . . . . . . . . . . . . 4 70 2.3. Relay Server . . . . . . . . . . . . . . . . . . . . . . . 5 71 2.4. SMTP Server . . . . . . . . . . . . . . . . . . . . . . . 5 72 2.5. Email Filter . . . . . . . . . . . . . . . . . . . . . . . 5 73 2.6. Firewall . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2.7. Mail User Agent . . . . . . . . . . . . . . . . . . . . . 6 75 2.8. Full Support of EAI Protocols . . . . . . . . . . . . . . 6 76 3. Alternate ASCII Address . . . . . . . . . . . . . . . . . . . 6 77 4. Internationalized Email Domains . . . . . . . . . . . . . . . 6 78 5. Converting Local Character Codes To UTF-8 encoding . . . . . . 7 79 6. Restrictions on Characters in Local Part . . . . . . . . . . . 7 80 7. Local Part Interpretations . . . . . . . . . . . . . . . . . . 8 81 8. Lookup in DNS . . . . . . . . . . . . . . . . . . . . . . . . 8 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 84 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 85 12. Change History . . . . . . . . . . . . . . . . . . . . . . . . 8 86 12.1. draft-yao-eai-deployment: Version 01 . . . . . . . . . . . 9 87 12.2. draft-yao-eai-deployment: Version 02 . . . . . . . . . . . 9 88 12.3. draft-yao-eai-deployment: Version 03 . . . . . . . . . . . 9 89 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 90 13.1. Normative References . . . . . . . . . . . . . . . . . . . 9 91 13.2. Informative References . . . . . . . . . . . . . . . . . . 10 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 94 1. Introduction 96 The IETF has published five RFCs [RFC4952] [RFC5335] [RFC5336] 97 [RFC5337] [RFC5504] about internationalized email addresses. The 98 goal of this document is to provide guidelines for Internationalized 99 Email Address (EAI) implementations. It highlights areas which EAI 100 implementors may find valuable. This document discusses potential 101 choices that can be made in an attempt to help to foster 102 interoperability between components that use the EAI protocols. EAI 103 extends the current base email standards [RFC5321] [RFC5322]. It is 104 important for EAI implementors to carry out a thorough analysis of 105 all of the base email standards to understand the relationships 106 between those standards and the current EAI protocols. A great deal 107 of the advice for making the EAI protocols more practical is 108 available to those who want to deploy the EAI protocols. More 109 discussions related to deployment reports on the prototype 110 implementation and the interoperability test results, as well as the 111 evaluation will be disscused in other document [DeploymentTests]. 113 1.1. Role of this specification 115 The framework document specifies the requirements for, and describes 116 components of, full internationalization of email address. The EAI 117 SMTP extension document [RFC5336] specifies the SMTP extension to use 118 the internationalized email address. The EAI header document 119 [RFC5335] allows the internationalized email address headers. The 120 EAI downgrade document [RFC5504] addresses how to downgrade to be 121 compatible with the current non-EAI-system. A thorough understanding 122 of the information in all these documents and in the base Internet 123 email specifications [RFC5321] [RFC5322] is necessary to understand 124 and implement this specification. 126 This document emphasizes some points in the EAI protocols and gives 127 some suggestions and advice for the usage, implementation and 128 deployment of internationalized email address. 130 1.2. Terminology 132 All the specialized terms used in this specification are defined in 133 the framework document [RFC4952], the EAI SMTP extension document 134 [RFC5336], the EAI header document [RFC5335] and the base Internet 135 email specifications [RFC5321] [RFC5322]. In particular, the terms 136 "ASCII user", and "i18mail user" are used in this document according 137 to the definitions in the framework one. 139 [[anchor3: NOTE TO RFC EDITOR: Please remove the following text 140 before publication.]] 141 Some ideas of this specification is being discussed on the EAI 142 mailing list. See https://www1.ietf.org/mailman/listinfo/ima for 143 information about subscribing. The list's archive is at 144 http://www1.ietf.org/mail-archive/web/ima/index.html. 146 2. Deployment 148 2.1. From non-EAI world to EAI world 150 An i18mail user normally uses the EAI-capability sending server which 151 his internationalized email address resides in. It is very unlikely 152 that the i18mail user use the non-EAI-capability server to send its 153 i18mail message. If that situations occures, the sending server will 154 reject the message or report it as an error. EAI Protocols are used 155 to exchange the message between at least 2 SMTP servers. If only one 156 SMTP server supports the EAI protocols, that is meaningless. When 157 one email service provider implements the EAI service, it can provide 158 registration of EAI account. The EAI user can exchange the email 159 within the domain. When another email service provider supports EAI 160 protocols, the EAI users within these 2 domains can exchange the EAI 161 message. When the demands for internationalized email address 162 increase, more and more email service providers will support EAI. 163 Although it is not possible to support EAI protocol within one night, 164 it is very possible that the EAI protocol will become more popular 165 with the time being. From non-EAI world to EAI world, it is 166 procedure of step by step. More issuses about this topic will be 167 discussed in other document[DeploymentTests]. 169 2.2. SMTP client 171 The SMTP client is used to send the message. It should implement the 172 specifications in the [RFC5335] and [RFC5336]. Since many SMTP 173 servers are still not ready to accept EAI messages, it is very 174 important to implement the mechanisms specified in the section 3.2 in 175 [RFC5336]. EAI messages can only be transferred to SMTP servers that 176 support EAI. If an alt-address is provided, it is easier for the 177 sender to reach the receiver as the downgrading mechanism spcified in 178 the [RFC5504] can be used. If the SMTP client has binded the EAI 179 account to the ASCII one specified in the section 3 of this document, 180 the SMTP client should find the ASCII address corresponding to the 181 EAI one and do some downgrading when encountering some non-EAI-aware 182 SMTP server. In other situations, the message can either be rejected 183 during the SMTP transaction or the SMTP server can accept the message 184 and then generate a notification of non-delivery. 186 2.3. Relay Server 188 It is possible that the relay server does not support EAI protocols. 189 If an EAI-aware SMTP client sends the message to a non-EAI-capable 190 relay server, the relay server should adopt one of the 4 methods 191 specified in section 3.2 in RFC 5336 [RFC5336]. If the relay server 192 is under the control of one organization which is in charge of both 193 the sending systems and relay servers, it is suggested that this 194 organization should update all its servers to support EAI protocols. 196 2.4. SMTP Server 198 If the SMTP server does not support EAI protocols, it will be not 199 accept the EAI message. If the EAI-aware SMTP server receiving the 200 EAI message is the the final delivery system, the message will be 201 delivered to the message store. If the EAI-capability server 202 receives the EAI message, the serve will distribute the message to 203 the message store. 205 2.5. Email Filter 207 Many email receivers have installed the email filters. Because EAI 208 messages may have some "non-ASCII" addresses, it is very strange to 209 email filters. Sometimes the internationalized domain names will be 210 transformed into punycode form when they arrived at the filters. 211 These forms are ugly and often get special processing from the filter 212 which suspects that the domain name with this form is randomly 213 created and is used for the spam mail. If the mail filters are not 214 updated to support EAI protocols, some may regard EAI messages as the 215 rubbish and drop them immediately; some may need more time to process 216 the message and delay it. It is suggested that the email filter 217 should be updated to accept EAI messages too when email server is 218 updatd. 220 2.6. Firewall 222 Firewall document [RFC2979] requires to perform extensive protocol 223 validity checks. Specially, in section 3.1.2 of RFC 2979 [RFC2979] 224 The firewall will scan the list of EHLO responses and only allow the 225 ones the firewalls understands through. The traditional fireall will 226 not understand the keyword "UTF8SMTP", lead to unnecessary protocol 227 failures, and cut off the SMTP connection. Some firewalls will be 228 acted as the SMTP relay or agent. These firewalls should be updated 229 to support EAI protocols. 231 2.7. Mail User Agent 233 The IETF has defined the protocols required to exchange EAI messages 234 between SMTP senders and SMTP receivers. If you want to use 235 internationalized email addresses, it is very vital that other parts 236 such as the Mail User Agent (MUA) supports EAI protocols. Since most 237 MUAs do not support internationalized email addresses, the MUA may 238 not be able to send EAI messages on behalf of the email user and 239 fetch EAI messages from the message store. For better use of EAI, 240 MUAs should be upgraded to support EAI protocols. 242 2.8. Full Support of EAI Protocols 244 The email system is very complex. Many parts of the email system 245 will use the email address. It is suggested that all parts of the 246 email system should be upgraded to support EAI protocols. 248 3. Alternate ASCII Address 250 There are millions email servers and clients. They cannot be updated 251 to support EAI protocols within a night. EAI protocols specify a 252 transitional mechanism which allows the EAI-capable SMTP clients to 253 talk with the non-EAI SMTP servers. During the deployment of EAI, it 254 is impossible to upgrade all SMTP clients and SMTP servers to support 255 EAI. The SMTPext document [RFC5336] specifies an ALT-ADDRESS 256 parameter for use when downgrading is required. Only EAI users may 257 require the Alternate ASCII Addresses, ASCII users has no need for 258 it. It is recommended that Alternate ASCII Addresses should not be 259 used by ASCII users as a general-purpose second-chance email address. 260 When the email user signs up for an internationalized email account, 261 it is better that the system automatically binds it with an Alternate 262 ASCII Address. This email account's name may be selected by email 263 account applicant. The Alternate ASCII Address is used for the ALT- 264 ADDRESS parameter. It can be an alias of the EAI account. Both the 265 internationalized email address and Alternate ASCII Address refer to 266 the same message store. This method has an advantage: When the EAI 267 user sends an email to other user, he or she does not need to fill in 268 an ASCII email address for the ALT-ADDRESS parameter when the 269 receiver does not support EAI. The EAI-capable SMTP system 270 automatically provides the Alternate ASCII Address which was prepared 271 in advance when the user signed up for an internationalized email 272 account. 274 4. Internationalized Email Domains 276 The email service provider could have both an internationalized email 277 domain and an ASCII email domain. The ASCII domain can be regarded 278 as the alias of the internationalized domain. The MX records for 279 both domains point to the same target host. 281 5. Converting Local Character Codes To UTF-8 encoding 283 Some systems, operating in local environments, will use local 284 character codes no matter what we specify. In many countries, there 285 are local national standards for character encoding. For example, in 286 China, GB2312 and GB18000 is the national standards. Japan has also 287 its own national character encoding standards. So there are some 288 reasons for permitting local-parts to be written in locally-used 289 character codes other than the UTF-8 encoding of UNICODE. On the 290 other hand, having an application presented with an octet (or bit) 291 string and not knowing what charset is involved would block the 292 attempt to intelligently display local parts. The EAI protocol 293 allows only UTF-8 encoding in the local part in the email header and 294 envelop. The MUA may display the message information with the local 295 character codes. But when the email address information is 296 transferred on the wire, it must use the UTF-8 encoding other than 297 local character encodings. Use of local coding also implies an 298 encoding for the local part different from that for the domain part. 299 The domain part of the internationalized email address will support 300 IDNA [RFC3490] and uses the UTF-8 encodings. If local codings can be 301 avoided entirely, it will considerably reduce complexity and 302 "opportunities" for systems to not interoperate. 304 6. Restrictions on Characters in Local Part 306 The EAI specification is extremely liberal about what can be included 307 in a UTF-8 string that represents a local-part. It prohibits the use 308 of quoted strings, or quoted characters, in non-ASCII local parts. 309 Quoted strings and characters in local parts have, in general, been 310 nothing but trouble and there appears to be no reason to carry that 311 trouble forward into an internationalized world. It is suggested 312 that applying restrictions by use of a stringprep [RFC3454] profile 313 that would eliminate particularly problematic characters is 314 suggested. IDNAbis label check may be used for local parts. Some 315 languages characters has some special features. For example, Chinese 316 characters has some varants. When registering the email account, the 317 technique specified in the RFC 3743 may be used for the possible 318 confusion. ASCII local-parts are inherently case sensitive. The 319 local systems are encouraged to not take advantage of that feature. 320 All internationalized email local part are suggested to be case 321 insensitive. 323 7. Local Part Interpretations 325 In the Internet email context, the interpretation and permitted 326 syntax for an email local-part is entirely the responsibility of the 327 receiving system. The general advice to system designers still 328 include "treat addresses in a case-independent fashion" and "do not 329 use addresses that require quoting". Senders should continue to be 330 conservative about what they send, and relays should continue to 331 avoid presumptions about their understanding of the content of local- 332 parts. Receiving systems that have reason to adopt more restricted 333 syntax rules, or interpretations of matching, should continue to be 334 able to do so. 336 8. Lookup in DNS 338 The domain part of the email address is used to route the message to 339 the proper destination. The domain part must be processed into the 340 punycode form specified in RFC 3490 [RFC3490] before DNS lookup. 342 9. IANA Considerations 344 There is no IANA consideraton. 346 10. Security Considerations 348 See the extended security considerations discussion in the framework 349 document [RFC4952]. 351 11. Acknowledgements 353 Many ideas are from the discussion in the list ima@ietf.org. John C 354 Klensin has done a lot of reasearch on ASCII email address and 355 internationalized email address. I got many significant words or 356 ideas from him. Many friends and experts in the EAI WG help us to 357 produce the valuable ideas. Many organizations including CNNIC, 358 TWNIC, JPRS, NIDA, AND AFFLILIAS have implemented EAI systems. These 359 organizations have already done a lot of inter-operating testing. S. 360 Moonesamy gives many kind comments to draft version 01. Thanks John 361 C Klensin for his comments to Draft version 02. 363 12. Change History 365 [[anchor12: RFC Editor: Please remove this section.]] 367 12.1. draft-yao-eai-deployment: Version 01 369 o update the section "Sending Server" 370 o add the new section "From non-EAI world to EAI world" 371 o update and refine the texts of this document 373 12.2. draft-yao-eai-deployment: Version 02 375 o rename the section "Sending Server" to "SMTP client" 376 o rename the section "Recieve Server" to "SMTP server" 377 o add the new section "Internationalized email domain" 378 o move and refine the section "Firewall" 379 o update and refine the texts of this document 381 12.3. draft-yao-eai-deployment: Version 03 383 o rename the draft title from "eai deployment practise" to 384 "Guidelines for Internationalized Email Deployment" 385 o remove the section "Test Scenarios" 386 o remove the section "Test Results and Experiences" 387 o update and refine the texts of this document 389 13. References 391 13.1. Normative References 393 [ASCII] American National Standards Institute (formerly United 394 States of America Standards Institute), "USA Code for 395 Information Interchange", ANSI X3.4-1968, 1968. 397 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 398 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 399 RFC 1652, July 1994. 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, March 1997. 404 [RFC2979] Freed, N., "Behavior of and Requirements for Internet 405 Firewalls", RFC 2979, October 2000. 407 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 408 Extension for Delivery Status Notifications (DSNs)", 409 RFC 3461, January 2003. 411 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 412 RFC 3463, January 2003. 414 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 415 "Internationalizing Domain Names in Applications (IDNA)", 416 RFC 3490, March 2003. 418 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 419 10646", RFC 3629, November 2003. 421 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 422 RFC 4409, April 2006. 424 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for 425 Internationalized Email", RFC 4952, July 2007. 427 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 428 October 2008. 430 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 431 October 2008. 433 [RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, 434 September 2008. 436 [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized 437 Email Addresses", RFC 5336, September 2008. 439 [RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery 440 Status and Disposition Notifications", RFC 5337, 441 September 2008. 443 13.2. Informative References 445 [DeploymentTests] 446 YAO, J., YEE, J., KAO, M., and D. KIM, "Discussion, Test 447 and Evaulation for EAI deployment", 448 draft-yao-eai-tests-00.txt (work in progress), 449 August 2009. 451 [RFC5504] YONEYA, Y., Ed. and K. Fujiwara, Ed., "Downgrading 452 mechanism for Internationalized eMail Address", RFC 5504, 453 3 2009. 455 Authors' Addresses 457 Jiankang YAO 458 CNNIC 459 No.4 South 4th Street, Zhongguancun 460 Beijing 462 Phone: +86 10 58813007 463 Email: yaojk@cnnic.cn 465 Xiaodong LEE 466 CNNIC 467 No.4 South 4th Street, Zhongguancun 468 Beijing 470 Phone: +86 10 58813020 471 Email: lee@cnnic.cn