idnits 2.17.1 draft-ietf-eai-smtpext-05.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, updated by RFC 4748 on line 796. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 807. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 814. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 820. 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 Copyright Line does not match the current year == Line 448 has weird spacing: '...rn-path forw...' == 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 UTF-8 header [EAI-utf8header]. It MAY transmit the domain part of that string in either the form of ACE labels specified in [RFC3490] or UTF-8 form. If it sends the domain in UTF-8 form, the Submission SMTP client that first injects the message into the Internet SHOULD first verify that the string is valid for a domain name according to IDNA rules. The presence of the UTF8SMTP extension does not change the requirement of RFC 2821 that servers MUST not attempt to parse, evaluate, or transform the local part in any way. We say that an ASCII address is "available" for a forwarding path or return path if the address is all-ASCII or an ALT-ADDRESS parameter is specified for the path. 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 message which contains internationalized mail headers [EAI-utf8header] at any level within it MIME structure. Instead, an SMTP client other than the Submission MTA MUST make one of the following three choices: 1. Reject or return the message as undeliverable. 2. Find an alternate route to the destination that permits UTF8SMTP. 3. If and only if an ASCII address is available for the return path and one or more of the specific forwarding paths being attempted, downgrade the message to an all-ASCII form as specified in [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 (April 9, 2007) is 6227 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFCxxxx' is mentioned on line 565, but not defined == Unused Reference: 'ASCII' is defined on line 649, but no explicit reference was found in the text == Unused Reference: 'RFC2449' is defined on line 673, but no explicit reference was found in the text == Unused Reference: 'RFC3454' is defined on line 682, but no explicit reference was found in the text == Unused Reference: 'RFC3492' is defined on line 697, but no explicit reference was found in the text == Unused Reference: 'RFC3987' is defined on line 704, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 745, but no explicit reference was found in the text == Unused Reference: 'RFC3501' is defined on line 753, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-eai-utf8headers-05 ** Obsolete normative reference: RFC 1652 (Obsoleted by RFC 6152) ** Obsolete normative reference: RFC 1869 (Obsoleted by RFC 2821) ** 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 4234 (Obsoleted by RFC 5234) == Outdated reference: A later version (-12) exists of draft-ietf-eai-downgrade-02 == Outdated reference: A later version (-06) exists of draft-ietf-eai-dsn-00 == Outdated reference: A later version (-09) exists of draft-ietf-eai-imap-utf8-01 == Outdated reference: A later version (-09) exists of draft-ietf-eai-pop-01 -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 4409 (Obsoleted by RFC 6409) Summary: 8 errors (**), 0 flaws (~~), 17 warnings (==), 9 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: Experimental CNNIC 5 Expires: October 11, 2007 April 9, 2007 7 SMTP extension for internationalized email address 8 draft-ietf-eai-smtpext-05.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 October 11, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document specifies the use of SMTP extension for 42 internationalized email address delivery. Communication with systems 43 that do not implement this specification is specified in another 44 document. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1. Role of this specification . . . . . . . . . . . . . . . . 3 50 1.2. Proposal Context . . . . . . . . . . . . . . . . . . . . . 3 51 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Mail Transport-level Protocol . . . . . . . . . . . . . . . . 4 53 2.1. Framework for the Internationalization Extension . . . . . 4 54 2.2. The UTF8SMTP Extension . . . . . . . . . . . . . . . . . . 5 55 2.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 6 56 2.4. The ALT-ADDRESS parameter . . . . . . . . . . . . . . . . 8 57 2.5. Using the ALT-ADDRESS parameter . . . . . . . . . . . . . 8 58 2.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 9 59 2.7. Additional ESMTP Changes and Clarifications . . . . . . . 9 60 2.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 10 61 2.7.2. Message Retry . . . . . . . . . . . . . . . . . . . . 10 62 2.7.3. Trace Information . . . . . . . . . . . . . . . . . . 11 63 3. Issues with Other Parts of the Email System . . . . . . . . . 12 64 3.1. LMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 3.2. SMTP Service Extension for DSNs . . . . . . . . . . . . . 12 66 3.3. POP and IMAP . . . . . . . . . . . . . . . . . . . . . . . 12 67 4. Potential problems . . . . . . . . . . . . . . . . . . . . . . 12 68 4.1. Impact many email related RFC . . . . . . . . . . . . . . 12 69 5. Implementation Advice . . . . . . . . . . . . . . . . . . . . 13 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 7. Security considerations . . . . . . . . . . . . . . . . . . . 13 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 73 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 14 74 9.1. draft-ietf-eai-smtpext: Version 00 . . . . . . . . . . . . 14 75 9.2. draft-ietf-eai-smtpext: Version 01 . . . . . . . . . . . . 14 76 9.3. draft-ietf-eai-smtpext: Version 02 . . . . . . . . . . . . 14 77 9.4. draft-ietf-eai-smtpext: Version 03 . . . . . . . . . . . . 14 78 9.5. draft-ietf-eai-smtpext: Version 04 . . . . . . . . . . . . 15 79 9.6. draft-ietf-eai-smtpext: Version 05 . . . . . . . . . . . . 15 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 84 Intellectual Property and Copyright Statements . . . . . . . . . . 19 86 1. Introduction 88 Internationalized email address includes two parts, the local part 89 and the domain part. The ways email addresses are used by protocols 90 are different from the ways domain names are used. The most critical 91 difference is that emails are delivered through a chain of peering 92 clients and servers while domain names are resolved by name servers 93 by looking up their own tables. In addition to this, email transport 94 protocol ESMTP[RFC1869] provide a negotiation mechanism through which 95 clients can make decisions for further processing; please see more in 96 [EAI-framework]. Email addresses can exploit the SMTP extension 97 negotiation mechanism while Internationalized Domain Name(IDN) does 98 not have such a facility. This is also more desirable 99 architecturally. This document specifies an SMTP extension to permit 100 internationalized email addresses in envelopes, and UTF-8 in headers. 101 The protocol described here is an MTA solution which is feasible, 102 architecturally elegant, and not difficult to deploy. 104 1.1. Role of this specification 106 An framework document [EAI-framework] specifies the requirements for, 107 and components of, full internationalization of electronic mail. To 108 understand and implement this specification, understanding the 109 context presented in [EAI-framework] is necessary. 111 This document specifies an element of that work, specifically the 112 definition of an SMTP extension [RFC1869] for the internationalized 113 email address transport delivery. 115 1.2. Proposal Context 117 This specification describes a change to the email transport 118 mechanism that permits non-ASCII characters in both the envelope and 119 header fields of messages while the specification in [EAI-utf8header] 120 specifies the details of how and where non-ASCII characters are 121 permitted in the header fields of messages. The context for the 122 change is described in [EAI-framework]. 124 1.3. Terminology 126 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 127 and "MAY" in this document are to be interpreted as described in RFC 128 2119 [RFC2119]. 130 All specialized terms used in this specification are defined in the 131 EAI framework [EAI-framework] or in [RFC2821] and [RFC2822]. The 132 terms "ASCII address", "internationalized email address", "non-ASCII 133 address", "i18mail address", "UTF8SMTP", "message" and "mailing list" 134 are used with the definitions from the [EAI-framework] document. 136 This document defines only those ABNF [RFC4234] syntax rules that are 137 different from those of the base email specifications 138 [RFC2821][RFC2822] and, where the earlier rules are upgraded or 139 extended, gives them new names. When the new rule is a small upgrade 140 to the older one, it is typically given a name starting with "u". 141 Rules that are undefined here may be found in the base email 142 documents under the same names. 144 [[anchor4: RFC EDITOR'S NOTE: The following text should be deleted 145 before publication.]] This document is being discussed on the EAI 146 mailing list. See https://www1.ietf.org/mailman/listinfo/ima for 147 information about subscribing. The list's archive is at 148 http://www1.ietf.org/mail-archive/web/ima/index.html. 150 2. Mail Transport-level Protocol 152 2.1. Framework for the Internationalization Extension 154 The following service extension is defined: 156 1. The name of the SMTP service extension is "Email Address 157 Internationalization"; 158 2. The EHLO keyword value associated with this extension is 159 "UTF8SMTP"; 160 3. No parameter values are defined for this EHLO keyword value. In 161 order to permit future (although unanticipated) extensions, the 162 EHLO response MUST NOT contain any parameters for that keyword. 163 Clients MUST ignore any parameters, that is, clients MUST behave 164 as if the parameters do not appear. If a server includes 165 UTF8SMTP in its EHLO response, it MUST be fully compliant with 166 this version of this specification. 167 4. One optional parameter, ALT-ADDRESS, is added to the SMTP MAIL 168 and RCPT commands. ALT-ADDRESS specifies an all-ASCII address 169 which can be used as a substitute for the i18mail addresses that 170 we call the primary address; you can learn more in 171 [EAI-framework] or [EAI-downgrading]. 172 5. No additional SMTP verbs are defined by this extension. 173 6. Servers offering this extension MUST provide support for, and 174 announce, the 8BITMIME extension [RFC1652]. 175 7. The reverse-path and forward-path of SMTP MAIL and RCPT commands 176 are extended to allow UTF-8 characters in the specified mailbox 177 address. 178 8. The mail data is extended on compliance with [EAI-utf8header] 179 9. The maximum length of a MAIL FROM and RCPT TO command lines is 180 increased by 396 characters by the possible addition of the ALT- 181 ADDRESS keyword and value. 183 2.2. The UTF8SMTP Extension 185 An SMTP Server that announces this extension MUST be prepared to 186 accept a UTF-8 string [RFC3629] in any position in which RFC 2821 187 specifies that a "mailbox" MAY appear. That string MUST be parsed 188 only as specified in RFC 2821, i.e., by separating the mailbox into 189 source route, local part and domain part, using only the characters 190 colon (U+003A), comma (U+002C), and at-sign (U+0040) as specified 191 there. Once isolated by this parsing process, the local part MUST be 192 treated as opaque unless the SMTP Server is the final delivery MTA. 193 Any domain names that are to be looked up in the DNS MUST first be 194 processed into the form specified in IDNA [RFC3490] by means of the 195 ToASCII() operation unless they are already in that form. Any domain 196 names that are to be compared to local strings SHOULD be checked for 197 validity and then MUST be compared as specified in section 3.4 of 198 IDNA. 200 The UTF8SMTP extension is valid on the submission port [RFC4409]. 202 An SMTP Client that receives the UTF8SMTP extension keyword in 203 response to the "EHLO" command MAY transmit a mailbox name as an 204 internationalized string in UTF-8 form and MAY send an UTF-8 header 205 [EAI-utf8header]. It MAY transmit the domain part of that string in 206 either the form of ACE labels specified in [RFC3490] or UTF-8 form. 207 If it sends the domain in UTF-8 form, the Submission SMTP client that 208 first injects the message into the Internet SHOULD first verify that 209 the string is valid for a domain name according to IDNA rules. The 210 presence of the UTF8SMTP extension does not change the requirement of 211 RFC 2821 that servers MUST not attempt to parse, evaluate, or 212 transform the local part in any way. We say that an ASCII address is 213 "available" for a forwarding path or return path if the address is 214 all-ASCII or an ALT-ADDRESS parameter is specified for the path. If 215 the UTF8SMTP SMTP extension is not offered by the Server, the SMTP 216 client MUST NOT transmit an internationalized address and MUST NOT 217 transmit a mail message which contains internationalized mail headers 218 [EAI-utf8header] at any level within it MIME structure. Instead, an 219 SMTP client other than the Submission MTA MUST make one of the 220 following three choices: 221 1. Reject or return the message as undeliverable. 222 2. Find an alternate route to the destination that permits UTF8SMTP. 223 3. If and only if an ASCII address is available for the return path 224 and one or more of the specific forwarding paths being attempted, 225 downgrade the message to an all-ASCII form as specified in 226 [EAI-downgrading]. 228 To be able to deliver internationalized email through SMTP servers, 229 we need to upgrade SMTP server to be able to carry the 230 internationalized email address. Submission servers [RFC4409] are 231 permitted to perform a broader range of changes to allow the 232 internationalized email address. The older SMTP servers, the mail- 233 reading clients and other systems that are downstream from them might 234 not be prepared to handle these extended addresses. If a SMTP server 235 does not support the UTF8SMTP extension, then the SMTP client MUST 236 NOT, under any circumstances, attempt to send UTF8SMTP message to 237 this server or attempt to use UTF-8 characters of the MAIL FROM or 238 RCPT TO commands. 240 2.3. Extended Mailbox Address Syntax 242 RFC 2821, section 4.1.2, defines the syntax of a mailbox entirely in 243 terms of ASCII characters, using the production for "Mailbox" and 244 those on which it depends. 246 The key changes made by this specification are, informally, to 248 o Change the definition of "sub-domain" to permit either the 249 definition above or a UTF-8 string representing a DNS label that 250 is conformant with IDNA [RFC3490]. 251 o Change the definition of "Atom" to permit either the definition 252 above or a UTF-8 string. That string MUST NOT contain any of the 253 ASCII characters (either graphics or controls) that are not 254 permitted in "atext"; it is otherwise unrestricted. 256 According to the description above, define the syntax of an 257 internationalized email mailbox with ABNF [RFC4234] as 258 uMailbox = uLocal-part "@" uDomain 259 ; Replace Mailbox in RFC 2821, section 4.1.2 261 uLocal-part = uDot-string / uQuoted-string 262 ; MAY be case-sensitive 263 ; Replace Local-part in RFC 2821, section 4.1.2 265 uDot-string = uAtom *("." uAtom) 266 ; Replace Dot-string in RFC 2821, section 4.1.2 268 uAtom = 1*ucharacter 269 ; Replace Atom in RFC 2821, section 4.1.2 271 ucharacter = atext / UTF8-xtra-char 272 ; Replace character in RFC 2821, section 4.1.2 273 ; atext is defined in RFC 2822 275 uQuoted-string = DQUOTE *uqcontent DQUOTE 276 ; Replace Quoted-string in RFC 2821, section 4.1.2 277 ; DQUOTE is Double Quote defined in RFC 4234 279 uqcontent = qcontent / UTF8-xtra-char 280 ; qcontent is defined in RFC 2822, section 3.2.5 282 uDomain = (sub-udomain 1*("." sub-udomain)) / address-literal 283 ; Replace Domain in RFC 2821, section 4.1.2 284 ; address-literal is defined in RFC2821 section 4.1.2 286 sub-udomain = uLet-dig [uLdh-str] 287 ; Replace sub-domain in RFC 2821, section 4.1.2 289 uLet-dig = Let-dig / UTF8-xtra-char 290 ; Let-dig is defined in RFC 2821, section 4.1.3 292 uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-xtra-char) uLet-dig 293 ; Replace Ldh-str in RFC 2821, section 4.1.3 295 UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 296 ; UTF8-2, UTF8-3 and UTF8-4 are defined in RFC 3629 298 The value of "udomain" SHOULD be verified with IDNA [RFC3490]; If 299 failed, the email address with that udomain can not be regarded as 300 the valid email address. 302 2.4. The ALT-ADDRESS parameter 304 If the UTF8SMTP extension is offered, the syntax of the SMTP MAIL and 305 RCPT commands is extended to support the optional esmtp-keyword "ALT- 306 ADDRESS", which specifies an alternate all-ASCII address which may be 307 used when downgrading. If the ALT-ADDRESS esmtp-keyword is used, it 308 MUST have an associated esmtp-value (ALT-ADDRESS-esmtp-value which is 309 defined below). 311 Based on the definition of mail-parameters in [RFC2821], the ALT- 312 ADDRESS parameter usage in the commands of "mail from" and "rcpt to" 313 is defined below. 315 "MAIL FROM:" SP [ SP ] 316 ; Update mail command in RFC 2821, section 3.3 317 ; The syntax for "esmtp-value" in RFC2821 318 ; does not allow "=", SP and control characters. 319 ; Therefore ALT-ADDRESS-paramater is extended. 321 "RCPT TO:" SP [ SP ] 322 ; Update rcpt command in RFC 2821, section 3.3 324 uReverse-path = uPath 325 ; Replace Reverse-path in RFC 2821, section 4.1.2 327 uForward-path = uPath 328 ; Replace Forward-path in RFC 2821, section 4.1.2 330 uPath = "<" [ A-d-l ":" ] uMailbox ">" 331 ; Replace Path in RFC 2821, section 4.1.2 332 ; A-d-l is defined in RFC 2821, section 4.1.2 333 ; uMailbox is defined in section 2.3 of this document 335 ALT-ADDRESS-parameter="ALT-ADDRESS=" ALT-ADDRESS-esmtp-value 337 ALT-ADDRESS-esmtp-value=xtext 338 ; xtext is defined in RFC 3461, section 4.2 340 The ALT-ADDRESS-parameter MUST NOT appear more than once in any MAIL 341 or RCPT command. ALT-ADDRESS-esmtp-value MUST be an all-ASCII email 342 address before xtext encoding. 344 2.5. Using the ALT-ADDRESS parameter 346 A message containing non-ASCII envelope addresses or header fields 347 MUST NOT be sent to an SMTP server which does not support UTF8SMTP. 348 Such a message MAY be rejected due to lack of the ALT-ADDRESS as 349 discussed in section 2.2 of this document. 351 When messages are rejected because they require UTF8SMTP, response 352 code "550" is used, defined in [RFC2821], meaning "mailbox 353 unavailable". If enhanced mail system status codes [RFC3463] is 354 used, the response code should be "5.6.x" [SMTP-codes], meaning that 355 "alt-address is required but not specified". 357 [[anchor8: REMOVE THIS: IANA please assign the proper error codes for 358 "5.6.x".]] 360 2.6. Body Parts and SMTP Extensions 362 Since there is no ESMTP parameter which tells whether the message is 363 UTF8SMTP message, SMTP server needs to parse all message header 364 fields and MIME header fields in the message body to discover which 365 messages are UTF8SMTP. While this specification requires that 366 servers support the 8BITMIME extension [RFC1652] to ensure that 367 servers have adequate handling capability for 8-bit data and to avoid 368 a number of complex encoding problems, the use of internationalized 369 addresses obviously does not require non-ASCII body parts in the MIME 370 message. The UTF8SMTP extension MAY be used with the BODY=8BITMIME 371 parameter if that is appropriate given the body content or, if the 372 server advertises it and it is appropriate, with the BODY=BINARYMIME 373 parameter specified in [RFC3030]. This document does not modify the 374 intent of BODY=BINARYMIME that text body parts and headers must still 375 be handled in a line-oriented way. 377 Assuming that the server advertises UTF8SMTP and 8BITMIME, and at 378 least one non-ASCII address, with or without ALT-ADDRESS, the precise 379 interpretation of these parameters of "No 'Body' parameter", "BODY= 380 8BITMIME", and "BODY= BINARYMIME" of the MAIL command is: 381 1. For No "Body" parameter, headers are in UTF-8, body parts are in 382 ASCII. 383 2. For BODY=8BITMIME parameter, headers are in UTF-8, some or all 384 body parts contain 8-bit line-oriented data. 385 3. For BODY=BINARYMIME parameter, headers are in UTF-8, some or all 386 body parts contain binary data without restriction as to line 387 lengths or delimiters. 389 2.7. Additional ESMTP Changes and Clarifications 391 The mail transport process involves addresses ("mailboxes") and 392 domain names in contexts in addition to the MAIL and RCPT commands 393 and extended alternatives to them. In general, the rule is that, 394 when RFC 2821 specifies a mailbox, this document expects UTF-8 to be 395 used for the entire string; when RFC 2821 specifies a domain name, 396 the name SHOULD be in the form of ACE labels if its raw form is non- 397 ASCII. 399 The following subsections list and discuss all of the relevant cases. 401 Support and use of this extension requires support for 8BITMIME. It 402 means that 8BITMIME MUST be advertised by the UTF8SMTP capability 403 SMTP server. 405 2.7.1. The Initial SMTP Exchange 407 When an SMTP or ESMTP connection is opened, the server normally sends 408 a "greeting" response consisting of the '220' reply code and some 409 information. The client then sends the EHLO command. Since the 410 client cannot know whether the server supports UTF8SMTP until after 411 it receives the response from EHLO, any domain names that appear in 412 this dialogue, or in responses to EHLO, MUST be in the hostname form, 413 i.e., internationalized ones MUST be in the form of ACE labels. 415 2.7.2. Message Retry 417 An MSA or MTA may encounter a server that doesn't support UTF8SMTP 418 while relaying a message that requires such support. The selection 419 of submission servers is presumably under the control of the sender's 420 client, while the selection of potential intermediate relays is under 421 the control of the administration of the final delivery server. 422 Hence, there is a presumption, at least when the recipient address is 423 non-ASCII, that the delivery path servers normally support UTF8SMTP 424 (if the sender's client or MSA didn't support UTF8SMTP, the message 425 would not have been accepted for delivery in the first place). Thus, 426 a lack of UTF8SMTP support is likely to be a temporary situation. It 427 is suggested that an alternate MX be tried, and/or the message is 428 requeued for a later attempt, rather than immediately downgrading or 429 rejecting. If the message is requeued, the total elapsed time before 430 rejecting or downgrading SHOULD be smaller than the value used for 431 other SMTP error conditions such as host unreachable or persistent 432 '4xx' response codes. 434 An example of such an algorithm: 436 If a message requires UTF8SMTP but the contacted server doesn't 437 support it, treat this as a temporary failure if the message has been 438 queued for less than 24 hours, unless the return-path is non-ASCII 439 and the forward path is all-ASCII. Normal temporary failure action 440 is taken, such as, additional address records of the current MX 441 record are attempted, then additional MX records are attempted, then 442 the message is requeued with increasing back-off timers. 444 If message has been queued for less than 24 hours and the message 445 requires UTF8SMTP support but the contact server doesn't offer this, 446 the following diagram describes some situations: 448 return-path forward-path action 449 ----------- ------------ ------ 450 ASCII ASCII reject or downgrade 451 non-ASCII non-ASCII temp fail 452 ASCII non-ASCII temp fail 453 non-ASCII ASCII reject or downgrade 455 This alternate-MX-or-retry-later technique SHOULD NOT be used when 456 the message's return path is a non-ASCII address and the specific 457 forward path being attempted is an ASCII address (because the 458 implication that the delivery path normally supports UTF8SMTP does 459 not hold in this case). 461 2.7.3. Trace Information 463 When an SMTP server receives a message for delivery or further 464 processing, it MUST insert trace ("time stamp" or "Received") 465 information at the beginning of the message content. Time stamp 466 appears in the form of "Received: lines". The most important use of 467 Received: lines is for debugging mail faults. When the delivery SMTP 468 server makes the "final delivery" of a message, it inserts a return- 469 path line at the beginning of the mail data. The primary purpose of 470 the Return-path is to designate the address to which messages 471 indicating non-delivery or other mail system failures are to be sent. 472 For the trace information, we update the time stamp line and the 473 return path line [RFC2821] formally defined as follows: 475 uReturn-path-line = "Return-Path:" FWS uReverse-path 476 ; Replaces Return-path-line in the section 4.4 of [RFC2821] 477 ; uReverse-path is defined in Section 2.3 479 uTime-stamp-line = "Received:" FWS uStamp 480 ; Replaces Time-stamp-line in the section 4.4 of [RFC2821] 482 uStamp = From-domain By-domain uOpt-info ";" FWS date-time 483 ; Replaces Stamp in the section 4.4 of [RFC2821] 485 uOpt-info = [Via] [With] [ID] [uFor] 486 ; Replaces Opt-info in the section 4.4 of [RFC2821] 487 ; [With]'s protocl value will allow UTF8SMTP value 489 uFor = "FOR" FWS 1*( uPath / uMailbox ) CFWS 490 ; Replaces For in the section 4.4 of [RFC2821] 491 ; uPath is defined in section 2.4 of this document 493 ; uMailbox is defined in section 2.3 of this document 495 Except in the 'uFor' and 'uReverse-path' line where non-ASCII domain 496 name may be used, internationalized domain names in Received fields 497 MUST be transmitted in the form of ACE labels. The protocol value of 498 the WITH clause is UTF8SMTP when this extension is used. More 499 information is in the "IANA Considerations" section of this document, 500 below. 502 3. Issues with Other Parts of the Email System 504 3.1. LMTP 506 LMTP [RFC2033] may be used as the final delivery agent. In such 507 cases, LMTP may be arranged to deliver the mail to the mail store. 508 The mail store may not have UTF8SMTP capability. LMTP need to be 509 updated to deal with these situations. 511 3.2. SMTP Service Extension for DSNs 513 The existing draft standard Delivery status notifications 514 (DSNs)[RFC3461] is presently limited to US-ASCII text in the machine 515 readable portions of the protocol. "International Delivery and 516 Disposition Notifications" [EAI-dsn] adds a new address type for 517 international email addresses so an original recipient address with 518 non-US-ASCII characters can be correctly preserved even after 519 downgrading. If an SMTP server advertises both the UTF8SMTP and the 520 DSN extension, that server MUST implement EAI-dsn [EAI-dsn] including 521 support for the ORCPT parameter. 523 3.3. POP and IMAP 525 The [EAI-framework] has introduced two documents [EAI-pop] and 526 [EAI-imap] to how to use internationalized user names based on UTF-8 527 characters for the retrieval of messages from a mail server. 529 4. Potential problems 531 4.1. Impact many email related RFC 533 Internationalized email has implications for all processes and 534 protocols which examine, handle, generate, or otherwise deal with 535 mail. In particular, address parsing or validity checks, message 536 parsing or handling, etc. 538 5. Implementation Advice 540 In the absence of this extension, SMTP clients and servers are 541 constrained to using only those addresses permitted by RFC 2821. The 542 local parts of those addresses MAY be made up of any ASCII 543 characters, although some of them MUST be quoted as specified there. 544 It is notable in an internationalization context that there is a long 545 history on some systems of using overstruck ASCII characters (a 546 character, a backspace, and another character) within a quoted string 547 to approximate non-ASCII characters. This form of 548 internationalization SHOULD be phased out as this extension becomes 549 widely deployed but backward-compatibility considerations require 550 that it continue to be supported. 552 6. IANA Considerations 554 IANA is requested to add "UTF8SMTP" to the SMTP extensions registry 555 with the entry pointing to this specification for its definition. 557 IANA is requested to assign the proper error codes "5.6.x" for this 558 specification based on [SMTP-codes]. 560 The "Mail Transmission Types" registry is requested to be updated to 561 include the following new entries: 563 WITH protocol types Description Reference 564 ------------------- ---------------------------- --------- 565 UTF8SMTP UTF8SMTP with Service Extensions [RFCxxxx] 567 [[anchor20: REMOVE THIS: where RFCxxxx represents the future RFC N0. 568 of this document. When this document is published as RFC and 569 assigned with a RFC No., "xxxx" should be replaced with 4-digits 570 No..]] 572 7. Security considerations 574 See the extended security considerations discussion in 575 [EAI-framework] 577 8. Acknowledgements 579 Much of the text in the initial version of this document was derived 580 or copied from [Klensin-emailaddr] with the permission of the author. 582 Significant comments and suggestions were received from Xiaodong LEE, 583 Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other members of the JET 584 team and were incorporated into the document. Special thanks to 585 those contributors for this version of document, those includes (but 586 not limited to) John C Klensin, Charles Lindsey, Dave Crocker, Harald 587 Tveit Alvestrand, Marcos Sanz, Chris Newman, Martin Duerst, Edmon 588 Chung, Tony Finch, Kari Hurtta, Randall Gellens, Frank Ellermann. Of 589 course, none of the individuals are necessarily responsible for the 590 combination of ideas represented here. 592 9. Change History 594 [[anchor23: REMOVE THIS: This section is used for tracking the update 595 of this document. It may be useful to retain parts of it to 596 facilitate establishing dates and documents for the history of this 597 work.]] 599 9.1. draft-ietf-eai-smtpext: Version 00 601 This version supercedes draft-yao-ima-smtpext-03.txt. It refines the 602 ABNF definition of the internationalized email address. It 603 represents as the EAI working group document. 605 9.2. draft-ietf-eai-smtpext: Version 01 607 o Upgraded to reflect discussions during IETF 66. 608 o Remove the atomic parameter. 609 o Add the new section of "the Suggestion of the value of the ALT- 610 ADDRESS parameter". 612 9.3. draft-ietf-eai-smtpext: Version 02 614 o Upgraded to reflect the recent discussion of the ima@ietf.org 615 mailing list. 616 o Add the section of "Body Parts and SMTP Extensions". 617 o Add the new section of "Change History". 618 o Add the subsection about SMTP extensions for DSN. 620 9.4. draft-ietf-eai-smtpext: Version 03 622 o Update the syntax related to mailbox. 623 o Update the trace field section. 624 o Add the new section about message retry. 625 o Update the subsection about SMTP extensions for DSN. 627 9.5. draft-ietf-eai-smtpext: Version 04 629 o Refine some syntax. 630 o Delete "Message Header Label" section. 631 o Change "bounce" to "reject". 633 9.6. draft-ietf-eai-smtpext: Version 05 635 o Refine the abstract. 636 o Delete "The Suggestion of the Value of the ALT-ADDRESS parameter" 637 section. 638 o Move original section 2.7.4 and 2.7.5 to section 3 with the name 639 "Issues with other parts of the email system". 640 o Add the new section "LMTP". 641 o Refine some text according to suggestions from the EAI mailing 642 list discussion 643 o Remove the section "Mailing List Question" 645 10. References 647 10.1. Normative References 649 [ASCII] Cerf, V., "ASCII format for network interchange", RFC 20, 650 October 1969. 652 [EAI-framework] 653 Klensin, J. and Y. Ko, "Overview and Framework for 654 Internationalized Email", draft-ietf-eai-framework-05.txt 655 (work in progress), 2 2007. 657 [EAI-utf8header] 658 Yeh, J., "Transmission of Email Headers in UTF-8 659 Encoding", draft-ietf-eai-utf8headers-05.txt (work in 660 progress), April 2007. 662 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 663 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 664 RFC 1652, July 1994. 666 [RFC1869] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 667 Crocker, "SMTP Service Extensions", STD 10, RFC 1869, 668 November 1995. 670 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 671 Requirement Levels", BCP 14, RFC 2119, March 1997. 673 [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension 674 Mechanism", RFC 2449, November 1998. 676 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 677 April 2001. 679 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 680 April 2001. 682 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 683 Internationalized Strings ("stringprep")", RFC 3454, 684 December 2002. 686 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 687 Extension for Delivery Status Notifications (DSNs)", 688 RFC 3461, January 2003. 690 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 691 RFC 3463, January 2003. 693 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 694 "Internationalizing Domain Names in Applications (IDNA)", 695 RFC 3490, March 2003. 697 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 698 for Internationalized Domain Names in Applications 699 (IDNA)", RFC 3492, March 2003. 701 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 702 10646", RFC 3629, November 2003. 704 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 705 Identifiers (IRIs)", RFC 3987, January 2005. 707 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 708 Specifications: ABNF", RFC 4234, October 2005. 710 10.2. Informative References 712 [EAI-downgrading] 713 YONEYA, Y., Ed. and K. Fujiwara, Ed., "Downgrading 714 mechanism for Internationalized eMail Address (IMA)", 715 draft-ietf-eai-downgrade-02 (work in progress), 716 August 2006. 718 [EAI-dsn] Newman, C., "SMTP extensions for DSNs", 719 draft-ietf-eai-dsn-00.txt (work in progress), 1 2007. 721 [EAI-imap] 722 Resnick, P. and C. Newman, "Considerations for IMAP in 723 Conjunction with Email Address Internationalization", 724 draft-ietf-eai-imap-utf8-01 (work in progress), 725 March 2007. 727 [EAI-mailing list] 728 Gellens, R. and E. Chung, "Mailing Lists and 729 Internationalized Email Addresses", 730 draft-ietf-eai-mailinglist-01.txt (work in progress), 731 January 2007. 733 [EAI-pop] Newman, C., "POP3 Support for UTF-8", 734 draft-ietf-eai-pop-01.txt (work in progress), 735 January 2007. 737 [Klensin-emailaddr] 738 Klensin, J., "Internationalization of Email Addresses", 739 draft-klensin-emailaddr-i18n-03 (work in progress), 740 July 2005. 742 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 743 October 1996. 745 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 746 Extensions (MIME) Part One: Format of Internet Message 747 Bodies", RFC 2045, November 1996. 749 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 750 of Large and Binary MIME Messages", RFC 3030, 751 December 2000. 753 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 754 4rev1", RFC 3501, March 2003. 756 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 757 RFC 4409, April 2006. 759 [SMTP-codes] 760 KLensin, J., "An IANA Registry for Extended SMTP Status 761 Codes", draft-klensin-smtp-code-registry-00 (work in 762 progress), April 2007. 764 Authors' Addresses 766 Jiankang YAO (editor) 767 CNNIC 768 No.4 South 4th Street, Zhongguancun 769 Beijing 771 Phone: +86 10 58813007 772 Email: yaojk@cnnic.cn 774 Wei MAO (editor) 775 CNNIC 776 No.4 South 4th Street, Zhongguancun 777 Beijing 779 Phone: +86 10 58813055 780 Email: maowei_ietf@cnnic.cn 782 Full Copyright Statement 784 Copyright (C) The IETF Trust (2007). 786 This document is subject to the rights, licenses and restrictions 787 contained in BCP 78, and except as set forth therein, the authors 788 retain all their rights. 790 This document and the information contained herein are provided on an 791 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 792 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 793 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 794 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 795 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 796 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 798 Intellectual Property 800 The IETF takes no position regarding the validity or scope of any 801 Intellectual Property Rights or other rights that might be claimed to 802 pertain to the implementation or use of the technology described in 803 this document or the extent to which any license under such rights 804 might or might not be available; nor does it represent that it has 805 made any independent effort to identify any such rights. Information 806 on the procedures with respect to rights in RFC documents can be 807 found in BCP 78 and BCP 79. 809 Copies of IPR disclosures made to the IETF Secretariat and any 810 assurances of licenses to be made available, or the result of an 811 attempt made to obtain a general license or permission for the use of 812 such proprietary rights by implementers or users of this 813 specification can be obtained from the IETF on-line IPR repository at 814 http://www.ietf.org/ipr. 816 The IETF invites any interested party to bring to its attention any 817 copyrights, patents or patent applications, or other proprietary 818 rights that may cover technology that may be required to implement 819 this standard. Please address the information to the IETF at 820 ietf-ipr@ietf.org. 822 Acknowledgment 824 Funding for the RFC Editor function is provided by the IETF 825 Administrative Support Activity (IASA).