idnits 2.17.1 draft-yao-eai-rfc5336bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2821, but the abstract doesn't seem to directly say this. It does mention RFC2821 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2821, updated by this document, for RFC5378 checks: 1995-11-08) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 3, 2009) is 5404 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFCXXXX' is mentioned on line 713, but not defined ** Obsolete normative reference: RFC 1652 (Obsoleted by RFC 6152) ** 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 4409 (Obsoleted by RFC 6409) ** Obsolete normative reference: RFC 4952 (Obsoleted by RFC 6530) ** Obsolete normative reference: RFC 5335 (Obsoleted by RFC 6532) ** Obsolete normative reference: RFC 5337 (Obsoleted by RFC 6533) -- Obsolete informational reference (is this intentional?): RFC 974 (Obsoleted by RFC 2821) == Outdated reference: A later version (-11) exists of draft-klensin-rfc2821bis-10 -- Obsolete informational reference (is this intentional?): RFC 5504 (Obsoleted by RFC 6530) Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 5 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 Updates: RFC4952, 2821 and 2822 CNNIC 5 (if approved) July 3, 2009 6 Intended status: Experimental 7 Expires: January 4, 2010 9 SMTP Extension for Internationalized Email Address 10 draft-yao-eai-rfc5336bis-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on January 4, 2010. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 This document specifies an SMTP extension for transport and delivery 59 of email messages with internationalized email addresses or header 60 information. Communication with systems that do not implement this 61 specification is specified in another document. This document 62 updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and 63 has some material updating RFC 4952. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Role of This Specification . . . . . . . . . . . . . . . . 4 69 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 71 3. Mail Transport-Level Protocol . . . . . . . . . . . . . . . . 5 72 3.1. Framework for the Internationalization Extension . . . . . 5 73 3.2. The UTF8SMTP Extension . . . . . . . . . . . . . . . . . . 6 74 3.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 7 75 3.4. The ALT-ADDRESS Parameter . . . . . . . . . . . . . . . . 10 76 3.5. ALT-ADDRESS Parameter Usage and Response Codes . . . . . . 11 77 3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 12 78 3.7. Additional ESMTP Changes and Clarifications . . . . . . . 12 79 3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 13 80 3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 13 81 3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 13 82 3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 14 83 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 85 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 86 7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 18 87 7.1. draft-yao-eai-rfc5336bis: Version 00 . . . . . . . . . . . 18 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 90 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 91 Appendix A. Material Updating RFC 4952 . . . . . . . . . . . . . 20 92 A.1. Conventional Message and Internationalized Message . . . . 21 93 A.2. LMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 A.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 21 95 A.4. Implementation Advice . . . . . . . . . . . . . . . . . . 21 96 A.5. Applicability of SMTP Extension to Additional Uses . . . . 21 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 100 1. Introduction 102 An internationalized email address includes two parts, the local part 103 and the domain part. The ways email addresses are used by protocols 104 are different from the ways domain names are used. The most critical 105 difference is that emails are delivered through a chain of clients 106 and servers, while domain names are resolved by name servers looking 107 up those names in their own tables. In addition to this, the Simple 108 Mail Transfer Protocol [RFC2821] provides a negotiation mechanism 109 about service extension with which clients can discover server 110 capabilities and make decisions for further processing. An extended 111 overview of the extension model for internationalized addresses and 112 headers appears in [RFC4952], referred to as "the framework document" 113 or just as "Framework" elsewhere in this specification. This 114 document specifies an SMTP extension to permit internationalized 115 email addresses in envelopes, and UNICODE characters (encoded in 116 UTF-8) [RFC3629] in headers. 118 1.1. Role of This Specification 120 The framework document specifies the requirements for, and describes 121 components of, full internationalization of electronic mail. A 122 thorough understanding of the information in that document and in the 123 base Internet email specifications [RFC2821] [RFC2822] is necessary 124 to understand and implement this specification. 126 This document specifies an element of the email internationalization 127 work, specifically the definition of an SMTP extension [RFC2821] for 128 internationalized email address transport delivery. 130 1.2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119]. 136 The terms "conventional message" and "internationalized message" are 137 defined in an appendix to this specification. The terms "UTF-8 138 string" or "UTF-8 character" are used informally to refer to Unicode 139 characters encoded in UTF-8 [RFC3629]. All other specialized terms 140 used in this specification are defined in the framework document or 141 in the base Internet email specifications [RFC2821] [RFC2822]. In 142 particular, the terms "ASCII address", "internationalized email 143 address", "non-ASCII address", "i18mail address", "UTF8SMTP", 144 "message", and "mailing list" are used in this document according to 145 the definitions in the framework document. 147 This specification defines only those Augmented BNF (ABNF) [RFC5234] 148 syntax rules that are different from those of the base email 149 specifications [RFC2821][RFC2822] and, where the earlier rules are 150 upgraded or extended, gives them new names. When the new rule is a 151 small modification to the older one, it is typically given a name 152 starting with "u". Rules that are undefined here may be found in the 153 base email specifications under the same names. 155 2. Overview of Operation 157 This specification describes an optional extension to the email 158 transport mechanism that permits non-ASCII [ASCII] characters in both 159 the envelope and header fields of messages, which are encoded with 160 UTF-8 [RFC3629] characters. The extension is identified with the 161 token "UTF8SMTP". In order to provide information that may be needed 162 in downgrading, an optional alternate ASCII address may be needed if 163 an SMTP client attempts to transfer an internationalized message and 164 encounters a server that does not support this extension. 166 The EAI UTF-8 header specification [RFC5335] provides the details of 167 how and where non-ASCII characters are permitted in the header fields 168 of messages. The context for this specification is described in the 169 framework document. 171 3. Mail Transport-Level Protocol 173 3.1. Framework for the Internationalization Extension 175 The following service extension is defined: 176 1. The name of the SMTP service extension is "Email Address 177 Internationalization". 178 2. The EHLO keyword value associated with this extension is 179 "UTF8SMTP". 180 3. No parameter values are defined for this EHLO keyword value. In 181 order to permit future (although unanticipated) extensions, the 182 EHLO response MUST NOT contain any parameters for that keyword. 183 Clients MUST ignore any parameters; that is, clients MUST behave 184 as if the parameters do not appear. If a server includes 185 UTF8SMTP in its EHLO response, it MUST be fully compliant with 186 this version of this specification. 187 4. One optional parameter, ALT-ADDRESS, is added to the MAIL and 188 RCPT commands of SMTP. ALT-ADDRESS specifies an all-ASCII 189 address which can be used as a substitute for the corresponding 190 primary (i18mail) address when downgrading. More discussion of 191 the use of this parameter appears in [RFC4952] and [RFC5504]. 193 5. One optional parameter "UTF8REPLY" is added to the VRFY and EXPN 194 commands. The parameter UTF8REPLY has no value. The parameter 195 indicates that the SMTP client can accept Unicode characters in 196 UTF-8 encoding in replies from the VRFY and EXPN commands. 197 6. No additional SMTP verbs are defined by this extension. 198 7. Servers offering this extension MUST provide support for, and 199 announce, the 8BITMIME extension [RFC1652]. 200 8. The reverse-path and forward-path of the SMTP MAIL and RCPT 201 commands are extended to allow Unicode characters encoded in 202 UTF-8 in mailbox names (addresses). 203 9. The mail message body is extended as specified in [RFC5335]. 204 10. The maximum length of MAIL and RCPT command lines is increased 205 by 460 characters by the possible addition of the ALT-ADDRESS 206 keyword and value. 207 11. The UTF8SMTP extension is valid on the submission port 208 [RFC4409]. 210 3.2. The UTF8SMTP Extension 212 An SMTP server that announces this extension MUST be prepared to 213 accept a UTF-8 string [RFC3629] in any position in which RFC 2821 214 specifies that a mailbox can appear. That string MUST be parsed only 215 as specified in RFC 2821, i.e., by separating the mailbox into source 216 route, local part, and domain part, using only the characters colon 217 (U+003A), comma (U+002C), and at-sign (U+0040) as specified there. 218 Once isolated by this parsing process, the local part MUST be treated 219 as opaque unless the SMTP server is the final delivery Mail Transfer 220 Agent (MTA). Any domain names that are to be looked up in the DNS 221 MUST first be processed into the form specified in 222 "Internationalizing Domain Names in Applications (IDNA)" [RFC3490] by 223 means of the ToASCII() operation unless they are already in that 224 form. Any domain names that are to be compared to local strings 225 SHOULD be checked for validity and then MUST be compared as specified 226 in Section 3.4 of IDNA. 228 An SMTP client that receives the UTF8SMTP extension keyword in 229 response to the EHLO command MAY transmit mailbox names within SMTP 230 commands as internationalized strings in UTF-8 form. It MAY send a 231 UTF-8 header [RFC5335] (which may also include mailbox names in 232 UTF-8). It MAY transmit the domain parts of mailbox names within 233 SMTP commands or the message header as either ACE (ASCII Compatible 234 Encoding) labels (as specified in IDNA [RFC3490]) or UTF-8 strings. 235 All labels in domain parts of mailbox names which are IDNs (either 236 UTF-8 or ACE strings) MUST be valid. If the original client submits 237 a message to a Message Submission Server ("MSA") [RFC4409], it is the 238 responsibility of the MSA that all domain labels are valid; 239 otherwise, it is the original client's responsibility. The presence 240 of the UTF8SMTP extension does not change the requirement of RFC 2821 241 that servers relaying mail MUST NOT attempt to parse, evaluate, or 242 transform the local part in any way. 244 If the UTF8SMTP SMTP extension is not offered by the Server, the SMTP 245 client MUST NOT transmit an internationalized address and MUST NOT 246 transmit a mail message containing internationalized mail headers as 247 described in [RFC5335] at any level within its MIME structure. (For 248 this paragraph, the internationalized domain name in the form of ACE 249 labels as specified in IDNA [RFC3490] is not considered as 250 "internationalized".) Instead, if an SMTP client (SMTP sender) 251 attempts to transfer an internationalized message and encounters a 252 server that does not support the extension, it MUST make one of the 253 following four choices: 255 1. If and only if the SMTP client (sender) is a Message Submission 256 Server ("MSA") [RFC4409], it MAY, consistent with the general 257 provisions for changes by such servers, rewrite the envelope, 258 headers, or message material to make them entirely ASCII and 259 consistent with the provisions of RFC 2821 [RFC2821] and RFC 2822 260 [RFC2822]. 261 2. It may either reject the message during the SMTP transaction or 262 accept the message and then generate and transmit a notification 263 of non-deliverability. Such notification MUST be done as 264 specified in RFC 2821 [RFC2821], RFC 3464 [RFC3464], and the EAI 265 delivery status notification (DSN) specification [RFC5337]. 266 3. It may find an alternate route to the destination that permits 267 UTF8SMTP. That route may be discovered by trying alternate Mail 268 eXchanger (MX) hosts (using preference rules as specified in RFC 269 2821) or using other means available to the SMTP-sender. 270 4. If and only if ASCII addresses are available for all addresses 271 that appear in the return path and the specific forward paths 272 being attempted, it may downgrade the message to an all-ASCII 273 form as specified in [RFC5504]. An ASCII address is considered 274 to be "available" for a particular address if the original 275 address in the envelope is in ASCII or if an ALT-ADDRESS 276 parameter is specified for a UTF8SMTP address. 278 The difference between choice 1 and choice 4 is that choice 1 is 279 constrained by Message Submission [RFC4409], while choice 4 is 280 constrained by [RFC5504]. 282 3.3. Extended Mailbox Address Syntax 284 RFC 2821, Section 4.1.2, defines the syntax of a mailbox entirely in 285 terms of ASCII characters, using the production for a mailbox and 286 those productions on which it depends. 288 The key changes made by this specification are, informally, to 289 o Change the definition of "sub-domain" to permit either the 290 definition above or a UTF-8 string representing a DNS label that 291 is conformant with IDNA [RFC3490]. 292 o Change the definition of "Atom" to permit either the definition 293 above or a UTF-8 string. That string MUST NOT contain any of the 294 ASCII characters (either graphics or controls) that are not 295 permitted in "atext"; it is otherwise unrestricted. 297 According to the description above, the syntax of an 298 internationalized email mailbox name (address) is defined in ABNF 299 [RFC5234] as follows. 301 uMailbox = uLocal-part "@" uDomain 302 ; Replace Mailbox in RFC 2821, Section 4.1.2 304 uLocal-part = uDot-string / uQuoted-string 305 ; MAY be case-sensitive 306 ; Replace Local-part in RFC 2821, Section 4.1.2 308 uDot-string = uAtom *("." uAtom) 309 ; Replace Dot-string in RFC 2821, Section 4.1.2 311 uAtom = 1*ucharacter 312 ; Replace Atom in RFC 2821, Section 4.1.2 314 ucharacter = atext / UTF8-non-ascii 316 atext = 318 uQuoted-string = DQUOTE *uqcontent DQUOTE 319 ; Replace Quoted-string in RFC 2821, Section 4.1.2 321 DQUOTE = 323 uqcontent = qcontent / UTF8-non-ascii 325 qcontent = 327 uDomain = (sub-udomain 1*("." sub-udomain)) / address-literal 328 ; Replace Domain in RFC 2821, Section 4.1.2 330 address-literal = 332 sub-udomain = uLet-dig [uLdh-str] 333 ; Replace sub-domain in RFC 2821, Section 4.1.2 335 uLet-dig = Let-dig / UTF8-non-ascii 337 Let-dig = 339 uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-non-ascii) uLet-dig 340 ; Replace Ldh-str in RFC 2821, Section 4.1.3 342 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 344 UTF8-2 = 346 UTF8-3 = 348 UTF8-4 = 350 The value of "uDomain" SHOULD be verified by applying the tests 351 specified as part of IDNA [RFC3490]. If that verification fails, the 352 email address with that uDomain MUST NOT be regarded as a valid email 353 address. 355 3.4. The ALT-ADDRESS Parameter 357 If the UTF8SMTP extension is offered, the syntax of the SMTP MAIL and 358 RCPT commands is extended to support the optional esmtp-keyword "ALT- 359 ADDRESS". That keyword specifies an alternate all-ASCII address that 360 may be used when downgrading. If the ALT-ADDRESS esmtp-keyword is 361 used, it MUST have an associated esmtp-value (ALT-ADDRESS-esmtp- 362 value, which is defined below). 364 While it may be tempting to consider ALT-ADDRESS as a general-purpose 365 second-chance address, such behavior is not defined here. Instead, 366 in this specification ALT-ADDRESS only has meaning when the 367 associated primary address is non-ASCII and the message is 368 downgraded. This restriction allows for future extension of the 369 specification even though no such extensions are currently 370 anticipated. 372 Based on the definition of mail-parameters in [RFC2821], the ALT- 373 ADDRESS parameter usage in the commands of MAIL and RCPT is defined 374 as follows. The following definitions are given in the same format 375 as used in RFC 2821. 377 "MAIL FROM:" ("<>" / uReverse-path) [ SP Mail-parameters ] CRLF 378 ; Update the MAIL command in RFC 2821, Section 4.1.1.2. 379 ; A new parameter defined by the ABNF non-terminal 380 ; is added. It complies 381 ; with the syntax specified for in RFC 2821. 383 "RCPT TO:" ("" / "" / 384 uForward-path) [ SP Rcpt-parameters ] CRLF 385 ; Update RCPT command in RFC 2821, Section 4.1.1.3. 386 ; A new parameter defined by the ABNF non-terminal 387 ; is added. It complies 388 ; with the syntax specified for . 389 ; uDomain is defined in Section 3.3 of this document 391 uReverse-path = uPath 392 ; Replace Reverse-path in RFC 2821, Section 4.1.2 394 uForward-path = uPath 395 ; Replace Forward-path in RFC 2821, Section 4.1.2 397 uPath = "<" [ A-d-l ":" ] uMailbox ">" 398 ; Replace Path in RFC 2821, Section 4.1.2 399 ; uMailbox is defined in Section 3.3 of this document 401 A-d-l = 403 ALT-ADDRESS-parameter="ALT-ADDRESS=" ALT-ADDRESS-value 405 ALT-ADDRESS-value= xtext 406 ; The value is a mailbox name encoded as xtext. 408 xtext= 410 The ALT-ADDRESS-parameter MUST NOT appear more than once in any MAIL 411 or RCPT command. ALT-ADDRESS-value MUST be an all-ASCII email 412 address before xtext encoding. 414 3.5. ALT-ADDRESS Parameter Usage and Response Codes 416 An "internationalized message" as defined in the appendix of this 417 specification MUST NOT be sent to an SMTP server that does not 418 support UTF8SMTP. Such a message MAY be rejected by a server if it 419 lacks ALT-ADDRESSes as discussed in Section 3.2 of this 420 specification. 422 The three-digit reply codes used in this section are consistent with 423 their meanings as defined in RFC 2821. 425 When messages are rejected because the RCPT command requires an ALT- 426 ADDRESS, the response code 553 is used with the meaning "mailbox name 427 not allowed". When messages are rejected for other reasons, such as 428 the MAIL command requiring an ALT-ADDRESS, the response code 550 is 429 used with the meaning "mailbox unavailable". When the server 430 supports enhanced mail system status codes [RFC3463], response code 431 "X.6.7" [RFC5248] is used, meaning that "The ALT-ADDRESS is required 432 but not specified". 434 If the response code is issued after the final "." of the DATA 435 command, the response code "554" is used with the meaning 436 "Transaction failed". When the server supports enhanced mail system 437 status codes [RFC3463], response code "X.6.9" [RFC5248] is used, 438 meaning that "UTF8SMTP downgrade failed". 440 3.6. Body Parts and SMTP Extensions 442 There is no ESMTP parameter to assert that a message is an 443 internationalized message. An SMTP server that requires accurate 444 knowledge of whether a message is internationalized is required to 445 parse all message header fields and MIME header fields in the message 446 body. 448 While this specification requires that servers support the 8BITMIME 449 extension [RFC1652] to ensure that servers have adequate handling 450 capability for 8-bit data and to avoid a number of complex encoding 451 problems, the use of internationalized addresses obviously does not 452 require non-ASCII body parts in the MIME message. The UTF8SMTP 453 extension MAY be used with the BODY=8BITMIME parameter if that is 454 appropriate given the body content or, with the BODY=BINARYMIME 455 parameter, if the server advertises BINARYMIME [RFC3030] and that is 456 appropriate. 458 Assuming that the server advertises UTF8SMTP and 8BITMIME, and 459 receives at least one non-ASCII address, with or without ALT-ADDRESS, 460 the precise interpretation of 'No BODY parameter', "BODY=8BITMIME", 461 and "BODY=BINARYMIME" in the MAIL command is: 462 1. If there is no BODY parameter, the header contains UTF-8 463 characters, but all the body parts are in ASCII (possibly as the 464 result of a content-transfer-encoding). 465 2. If a BODY=8BITMIME parameter is present, the header contains 466 UTF-8 characters, and some or all of the body parts contain 8-bit 467 line-oriented data. 468 3. If a BODY=BINARYMIME parameter is present, the header contains 469 UTF-8 characters, and some or all body parts contain binary data 470 without restriction as to line lengths or delimiters. 472 3.7. Additional ESMTP Changes and Clarifications 474 The information carried in the mail transport process involves 475 addresses ("mailboxes") and domain names in various contexts in 476 addition to the MAIL and RCPT commands and extended alternatives to 477 them. In general, the rule is that, when RFC 2821 specifies a 478 mailbox, this specification expects UTF-8 to be used for the entire 479 string; when RFC 2821 specifies a domain name, the name SHOULD be in 480 the form of ACE labels if its raw form is non-ASCII. 482 The following subsections list and discuss all of the relevant cases. 484 3.7.1. The Initial SMTP Exchange 486 When an SMTP connection is opened, the server normally sends a 487 "greeting" response consisting of the 220 response code and some 488 information. The client then sends the EHLO command. Since the 489 client cannot know whether the server supports UTF8SMTP until after 490 it receives the response from EHLO, any domain names that appear in 491 this dialogue, or in responses to EHLO, MUST be in the hostname form, 492 i.e., internationalized ones MUST be in the form of ACE labels. 494 3.7.2. Mail eXchangers 496 Organizations often authorize multiple servers to accept mail 497 addressed to them. For example, the organization may itself operate 498 more than one server, and may also or instead have an agreement with 499 other organizations to accept mail as a backup. Authorized servers 500 are generally listed in MX records as described in RFC 2821. When 501 more than one server accepts mail for the domain-part of a mailbox, 502 it is strongly advised that either all or none of them support the 503 UTF8SMTP extension. Otherwise, surprising downgrades can happen 504 during temporary failures, which users might perceive as a serious 505 reliability issue. 507 3.7.3. Trace Information 509 When an SMTP server receives a message for delivery or further 510 processing, it MUST insert trace ("time stamp" or "Received") 511 information at the beginning of the message content. "Time stamp" or 512 "Received" appears in the form of "Received:" lines. The most 513 important use of Received: lines is for debugging mail faults. When 514 the delivery SMTP server makes the "final delivery" of a message, it 515 inserts a Return-path line at the beginning of the mail data. The 516 primary purpose of the Return-path is to designate the address to 517 which messages indicating non-delivery or other mail system failures 518 are to be sent. For the trace information, this memo updates the 519 time stamp line and the return path line [RFC2821] formally defined 520 as follows: 522 uReturn-path-line = "Return-Path:" FWS uReverse-path 523 ; Replaces Return-path-line in Section 4.4 of RFC 2821 524 ; uReverse-path is defined in Section 3.3 of this document 526 uTime-stamp-line = "Received:" FWS uStamp 527 ; Replaces Time-stamp-line in Section 4.4 of RFC 2821 529 uStamp = From-domain By-domain uOpt-info ";" FWS date-time 530 ; Replaces Stamp in Section 4.4 of RFC 2821 532 uOpt-info = [Via] [With] [ID] [uFor] 533 ; Replaces Opt-info in Section 4.4 of RFC 2821 534 ; The protocol value for With will allow a UTF8SMTP value 536 uFor = "FOR" ( FWS (uPath / uMailbox) ) CFWS 537 ; Replaces For in Section 4.4 of RFC 2821 538 ; uPath and uMailbox are defined in Sections 3.4 and 539 ; 3.3, respectively, of this document 541 Note: The FOR parameter has been changed to match the definition in 542 [RFC2821bis], permitting only one address in the For clause. The 543 group working on that document reached mailing list consensus that 544 the syntax in [RFC2821] that permitted more than one address was 545 simply a mistake. 547 Except in the 'uFor' clause and 'uReverse-path' value where non-ASCII 548 domain names may be used, internationalized domain names in Received 549 fields MUST be transmitted in the form of ACE labels. The protocol 550 value of the WITH clause when this extension is used is one of the 551 UTF8SMTP values specified in the "IANA Considerations" section of 552 this document. 554 3.7.4. UTF-8 Strings in Replies 556 3.7.4.1. MAIL and RCPT Commands 558 If the client issues a RCPT command containing non-ASCII characters, 559 the SMTP server is permitted to use UTF-8 characters in the email 560 address associated with 251 and 551 response codes. 562 If an SMTP client follows this specification and sends any RCPT 563 commands containing non-ASCII addresses, it MUST be able to accept 564 and process 251 or 551 responses containing UTF-8 email addresses. 565 If a given RCPT command does not include a non-ASCII envelope 566 address, the server MUST NOT return a 251 or 551 response containing 567 a non-ASCII mailbox. Instead, it MUST transform such responses into 568 250 or 550 responses that do not contain addresses. 570 3.7.4.2. VRFY and EXPN Commands and the UTF8REPLY Parameter 572 If the VRFY and EXPN commands are transmitted with the optional 573 parameter "UTF8REPLY", it indicates the client can accept UTF-8 574 strings in replies to those commands. This allows the server to use 575 UTF-8 strings in mailbox names and full names that occur in replies 576 without concern that the client might be confused by them. An SMTP 577 client that conforms to this specification MUST accept and correctly 578 process replies from the VRFY and EXPN commands that contain UTF-8 579 strings. However, the SMTP server MUST NOT use UTF-8 strings in 580 replies if the SMTP client does not specifically allow such replies 581 by transmitting this parameter. Most replies do not require that a 582 mailbox name be included in the returned text, and therefore UTF-8 is 583 not needed in them. Some replies, notably those resulting from 584 successful execution of the VRFY and EXPN commands, do include the 585 mailbox, making the provisions of this section important. 587 VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to: 589 "VRFY" SP ( uLocal-part / uMailbox ) [ SP "UTF8REPLY" ] CRLF 590 ; uLocal-part and uMailbox are defined in 591 ; Section 3.3 of this document. 593 "EXPN" SP ( uLocal-part / uMailbox ) [ SP "UTF8REPLY" ] CRLF 594 ; uLocal-part and uMailbox are defined in 595 ; Section 3.3 of this document. 597 The "UTF8REPLY" parameter does not use a value. If the reply to a 598 VERIFY (VRFY) or EXPAND (EXPN) command requires UTF-8, but the SMTP 599 client did not use the "UTF8REPLY" parameter, then the server MUST 600 use either the response code 252 or 550. Response code 252, defined 601 in [RFC2821], means "Cannot VRFY user, but will accept the message 602 and attempt the delivery". Response code 550, also defined in 603 [RFC2821], means "Requested action not taken: mailbox unavailable". 604 When the server supports enhanced mail system status codes [RFC3463], 605 the enhanced response code as specified below is used. Using the 606 "UTF8REPLY" parameter with a VERIFY (VRFY) or EXPAND (EXPN) command 607 enables UTF-8 replies for that command only. 609 If a normal success response (i.e., 250) is returned, the response 610 MAY include the full name of the user and MUST include the mailbox of 611 the user. It MUST be in either of the following forms: 613 User Name 614 ; uMailbox is defined in Section 3.3 of this document. 615 ; User Name can contain non-ASCII characters. 617 uMailbox 618 ; uMailbox is defined in Section 3.3 of this document. 620 If the SMTP reply requires UTF-8 strings, but UTF-8 is not allowed in 621 the reply, and the server supports enhanced mail system status codes 622 [RFC3463], the enhanced response code is either "X.6.8" or "X.6.10" 623 [RFC5248], meaning "A reply containing a UTF-8 string is required to 624 show the mailbox name, but that form of response is not permitted by 625 the client". 627 If the SMTP client does not support the UTF8SMTP extension, but 628 receives a UTF-8 string in a reply, it may not be able to properly 629 report the reply to the user, and some clients might crash. 630 Internationalized messages in replies are only allowed in the 631 commands under the situations described above. Under any other 632 circumstances, UTF-8 text MUST NOT appear in the reply. 634 Although UTF-8 is needed to represent email addresses in responses 635 under the rules specified in this section, this extension does not 636 permit the use of UTF-8 for any other purposes. SMTP servers MUST 637 NOT include non-ASCII characters in replies except in the limited 638 cases specifically permitted in this section. 640 4. IANA Considerations 642 IANA has added a new value "UTF8SMTP" to the SMTP Service Extension 643 subregistry of the Mail Parameters registry, according to the 644 following data: 646 +----------+---------------------------------+-----------+ 647 | Keywords | Description | Reference | 648 +----------+---------------------------------+-----------+ 649 | UTF8SMTP | Internationalized email address | [RFCXXXX] | 650 +----------+---------------------------------+-----------+ 652 This document adds new values to the SMTP Enhanced Status Code 653 subregistry of the Mail Parameters registry, following the guidance 654 in Sections 3.5 and 3.7.4.2 of this document, and being based on 655 [RFC5248]. The registration data is as follows: 657 Code: X.6.7 658 Sample Text: The ALT-ADDRESS is required but not specified 659 Associated basic status code: 553, 550 660 Description: This indicates the reception of a MAIL or RCPT 661 command that required an ALT-ADDRESS parameter 662 but such parameter was not present. 663 Defined: RFC 5336 (Experimental track) 664 Submitter: Jiankang YAO 665 Change controller: IESG. 667 Code: X.6.8 668 Sample Text: UTF-8 string reply is required, 669 but not permitted by the client 670 Associated basic status code: 553, 550 671 Description: This indicates that a reply containing a UTF-8 672 string is required to show the mailbox name, 673 but that form of response is not 674 permitted by the client. 675 Defined: RFC 5336. (Experimental track) 676 Submitter: Jiankang YAO 677 Change controller: IESG. 679 Code: X.6.9 680 Sample Text: UTF8SMTP downgrade failed 681 Associated basic status code: 550 682 Description: This indicates that transaction failed 683 after the final "." of the DATA command. 684 Defined: RFC 5336. (Experimental track) 685 Submitter: Jiankang YAO 686 Change controller: IESG. 688 Code: X.6.10 689 Sample Text: UTF-8 string reply is required, 690 but not permitted by the client 691 Associated basic status code: 252 692 Description: This indicates that a reply containing a UTF-8 693 string is required to show the mailbox name, 694 but that form of response is not 695 permitted by the client. 696 Defined: RFC 5336. (Experimental track) 697 Submitter: Jiankang YAO 698 Change controller: IESG. 700 The "Mail Transmission Types" registry under the Mail Parameters 701 registry is requested to be updated to include the following new 702 entries: 704 +---------------+----------------------------+----------------------+ 705 | WITH protocol | Description | Reference | 706 | types | | | 707 +---------------+----------------------------+----------------------+ 708 | UTF8SMTP | UTF8SMTP with Service | [RFCXXXX] | 709 | | Extensions | | 710 | UTF8SMTPA | UTF8SMTP with SMTP AUTH | [RFC4954] [RFCXXXX] | 711 | UTF8SMTPS | UTF8SMTP with STARTTLS | [RFC3207] [RFCXXXX] | 712 | UTF8SMTPSA | UTF8SMTP with both | [RFC3207] [RFC4954] | 713 | | STARTTLS and SMTP AUTH | [RFCXXXX] | 714 +---------------+----------------------------+----------------------+ 716 5. Security Considerations 718 See the extended security considerations discussion in the framework 719 document [RFC4952]. 721 6. Acknowledgements 723 Much of the text in the initial version of this specification was 724 derived or copied from [Emailaddr] with the permission of the author. 725 Significant comments and suggestions were received from Xiaodong LEE, 726 Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other members of the JET 727 team and were incorporated into the specification. Additional 728 important comments and suggestions, and often specific text, were 729 contributed by many members of the WG and design team. Those 730 contributions include material from John C Klensin, Charles Lindsey, 731 Dave Crocker, Harald Tveit Alvestrand, Marcos Sanz, Chris Newman, 732 Martin Duerst, Edmon Chung, Tony Finch, Kari Hurtta, Randall Gellens, 733 Frank Ellermann, Alexey Melnikov, Pete Resnick, S. Moonesamy, Soobok 734 Lee, Shawn Steele, Alfred Hoenes, Miguel Garcia, Magnus Westerlund, 735 and Lars Eggert. Of course, none of the individuals are necessarily 736 responsible for the combination of ideas represented here. 738 7. Change History 740 [[anchor12: RFC Editor: Please remove this section.]] 742 7.1. draft-yao-eai-rfc5336bis: Version 00 744 Applied errata suggested by Alfred Hoenes. 746 8. References 747 8.1. Normative References 749 [ASCII] American National Standards Institute (formerly United 750 States of America Standards Institute), "USA Code for 751 Information Interchange", ANSI X3.4-1968, 1968. 753 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 754 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 755 RFC 1652, July 1994. 757 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 758 Requirement Levels", BCP 14, RFC 2119, March 1997. 760 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 761 April 2001. 763 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 764 April 2001. 766 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 767 Extension for Delivery Status Notifications (DSNs)", 768 RFC 3461, January 2003. 770 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 771 RFC 3463, January 2003. 773 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 774 for Delivery Status Notifications", RFC 3464, 775 January 2003. 777 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 778 "Internationalizing Domain Names in Applications (IDNA)", 779 RFC 3490, March 2003. 781 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 782 10646", RFC 3629, November 2003. 784 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 785 RFC 4409, April 2006. 787 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for 788 Internationalized Email", RFC 4952, July 2007. 790 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 791 Specifications: ABNF", STD 68, RFC 5234, January 2008. 793 [RFC5248] Hansen , T. and J. Klensin, "A Registry for SMTP Enhanced 794 Mail System Status Codes", RFC 5248, June 2008. 796 [RFC5335] Abel, Y., Ed., "Internationalized Email Headers", 797 RFC 5335, August 2008. 799 [RFC5337] Newman, C. and A. Melnikov, Ed., "Internationalized 800 Delivery Status and Disposition Notifications", RFC 5337, 801 August 2008. 803 8.2. Informative References 805 [Emailaddr] 806 Klensin, J., "Internationalization of Email Addresses", 807 draft-klensin-emailaddr-i18n-03 (work in progress), 808 July 2005. 810 [RFC0974] Partridge, C., "Mail routing and the domain system", 811 RFC 974, January 1986. 813 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 814 October 1996. 816 [RFC2821bis] 817 Klensin, J., "Simple Mail Transfer Protocol", 818 draft-klensin-rfc2821bis-10 (work in progress), 4 2008. 820 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 821 of Large and Binary MIME Messages", RFC 3030, 822 December 2000. 824 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 825 Transport Layer Security", RFC 3207, February 2002. 827 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 828 for Authentication", RFC 4954, July 2007. 830 [RFC5504] YONEYA, Y., Ed. and K. Fujiwara, Ed., "Downgrading 831 mechanism for Internationalized eMail Address", RFC 5504, 832 March 2009. 834 Appendix A. Material Updating RFC 4952 836 RFC 4952, the Overview and Framework document covering this set of 837 extensions for internationalized email, was completed before this 838 specification, which specifies a particular part of the protocol set. 839 This appendix, which is normative, contains material that would have 840 been incorporated into RFC 4952 had it been delayed until the work 841 described in the rest of this specification was completed. This 842 material should be included in any update to RFC 4952. 844 A.1. Conventional Message and Internationalized Message 846 o A conventional message is one that does not use any extension 847 defined in this document or in the UTF-8 header specification 848 [RFC5335], and which is strictly conformant to RFC 2822 [RFC2822]. 849 o An internationalized message is a message utilizing one or more of 850 the extensions defined in this specification or in the UTF-8 851 header specification [RFC5335], so that it is no longer conformant 852 to the RFC 2822 specification of a message. 854 A.2. LMTP 856 LMTP [RFC2033] may be used as the final delivery agent. In such 857 cases, LMTP may be arranged to deliver the mail to the mail store. 858 The mail store may not have UTF8SMTP capability. LMTP needs to be 859 updated to deal with these situations. 861 A.3. SMTP Service Extension for DSNs 863 The existing Draft Standard regarding delivery status notifications 864 (DSNs) [RFC3461] is limited to ASCII text in the machine readable 865 portions of the protocol. "International Delivery and Disposition 866 Notifications" [RFC5337] adds a new address type for international 867 email addresses so an original recipient address with non-ASCII 868 characters can be correctly preserved even after downgrading. If an 869 SMTP server advertises both the UTF8SMTP and the DSN extension, that 870 server MUST implement EAI DSN [RFC5337] including support for the 871 ORCPT parameter. 873 A.4. Implementation Advice 875 In the absence of this extension, SMTP clients and servers are 876 constrained to using only those addresses permitted by RFC 2821. The 877 local parts of those addresses MAY be made up of any ASCII 878 characters, although some of them MUST be quoted as specified there. 879 It is notable in an internationalization context that there is a long 880 history on some systems of using overstruck ASCII characters (a 881 character, a backspace, and another character) within a quoted string 882 to approximate non-ASCII characters. This form of 883 internationalization SHOULD be phased out as this extension becomes 884 widely deployed, but backward-compatibility considerations require 885 that it continue to be supported. 887 A.5. Applicability of SMTP Extension to Additional Uses 889 Among other protocol changes, the SMTP extension allows an optional 890 alternate address to be supplied with the MAIL and RCPT commands. 891 For the purposes of this set of specifications, this alternate 892 address only has meaning when the primary address contains UTF-8 893 characters and the message is downgraded. While it may be tempting 894 to consider the alternate address as a general-purpose second-chance 895 address to be used whenever the primary address is rejected, such 896 behavior is not defined here. This restriction allows for future 897 extensions to be developed which create such a general-purpose 898 second-chance address, although no specific work on such an extension 899 is currently anticipated. Note that any such extension needs to 900 consider the question of what the [RFC0974] sequencing rules mean 901 when different possible servers support different sets of ESMTP 902 options (or, in this case, addresses). The answer to this question 903 may also imply updates to [RFC2821]. 905 Authors' Addresses 907 Jiankang YAO (editor) 908 CNNIC 909 No.4 South 4th Street, Zhongguancun 910 Beijing 912 Phone: +86 10 58813007 913 Email: yaojk@cnnic.cn 915 Wei MAO (editor) 916 CNNIC 917 No.4 South 4th Street, Zhongguancun 918 Beijing 920 Phone: +86 10 58812230 921 Email: maowei_ietf@cnnic.cn