idnits 2.17.1 draft-ietf-eai-smtpext-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 663. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 681. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 687. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: An SMTP Client that receives the UTF8SMTP extension keyword in response to the "EHLO" command MAY transmit a mailbox name as an internationalized string in UTF-8 form and MAY send an internationalized mail header [EAI-utf8header]. It MAY transmit the domain part of that string in either punycode (derived from the IDNA process) or UTF-8 form. If it sends the domain in UTF-8 form, the original SMTP client SHOULD first verify that the string is valid for a domain name according to IDNA rules. As required by RFC 2821, it MUST not attempt to parse, evaluate, or transform the local part in any way if the UTF8SMTP SMTP extension is offered by the server. If the UTF8SMTP SMTP extension is not offered by the Server, the SMTP Client MUST NOT transmit an internationalized address and MUST NOT transmit a mail body which contains internationalized mail headers [EAI-utf8header]. Instead, it MUST either return the message to the user as undeliverable or replace it with the alternate ASCII address. If it is replaced, the replacement MUST be the ASCII-only address specified with the ALT-ADDRESS parameter.[EAI-downgrading]. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 23, 2006) is 6394 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Ldh-str' is mentioned on line 230, but not defined == Unused Reference: 'ASCII' is defined on line 520, but no explicit reference was found in the text == Unused Reference: 'RFC3454' is defined on line 589, but no explicit reference was found in the text == Unused Reference: 'RFC3492' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 627, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-eai-downgrade-02 == Outdated reference: A later version (-09) exists of draft-ietf-eai-imap-utf8-00 == Outdated reference: A later version (-05) exists of draft-ietf-eai-framework-02 == Outdated reference: A later version (-12) exists of draft-ietf-eai-utf8headers-01 ** Obsolete normative reference: RFC 1652 (Obsoleted by RFC 6152) ** Obsolete normative reference: RFC 1869 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 2476 (Obsoleted by RFC 4409) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) Summary: 12 errors (**), 0 flaws (~~), 12 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Yao, Ed. 3 Internet-Draft W. Mao, Ed. 4 Intended status: Informational CNNIC 5 Expires: April 26, 2007 October 23, 2006 7 SMTP extension for internationalized email address 8 draft-ietf-eai-smtpext-02.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 26, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 Internationalized email address includes two parts, the local part 42 and the domain part. The ways email addresses are used by protocols 43 are different from the ways domain names are used. The most critical 44 difference is that emails are delivered through a chain of peering 45 clients and servers while domain names are resolved by name servers 46 by looking up their own tables. In addition to this, email transport 47 protocols SMTP and ESMTP provide a negotiation mechanism through 48 which clients can make decisions for further processing. So 49 internationalized email address is different from the 50 internationalized domain name (IDN). It can be solved by exploiting 51 the negotiation mechanism while IDN can not use the negotiation 52 mechanism. So internationalized email address SHOULD be solved in 53 the mail transport-level using the negotiation mechanism, which is an 54 architecturally desirable approach. This document specifies the use 55 of SMTP extension for internationalized email address delivery. It 56 also mentions the backward compatible mechanism for downgrade 57 procedure, as specified in an associated specification. The protocol 58 proposed here is MTA-level solution which is feasible, 59 architecturally more elegant, and not as difficult to deploy in 60 relevant communities. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.1. Role of this specification . . . . . . . . . . . . . . . . 4 66 1.2. Proposal Context . . . . . . . . . . . . . . . . . . . . . 4 67 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Mail Transport-level Protocol . . . . . . . . . . . . . . . . 5 69 2.1. Framework for the Internationalization Extension . . . . . 5 70 2.2. The Address Internationalization Service Extension . . . . 5 71 2.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 6 72 2.4. The ALT-ADDRESS parameter . . . . . . . . . . . . . . . . 7 73 2.5. The Suggestion of the Value of the ALT-ADDRESS 74 parameter . . . . . . . . . . . . . . . . . . . . . . . . 8 75 2.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 9 76 2.7. Additional ESMTP Changes and Clarifications . . . . . . . 9 77 2.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 10 78 2.7.2. Trace Fields . . . . . . . . . . . . . . . . . . . . . 10 79 2.7.3. Mailing List Question . . . . . . . . . . . . . . . . 10 80 2.7.4. Message Header Label . . . . . . . . . . . . . . . . . 10 81 2.7.5. POP and IMAP . . . . . . . . . . . . . . . . . . . . . 10 82 2.7.6. SMTP Service Extension for DSNs . . . . . . . . . . . 11 83 3. Potential problems . . . . . . . . . . . . . . . . . . . . . . 11 84 3.1. Impact to IRI . . . . . . . . . . . . . . . . . . . . . . 11 85 3.2. Impact to RFC 2476 and many email related RFC . . . . . . 11 86 4. Implementation Advice . . . . . . . . . . . . . . . . . . . . 11 87 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 88 6. Security considerations . . . . . . . . . . . . . . . . . . . 12 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 90 8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 12 91 8.1. draft-ietf-eai-smtpext: Version 00 . . . . . . . . . . . . 12 92 8.2. draft-ietf-eai-smtpext: Version 01 . . . . . . . . . . . . 12 93 8.3. draft-ietf-eai-smtpext: Version 02 . . . . . . . . . . . . 12 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 95 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 96 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 98 Intellectual Property and Copyright Statements . . . . . . . . . . 16 100 1. Introduction 102 1.1. Role of this specification 104 An overview document [EAI-overview] specifies the requirements for, 105 and components of, full internationalization of electronic mail. 106 This document specifies an element of that work, specifically the 107 definition of an SMTP extension [RFC1869] for the internationalized 108 email address transport delivery. 110 1.2. Proposal Context 112 In order to use internationalized email addresses, we need to 113 internationalize both the domain part and the local part of the email 114 address. Domain part of the email address has been internationalized 115 through IDNA [RFC3490]. But the local part of the email address 116 still remains as non-internationalized. 118 The syntax of Internet email addresses is restricted to a subset of 119 7-bit ASCII for the domain-part, with a less-restricted subset for 120 the local-part. These restrictions are specified in RFC 2821 121 [RFC2821]. To be able to deliver internationalized email through 122 SMTP servers, we need to upgrade SMTP server to be able to carry the 123 internationalized email address. Since older SMTP servers and the 124 mail-reading clients and other systems that are downstream from them 125 MAY not be prepared to handle these extended addresses, an SMTP 126 extension is specified to identify and protect the addressing 127 mechanism. 129 This specification describes a change to the email transport 130 mechanism that permits non-ASCII address in both the envelope and 131 header fields of messages. The context for the change is described 132 in [EAI-overview] and the details of the header changes are described 133 in [EAI-utf8header]. 135 1.3. Terminology 137 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 138 and "MAY" in this document are to be interpreted as described in RFC 139 2119 [RFC2119]. 141 All specialized terms used in this specification are defined in the 142 EAI overview [EAI-overview] or in [RFC2821] and [RFC2822]. The terms 143 "ASCII address", "internationalized email address", "non-ASCII 144 address", "i18mail address", "UTF8SMTP", "message" and "mailing list" 145 are used with the definitions from the EAI overview document. 147 This document is being discussed on the EAI mailing list. See 148 https://www1.ietf.org/mailman/listinfo/ima for information about 149 subscribing. The list's archive is at 150 http://www1.ietf.org/mail-archive/web/ima/index.html. 152 2. Mail Transport-level Protocol 154 2.1. Framework for the Internationalization Extension 156 The following service extension is defined: 158 1. The name of the SMTP service extension is "Email Address 159 Internationalization"; 160 2. The EHLO keyword value associated with this extension is 161 "UTF8SMTP"; 162 3. No parameter values are defined for this EHLO keyword value. In 163 order to permit future (although unanticipated) extensions, the 164 EHLO response MUST NOT contain any parameters for that keyword. 165 If a parameter appears, the SMTP client that is conformant to 166 this version of this specification MUST treat the ESMTP response 167 as if the "UTF8SMTP" keyword did not appear. 168 4. An optional parameter is added to the SMTP MAIL and RCPT 169 commands. The parameter is named as ALT-ADDRESS. The "ALT- 170 ADDRESS" requires an all-ASCII address as a substitute for the 171 i18mail addresses that we call the primary address; you can learn 172 more in [EAI-overview] or [EAI-downgrading]. The value of "ALT- 173 ADDRESS" is set by the sender when MUA and the Submission server 174 have a communication. 175 5. No additional SMTP verbs are defined by this extension. 176 6. Servers offering this extension MUST provide support for, and 177 announce, the 8BITMIME extension [RFC1652]. 179 2.2. The Address Internationalization Service Extension 181 An SMTP Server that announces this extension MUST be prepared to 182 accept a UTF-8 string [RFC3629] in any position in which RFC 2821 183 specifies that a "mailbox" MAY appear. That string MUST be parsed 184 only as specified in RFC 2821, i.e., by separating the mailbox into 185 source route, local part and domain part, using only the characters 186 colon (U+003A), comma (U+002C), and at-sign (U+0040) as specified 187 there. Once isolated by this parsing process, the local part MUST be 188 treated as opaque unless the SMTP Server is the final delivery MTA. 189 Any domain names that are to be looked up in the DNS MUST first be 190 processed into the form as specified in IDNA [RFC3490] by means of 191 the ToASCII() operation unless they are already in that form. Any 192 domain names that are to be compared to local strings SHOULD be 193 checked for validity and then MUST be compared as specified in 194 section 3.4 of IDNA. 196 An SMTP Client that receives the UTF8SMTP extension keyword in 197 response to the "EHLO" command MAY transmit a mailbox name as an 198 internationalized string in UTF-8 form and MAY send an 199 internationalized mail header [EAI-utf8header]. It MAY transmit the 200 domain part of that string in either punycode (derived from the IDNA 201 process) or UTF-8 form. If it sends the domain in UTF-8 form, the 202 original SMTP client SHOULD first verify that the string is valid for 203 a domain name according to IDNA rules. As required by RFC 2821, it 204 MUST not attempt to parse, evaluate, or transform the local part in 205 any way if the UTF8SMTP SMTP extension is offered by the server. If 206 the UTF8SMTP SMTP extension is not offered by the Server, the SMTP 207 Client MUST NOT transmit an internationalized address and MUST NOT 208 transmit a mail body which contains internationalized mail headers 209 [EAI-utf8header]. Instead, it MUST either return the message to the 210 user as undeliverable or replace it with the alternate ASCII address. 211 If it is replaced, the replacement MUST be the ASCII-only address 212 specified with the ALT-ADDRESS parameter.[EAI-downgrading]. 214 2.3. Extended Mailbox Address Syntax 216 RFC 2821, section 4.1.2, defines the syntax of a mailbox as 218 Mailbox = Local-part "@" Domain 220 Local-part = Dot-string / Quoted-string 221 ; MAY be case-sensitive 223 Dot-string = Atom *("." Atom) 225 Atom = 1*atext 227 Quoted-string = DQUOTE *qcontent DQUOTE 229 Domain = (sub-domain 1*("." sub-domain)) / address-literal 230 sub-domain = Let-dig [Ldh-str] 232 The key changes made by this specification are, informally, to 234 o Change the definition of "sub-domain" to permit either the 235 definition above or a UTF-8 string representing a DNS label that 236 is conformant with IDNA [RFC3490]. That label MUST NOT contain 237 the characters "@" or ".", even though those characters can 238 normally be inserted into a DNS label. 239 o Change the definition of "Atom" to permit either the definition 240 above or a UTF-8 string. That string MUST NOT contain any of the 241 ASCII characters (either graphics or controls) that are not 242 permitted in "atext"; it is otherwise unrestricted. 244 According to the description above, define the syntax of an 245 internationalized email mailbox with ABNF [RFC4234] as 247 Mailbox = Local-part "@" Domain 249 Local-part = Dot-string / Quoted-string 250 ; MAY be case-sensitive 252 Dot-string = Atom *("." Atom) 254 Atom = 1*Ucharacter 255 Ucharacter = atext / UTF8-2 / UTF8-3 / UTF8-4 257 Quoted-string = DQUOTE *qcontent DQUOTE 259 Domain = (sub-domain 1*("." sub-domain)) / address-literal 260 sub-domain = ULet-dig [ULdh-str] 262 ULet-dig = Let-dig / Non-ASCII 264 ULdh-str = *( ALPHA / DIGIT / "-" / Non-ASCII) ULet-dig 266 Non-ASCII = UTF8-2 / UTF8-3 / UTF8-4 268 Where "atext", "qcontent" and "DQUOTE" are defined in [RFC2822], 269 "Let-dig", "Ldh-str" and "address-literal" are defined in [RFC2821] 270 and UTF8-2, UTF8-3 and UTF8-4 are defined in [RFC3629]. The value of 271 "domain" SHOULD be verified with [RFC3490]; If failed, the email 272 address with that domain can not be regarded as the valid email 273 address. 275 2.4. The ALT-ADDRESS parameter 277 If the UTF8SMTP extension is offered, the syntax of the SMTP MAIL and 278 RCPT commands is extended to support the optional "ALT-ADDRESS" 279 parameter. 281 The "ALT-ADDRESS" requires an all-ASCII address. 283 The ALT-ADDRESS parameter usage in the commands of "mail from" and 284 "rcpt to" is defined according to the definition of mail-parameters 285 in [RFC2821] below. 287 MAIL FROM: [ SP ] 288 RCPT TO: [ SP ] 289 Mail-parameters = esmtp-param *(SP esmtp-param) 290 Rcpt-parameters = esmtp-param *(SP esmtp-param) 291 esmtp-param = esmtp-keyword ["=" esmtp-value] 292 esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") 293 esmtp-value = 1*(%d33-60 / %d62-127) 294 ; any CHAR excluding "=", SP, and control characters 295 Reverse-path = Path 296 Forward-path = Path 297 Path = "<" [ A-d-l ":" ] Mailbox ">" 298 A-d-l = At-domain *( "," A-d-l ) 299 ; Note that this form, the so-called "source route", 300 ; MUST BE accepted, SHOULD NOT be generated, and SHOULD be 301 ; ignored. 302 At-domain = "@" domain 304 where the value of esmtp-keyword is "ALT-ADDRESS" and the value of 305 esmtp-value is all-ASCII email address, and where the domain and 306 Mailbox are defined at section 2.3 of this document. 308 The use of the ALT-ADDRESS is specified below: If some involved SMTP 309 servers can not support UTF8SMTP capability and if the sender has 310 already set the ALT-ADDRESS value, the client SMTP server will use 311 this address as the email address when the SMTP server does the 312 subsequent operations. If the ALT-ADDRESS value is not set by the 313 sender, the email must be bounced to the original sender. If the 314 email is bounced due to the incapability of supporting UTF8SMTP, the 315 relative server should issue the response error code "5.3.3" defined 316 in [RFC3463] which means that System is not capable of selected 317 features, permanent failure. 319 2.5. The Suggestion of the Value of the ALT-ADDRESS parameter 321 The "ALT-ADDRESS" requires an all-ASCII address. There are two 322 alternative ways to set ALT-ADDRESS value: one is set by the sender 323 using the all-ASCII address, the other is set using the transformed 324 email address. 326 Some may prefer transformed the non-ASCII address to the ASCII 327 Compatible Encoding(ACE) address as the value of the ALT-ADDRESS. 328 The big problem with applying an ACE to all local-parts is that the 329 sending or converting system doesn't know if there are some specific 330 data or instructions embedded in the address that the ACE process 331 would hide. Some SMTP servers may depend on these specific data or 332 instructions to do some operations while the local parts applied with 333 ACE will lose or hide these data or instructions. SMTP [RFC2821] 334 prohibits SMTP relays from converting local parts because the level 335 of SMTP relays' knowledge on the structure of local parts is assumed 336 to be zero. However, we can raise the knowledge level by supplying 337 additional information. Many human users' email addresses do not 338 have any embedded structure processed by the final delivery MTA. In 339 that case, the sender can specify that these email addresses are safe 340 to be converted in the predefined way. The final delivery SMTP 341 server can revert the addresses even though they are as in all ASCII 342 form. Unless the MUA or the submission server clearly knows that the 343 non-ASCII address can be safely transformed into the all-ASCII 344 address, the non-ASCII address should not be transformed because 345 transformed email address may cause some potential problems. 347 This document suggests that the ALT-ADDRESS is set directly by the 348 sender; In default, the all-ASCII address should not be gotten from 349 the transformation of the non-ASCII address. 351 2.6. Body Parts and SMTP Extensions 353 While this specification requires that servers support the 8BITMIME 354 extension [RFC1652] to ensure that servers have adequate handling 355 capability for 8-bit data and to avoid a number of complex encoding 356 problems, the use of internationalized addresses obviously does not 357 require non-ASCII body parts in the MIME message. The UTF8SMTP 358 extension MAY be used with the BODY=8BITMIME parameter if that is 359 appropriate given the body content or, if the server advertises it 360 and it is appropriate, with the BODY=BINARYMIME parameter specified 361 in [RFC3030]. 363 Assuming that the server advertises UTF8SMTP and 8BITMIME, and at 364 least one non-ASCII address, with or without ALT-ADDRESS, the precise 365 interpretation of these parameters on the MAIL command is: 366 1. Headers are in UTF-8, body parts are in ASCII. 367 2. Headers are in UTF-8, some or all body parts contain 8-bit line- 368 oriented data. 369 3. Headers are in UTF-8, some or all body parts contain binary data 370 without restriction as to line lengths or delimiters. 372 2.7. Additional ESMTP Changes and Clarifications 374 The mail transport process involves addresses ("mailboxes") and 375 domain names in contexts in addition to the MAIL and RCPT commands 376 and extended alternatives to them. In general, the rule is that, 377 when RFC 2821 specifies a mailbox, this document expects UTF-8 to be 378 used for the entire string; when RFC 2821 specifies a domain name, 379 the name SHOULD be in punycode form if its raw form is non-ASCII. 381 The following subsections list and discuss all of the relevant cases. 383 Support and use of this extension requires support for 8BITMIME. It 384 means that 8BITMIME MUST be advertised by the UTF8SMTP capability 385 SMTP server. 387 2.7.1. The Initial SMTP Exchange 389 When an SMTP or ESMTP connection is opened, the server sends a 390 "banner" response consisting of the 220 reply code and some 391 information. The client then sends the EHLO command. Since the 392 client cannot know whether the server supports UTF8SMTP until after 393 it receives the response from EHLO, any domain names that appear in 394 this dialogue, or in responses to EHLO, MUST be in hostname form, 395 i.e., internationalized ones MUST be in punycode form. 397 2.7.2. Trace Fields 399 Internationalized domain names in Received fields MUST be transmitted 400 in the punycode form. Addresses in "for" clauses need further 401 examination and might be treated differently depending on 402 [EAI-utf8header]. The reasoning in the introductory portion of 403 [EAI-overview] strongly suggests that these addresses be in UTF-8 404 form, rather than some specialized encoding. 406 2.7.3. Mailing List Question 408 How a mixture of traditional and internationalized addresses on a 409 mailing list will impact message flows, error reports, and delivery 410 notifications in all plausible combinations of UTF8SMTP capability 411 and un-capability servers is discussed and specified in the 412 [EAI-mailing list]. 414 2.7.4. Message Header Label 416 The message header label MAY be used to identify and distinguish the 417 i18mail message from the normal message when SMTP messages are 418 transmitted on wire. This issue is discussed and specified in 419 [EAI-utf8header]. 421 2.7.5. POP and IMAP 423 While SMTP mainly takes care of the transportation of messages and 424 the header fields on wire, POP essentially handles the retrieval of 425 mail objects from the server by a client. In order to use 426 internationalized user names based on i18mail for the retrieval of 427 messages from a mail server using the POP protocol, a new capability 428 SHOULD be introduced following the POP3 extension mechanism 429 [RFC2449]. This is discussed and specified in the [EAI-pop]. 431 IMAP [RFC3501] uses the traditional user name which is based on 432 ASCII. IMAP SHOULD be updated to support the internationalized user 433 names based on i18mail for the retrieval of messages from a mail 434 server. This is discussed and specified in the [EAI-imap]. 436 2.7.6. SMTP Service Extension for DSNs 438 How to facilitate the use of SMTP Service Extension for DSNs 439 [RFC3461] in the work of EAI will be addressed in the [EAI-dsn]. 441 3. Potential problems 443 3.1. Impact to IRI 445 The mailto: schema in IRI [RFC3987] MAY need to be modified when EAI 446 is standardized. 448 3.2. Impact to RFC 2476 and many email related RFC 450 The EAI protocols will impact on many email related RFC documents 451 such as Message Submission [RFC2476]. These protocols SHOULD be 452 considered when implementing the EAI protocol. 454 4. Implementation Advice 456 In the absence of this extension, SMTP clients and servers are 457 constrained to using only those addresses permitted by RFC 2821. The 458 local parts of those addresses MAY be made up of any ASCII 459 characters, although certain of them MUST be quoted as specified 460 there. It is notable in an internationalization context that there 461 is a long history on some systems of using overstruck ASCII 462 characters (a character, a backspace, and another character) within a 463 quoted string to approximate non-ASCII characters. This form of 464 internationalization SHOULD be phased out as this extension becomes 465 widely deployed but backward-compatibility considerations require 466 that it continue to be supported. 468 5. IANA Considerations 470 IANA is requested to add "UTF8SMTP" to the SMTP extensions registry 471 with the entry pointing to this specification for its definition. 473 6. Security considerations 475 See the extended security considerations discussion in [EAI-overview] 477 7. Acknowledgements 479 Much of the text in the initial version of this document was derived 480 or copied from [Klensin-emailaddr] with the permission of the author. 481 Significant comments and suggestions were received from Xiaodong LEE, 482 Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other members of the JET 483 team and were incorporated into the document. Special thanks to 484 those contributors for this version of document, those includes (but 485 not limited to) John C Klensin, Charles Lindsey, Dave Crocker, Harald 486 Tveit Alvestrand, Marcos Sanz, Chris Newman, Martin Duerst, Edmon 487 Chung, Tony Finch, Kari Hurtta. 489 8. Change History 491 [[anchor20: REMOVE THIS: This section is used for tracking the update 492 of this document. It may be useful to retain parts of it to 493 facilitate establishing dates and documents for the history of this 494 work.]] 496 8.1. draft-ietf-eai-smtpext: Version 00 498 This version supercedes draft-yao-ima-smtpext-03.txt. It refines the 499 ABNF definiton of the internationalized email address. It represents 500 as the EAI working group document. 502 8.2. draft-ietf-eai-smtpext: Version 01 504 o Upgraded to reflect discussions during IETF 66. 505 o Remove the atomic parameter. 506 o Add the new section of "the Suggestion of the value of the ALT- 507 ADDRESS parameter". 509 8.3. draft-ietf-eai-smtpext: Version 02 511 o Upgraded to reflect the recent discussion of the ima@ietf.org 512 mailing list. 513 o Add the section of "Body Parts and SMTP Extensions". 514 o Add the new section of "Change History". 515 o Add the subsection about SMTP extensions for DSN. 517 9. References 518 9.1. Normative References 520 [ASCII] American National Standards Institute (formerly United 521 States of America Standards Institute), "USA Code for 522 Information Interchange", ANSI X3.4-1968, 1968. 524 ANSI X3.4-1968 has been replaced by newer versions with 525 slight modifications, but the 1968 version remains 526 definitive for the Internet. 528 [EAI-downgrading] 529 YONEYA, Y., Ed. and K. Fujiwara, Ed., "Downgrading 530 mechanism for Internationalized eMail Address (IMA)", 531 draft-ietf-eai-downgrade-02 (work in progress), 532 August 2006. 534 [EAI-dsn] Newman, C., "SMTP extensions for DSNs", 12 2006, . 537 [EAI-imap] 538 Resnick, P. and C. Newman, "Considerations for IMAP in 539 Conjunction with Email Address Internationalization", 540 draft-ietf-eai-imap-utf8-00 (work in progress), May 2006. 542 [EAI-mailing list] 543 Chung, E., "Mailing Lists and Internationalized Email 544 Addresses", June 2006. 546 Forthcoming 548 [EAI-overview] 549 Klensin, J. and Y. Ko, "Overview and Framework for 550 Internationalized Email", draft-ietf-eai-framework-02.txt 551 (work in progress), October 2006. 553 [EAI-pop] Newman, C., "POP3 Support for UTF-8", June 2006, . 556 [EAI-utf8header] 557 Yeh, J., "Transmission of Email Headers in UTF-8 558 Encoding", draft-ietf-eai-utf8headers-01.txt (work in 559 progress), August 2006. 561 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 562 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 563 RFC 1652, July 1994. 565 [RFC1869] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 567 Crocker, "SMTP Service Extensions", STD 10, RFC 1869, 568 November 1995. 570 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 571 Requirement Levels", BCP 14, RFC 2119, March 1997. 573 [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension 574 Mechanism", RFC 2449, November 1998. 576 [RFC2476] Gellens, R. and J. Klensin, "Message Submission", 577 RFC 2476, December 1998. 579 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 580 April 2001. 582 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 583 April 2001. 585 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 586 of Large and Binary MIME Messages", RFC 3030, 587 December 2000. 589 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 590 Internationalized Strings ("stringprep")", RFC 3454, 591 December 2002. 593 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 594 Extension for Delivery Status Notifications (DSNs)", 595 RFC 3461, January 2003. 597 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 598 RFC 3463, January 2003. 600 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 601 "Internationalizing Domain Names in Applications (IDNA)", 602 RFC 3490, March 2003. 604 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 605 for Internationalized Domain Names in Applications 606 (IDNA)", RFC 3492, March 2003. 608 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 609 4rev1", RFC 3501, March 2003. 611 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 612 10646", RFC 3629, November 2003. 614 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 615 Identifiers (IRIs)", RFC 3987, January 2005. 617 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 618 Specifications: ABNF", RFC 4234, October 2005. 620 9.2. Informative References 622 [Klensin-emailaddr] 623 Klensin, J., "Internationalization of Email Addresses", 624 draft-klensin-emailaddr-i18n-03 (work in progress), 625 July 2005. 627 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 628 Extensions (MIME) Part One: Format of Internet Message 629 Bodies", RFC 2045, November 1996. 631 Authors' Addresses 633 Jiankang YAO (editor) 634 CNNIC 635 No.4 South 4th Street, Zhongguancun 636 Beijing 638 Phone: +86 10 58813007 639 Email: yaojk@cnnic.cn 641 Wei MAO (editor) 642 CNNIC 643 No.4 South 4th Street, Zhongguancun 644 Beijing 646 Phone: +86 10 58813055 647 Email: mao@cnnic.cn 649 Full Copyright Statement 651 Copyright (C) The Internet Society (2006). 653 This document is subject to the rights, licenses and restrictions 654 contained in BCP 78, and except as set forth therein, the authors 655 retain all their rights. 657 This document and the information contained herein are provided on an 658 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 659 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 660 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 661 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 662 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 663 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 665 Intellectual Property 667 The IETF takes no position regarding the validity or scope of any 668 Intellectual Property Rights or other rights that might be claimed to 669 pertain to the implementation or use of the technology described in 670 this document or the extent to which any license under such rights 671 might or might not be available; nor does it represent that it has 672 made any independent effort to identify any such rights. Information 673 on the procedures with respect to rights in RFC documents can be 674 found in BCP 78 and BCP 79. 676 Copies of IPR disclosures made to the IETF Secretariat and any 677 assurances of licenses to be made available, or the result of an 678 attempt made to obtain a general license or permission for the use of 679 such proprietary rights by implementers or users of this 680 specification can be obtained from the IETF on-line IPR repository at 681 http://www.ietf.org/ipr. 683 The IETF invites any interested party to bring to its attention any 684 copyrights, patents or patent applications, or other proprietary 685 rights that may cover technology that may be required to implement 686 this standard. Please address the information to the IETF at 687 ietf-ipr@ietf.org. 689 Acknowledgment 691 Funding for the RFC Editor function is provided by the IETF 692 Administrative Support Activity (IASA).