idnits 2.17.1 draft-ietf-eai-smtpext-06.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 858. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 869. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 876. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 882. 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 == 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. In the domain part of the mailbox string, if any of the labels are intended to be interpreted as non-ASCII (i.e., are IDNs), then the Message Submission Server ("MSA") [RFC4409] MUST take responsibility for ensuring that the labels are valid (whether they appear in native character or ACE form). The presence of the UTF8SMTP extension does not change the requirement of RFC 2821 that servers relaying mail MUST not attempt to parse, evaluate, or transform the local part in any way. == 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: If the VRFY and EXPN commands has the optional parameter "UTF8REPLY", it indicates the client can accept UTF-8 on replies of the VRFY and EXPN commands. Specially this allows to use UTF-8 on mailboxes and full names which occur on replies. The SMTP client following this specification MUST accept UTF-8 on replies of the VRFY and EXPN commands. However the SMTP server MUST not use UTF-8 on replies, if SMTP client does not ask UTF-8 replies. Some replies include the mailbox, but usually most of replies do not require that the mailbox is included in it and therefore UTF-8 is not needed. UTF8REPLY parameter on the VRFY and EXPN commands tells the SMTP server that the client is prepared for UTF-8 on SMTP replies. -- 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 (June 6, 2007) is 6140 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFCxxxx' is mentioned on line 627, but not defined == Unused Reference: 'ASCII' is defined on line 720, 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 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 4409 (Obsoleted by RFC 6409) Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 8 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: December 8, 2007 June 6, 2007 7 SMTP extension for internationalized email address 8 draft-ietf-eai-smtpext-06.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 December 8, 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 . . . . . . . . . . . . . 9 58 2.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 9 59 2.7. Additional ESMTP Changes and Clarifications . . . . . . . 10 60 2.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 10 61 2.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 10 62 2.7.3. Trace Information . . . . . . . . . . . . . . . . . . 10 63 2.7.4. UTF-8 Reply . . . . . . . . . . . . . . . . . . . . . 11 64 3. Issues with Other Parts of the Email System . . . . . . . . . 13 65 3.1. LMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 3.2. SMTP Service Extension for DSNs . . . . . . . . . . . . . 13 67 3.3. POP and IMAP . . . . . . . . . . . . . . . . . . . . . . . 13 68 4. Potential problems . . . . . . . . . . . . . . . . . . . . . . 13 69 4.1. Impact many email related RFC . . . . . . . . . . . . . . 13 70 5. Implementation Advice . . . . . . . . . . . . . . . . . . . . 13 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 7. Security considerations . . . . . . . . . . . . . . . . . . . 14 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 74 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 15 75 9.1. draft-ietf-eai-smtpext: Version 00 . . . . . . . . . . . . 15 76 9.2. draft-ietf-eai-smtpext: Version 01 . . . . . . . . . . . . 15 77 9.3. draft-ietf-eai-smtpext: Version 02 . . . . . . . . . . . . 15 78 9.4. draft-ietf-eai-smtpext: Version 03 . . . . . . . . . . . . 15 79 9.5. draft-ietf-eai-smtpext: Version 04 . . . . . . . . . . . . 16 80 9.6. draft-ietf-eai-smtpext: Version 05 . . . . . . . . . . . . 16 81 9.7. draft-ietf-eai-smtpext: Version 06 . . . . . . . . . . . . 16 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 86 Intellectual Property and Copyright Statements . . . . . . . . . . 20 88 1. Introduction 90 Internationalized email address includes two parts, the local part 91 and the domain part. The ways email addresses are used by protocols 92 are different from the ways domain names are used. The most critical 93 difference is that emails are delivered through a chain of peering 94 clients and servers while domain names are resolved by name servers 95 by looking up their own tables. In addition to this, email transport 96 protocol ESMTP[RFC1869] provide a negotiation mechanism through which 97 clients can make decisions for further processing; please see more in 98 [EAI-framework]. Email addresses can exploit the SMTP extension 99 negotiation mechanism while Internationalized Domain Name(IDN) does 100 not have such a facility. This is also more desirable 101 architecturally. This document specifies an SMTP extension to permit 102 internationalized email addresses in envelopes, and UTF-8 in headers. 103 The protocol described here is an MTA solution which is feasible, 104 architecturally elegant, and not difficult to deploy. 106 1.1. Role of this specification 108 The framework document [EAI-framework] specifies the requirements 109 for, and components of, full internationalization of electronic mail. 110 To understand and implement this specification, understanding the 111 context presented in [EAI-framework] is necessary. 113 This document specifies an element of that work, specifically the 114 definition of an SMTP extension [RFC1869] for the internationalized 115 email address transport delivery. 117 1.2. Proposal Context 119 This specification describes a change to the email transport 120 mechanism that permits non-ASCII characters in both the envelope and 121 header fields of messages while the specification in [EAI-utf8header] 122 specifies the details of how and where non-ASCII characters are 123 permitted in the header fields of messages. The context for the 124 change is described in [EAI-framework]. 126 1.3. Terminology 128 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 129 and "MAY" in this document are to be interpreted as described in RFC 130 2119 [RFC2119]. 132 All specialized terms used in this specification are defined in the 133 EAI framework [EAI-framework] or in [RFC2821] and [RFC2822]. The 134 terms "ASCII address", "internationalized email address", "non-ASCII 135 address", "i18mail address", "UTF8SMTP", "message" and "mailing list" 136 are used with the definitions from the [EAI-framework] document. 138 This document defines only those ABNF [RFC4234] syntax rules that are 139 different from those of the base email specifications 140 [RFC2821][RFC2822] and, where the earlier rules are upgraded or 141 extended, gives them new names. When the new rule is a small upgrade 142 to the older one, it is typically given a name starting with "u". 143 Rules that are undefined here may be found in the base email 144 documents under the same names. 146 [[anchor4: RFC EDITOR'S NOTE: The following text should be deleted 147 before publication.]] This document is being discussed on the EAI 148 mailing list. See https://www1.ietf.org/mailman/listinfo/ima for 149 information about 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 Clients MUST ignore any parameters, that is, clients MUST behave 166 as if the parameters do not appear. If a server includes 167 UTF8SMTP in its EHLO response, it MUST be fully compliant with 168 this version of this specification. 169 4. One optional parameter, ALT-ADDRESS, is added to the SMTP MAIL 170 and RCPT commands. ALT-ADDRESS specifies an all-ASCII address 171 which can be used as a substitute for the i18mail addresses that 172 we call the primary address; you can learn more in 173 [EAI-framework] or [EAI-downgrading]. 174 5. One optional parameter "UTF8REPLY" is added to the VRFY and EXPN 175 commands. The parameter UTF8REPLY has no value. The parameter 176 indicates the SMTP client can accept UTF-8 on replies of the 177 VRFY and EXPN commands. 178 6. No additional SMTP verbs are defined by this extension. 179 7. Servers offering this extension MUST provide support for, and 180 announce, the 8BITMIME extension [RFC1652]. 182 8. The reverse-path and forward-path of SMTP MAIL and RCPT commands 183 are extended to allow UTF-8 characters in the specified mailbox 184 address. 185 9. The mail datum is extended in compliance with [EAI-utf8header] 186 10. The maximum length of a MAIL and RCPT command lines is increased 187 by 460 characters by the possible addition of the ALT-ADDRESS 188 keyword and value. 190 2.2. The UTF8SMTP Extension 192 An SMTP Server that announces this extension MUST be prepared to 193 accept a UTF-8 string [RFC3629] in any position in which RFC 2821 194 specifies that a "mailbox" MAY appear. That string MUST be parsed 195 only as specified in RFC 2821, i.e., by separating the mailbox into 196 source route, local part and domain part, using only the characters 197 colon (U+003A), comma (U+002C), and at-sign (U+0040) as specified 198 there. Once isolated by this parsing process, the local part MUST be 199 treated as opaque unless the SMTP Server is the final delivery MTA. 200 Any domain names that are to be looked up in the DNS MUST first be 201 processed into the form specified in IDNA [RFC3490] by means of the 202 ToASCII() operation unless they are already in that form. Any domain 203 names that are to be compared to local strings SHOULD be checked for 204 validity and then MUST be compared as specified in section 3.4 of 205 IDNA. 207 The UTF8SMTP extension is valid on the submission port [RFC4409]. 209 An SMTP Client that receives the UTF8SMTP extension keyword in 210 response to the "EHLO" command MAY transmit a mailbox name as an 211 internationalized string in UTF-8 form and MAY send an UTF-8 header 212 [EAI-utf8header]. It MAY transmit the domain part of that string in 213 either the form of ACE labels specified in [RFC3490] or UTF-8 form. 214 In the domain part of the mailbox string, if any of the labels are 215 intended to be interpreted as non-ASCII (i.e., are IDNs), then the 216 Message Submission Server ("MSA") [RFC4409] MUST take responsibility 217 for ensuring that the labels are valid (whether they appear in native 218 character or ACE form). The presence of the UTF8SMTP extension does 219 not change the requirement of RFC 2821 that servers relaying mail 220 MUST not attempt to parse, evaluate, or transform the local part in 221 any way. 223 If the UTF8SMTP SMTP extension is not offered by the Server, the SMTP 224 client MUST NOT transmit an internationalized address and MUST NOT 225 transmit a mail message which contains internationalized mail headers 226 [EAI-utf8header] at any level within its MIME structure. Instead, if 227 an SMTP client (SMTP sender) attempts to transfer a UTF8SMTP message 228 and encounters a server that does not support the extension, it MUST 229 make one of the following four choices: 231 1. If and only if the SMTP client (sender) is a Message Submission 232 Server[RFC4409], it MAY, consistent with the general provisions 233 for changes by such servers, rewrite the envelope, headers, or 234 message material to make them entirely ASCII and consistent with 235 the provisions of RFC 2821 [RFC2821] and RFC 2822 [RFC2822]. 236 2. Reject the message during the SMTP transaction or generate a 237 notification of non-deliverability, as specified in RFC 2821 238 [RFC2821] and RFC 3464 [RFC3464]. If the message content can be 239 returned without alteration, content should be returned as 240 specified in 2821 but, if a server is encountered along the 241 return path that cannot accept UTF8SMTP traffic, the content 242 should simply be abridged or dropped. 243 3. Find an alternate route to the destination that permits UTF8SMTP. 244 That route may be discovered by trying alternate MX hosts (using 245 preference rules as specified in RFC 2821) or using other means 246 available to the SMTP-sender. 247 4. If and only if ASCII addresses are available for all addresses 248 that appear in the return path and the specific forward paths 249 being attempted, downgrade the message to an all-ASCII form as 250 specified in [EAI-downgrading]. An ASCII address is considered 251 to be "available" for a particular address if the original 252 address in the envelope is in ASCII or if an ALT-Address 253 parameter is specified for a UTF8SMTP address. 255 2.3. Extended Mailbox Address Syntax 257 RFC 2821, section 4.1.2, defines the syntax of a mailbox entirely in 258 terms of ASCII characters, using the production for "Mailbox" and 259 those on which it depends. 261 The key changes made by this specification are, informally, to 263 o Change the definition of "sub-domain" to permit either the 264 definition above or a UTF-8 string representing a DNS label that 265 is conformant with IDNA [RFC3490]. 266 o Change the definition of "Atom" to permit either the definition 267 above or a UTF-8 string. That string MUST NOT contain any of the 268 ASCII characters (either graphics or controls) that are not 269 permitted in "atext"; it is otherwise unrestricted. 271 According to the description above, define the syntax of an 272 internationalized email mailbox with ABNF [RFC4234] as 273 uMailbox = uLocal-part "@" uDomain 274 ; Replace Mailbox in RFC 2821, section 4.1.2 276 uLocal-part = uDot-string / uQuoted-string 277 ; MAY be case-sensitive 278 ; Replace Local-part in RFC 2821, section 4.1.2 280 uDot-string = uAtom *("." uAtom) 281 ; Replace Dot-string in RFC 2821, section 4.1.2 283 uAtom = 1*ucharacter 284 ; Replace Atom in RFC 2821, section 4.1.2 286 ucharacter = atext / UTF8-xtra-char 287 ; Replace character in RFC 2821, section 4.1.2 288 ; atext is defined in RFC 2822 290 uQuoted-string = DQUOTE *uqcontent DQUOTE 291 ; Replace Quoted-string in RFC 2821, section 4.1.2 292 ; DQUOTE is Double Quote defined in RFC 4234 294 uqcontent = qcontent / UTF8-xtra-char 295 ; qcontent is defined in RFC 2822, section 3.2.5 297 uDomain = (sub-udomain 1*("." sub-udomain)) / address-literal 298 ; Replace Domain in RFC 2821, section 4.1.2 299 ; address-literal is defined in RFC2821 section 4.1.2 301 sub-udomain = uLet-dig [uLdh-str] 302 ; Replace sub-domain in RFC 2821, section 4.1.2 304 uLet-dig = Let-dig / UTF8-xtra-char 305 ; Let-dig is defined in RFC 2821, section 4.1.3 307 uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-xtra-char) uLet-dig 308 ; Replace Ldh-str in RFC 2821, section 4.1.3 310 UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 311 ; UTF8-2, UTF8-3 and UTF8-4 are defined in RFC 3629 313 The value of "udomain" SHOULD be verified with IDNA [RFC3490]; If 314 failed, the email address with that udomain can not be regarded as 315 the valid email address. 317 2.4. The ALT-ADDRESS parameter 319 If the UTF8SMTP extension is offered, the syntax of the SMTP MAIL and 320 RCPT commands is extended to support the optional esmtp-keyword "ALT- 321 ADDRESS", which specifies an alternate all-ASCII address which may be 322 used when downgrading. If the ALT-ADDRESS esmtp-keyword is used, it 323 MUST have an associated esmtp-value (ALT-ADDRESS-esmtp-value which is 324 defined below). 326 Based on the definition of mail-parameters in [RFC2821], the ALT- 327 ADDRESS parameter usage in the commands of "MAIL" and "RCPT" is 328 defined below. 330 "MAIL FROM:" ("<>" / uReverse-path) [ SP Mail-parameters ] CRLF 331 ; Update mail command in RFC 2821, section 4.1.1.2. 332 ; A new parameter defined by the ABNF non-terminal 333 ; is added. It complies 334 ; with the syntax specified by . 336 "RCPT TO:" ("" / "" / 337 uForward-Path) [ SP Rcpt-parameters ] CRLF 338 ; Update rcpt command in RFC 2821, section 4.1.1.3. 339 ; A new parameter defined by the ABNF non-terminal 340 ; is added. It complies 341 ; with the syntax specified by . 343 uReverse-path = uPath 344 ; Replace Reverse-path in RFC 2821, section 4.1.2 346 uForward-path = uPath 347 ; Replace Forward-path in RFC 2821, section 4.1.2 349 uPath = "<" [ A-d-l ":" ] uMailbox ">" 350 ; Replace Path in RFC 2821, section 4.1.2 351 ; A-d-l is defined in RFC 2821, section 4.1.2 352 ; uMailbox is defined in section 2.3 of this document 354 ALT-ADDRESS-parameter="ALT-ADDRESS=" ALT-ADDRESS-esmtp-value 356 ALT-ADDRESS-esmtp-value=xtext 357 ; Mailbox encoded as xtext. 358 ; xtext is defined in RFC 3461 [RFC3461], section 4.2 360 The ALT-ADDRESS-parameter MUST NOT appear more than once in any MAIL 361 or RCPT command. ALT-ADDRESS-esmtp-value MUST be an all-ASCII email 362 address before xtext encoding. 364 2.5. Using the ALT-ADDRESS parameter 366 A message containing non-ASCII envelope addresses or header fields 367 MUST NOT be sent to an SMTP server which does not support UTF8SMTP. 368 Such a message MAY be rejected due to lack of the ALT-ADDRESS as 369 discussed in section 2.2 of this document. 371 When messages are rejected because they require UTF8SMTP, response 372 code "550" is used, defined in [RFC2821], meaning "mailbox 373 unavailable". If enhanced mail system status codes [RFC3463] is 374 used, the response code should be "5.6.x" [SMTP-codes], meaning that 375 "alt-address is required but not specified". 377 If the response code is issued after the final "." of the DATA 378 command, the response code "554" is used, defined in [RFC2821], 379 meaning "Transaction failed". if enhanced mail system status codes 380 [RFC3463] is used, the response code should be "5.6.z" [SMTP-codes], 381 meaning that "UTF8SMTP downgrade failed". 383 [[anchor8: REMOVE THIS: IANA please assign the proper error codes for 384 "5.6.x" and "5.6.z".]] 386 2.6. Body Parts and SMTP Extensions 388 Since there is no ESMTP parameter which tells whether the message is 389 UTF8SMTP message, SMTP server needs to parse all message header 390 fields and MIME header fields in the message body to discover which 391 messages are UTF8SMTP. While this specification requires that 392 servers support the 8BITMIME extension [RFC1652] to ensure that 393 servers have adequate handling capability for 8-bit data and to avoid 394 a number of complex encoding problems, the use of internationalized 395 addresses obviously does not require non-ASCII body parts in the MIME 396 message. The UTF8SMTP extension MAY be used with the BODY=8BITMIME 397 parameter if that is appropriate given the body content or, if the 398 server advertises it and it is appropriate, with the BODY=BINARYMIME 399 parameter specified in [RFC3030]. 401 Assuming that the server advertises UTF8SMTP and 8BITMIME, and at 402 least one non-ASCII address, with or without ALT-ADDRESS, the precise 403 interpretation of "No 'Body' parameter", "BODY= 8BITMIME", and "BODY= 404 BINARYMIME" in the MAIL command is: 405 1. For No "Body" parameter, headers are in UTF-8, body parts are in 406 ASCII. 407 2. For BODY=8BITMIME parameter, headers are in UTF-8, some or all 408 body parts contain 8-bit line-oriented data. 410 3. For BODY=BINARYMIME parameter, headers are in UTF-8, some or all 411 body parts contain binary data without restriction as to line 412 lengths or delimiters. 414 2.7. Additional ESMTP Changes and Clarifications 416 The mail transport process involves addresses ("mailboxes") and 417 domain names in contexts in addition to the MAIL and RCPT commands 418 and extended alternatives to them. In general, the rule is that, 419 when RFC 2821 specifies a mailbox, this document expects UTF-8 to be 420 used for the entire string; when RFC 2821 specifies a domain name, 421 the name SHOULD be in the form of ACE labels if its raw form is non- 422 ASCII. 424 The following subsections list and discuss all of the relevant cases. 426 Support and use of this extension requires support for 8BITMIME. It 427 means that 8BITMIME MUST be advertised by the UTF8SMTP capable SMTP 428 server. 430 2.7.1. The Initial SMTP Exchange 432 When an SMTP or ESMTP connection is opened, the server normally sends 433 a "greeting" response consisting of the '220' reply code and some 434 information. The client then sends the EHLO command. Since the 435 client cannot know whether the server supports UTF8SMTP until after 436 it receives the response from EHLO, any domain names that appear in 437 this dialogue, or in responses to EHLO, MUST be in the hostname form, 438 i.e., internationalized ones MUST be in the form of ACE labels. 440 2.7.2. Mail eXchangers 442 Commonly, organizations authorize multiple servers to accept mail 443 addressed to them. For example, the organization may itself operate 444 more than one server, and may also or instead have an agreement with 445 other organizations to accept mail as a backup. Authorized servers 446 are generally listed in MX records [RFC2821]. When more than one 447 server accepts mail for the domain-part of a Mailbox, it is strongly 448 advised that either all or none of them support the UTF8SMTP 449 extension. Otherwise, surprising downgrades can happen during 450 temporary failures, which is not a good thing. 452 2.7.3. Trace Information 454 When an SMTP server receives a message for delivery or further 455 processing, it MUST insert trace ("time stamp" or "Received") 456 information at the beginning of the message content. Time stamp 457 appears in the form of "Received: lines". The most important use of 458 Received: lines is for debugging mail faults. When the delivery SMTP 459 server makes the "final delivery" of a message, it inserts a return- 460 path line at the beginning of the mail data. The primary purpose of 461 the Return-path is to designate the address to which messages 462 indicating non-delivery or other mail system failures are to be sent. 463 For the trace information, we update the time stamp line and the 464 return path line [RFC2821] formally defined as follows: 466 uReturn-path-line = "Return-Path:" FWS uReverse-path 467 ; Replaces Return-path-line in the section 4.4 of [RFC2821] 468 ; uReverse-path is defined in Section 2.3 470 uTime-stamp-line = "Received:" FWS uStamp 471 ; Replaces Time-stamp-line in the section 4.4 of [RFC2821] 473 uStamp = From-domain By-domain uOpt-info ";" FWS date-time 474 ; Replaces Stamp in the section 4.4 of [RFC2821] 476 uOpt-info = [Via] [With] [ID] [uFor] 477 ; Replaces Opt-info in the section 4.4 of [RFC2821] 478 ; [With]'s protocol value will allow UTF8SMTP value 480 uFor = "FOR" 1*( FWS (uPath / uMailbox) ) CFWS 481 ; Replaces For in the section 4.4 of [RFC2821] 482 ; uPath is defined in section 2.4 of this document 483 ; uMailbox is defined in section 2.3 of this document 485 [[anchor12: Note: Whether the FOR parameter is permitted to accept 486 more than one address is now under discussion as part of the 487 rfc2821bis effort. The multiple-address construction was introduced 488 with RFC 2821; it is not clear that it has been widely implemented or 489 that it is wise. Whatever decision is reached about RFC2821bis will 490 be reflected in the syntax of a future version of this document.]] 491 Except in the 'uFor' and 'uReverse-path' line where non-ASCII domain 492 name may be used, internationalized domain names in Received fields 493 MUST be transmitted in the form of ACE labels. The protocol value of 494 the WITH clause is UTF8SMTP when this extension is used. More 495 information is in the "IANA Considerations" section of this document. 497 2.7.4. UTF-8 Reply 499 If the client issues the "RCPT" command which contains non-ASCII 500 characters, the SMTP server is permitted to use UTF-8 characters 501 within 251 and 551 response codes. Servers MUST NOT include non- 502 ASCII characters except in the limited cases specifically permitted 503 in this section. 505 If the VRFY and EXPN commands has the optional parameter "UTF8REPLY", 506 it indicates the client can accept UTF-8 on replies of the VRFY and 507 EXPN commands. Specially this allows to use UTF-8 on mailboxes and 508 full names which occur on replies. The SMTP client following this 509 specification MUST accept UTF-8 on replies of the VRFY and EXPN 510 commands. However the SMTP server MUST not use UTF-8 on replies, if 511 SMTP client does not ask UTF-8 replies. Some replies include the 512 mailbox, but usually most of replies do not require that the mailbox 513 is included in it and therefore UTF-8 is not needed. UTF8REPLY 514 parameter on the VRFY and EXPN commands tells the SMTP server that 515 the client is prepared for UTF-8 on SMTP replies. 517 VERIFY (VRFY) and EXPAND (EXPN)command syntaxes are changed to: 519 "VRFY" SP uAtom [SP "UTF8REPLY"] CRLF; 520 ;uAtom is defined in section 2.3 of this document 522 "EXPN" SP uAtom [SP "UTF8REPLY"] CRLF; 523 ;uAtom is defined in section 2.3 of this document 525 This parameter "UTF8REPLY" does not have value. If SMTP reply 526 requires UTF-8, but SMTP client does not use "UTF8REPLY" parameter in 527 the VERIFY (VRFY) and EXPAND (EXPN) commands, the response code "252" 528 is used, defined in [RFC2821], meaning "Cannot VRFY user, but will 529 accept the message and attempt the delivery". If enhanced mail 530 system status code [RFC3463] is used, the response code should be 531 "5.6.y" or "2.6.y" [SMTP-codes], meaning that "The UTF-8 reply 532 required, but the UTF8REPLY parameter not used.". [[anchor13: REMOVE 533 THIS: IANA please assign the proper error codes for "5.6.y" and 534 "2.6.y".]] "UTF8REPLY" on the VERIFY (VRFY) or EXPAND (EXPN) 535 commands enables UTF-8 for that command only. 537 The uAtom of the VRFY and EXPN commands is a user name or a user name 538 and a domain (see below). If a normal (i.e., 250) response is 539 returned, the response MAY include the full name of the user and MUST 540 include the mailbox of the user. It MUST be in either of the 541 following forms: 543 User Name 544 ; uMailbox is defined in section 2.3 of this document 545 ; User Name allows the non-ASCII character. 547 uMailbox 548 ; uMailbox is defined in section 2.3 of this document 550 If the SMTP Client lack of the UTF8SMTP support receives the UTF-8 551 message on reply, it may crash. UTF-8 messages on reply are only 552 allowed in the commands under the situations described above. Under 553 any other circumstances, UTF-8 messages on the reply MUST NOT be 554 used. 556 3. Issues with Other Parts of the Email System 558 3.1. LMTP 560 LMTP [RFC2033] may be used as the final delivery agent. In such 561 cases, LMTP may be arranged to deliver the mail to the mail store. 562 The mail store may not have UTF8SMTP capability. LMTP need to be 563 updated to deal with these situations. 565 3.2. SMTP Service Extension for DSNs 567 The existing draft standard Delivery status notifications 568 (DSNs)[RFC3461] is presently limited to US-ASCII text in the machine 569 readable portions of the protocol. "International Delivery and 570 Disposition Notifications" [EAI-dsn] adds a new address type for 571 international email addresses so an original recipient address with 572 non-US-ASCII characters can be correctly preserved even after 573 downgrading. If an SMTP server advertises both the UTF8SMTP and the 574 DSN extension, that server MUST implement EAI-dsn [EAI-dsn] including 575 support for the ORCPT parameter. 577 3.3. POP and IMAP 579 The [EAI-framework] has introduced two documents [EAI-pop] and 580 [EAI-imap] to how to use internationalized user names based on UTF-8 581 characters for the retrieval of messages from a mail server. 583 4. Potential problems 585 4.1. Impact many email related RFC 587 Internationalized email has implications for all processes and 588 protocols which examine, handle, generate, or otherwise deal with 589 mail. In particular, address parsing or validity checks, message 590 parsing or handling, etc. 592 5. Implementation Advice 594 In the absence of this extension, SMTP clients and servers are 595 constrained to using only those addresses permitted by RFC 2821. The 596 local parts of those addresses MAY be made up of any ASCII 597 characters, although some of them MUST be quoted as specified there. 599 It is notable in an internationalization context that there is a long 600 history on some systems of using overstruck ASCII characters (a 601 character, a backspace, and another character) within a quoted string 602 to approximate non-ASCII characters. This form of 603 internationalization SHOULD be phased out as this extension becomes 604 widely deployed but backward-compatibility considerations require 605 that it continue to be supported. 607 6. IANA Considerations 609 IANA is requested to add "UTF8SMTP" to the SMTP extensions registry 610 with the entry pointing to this specification for its definition. 612 IANA is requested to assign the proper error codes "5.6.x", "5.6.z", 613 "5.6.y" and "2.6.y" for this specification based on [SMTP-codes]. 615 The "Mail Transmission Types" registry is requested to be updated to 616 include the following new entries: 618 WITH protocol types Description Reference 619 ------------------- ---------------------------- --------- 620 UTF8SMTP UTF8SMTP with Service Extensions [RFCxxxx] 621 UTF8SMTPA UTF8SMTP with SMTP AUTH [RFC2554bis] 622 [RFCxxxx] 623 UTF8SMTPS UTF8SMTP with STARTTLS [RFC3207] 624 [RFCxxxx] 625 UTF8SMTPSA UTF8SMTP with both STARTTLS and [RFC3207] 626 SMTP AUTH [RFC2554bis] 627 [RFCxxxx] 629 [[anchor22: REMOVE THIS: where RFCxxxx represents the future RFC N0. 630 of this document. When this document is published as RFC and 631 assigned with a RFC No., "xxxx" should be replaced with 4-digits No.. 632 "RFC2554bis" should be replaced with the new RFC No. when the 633 "RFC2554bis" document is assigned with the new RFC No.]] 635 7. Security considerations 637 See the extended security considerations discussion in 638 [EAI-framework] 640 8. Acknowledgements 642 Much of the text in the initial version of this document was derived 643 or copied from [Klensin-emailaddr] with the permission of the author. 644 Significant comments and suggestions were received from Xiaodong LEE, 645 Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other members of the JET 646 team and were incorporated into the document. Special thanks to 647 those contributors for this version of document, those includes (but 648 not limited to) John C Klensin, Charles Lindsey, Dave Crocker, Harald 649 Tveit Alvestrand, Marcos Sanz, Chris Newman, Martin Duerst, Edmon 650 Chung, Tony Finch, Kari Hurtta, Randall Gellens, Frank Ellermann, 651 Alexey Melnikov. Of course, none of the individuals are necessarily 652 responsible for the combination of ideas represented here. 654 9. Change History 656 [[anchor25: REMOVE THIS: This section is used for tracking the update 657 of this document. It may be useful to retain parts of it to 658 facilitate establishing dates and documents for the history of this 659 work.]] 661 9.1. draft-ietf-eai-smtpext: Version 00 663 This version supercedes draft-yao-ima-smtpext-03.txt. It refines the 664 ABNF definition of the internationalized email address. It 665 represents as the EAI working group document. 667 9.2. draft-ietf-eai-smtpext: Version 01 669 o Upgraded to reflect discussions during IETF 66. 670 o Remove the atomic parameter. 671 o Add the new section of "the Suggestion of the value of the ALT- 672 ADDRESS parameter". 674 9.3. draft-ietf-eai-smtpext: Version 02 676 o Upgraded to reflect the recent discussion of the ima@ietf.org 677 mailing list. 678 o Add the section of "Body Parts and SMTP Extensions". 679 o Add the new section of "Change History". 680 o Add the subsection about SMTP extensions for DSN. 682 9.4. draft-ietf-eai-smtpext: Version 03 684 o Update the syntax related to mailbox. 686 o Update the trace field section. 687 o Add the new section about message retry. 688 o Update the subsection about SMTP extensions for DSN. 690 9.5. draft-ietf-eai-smtpext: Version 04 692 o Refine some syntax. 693 o Delete "Message Header Label" section. 694 o Change "bounce" to "reject". 696 9.6. draft-ietf-eai-smtpext: Version 05 698 o Refine the abstract. 699 o Delete "The Suggestion of the Value of the ALT-ADDRESS parameter" 700 section. 701 o Move original section 2.7.4 and 2.7.5 to section 3 with the name 702 "Issues with other parts of the email system". 703 o Add the new section "LMTP". 704 o Refine some text according to suggestions from the EAI mailing 705 list discussion 706 o Remove the section "Mailing List Question" 708 9.7. draft-ietf-eai-smtpext: Version 06 710 o Delete the section about message retry. 711 o Add the new subsection about Mail eXchangers 712 o Add the new section about "UTF-8 Reply" 713 o Refine some response code for the section "Using the ALT-ADDRESS 714 parameter" 716 10. References 718 10.1. Normative References 720 [ASCII] Cerf, V., "ASCII format for network interchange", RFC 20, 721 October 1969. 723 [EAI-framework] 724 Klensin, J. and Y. Ko, "Overview and Framework for 725 Internationalized Email", draft-ietf-eai-framework-05.txt 726 (work in progress), 2 2007. 728 [EAI-utf8header] 729 Yeh, J., "Transmission of Email Headers in UTF-8 730 Encoding", draft-ietf-eai-utf8headers-05.txt (work in 731 progress), April 2007. 733 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 734 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 735 RFC 1652, July 1994. 737 [RFC1869] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 738 Crocker, "SMTP Service Extensions", STD 10, RFC 1869, 739 November 1995. 741 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 742 Requirement Levels", BCP 14, RFC 2119, March 1997. 744 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 745 April 2001. 747 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 748 April 2001. 750 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 751 Extension for Delivery Status Notifications (DSNs)", 752 RFC 3461, January 2003. 754 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 755 RFC 3463, January 2003. 757 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 758 for Delivery Status Notifications", RFC 3464, 759 January 2003. 761 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 762 "Internationalizing Domain Names in Applications (IDNA)", 763 RFC 3490, March 2003. 765 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 766 10646", RFC 3629, November 2003. 768 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 769 Specifications: ABNF", RFC 4234, October 2005. 771 10.2. Informative References 773 [EAI-downgrading] 774 YONEYA, Y., Ed. and K. Fujiwara, Ed., "Downgrading 775 mechanism for Internationalized eMail Address (IMA)", 776 draft-ietf-eai-downgrade-02 (work in progress), 777 August 2006. 779 [EAI-dsn] Newman, C., "SMTP extensions for DSNs", 780 draft-ietf-eai-dsn-00.txt (work in progress), 1 2007. 782 [EAI-imap] 783 Resnick, P. and C. Newman, "Considerations for IMAP in 784 Conjunction with Email Address Internationalization", 785 draft-ietf-eai-imap-utf8-01 (work in progress), 786 March 2007. 788 [EAI-mailing list] 789 Gellens, R. and E. Chung, "Mailing Lists and 790 Internationalized Email Addresses", 791 draft-ietf-eai-mailinglist-01.txt (work in progress), 792 January 2007. 794 [EAI-pop] Newman, C., "POP3 Support for UTF-8", 795 draft-ietf-eai-pop-01.txt (work in progress), 796 January 2007. 798 [Klensin-emailaddr] 799 Klensin, J., "Internationalization of Email Addresses", 800 draft-klensin-emailaddr-i18n-03 (work in progress), 801 July 2005. 803 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 804 October 1996. 806 [RFC2554bis] 807 Siemborski, R. and A. Melnikov, "SMTP Service Extension 808 for Authentication", draft-siemborski-rfc2554bis-09 (work 809 in progress), April 2007. 811 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 812 of Large and Binary MIME Messages", RFC 3030, 813 December 2000. 815 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 816 Transport Layer Security", RFC 3207, February 2002. 818 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 819 RFC 4409, April 2006. 821 [SMTP-codes] 822 KLensin, J., "An IANA Registry for Extended SMTP Status 823 Codes", draft-klensin-smtp-code-registry-00 (work in 824 progress), April 2007. 826 Authors' Addresses 828 Jiankang YAO (editor) 829 CNNIC 830 No.4 South 4th Street, Zhongguancun 831 Beijing 833 Phone: +86 10 58813007 834 Email: yaojk@cnnic.cn 836 Wei MAO (editor) 837 CNNIC 838 No.4 South 4th Street, Zhongguancun 839 Beijing 841 Phone: +86 10 58813055 842 Email: maowei_ietf@cnnic.cn 844 Full Copyright Statement 846 Copyright (C) The IETF Trust (2007). 848 This document is subject to the rights, licenses and restrictions 849 contained in BCP 78, and except as set forth therein, the authors 850 retain all their rights. 852 This document and the information contained herein are provided on an 853 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 854 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 855 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 856 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 857 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 858 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 860 Intellectual Property 862 The IETF takes no position regarding the validity or scope of any 863 Intellectual Property Rights or other rights that might be claimed to 864 pertain to the implementation or use of the technology described in 865 this document or the extent to which any license under such rights 866 might or might not be available; nor does it represent that it has 867 made any independent effort to identify any such rights. Information 868 on the procedures with respect to rights in RFC documents can be 869 found in BCP 78 and BCP 79. 871 Copies of IPR disclosures made to the IETF Secretariat and any 872 assurances of licenses to be made available, or the result of an 873 attempt made to obtain a general license or permission for the use of 874 such proprietary rights by implementers or users of this 875 specification can be obtained from the IETF on-line IPR repository at 876 http://www.ietf.org/ipr. 878 The IETF invites any interested party to bring to its attention any 879 copyrights, patents or patent applications, or other proprietary 880 rights that may cover technology that may be required to implement 881 this standard. Please address the information to the IETF at 882 ietf-ipr@ietf.org. 884 Acknowledgment 886 Funding for the RFC Editor function is provided by the IETF 887 Administrative Support Activity (IASA).