idnits 2.17.1 draft-ietf-eai-rfc5336bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, 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 (June 24, 2010) is 5048 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 643, but not defined == Unused Reference: 'RFC0974' is defined on line 754, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' ** 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) Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 3 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 Obsoletes: RFC5336 CNNIC 5 (if approved) June 24, 2010 6 Updates: RFC2821 and 2822 7 (if approved) 8 Intended status: Standards Track 9 Expires: December 26, 2010 11 SMTP Extension for Internationalized Email Address 12 draft-ietf-eai-rfc5336bis-00.txt 14 Abstract 16 This document specifies an SMTP extension for transport and delivery 17 of email messages with internationalized email addresses or header 18 information. Communication with systems that do not implement this 19 specification is specified in another document. This document 20 updates some syntaxes and rules defined in RFC 2821 and RFC 2822. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on December 26, 2010. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Role of This Specification . . . . . . . . . . . . . . . . 4 70 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 72 3. Mail Transport-Level Protocol . . . . . . . . . . . . . . . . 5 73 3.1. Framework for the Internationalization Extension . . . . . 5 74 3.2. The UTF8SMTPbis Extension . . . . . . . . . . . . . . . . 6 75 3.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 7 76 3.4. UTF8 addresses and Response Codes . . . . . . . . . . . . 9 77 3.5. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 9 78 3.6. Additional ESMTP Changes and Clarifications . . . . . . . 10 79 3.6.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 10 80 3.6.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 10 81 3.6.3. Trace Information . . . . . . . . . . . . . . . . . . 11 82 3.6.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 12 83 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 85 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 86 7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 16 87 7.1. draft-yao-eai-rfc5336bis: Version 00 . . . . . . . . . . . 16 88 7.2. draft-ietf-eai-rfc5336bis: Version 00 . . . . . . . . . . 16 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 91 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 92 Appendix A. Additional Material . . . . . . . . . . . . . . . . . 18 93 A.1. Conventional Message and Internationalized Message . . . . 18 94 A.2. LMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 95 A.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 18 96 A.4. Implementation Advice . . . . . . . . . . . . . . . . . . 19 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 99 1. Introduction 101 An internationalized email address includes two parts, the local part 102 and the domain part. The ways email addresses are used by protocols 103 are different from the ways domain names are used. The most critical 104 difference is that emails are delivered through a chain of clients 105 and servers, while domain names are resolved by name servers looking 106 up those names in their own tables. In addition to this, the Simple 107 Mail Transfer Protocol [RFC2821] provides a negotiation mechanism 108 about service extension with which clients can discover server 109 capabilities and make decisions for further processing. An extended 110 overview of the extension model for internationalized addresses and 111 headers appears in [RFC4952bis], referred to as "the framework 112 document" or just as "Framework" elsewhere in this specification. 113 This document specifies an SMTP extension to permit internationalized 114 email addresses in envelopes, and UNICODE characters (encoded in 115 UTF-8) [RFC3629] in headers. 117 1.1. Role of This Specification 119 The framework document specifies the requirements for, and describes 120 components of, full internationalization of electronic mail. A 121 thorough understanding of the information in that document and in the 122 base Internet email specifications [RFC2821] [RFC2822] is necessary 123 to understand and implement this specification. 125 This document specifies an element of the email internationalization 126 work, specifically the definition of an SMTP extension [RFC2821] for 127 internationalized email address transport delivery. 129 1.2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 The terms "conventional message" and "internationalized message" are 136 defined in an appendix to this specification. The terms "UTF-8 137 string" or "UTF-8 character" are used informally to refer to Unicode 138 characters encoded in UTF-8 [RFC3629]. All other specialized terms 139 used in this specification are defined in the framework document or 140 in the base Internet email specifications [RFC2821] [RFC2822]. In 141 particular, the terms "ASCII address", "internationalized email 142 address", "non-ASCII address", "i18mail address", "UTF8SMTPbis", 143 "message", and "mailing list" are used in this document according to 144 the definitions in the framework document. 146 This specification defines only those Augmented BNF (ABNF) [RFC5234] 147 syntax rules that are different from those of the base email 148 specifications [RFC2821][RFC2822] and, where the earlier rules are 149 upgraded or extended, gives them new names. When the new rule is a 150 small modification to the older one, it is typically given a name 151 starting with "u". Rules that are undefined here may be found in the 152 base email specifications under the same names. 154 2. Overview of Operation 156 This specification describes an optional extension to the email 157 transport mechanism that permits non-ASCII [ASCII] characters in both 158 the envelope and header fields of messages, which are encoded with 159 UTF-8 [RFC3629] characters. The extension is identified with the 160 token "UTF8SMTPbis". In order to provide information that may be 161 needed in downgrading, an optional alternate ASCII address may be 162 needed if an SMTP client attempts to transfer an internationalized 163 message and encounters a server that does not support this extension. 165 The EAI UTF-8 header specification [RFC5335bis] provides the details 166 of how and where non-ASCII characters are permitted in the header 167 fields of messages. The context for this specification is described 168 in the framework document. 170 3. Mail Transport-Level Protocol 172 3.1. Framework for the Internationalization Extension 174 The following service extension is defined: 175 1. The name of the SMTP service extension is "Email Address 176 Internationalization". 177 2. The EHLO keyword value associated with this extension is 178 "UTF8SMTPbis". 179 3. No parameter values are defined for this EHLO keyword value. In 180 order to permit future (although unanticipated) extensions, the 181 EHLO response MUST NOT contain any parameters for that keyword. 182 Clients MUST ignore any parameters; that is, clients MUST behave 183 as if the parameters do not appear. If a server includes 184 UTF8SMTPbis in its EHLO response, it MUST be fully compliant with 185 this version of this specification. 186 4. One optional parameter "UTF8REPLY" is added to the VRFY and EXPN 187 commands. The parameter UTF8REPLY has no value. The parameter 188 indicates that the SMTP client can accept Unicode characters in 189 UTF-8 encoding in replies from the VRFY and EXPN commands. 191 5. No additional SMTP verbs are defined by this extension. 192 6. Servers offering this extension MUST provide support for, and 193 announce, the 8BITMIME extension [RFC1652]. 194 7. The reverse-path and forward-path of the SMTP MAIL and RCPT 195 commands are extended to allow Unicode characters encoded in 196 UTF-8 in mailbox names (addresses). 197 8. The mail message body is extended as specified in [RFC5335bis]. 198 9. The UTF8SMTPbis extension is valid on the submission port 199 [RFC4409]. 201 3.2. The UTF8SMTPbis Extension 203 An SMTP server that announces this extension MUST be prepared to 204 accept a UTF-8 string [RFC3629] in any position in which RFC 2821 205 specifies that a mailbox can appear. That string MUST be parsed only 206 as specified in RFC 2821, i.e., by separating the mailbox into source 207 route, local part, and domain part, using only the characters colon 208 (U+003A), comma (U+002C), and at-sign (U+0040) as specified there. 209 Once isolated by this parsing process, the local part MUST be treated 210 as opaque unless the SMTP server is the final delivery Mail Transfer 211 Agent (MTA). Any domain names to be looked up in the DNS MUST allow 212 for [RFC5890] behavior. When doing lookups, the server MUST either 213 use a Unicode aware DNS library, or do ToAscii() defined in [RFC3490] 214 or [RFC5890]. Any domain names that are to be compared to local 215 strings SHOULD be checked for validity and then MUST be compared as 216 specified in [RFC3490] and [RFC5890]. 218 An SMTP client that receives the UTF8SMTPbis extension keyword in 219 response to the EHLO command MAY transmit mailbox names within SMTP 220 commands as internationalized strings in UTF-8 form. It MAY send a 221 UTF-8 header [RFC5335bis] (which may also include mailbox names in 222 UTF-8). It MAY transmit the domain parts of mailbox names within 223 SMTP commands or the message header as either ACE (ASCII Compatible 224 Encoding) labels (as specified in IDNA [RFC3490]) or UTF-8 strings. 225 All labels in domain parts of mailbox names which are IDNs (either 226 UTF-8 or ACE strings) MUST be valid. If the original client submits 227 a message to a Message Submission Server ("MSA") [RFC4409], it is the 228 responsibility of the MSA that all domain labels are valid; 229 otherwise, it is the original client's responsibility. The presence 230 of the UTF8SMTPbis extension does not change the requirement of RFC 231 2821 that servers relaying mail MUST NOT attempt to parse, evaluate, 232 or transform the local part in any way. 234 If the UTF8SMTPbis SMTP extension is not offered by the Server, the 235 SMTP client MUST NOT transmit an internationalized address and MUST 236 NOT transmit a mail message containing internationalized mail headers 237 as described in [RFC5335bis] at any level within its MIME structure. 238 (For this paragraph, the internationalized domain name in the form of 239 ACE labels as specified in IDNA [RFC3490] and [RFC5890] is not 240 considered as "internationalized".) Instead, if an SMTP client (SMTP 241 sender) attempts to transfer an internationalized message and 242 encounters a server that does not support the extension, it MUST make 243 one of the following three choices: 245 1. If and only if the SMTP client (sender) is a Message Submission 246 Server ("MSA") [RFC4409], it MAY, consistent with the general 247 provisions for changes by such servers, rewrite the envelope, 248 headers, or message material to make them entirely ASCII and 249 consistent with the provisions of RFC 2821 [RFC2821] and RFC 2822 250 [RFC2822]. 251 2. It may either reject the message during the SMTP transaction or 252 accept the message and then generate and transmit a notification 253 of non-deliverability. Such notification MUST be done as 254 specified in RFC 2821 [RFC2821], RFC 3464 [RFC3464], and the EAI 255 delivery status notification (DSN) specification [RFC5337bis]. 256 3. It may find an alternate route to the destination that permits 257 UTF8SMTPbis. That route may be discovered by trying alternate 258 Mail eXchanger (MX) hosts (using preference rules as specified in 259 RFC 2821) or using other means available to the SMTP-sender. 261 If a server advertises UTF8SMTP and the client does not recognize the 262 extension, the client may send a regular message [RFC2821] and 263 [RFC2822]. In this case, the client may continue to use the 264 [RFC3490] or [RFC5890] ToAscii() to encode the domain portion of an 265 address. UTF8SMTP servers MUST recognize and decode the ACE label(s) 266 as appropriate. 268 3.3. Extended Mailbox Address Syntax 270 RFC 2821, Section 4.1.2, defines the syntax of a mailbox entirely in 271 terms of ASCII characters, using the production for a mailbox and 272 those productions on which it depends. 274 The key changes made by this specification are, informally, to 275 o Change the definition of "sub-domain" to permit either the 276 definition above or a UTF-8 string representing a DNS label that 277 is conformant with IDNA [RFC3490]. 278 o Change the definition of "Atom" to permit either the definition 279 above or a UTF-8 string. That string MUST NOT contain any of the 280 ASCII characters (either graphics or controls) that are not 281 permitted in "atext"; it is otherwise unrestricted. 283 According to the description above, the syntax of an 284 internationalized email mailbox name (address) is defined in ABNF 285 [RFC5234] as follows. 287 uMailbox = uLocal-part "@" uDomain 288 ; Replace Mailbox in RFC 2821, Section 4.1.2 290 uLocal-part = uDot-string / uQuoted-string 291 ; MAY be case-sensitive 292 ; Replace Local-part in RFC 2821, Section 4.1.2 294 uDot-string = uAtom *("." uAtom) 295 ; Replace Dot-string in RFC 2821, Section 4.1.2 297 uAtom = 1*ucharacter 298 ; Replace Atom in RFC 2821, Section 4.1.2 300 ucharacter = atext / UTF8-non-ascii 302 atext = 304 uQuoted-string = DQUOTE *uqcontent DQUOTE 305 ; Replace Quoted-string in RFC 2821, Section 4.1.2 307 DQUOTE = 309 uqcontent = qcontent / UTF8-non-ascii 311 qcontent = 313 uDomain = (sub-udomain 1*("." sub-udomain)) / address-literal 314 ; Replace Domain in RFC 2821, Section 4.1.2 316 address-literal = 318 sub-udomain = uLet-dig [uLdh-str] 319 ; Replace sub-domain in RFC 2821, Section 4.1.2 321 uLet-dig = Let-dig / UTF8-non-ascii 323 Let-dig = 325 uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-non-ascii) uLet-dig 326 ; Replace Ldh-str in RFC 2821, Section 4.1.3 328 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 330 UTF8-2 = 332 UTF8-3 = 334 UTF8-4 = 336 The value of "uDomain" SHOULD be verified by applying the tests 337 specified as part of IDNA [RFC3490]. If that verification fails, the 338 email address with that uDomain MUST NOT be regarded as a valid email 339 address. 341 3.4. UTF8 addresses and Response Codes 343 An "internationalized message" as defined in the appendix of this 344 specification MUST NOT be sent to an SMTP server that does not 345 support UTF8SMTPbis. Such a message should be rejected by a server 346 if it lacks the support of UTF8SMTPbis. 348 The three-digit reply codes used in this section are consistent with 349 their meanings as defined in RFC 2821. 351 When messages are rejected because the RCPT command requires an ASCII 352 address, the response code 553 is used with the meaning "mailbox name 353 not allowed". When messages are rejected for other reasons, such as 354 the MAIL command requiring an ASCII address, the response code 550 is 355 used with the meaning "mailbox unavailable". When the server 356 supports enhanced mail system status codes [RFC3463], response code 357 "X.6.7" [RFC5248] is used, meaning that "UTF-8 addresses not 358 permitted for that sender/recipient". 360 If the response code is issued after the final "." of the DATA 361 command, the response code "554" is used with the meaning 362 "Transaction failed". When the server supports enhanced mail system 363 status codes [RFC3463], response code "X.6.9" [RFC5248] is used, 364 meaning that "UTF-8 header message can't be transferred to one or 365 more recipient so the message must be bounced". 367 3.5. Body Parts and SMTP Extensions 369 There is no ESMTP parameter to assert that a message is an 370 internationalized message. An SMTP server that requires accurate 371 knowledge of whether a message is internationalized is required to 372 parse all message header fields and MIME header fields in the message 373 body. 375 While this specification requires that servers support the 8BITMIME 376 extension [RFC1652] to ensure that servers have adequate handling 377 capability for 8-bit data and to avoid a number of complex encoding 378 problems, the use of internationalized addresses obviously does not 379 require non-ASCII body parts in the MIME message. The UTF8SMTPbis 380 extension MAY be used with the BODY=8BITMIME parameter if that is 381 appropriate given the body content or, with the BODY=BINARYMIME 382 parameter, if the server advertises BINARYMIME [RFC3030] and that is 383 appropriate. 385 Assuming that the server advertises UTF8SMTPbis and 8BITMIME, and 386 receives at least one non-ASCII address, the precise interpretation 387 of 'No BODY parameter', "BODY=8BITMIME", and "BODY=BINARYMIME" in the 388 MAIL command is: 389 1. If there is no BODY parameter, the header contains UTF-8 390 characters, but all the body parts are in ASCII (possibly as the 391 result of a content-transfer-encoding). 392 2. If a BODY=8BITMIME parameter is present, the header contains 393 UTF-8 characters, and some or all of the body parts contain 8-bit 394 line-oriented data. 395 3. If a BODY=BINARYMIME parameter is present, the header contains 396 UTF-8 characters, and some or all body parts contain binary data 397 without restriction as to line lengths or delimiters. 399 3.6. Additional ESMTP Changes and Clarifications 401 The information carried in the mail transport process involves 402 addresses ("mailboxes") and domain names in various contexts in 403 addition to the MAIL and RCPT commands and extended alternatives to 404 them. In general, the rule is that, when RFC 2821 specifies a 405 mailbox, this specification expects UTF-8 to be used for the entire 406 string; when RFC 2821 specifies a domain name, the name SHOULD be in 407 the form of ACE labels if its raw form is non-ASCII. 409 The following subsections list and discuss all of the relevant cases. 411 3.6.1. The Initial SMTP Exchange 413 When an SMTP connection is opened, the server normally sends a 414 "greeting" response consisting of the 220 response code and some 415 information. The client then sends the EHLO command. Since the 416 client cannot know whether the server supports UTF8SMTPbis until 417 after it receives the response from EHLO, any domain names that 418 appear in this dialogue, or in responses to EHLO, MUST be in the 419 hostname form, i.e., internationalized ones MUST be in the form of 420 ACE labels. 422 3.6.2. Mail eXchangers 424 Organizations often authorize multiple servers to accept mail 425 addressed to them. For example, the organization may itself operate 426 more than one server, and may also or instead have an agreement with 427 other organizations to accept mail as a backup. Authorized servers 428 are generally listed in MX records as described in RFC 2821. When 429 more than one server accepts mail for the domain-part of a mailbox, 430 it is strongly advised that either all or none of them support the 431 UTF8SMTPbis extension. Otherwise, surprising downgrades can happen 432 during temporary failures, which users might perceive as a serious 433 reliability issue. 435 3.6.3. Trace Information 437 When an SMTP server receives a message for delivery or further 438 processing, it MUST insert trace ("time stamp" or "Received") 439 information at the beginning of the message content. "Time stamp" or 440 "Received" appears in the form of "Received:" lines. The most 441 important use of Received: lines is for debugging mail faults. When 442 the delivery SMTP server makes the "final delivery" of a message, it 443 inserts a Return-path line at the beginning of the mail data. The 444 primary purpose of the Return-path is to designate the address to 445 which messages indicating non-delivery or other mail system failures 446 are to be sent. For the trace information, this memo updates the 447 time stamp line and the return path line [RFC2821] formally defined 448 as follows: 450 uReturn-path-line = "Return-Path:" FWS uReverse-path 451 ; Replaces Return-path-line in Section 4.4 of RFC 2821 452 ; uReverse-path is defined in Section 3.3 of this document 454 uTime-stamp-line = "Received:" FWS uStamp 455 ; Replaces Time-stamp-line in Section 4.4 of RFC 2821 457 uStamp = From-domain By-domain uOpt-info ";" FWS date-time 458 ; Replaces Stamp in Section 4.4 of RFC 2821 460 uOpt-info = [Via] [With] [ID] [uFor] 461 ; Replaces Opt-info in Section 4.4 of RFC 2821 462 ; The protocol value for With will allow a UTF8SMTPbis value 464 uFor = "FOR" ( FWS (uPath / uMailbox) ) CFWS 465 ; Replaces For in Section 4.4 of RFC 2821 466 ; uPath and uMailbox are defined in Sections 3.4 and 467 ; 3.3, respectively, of this document 469 Note: The FOR parameter has been changed to match the definition in 470 [RFC5321], permitting only one address in the For clause. The group 471 working on that document reached mailing list consensus that the 472 syntax in [RFC2821] that permitted more than one address was simply a 473 mistake. 475 Except in the 'uFor' clause and 'uReverse-path' value where non-ASCII 476 domain names may be used, internationalized domain names in Received 477 fields MUST be transmitted in the form of ACE labels. The protocol 478 value of the WITH clause when this extension is used is one of the 479 UTF8SMTPbis values specified in the "IANA Considerations" section of 480 this document. 482 3.6.4. UTF-8 Strings in Replies 484 3.6.4.1. MAIL and RCPT Commands 486 If the client issues a RCPT command containing non-ASCII characters, 487 the SMTP server is permitted to use UTF-8 characters in the email 488 address associated with 251 and 551 response codes. 490 If an SMTP client follows this specification and sends any RCPT 491 commands containing non-ASCII addresses, it MUST be able to accept 492 and process 251 or 551 responses containing UTF-8 email addresses. 493 If a given RCPT command does not include a non-ASCII envelope 494 address, the server MUST NOT return a 251 or 551 response containing 495 a non-ASCII mailbox. Instead, it MUST transform such responses into 496 250 or 550 responses that do not contain addresses. 498 3.6.4.2. VRFY and EXPN Commands and the UTF8REPLY Parameter 500 If the VRFY and EXPN commands are transmitted with the optional 501 parameter "UTF8REPLY", it indicates the client can accept UTF-8 502 strings in replies to those commands. This allows the server to use 503 UTF-8 strings in mailbox names and full names that occur in replies 504 without concern that the client might be confused by them. An SMTP 505 client that conforms to this specification MUST accept and correctly 506 process replies from the VRFY and EXPN commands that contain UTF-8 507 strings. However, the SMTP server MUST NOT use UTF-8 strings in 508 replies if the SMTP client does not specifically allow such replies 509 by transmitting this parameter. Most replies do not require that a 510 mailbox name be included in the returned text, and therefore UTF-8 is 511 not needed in them. Some replies, notably those resulting from 512 successful execution of the VRFY and EXPN commands, do include the 513 mailbox, making the provisions of this section important. 515 VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to: 517 "VRFY" SP ( uLocal-part / uMailbox ) [ SP "UTF8REPLY" ] CRLF 518 ; uLocal-part and uMailbox are defined in 519 ; Section 3.3 of this document. 521 "EXPN" SP ( uLocal-part / uMailbox ) [ SP "UTF8REPLY" ] CRLF 522 ; uLocal-part and uMailbox are defined in 523 ; Section 3.3 of this document. 525 The "UTF8REPLY" parameter does not use a value. If the reply to a 526 VERIFY (VRFY) or EXPAND (EXPN) command requires UTF-8, but the SMTP 527 client did not use the "UTF8REPLY" parameter, then the server MUST 528 use either the response code 252 or 550. Response code 252, defined 529 in [RFC2821], means "Cannot VRFY user, but will accept the message 530 and attempt the delivery". Response code 550, also defined in 531 [RFC2821], means "Requested action not taken: mailbox unavailable". 532 When the server supports enhanced mail system status codes [RFC3463], 533 the enhanced response code as specified below is used. Using the 534 "UTF8REPLY" parameter with a VERIFY (VRFY) or EXPAND (EXPN) command 535 enables UTF-8 replies for that command only. 537 If a normal success response (i.e., 250) is returned, the response 538 MAY include the full name of the user and MUST include the mailbox of 539 the user. It MUST be in either of the following forms: 541 User Name 542 ; uMailbox is defined in Section 3.3 of this document. 543 ; User Name can contain non-ASCII characters. 545 uMailbox 546 ; uMailbox is defined in Section 3.3 of this document. 548 If the SMTP reply requires UTF-8 strings, but UTF-8 is not allowed in 549 the reply, and the server supports enhanced mail system status codes 550 [RFC3463], the enhanced response code is either "X.6.8" or "X.6.10" 551 [RFC5248], meaning "A reply containing a UTF-8 string is required to 552 show the mailbox name, but that form of response is not permitted by 553 the client". 555 If the SMTP client does not support the UTF8SMTPbis extension, but 556 receives a UTF-8 string in a reply, it may not be able to properly 557 report the reply to the user, and some clients might crash. 558 Internationalized messages in replies are only allowed in the 559 commands under the situations described above. Under any other 560 circumstances, UTF-8 text MUST NOT appear in the reply. 562 Although UTF-8 is needed to represent email addresses in responses 563 under the rules specified in this section, this extension does not 564 permit the use of UTF-8 for any other purposes. SMTP servers MUST 565 NOT include non-ASCII characters in replies except in the limited 566 cases specifically permitted in this section. 568 4. IANA Considerations 570 IANA has added a new value "UTF8SMTPbis" to the SMTP Service 571 Extension subregistry of the Mail Parameters registry, according to 572 the following data: 574 +-------------+---------------------------------+-----------+ 575 | Keywords | Description | Reference | 576 +-------------+---------------------------------+-----------+ 577 | UTF8SMTPbis | Internationalized email address | [RFCXXXX] | 578 +-------------+---------------------------------+-----------+ 580 This document updates the values to the SMTP Enhanced Status Code 581 subregistry of the Mail Parameters registry, following the guidance 582 in Sections 3.4 and 3.6.4.2 of this document, and being based on 583 [RFC5248]. The registration data is as follows: 585 Code: X.6.7 586 Sample Text: UTF-8 addresses not permitted 587 for that sender/recipient 588 Associated basic status code: 553, 550 589 Description: This indicates the reception of a MAIL or RCPT 590 command that rUTF-8 addresses are not permitted 591 Defined: RFC XXXX (Standard track) 592 Submitter: Jiankang YAO 593 Change controller: IESG. 595 Code: X.6.8 596 Sample Text: UTF-8 string reply is required, 597 but not permitted by the client 598 Associated basic status code: 553, 550 599 Description: This indicates that a reply containing a UTF-8 600 string is required to show the mailbox name, 601 but that form of response is not 602 permitted by the client. 603 Defined: RFC XXXX (Standard track) 604 Submitter: Jiankang YAO 605 Change controller: IESG. 607 Code: X.6.9 608 Sample Text: UTF-8 header message can't be transferred 609 to one or more recipient so the message 610 must be bounced 611 Associated basic status code: 550 612 Description: This indicates that transaction failed 613 after the final "." of the DATA command. 614 Defined: RFC XXXX (Standard track) 615 Submitter: Jiankang YAO 616 Change controller: IESG. 618 Code: X.6.10 619 Sample Text: UTF-8 string reply is required, 620 but not permitted by the client 621 Associated basic status code: 252 622 Description: This indicates that a reply containing a UTF-8 623 string is required to show the mailbox name, 624 but that form of response is not 625 permitted by the client. 626 Defined: RFC XXXX (Standard track) 627 Submitter: Jiankang YAO 628 Change controller: IESG. 630 The "Mail Transmission Types" registry under the Mail Parameters 631 registry is requested to be updated to include the following new 632 entries: 634 +---------------+-----------------------------+---------------------+ 635 | WITH protocol | Description | Reference | 636 | types | | | 637 +---------------+-----------------------------+---------------------+ 638 | UTF8SMTPbis | UTF8SMTPbis with Service | [RFCXXXX] | 639 | | Extensions | | 640 | UTF8SMTPbisA | UTF8SMTPbis with SMTP AUTH | [RFC4954] [RFCXXXX] | 641 | UTF8SMTPbisS | UTF8SMTPbis with STARTTLS | [RFC3207] [RFCXXXX] | 642 | UTF8SMTPbisSA | UTF8SMTPbis with both | [RFC3207] [RFC4954] | 643 | | STARTTLS and SMTP AUTH | [RFCXXXX] | 644 +---------------+-----------------------------+---------------------+ 646 5. Security Considerations 648 See the extended security considerations discussion in the framework 649 document [RFC4952bis]. 651 6. Acknowledgements 653 Much of the text in the initial version of this specification was 654 derived or copied from [Emailaddr] with the permission of the author. 655 Significant comments and suggestions were received from Xiaodong LEE, 656 Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other members of the JET 657 team and were incorporated into the specification. Additional 658 important comments and suggestions, and often specific text, were 659 contributed by many members of the WG and design team. Those 660 contributions include material from John C Klensin, Charles Lindsey, 661 Dave Crocker, Harald Tveit Alvestrand, Marcos Sanz, Chris Newman, 662 Martin Duerst, Edmon Chung, Tony Finch, Kari Hurtta, Randall Gellens, 663 Frank Ellermann, Alexey Melnikov, Pete Resnick, S. Moonesamy, Soobok 664 Lee, Shawn Steele, Alfred Hoenes, Miguel Garcia, Magnus Westerlund, 665 and Lars Eggert. Of course, none of the individuals are necessarily 666 responsible for the combination of ideas represented here. 668 7. Change History 670 [[anchor11: RFC Editor: Please remove this section.]] 672 7.1. draft-yao-eai-rfc5336bis: Version 00 674 Applied errata suggested by Alfred Hoenes. 676 7.2. draft-ietf-eai-rfc5336bis: Version 00 678 Applied the changes suggested by the EAI new charter. 680 8. References 682 8.1. Normative References 684 [ASCII] American National Standards Institute (formerly United 685 States of America Standards Institute), "USA Code for 686 Information Interchange", ANSI X3.4-1968, 1968. 688 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 689 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 690 RFC 1652, July 1994. 692 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 693 Requirement Levels", BCP 14, RFC 2119, March 1997. 695 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 696 April 2001. 698 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 699 April 2001. 701 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 702 Extension for Delivery Status Notifications (DSNs)", 703 RFC 3461, January 2003. 705 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 706 RFC 3463, January 2003. 708 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 709 for Delivery Status Notifications", RFC 3464, 710 January 2003. 712 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 713 "Internationalizing Domain Names in Applications (IDNA)", 714 RFC 3490, March 2003. 716 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 717 10646", RFC 3629, November 2003. 719 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 720 RFC 4409, April 2006. 722 [RFC4952bis] 723 Klensin, J. and Y. Ko, "Overview and Framework for 724 Internationalized Email", RFC 4952, July 2007. 726 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 727 Specifications: ABNF", STD 68, RFC 5234, January 2008. 729 [RFC5248] Hansen , T. and J. Klensin, "A Registry for SMTP Enhanced 730 Mail System Status Codes", RFC 5248, June 2008. 732 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 733 October 2008. 735 [RFC5335bis] 736 Abel, Y., Ed., "Internationalized Email Headers", 737 RFC 5335, August 2008. 739 [RFC5337bis] 740 Newman, C. and A. Melnikov, Ed., "Internationalized 741 Delivery Status and Disposition Notifications", RFC 5337, 742 August 2008. 744 [RFC5890] Klensin, J., "Internationalizing Domain Names in 745 Applications (IDNA)", RFC 5890, June 2010. 747 8.2. Informative References 749 [Emailaddr] 750 Klensin, J., "Internationalization of Email Addresses", 751 draft-klensin-emailaddr-i18n-03 (work in progress), 752 July 2005. 754 [RFC0974] Partridge, C., "Mail routing and the domain system", 755 RFC 974, January 1986. 757 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 758 October 1996. 760 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 761 of Large and Binary MIME Messages", RFC 3030, 762 December 2000. 764 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 765 Transport Layer Security", RFC 3207, February 2002. 767 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 768 for Authentication", RFC 4954, July 2007. 770 Appendix A. Additional Material 772 A.1. Conventional Message and Internationalized Message 774 o A conventional message is one that does not use any extension 775 defined in this document or in the UTF-8 header specification 776 [RFC5335bis], and which is strictly conformant to RFC 2822 777 [RFC2822]. 778 o An internationalized message is a message utilizing one or more of 779 the extensions defined in this specification or in the UTF-8 780 header specification [RFC5335bis], so that it is no longer 781 conformant to the RFC 2822 specification of a message. 783 A.2. LMTP 785 LMTP [RFC2033] may be used as the final delivery agent. In such 786 cases, LMTP may be arranged to deliver the mail to the mail store. 787 The mail store may not have UTF8SMTPbis capability. LMTP needs to be 788 updated to deal with these situations. 790 A.3. SMTP Service Extension for DSNs 792 The existing Draft Standard regarding delivery status notifications 793 (DSNs) [RFC3461] is limited to ASCII text in the machine readable 794 portions of the protocol. "International Delivery and Disposition 795 Notifications" [RFC5337bis] adds a new address type for international 796 email addresses so an original recipient address with non-ASCII 797 characters can be correctly preserved even after downgrading. If an 798 SMTP server advertises both the UTF8SMTPbis and the DSN extension, 799 that server MUST implement EAI DSN [RFC5337bis] including support for 800 the ORCPT parameter. 802 A.4. Implementation Advice 804 In the absence of this extension, SMTP clients and servers are 805 constrained to using only those addresses permitted by RFC 2821. The 806 local parts of those addresses MAY be made up of any ASCII 807 characters, although some of them MUST be quoted as specified there. 808 It is notable in an internationalization context that there is a long 809 history on some systems of using overstruck ASCII characters (a 810 character, a backspace, and another character) within a quoted string 811 to approximate non-ASCII characters. This form of 812 internationalization SHOULD be phased out as this extension becomes 813 widely deployed, but backward-compatibility considerations require 814 that it continue to be supported. 816 Authors' Addresses 818 Jiankang YAO (editor) 819 CNNIC 820 No.4 South 4th Street, Zhongguancun 821 Beijing 823 Phone: +86 10 58813007 824 Email: yaojk@cnnic.cn 826 Wei MAO (editor) 827 CNNIC 828 No.4 South 4th Street, Zhongguancun 829 Beijing 831 Phone: +86 10 58812230 832 Email: maowei_ietf@cnnic.cn