idnits 2.17.1 draft-ietf-eai-rfc5336bis-05.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 (December 2, 2010) is 4892 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 644, but not defined == Unused Reference: 'RFC3030' is defined on line 787, but no explicit reference was found in the text == Unused Reference: 'RFC5336' is defined on line 797, 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) ** Downref: Normative reference to an Informational RFC: RFC 2033 ** 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 5336 (Obsoleted by RFC 6531) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Yao 3 Internet-Draft W. Mao 4 Obsoletes: RFC5336 CNNIC 5 (if approved) December 2, 2010 6 Updates: RFC5321 and 5322 7 (if approved) 8 Intended status: Standards Track 9 Expires: June 5, 2011 11 SMTP Extension for Internationalized Email Address 12 draft-ietf-eai-rfc5336bis-05.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. This document updates some syntax rules defined in RFC 19 5321 and RFC 5322. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on June 5, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 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 UTF8SMTPbis Extension . . . . . . . . . . . . . . . . 5 74 3.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 7 75 3.4. UTF8 addresses and Response Codes . . . . . . . . . . . . 9 76 3.5. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 9 77 3.6. Additional ESMTP Changes and Clarifications . . . . . . . 10 78 3.6.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 10 79 3.6.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 10 80 3.6.3. Trace Information . . . . . . . . . . . . . . . . . . 11 81 3.6.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 12 82 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 84 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 85 7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 16 86 7.1. draft-yao-eai-rfc5336bis: Version 00 . . . . . . . . . . . 16 87 7.2. draft-ietf-eai-rfc5336bis: Version 00 . . . . . . . . . . 16 88 7.3. draft-ietf-eai-rfc5336bis: Version 01 . . . . . . . . . . 16 89 7.4. draft-ietf-eai-rfc5336bis: Version 02 . . . . . . . . . . 16 90 7.5. draft-ietf-eai-rfc5336bis: Version 03 . . . . . . . . . . 16 91 7.6. draft-ietf-eai-rfc5336bis: Version 04 . . . . . . . . . . 16 92 7.7. draft-ietf-eai-rfc5336bis: Version 05 . . . . . . . . . . 16 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 95 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 99 1. Introduction 101 The Simple Mail Transfer Protocol [RFC5321] provides a negotiation 102 mechanism about service extension with which clients can discover 103 server capabilities and make decisions for further processing. This 104 document use this mechanism to support an internationalized email 105 address. An extended overview of the extension model for 106 internationalized addresses and headers appears in [RFC4952bis], 107 referred to as "the framework document" or just as "framework" 108 elsewhere in this specification. This document specifies an SMTP 109 extension to permit internationalized email addresses in envelopes, 110 and UNICODE characters (encoded in UTF-8) [RFC3629] in headers. 112 1.1. Role of This Specification 114 The framework document specifies the requirements for, and describes 115 components of, full internationalization of the electronic mail. A 116 thorough understanding of the information in that document and in the 117 base Internet email specifications [RFC5321] [RFC5322] is necessary 118 to understand and implement this specification. 120 This document specifies an element of the email internationalization 121 work, specifically the definition of an SMTP extension for 122 internationalized email address transport delivery. 124 1.2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 The terms "UTF-8 string" or "UTF-8 character" are used informally to 131 refer to Unicode characters encoded in UTF-8. All other specialized 132 terms used in this specification are defined in the framework 133 document or in the base Internet email specifications. In 134 particular, the terms "ASCII address", "internationalized email 135 address", "non-ASCII address", "i18mail address", 136 "UTF8SMTPbis","conventional message", "internationalized message", 137 "message", and "mailing list" are used in this document according to 138 the definitions in the framework document. 140 This specification defines only those Augmented BNF (ABNF) [RFC5234] 141 syntax rules that are different from those of the base email 142 specifications and, where the earlier rules are upgraded or extended, 143 gives them new names. When the new rule is a small modification to 144 the older one, it is typically given a name starting with "u". Rules 145 that are undefined here may be found in the base email specifications 146 under the same names. 148 2. Overview of Operation 150 This specification describes an optional extension to the email 151 transport mechanism that permits non-ASCII [ASCII] characters in both 152 the envelope and header fields of messages, which are encoded with 153 UTF-8 characters. The extension is identified with the token 154 "UTF8SMTPbis". 156 The EAI UTF-8 header specification [RFC5335bis] provides the details 157 of how and where non-ASCII characters are permitted in the header 158 fields of messages. The context for this specification is described 159 in the framework document. 161 3. Mail Transport-Level Protocol 163 3.1. Framework for the Internationalization Extension 165 The following service extension is defined: 166 1. The name of the SMTP service extension is "Email Address 167 Internationalization". 168 2. The EHLO keyword value associated with this extension is 169 "UTF8SMTPbis". 170 3. No parameter values are defined for this EHLO keyword value. In 171 order to permit future (although unanticipated) extensions, the 172 EHLO response MUST NOT contain any parameters for that keyword. 173 Clients MUST reject any parameters; that is, clients MUST behave 174 as if the parameters do not appear. If a server includes 175 UTF8SMTPbis in its EHLO response, it MUST be fully compliant with 176 this version of this specification. 177 4. One optional parameter "UTF8REPLY" is added to the VRFY and EXPN 178 commands. The parameter UTF8REPLY has no value. The parameter 179 indicates that the SMTP client can accept Unicode characters in 180 UTF-8 encoding in replies from the VRFY and EXPN commands. 181 5. No additional SMTP verbs are defined by this extension. 182 6. Servers offering this extension MUST provide support for, and 183 announce, the 8BITMIME extension [RFC1652]. 184 7. The reverse-path and forward-path of the SMTP MAIL and RCPT 185 commands are extended to allow Unicode characters encoded in 186 UTF-8 in mailbox names (addresses). 187 8. The mail message body is extended as specified in [RFC5335bis]. 188 9. The UTF8SMTPbis extension is valid on the submission port 189 [RFC4409], and can be used with LMTP [RFC2033]. 191 3.2. The UTF8SMTPbis Extension 193 An SMTP server that announces this extension MUST be prepared to 194 accept a UTF-8 string [RFC3629] in any position in which RFC 5321 195 specifies that a mailbox can appear. That string MUST be parsed only 196 as specified in [RFC5321], i.e., by separating the mailbox into 197 source route, local part, and domain part, using only the characters 198 colon (U+003A), comma (U+002C), and at-sign (U+0040) as specified 199 there. Once isolated by this parsing process, the local part MUST be 200 treated as opaque unless the SMTP server is the final delivery Mail 201 Transfer Agent (MTA). Any domain names to be looked up in the DNS 202 MUST allow for [RFC5890] behavior. When doing lookups, the server 203 MUST either use a Unicode aware DNS library, or transform it to 204 A-label defined in [RFC5890]. Any domain names that are to be 205 compared to local strings SHOULD be checked for validity and then 206 MUST be compared as specified in section 3 of [RFC5891]. 208 An SMTP client that receives the UTF8SMTPbis extension keyword in 209 response to the EHLO command MAY transmit mailbox names within SMTP 210 commands as internationalized strings in UTF-8 form. It MAY send a 211 UTF-8 header [RFC5335bis] (which may also include mailbox names in 212 UTF-8). It MAY transmit the domain parts of mailbox names within 213 SMTP commands or the message header as A-labels or U-labels 214 [RFC5890]. All labels in domain parts of mailbox names which are IDN 215 forms of A-labels or U-labels MUST be valid. When a Mail User 216 Agent(MUA) submits a message to a Message Submission Server 217 ("MSA")[RFC4409], it is the responsibility of the MSA to ensure that 218 all domain labels are valid. The presence of the UTF8SMTPbis 219 extension does not change the requirement of RFC 5321 that servers 220 relaying mail MUST NOT attempt to parse, evaluate, or transform the 221 local part in any way. 223 If the UTF8SMTPbis SMTP extension is not offered by the server, the 224 SMTP client MUST NOT transmit an internationalized address and MUST 225 NOT transmit a mail message containing internationalized mail headers 226 as described in [RFC5335bis] at any level within its MIME structure 227 [RFC2045] and [RFC2047]. (For this paragraph, the internationalized 228 domain name in the form of A-labels as specified in IDNA definitions 229 [RFC5890] is not considered to be "internationalized".) Instead, if 230 an SMTP client (SMTP sender) attempts to transfer an 231 internationalized message and encounters a server that does not 232 support the extension, it MUST make one of the following three 233 choices: 235 1. If and only if the SMTP client (sender) is a Message Submission 236 Server ("MSA") [RFC4409], it MAY, consistent with the general 237 provisions for changes by such servers, rewrite the envelope, 238 headers, or message material to make them entirely ASCII and 239 consistent with the provisions of RFC 5321 [RFC5321] and RFC 5322 240 [RFC5322]. 242 2. It may either reject the message during the SMTP transaction or 243 accept the message and then generate and transmit a notification 244 of non-deliverability. Such notification MUST be done as 245 specified in RFC 5321 [RFC5321], RFC 3464 [RFC3464], and the EAI 246 delivery status notification (DSN) specification [RFC5337bis]. 247 3. It may find an alternate route to the destination that permits 248 UTF8SMTPbis. That route may be discovered by trying alternate 249 Mail eXchanger (MX) hosts (using preference rules as specified in 250 RFC 5321) or using other means available to the SMTP-sender. 252 This document applies only when an UTF8SMTPbis-aware client is trying 253 to send an internationalized message to an UTF8SMTPbis-aware server. 254 For all other cases, and for addresses and messages that do not 255 require an UTF8SMTPbis extension, SMTP clients and servers are 256 expected to behave exactly as specified in [RFC5321]. 258 A UTF8SMTPbis aware MUA/MSA sending to a legacy SMTP server [RFC5321] 259 and [RFC5322] MAY convert an ASCII@non-ASCII address into the format 260 of ASCII@A-label [RFC5890] if the email address is in the format of 261 ASCII@non-ASCII. 263 3.3. Extended Mailbox Address Syntax 265 RFC 5321, Section 4.1.2, defines the syntax of a mailbox entirely in 266 terms of ASCII characters, using the production for a mailbox and 267 those productions on which it depends. 269 The key changes made by this specification are, informally, to 270 o Change the definition of "Domain" to permit either the definition 271 above or a UTF-8 string representing a DNS label that is 272 conformant with IDNA definitions [RFC5890]. 273 o Change the definition of "Local-part" to permit either the 274 definition above or a UTF-8 string. That string MUST NOT contain 275 any of the ASCII characters (either graphics or controls) that are 276 not permitted in "atext"; it is otherwise unrestricted. 278 According to the description above, the syntax of an 279 internationalized email mailbox name (address) is defined in ABNF 280 [RFC5234] as follows. 282 uMailbox = uLocal-part "@" ( uDomain / address-literal ) 283 ; Replace Mailbox in RFC 5321, Section 4.1.2 285 address-literal = 287 uLocal-part = uDot-string / uQuoted-string 288 ; MAY be case-sensitive 289 ; Replace Local-part in RFC 5321, Section 4.1.2 291 uDot-string = uAtom *("." uAtom) 292 ; Replace Dot-string in RFC 5321, Section 4.1.2 294 uAtom = 1*ucharacter 295 ; Replace Atom in RFC 5321, Section 4.1.2 297 ucharacter = atext / UTF8-non-ascii 299 atext = 301 uQuoted-string = DQUOTE *uqcontent DQUOTE 302 ; Replace Quoted-string in RFC 5321, Section 4.1.2 304 DQUOTE = 306 uqcontent = qcontent / UTF8-non-ascii 308 qcontent = 310 uDomain = sub-udomain *("." sub-udomain) 311 ; Replace Domain in RFC 5321, Section 4.1.2 313 sub-udomain = uLet-dig [uLdh-str] 314 ; Replace sub-domain in RFC 5321, Section 4.1.2 316 uLet-dig = Let-dig / UTF8-non-ascii 318 Let-dig = 320 uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-non-ascii) uLet-dig 321 ; Replace Ldh-str in RFC 5321, Section 4.1.2 323 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 325 UTF8-2 = 327 UTF8-3 = 329 UTF8-4 = 331 The value of "uDomain" SHOULD be verified by IDNA definitions 332 [RFC5890]. If that verification fails, the email address with that 333 uDomain MUST NOT be regarded as a valid email address. 335 3.4. UTF8 addresses and Response Codes 337 An internationalized message MUST NOT be sent to an SMTP server that 338 does not support UTF8SMTPbis. Such a message should be rejected by a 339 server if it lacks the support of UTF8SMTPbis. 341 The three-digit reply codes used in this section are consistent with 342 their meanings as defined in RFC 5321. 344 When messages are rejected because the RCPT command requires an ASCII 345 address, the response code 553 is used with the meaning "mailbox name 346 not allowed". When messages are rejected for other reasons, such as 347 the MAIL command requiring an ASCII address, the response code 550 is 348 used with the meaning "mailbox unavailable". When the server 349 supports enhanced mail system status codes [RFC3463], response code 350 "X.6.7" [RFC5248] is used, meaning that "UTF-8 addresses not 351 permitted for that sender/recipient". 353 If the response code is issued after the final "." of the DATA 354 command, the response code "554" is used with the meaning 355 "Transaction failed". When the server supports enhanced mail system 356 status codes [RFC3463], response code "X.6.9" [RFC5248] is used, 357 meaning that "UTF-8 header message can not be transferred to one or 358 more recipient so the message must be rejected". 360 3.5. Body Parts and SMTP Extensions 362 There is no ESMTP parameter to assert that a message is an 363 internationalized message. An SMTP server that requires accurate 364 knowledge of whether a message is internationalized is required to 365 parse all message header fields and MIME header fields [RFC2045] and 366 [RFC2047] in the message body. 368 While this specification requires that servers support the 8BITMIME 369 extension [RFC1652] to ensure that servers have adequate handling 370 capability for 8-bit data and to avoid a number of complex encoding 371 problems, the use of internationalized addresses obviously does not 372 require non-ASCII body parts in the MIME message [RFC2045] and 373 [RFC2047]. The UTF8SMTPbis extension MAY be used with the 374 BODY=8BITMIME parameter if that is appropriate given the body content 375 or, with the BODY=BINARYMIME parameter, if the server advertises 376 BINARYMIME [RFC3030] and that is appropriate. 378 Assuming that the server advertises UTF8SMTPbis and 8BITMIME, and 379 receives at least one non-ASCII address, the precise interpretation 380 of "BODY=8BITMIME", and "BODY=BINARYMIME" in the MAIL command is: 381 1. If a BODY=8BITMIME parameter is present, the header contains 382 UTF-8 characters, and some or all of the body parts contain 8-bit 383 line-oriented data. 384 2. If a BODY=BINARYMIME parameter is present, the header contains 385 UTF-8 characters, and some or all body parts contain binary data 386 without restriction as to line lengths or delimiters. 388 3.6. Additional ESMTP Changes and Clarifications 390 The information carried in the mail transport process involves 391 addresses ("mailboxes") and domain names in various contexts in 392 addition to the MAIL and RCPT commands and extended alternatives to 393 them. In general, the rule is that, when RFC 5321 specifies a 394 mailbox, this specification expects UTF-8 to be used for the entire 395 string; when RFC 5321 specifies a domain name, the name SHOULD be in 396 the form of A-label if its raw form is non-ASCII. 398 The following subsections list and discuss all of the relevant cases. 400 3.6.1. The Initial SMTP Exchange 402 When an SMTP connection is opened, the server normally sends a 403 "greeting" response consisting of the 220 response code and some 404 information. The client then sends the EHLO command. Since the 405 client cannot know whether the server supports UTF8SMTPbis until 406 after it receives the response from EHLO, the client must send only 407 ASCII (LDH label [RFC5890] or A-label) domains in the EHLO command 408 and that, if the server provides domain names in the EHLO response, 409 they must be in the form of LDH labels or A-labels. 411 3.6.2. Mail eXchangers 413 Organizations often authorize multiple servers to accept mail 414 addressed to them. For example, the organization may itself operate 415 more than one server, and may also or instead have an agreement with 416 other organizations to accept mail as a backup. Authorized servers 417 are generally listed in MX records as described in RFC 5321. When 418 more than one server accepts mail for the domain-part of a mailbox, 419 it is strongly advised that either all or none of them support the 420 UTF8SMTPbis extension. Otherwise, surprising rejections can happen 421 during temporary failures, which users might perceive as a serious 422 reliability issue. In order to avoid the possible surprising 423 rejections, you may also implement the advice in EAI addresses advice 424 document [EAI addresses] and EAI deployment advice document [EAI 425 Deployment]. 427 3.6.3. Trace Information 429 When an SMTP server receives a message for delivery or further 430 processing, RFC 5321 requires that it MUST insert trace ("time stamp" 431 or "Received") information at the beginning of the message content. 432 For the trace information, this memo updates the time stamp line and 433 the return path line [RFC5321] formally defined as follows: 435 uReturn-path-line = "Return-Path:" FWS uReverse-path 436 ; Replaces Return-path-line in Section 4.4 of RFC 5321 438 uReverse-path = uPath / "<>" 439 ; Replace Reverse-path in RFC 5321, section 4.1.2 441 uPath = "<" [ A-d-l ":" ] uMailbox ">" 442 ; Replace Path in RFC 5321, section 4.1.2 443 ; uMailbox is defined in section 3.3 of this document 445 A-d-l = 447 uTime-stamp-line = "Received:" FWS uStamp 448 ; Replaces Time-stamp-line in Section 4.4 of RFC 5321 450 uStamp = From-domain By-domain uOpt-info [CFWS] ";" FWS date-time 451 ; Replaces Stamp in Section 4.4 of RFC 5321 453 From-domain = 455 By-domain = 457 date-time = 459 uOpt-info = [Via] [With] [ID] [uFor] 460 [Additional-Registered-Clauses] 461 ; Replaces Opt-info in Section 4.4 of RFC 5321 462 ; The protocol value for With will allow a UTF8SMTPbis value 464 Via = 466 With = 468 ID = 470 Additional-Registered-Clauses = 472 uFor = CFWS "FOR" FWS ( uPath / uMailbox) 473 ; Replaces For in Section 4.4 of RFC 5321 474 ; uMailbox is defined in section 3.3 of this document 476 Except in the 'uFor' clause and 'uReverse-path' value where non-ASCII 477 domain names may be used, internationalized domain names in Received 478 fields MUST be transmitted in the form of A-labels. The protocol 479 value of the WITH clause when this extension is used is one of the 480 UTF8SMTPbis values specified in the "IANA Considerations" section of 481 this document. 483 3.6.4. UTF-8 Strings in Replies 485 3.6.4.1. RCPT Commands 487 If an SMTP client follows this specification and sends any RCPT 488 commands containing non-ASCII addresses, the SMTP server is permitted 489 to use UTF-8 characters in the email address associated with 251 and 490 551 response codes, and the client MUST be able to accept and process 491 them. If a given RCPT command does not include a non-ASCII envelope 492 address, the server MUST NOT return a 251 or 551 response containing 493 a non-ASCII mailbox. Instead, it MUST transform such responses into 494 250 or 550 responses that do not contain non-ASCII addresses. 496 3.6.4.2. VRFY and EXPN Commands and the UTF8REPLY Parameter 498 If the VRFY and EXPN commands are transmitted with the optional 499 parameter "UTF8REPLY", it indicates the client can accept UTF-8 500 strings in replies to those commands. This allows the server to use 501 UTF-8 strings in mailbox names and full names that occur in replies 502 without concern that the client might be confused by them. An SMTP 503 client that conforms to this specification MUST accept and correctly 504 process replies from the VRFY and EXPN commands that contain UTF-8 505 strings. However, the SMTP server MUST NOT use UTF-8 strings in 506 replies if the SMTP client does not specifically allow such replies 507 by transmitting this parameter. Most replies do not require that a 508 mailbox name be included in the returned text, and therefore UTF-8 is 509 not needed in them. Some replies, notably those resulting from 510 successful execution of the VRFY and EXPN commands, do include the 511 mailbox, making the provisions of this section important. 513 VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to: 515 vrfy = "VRFY" SP ( uLocal-part / uMailbox ) 516 [ SP "UTF8REPLY" ] CRLF 517 ; uLocal-part and uMailbox are defined in 518 ; Section 3.3 of this document. 520 expn = "EXPN" SP ( uLocal-part / uMailbox ) 521 [ 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 [RFC5321], means "Cannot VRFY user, but will accept the message 530 and attempt the delivery". Response code 550, also defined in 531 [RFC5321], 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 [RFC5248] is either "X.6.8" if 551 the associated basic status code [RFC5321] is 252 or "Y.6.8" if the 552 associated basic status code [RFC5321] is 553 or 550, meaning "A 553 reply containing a UTF-8 string is required to show the mailbox name, 554 but that form of response is not permitted by the client". 556 If the SMTP client does not support the UTF8SMTPbis extension, but 557 receives a UTF-8 string in a reply, it may not be able to properly 558 report the reply to the user, and some clients might crash. 559 Internationalized messages in replies are only allowed in the 560 commands under the situations described above. Under any other 561 circumstances, UTF-8 text MUST NOT appear in the reply. 563 Although UTF-8 is needed to represent email addresses in responses 564 under the rules specified in this section, this extension does not 565 permit the use of UTF-8 for any other purposes. SMTP servers MUST 566 NOT include non-ASCII characters in replies except in the limited 567 cases specifically permitted in this section. 569 4. IANA Considerations 571 IANA should add a new value "UTF8SMTPbis" to the SMTP Service 572 Extension subregistry of the Mail Parameters registry, according to 573 the following data: 575 +-------------+---------------------------------+-----------+ 576 | Keywords | Description | Reference | 577 +-------------+---------------------------------+-----------+ 578 | UTF8SMTPbis | Internationalized email address | [RFCXXXX] | 579 +-------------+---------------------------------+-----------+ 581 This document updates the values to the SMTP Enhanced Status Code 582 subregistry of the Mail Parameters registry, following the guidance 583 in Sections 3.4 and 3.6.4.2 of this document, and being based on 584 [RFC5248]. The registration data is as follows: 586 Code: X.6.7 587 Sample Text: UTF-8 addresses not permitted 588 for that sender/recipient 589 Associated basic status code: 553, 550 590 Description: This indicates the reception of a MAIL or RCPT 591 command that rUTF-8 addresses are not permitted 592 Defined: RFC XXXX (Standard track) 593 Submitter: Jiankang YAO 594 Change controller: ima@ietf.org 596 Code: X.6.8 597 Sample Text: UTF-8 string reply is required, 598 but not permitted by the client 599 Associated basic status code: 553, 550 600 Description: This indicates that a reply containing a UTF-8 601 string is required to show the mailbox name, 602 but that form of response is not 603 permitted by the client. 604 Defined: RFC XXXX (Standard track) 605 Submitter: Jiankang YAO 606 Change controller: ima@ietf.org 608 Code: X.6.9 609 Sample Text: UTF-8 header message can not be transferred 610 to one or more recipient so the message 611 must be rejected 612 Associated basic status code: 550 613 Description: This indicates that transaction failed 614 after the final "." of the DATA command. 615 Defined: RFC XXXX (Standard track) 616 Submitter: Jiankang YAO 617 Change controller: ima@ietf.org 619 Code: Y.6.8 620 Sample Text: UTF-8 string reply is required, 621 but not permitted by the client 622 Associated basic status code: 252 623 Description: This indicates that a reply containing a UTF-8 624 string is required to show the mailbox name, 625 but that form of response is not 626 permitted by the client. 627 Defined: RFC XXXX (Standard track) 628 Submitter: Jiankang YAO 629 Change controller: ima@ietf.org 631 The "Mail Transmission Types" registry under the Mail Parameters 632 registry is requested to be updated to include the following new 633 entries: 635 +---------------+-----------------------------+---------------------+ 636 | WITH protocol | Description | Reference | 637 | types | | | 638 +---------------+-----------------------------+---------------------+ 639 | UTF8SMTPbis | UTF8SMTPbis with Service | [RFCXXXX] | 640 | | Extensions | | 641 | UTF8SMTPbisA | UTF8SMTPbis with SMTP AUTH | [RFC4954] [RFCXXXX] | 642 | UTF8SMTPbisS | UTF8SMTPbis with STARTTLS | [RFC3207] [RFCXXXX] | 643 | UTF8SMTPbisSA | UTF8SMTPbis with both | [RFC3207] [RFC4954] | 644 | | STARTTLS and SMTP AUTH | [RFCXXXX] | 645 +---------------+-----------------------------+---------------------+ 647 5. Security Considerations 649 See the extended security considerations discussion in the framework 650 document [RFC4952bis]. 652 6. Acknowledgements 654 This document revised the [RFC5336]document based on the EAI WG's 655 discussion result. Many EAI WG members did some tests and 656 implementations to move this document to the Standard Track document. 657 Significant comments and suggestions were received from Xiaodong LEE, 658 Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other members of the JET 659 team and were incorporated into the specification. Additional 660 important comments and suggestions, and often specific text, were 661 contributed by many members of the WG and design team. Those 662 contributions include material from John C Klensin, Charles Lindsey, 663 Dave Crocker, Harald Tveit Alvestrand, Marcos Sanz, Chris Newman, 664 Martin Duerst, Edmon Chung, Tony Finch, Kari Hurtta, Randall Gellens, 665 Frank Ellermann, Alexey Melnikov, Pete Resnick, S. Moonesamy, Soobok 666 Lee, Shawn Steele, Alfred Hoenes, Miguel Garcia, Magnus Westerlund, 667 and Lars Eggert. Of course, none of the individuals are necessarily 668 responsible for the combination of ideas represented here. 670 7. Change History 672 [[anchor11: RFC Editor: Please remove this section.]] 674 7.1. draft-yao-eai-rfc5336bis: Version 00 676 Applied errata suggested by Alfred Hoenes. 678 7.2. draft-ietf-eai-rfc5336bis: Version 00 680 Applied the changes suggested by the EAI new charter. 682 7.3. draft-ietf-eai-rfc5336bis: Version 01 684 Applied the changes suggested by 78 IETF EAI meeting. 686 7.4. draft-ietf-eai-rfc5336bis: Version 02 688 remove the appendix since rfc4952bis has added this material 690 improve the text 692 remove the text about no body parameter 694 7.5. draft-ietf-eai-rfc5336bis: Version 03 696 improve the text 698 7.6. draft-ietf-eai-rfc5336bis: Version 04 700 update the abstract 702 improve the text 704 7.7. draft-ietf-eai-rfc5336bis: Version 05 706 improve the text based on AD and Co-chairs 708 8. References 709 8.1. Normative References 711 [ASCII] American National Standards Institute (formerly United 712 States of America Standards Institute), "USA Code for 713 Information Interchange", ANSI X3.4-1968, 1968. 715 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 716 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 717 RFC 1652, July 1994. 719 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 720 October 1996. 722 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 723 Requirement Levels", BCP 14, RFC 2119, March 1997. 725 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 726 RFC 3463, January 2003. 728 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 729 for Delivery Status Notifications", RFC 3464, 730 January 2003. 732 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 733 10646", RFC 3629, November 2003. 735 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 736 RFC 4409, April 2006. 738 [RFC4952bis] 739 Klensin, J. and Y. Ko, "Overview and Framework for 740 Internationalized Email", RFC 4952, July 2010. 742 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 743 Specifications: ABNF", STD 68, RFC 5234, January 2008. 745 [RFC5248] Hansen , T. and J. Klensin, "A Registry for SMTP Enhanced 746 Mail System Status Codes", RFC 5248, June 2008. 748 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 749 October 2008. 751 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 752 October 2008. 754 [RFC5335bis] 755 Abel, Y. and S. Steel, "Internationalized Email Headers", 756 RFC 5335, December 2010. 758 [RFC5337bis] 759 Newman, C. and A. Melnikov, Ed., "Internationalized 760 Delivery Status and Disposition Notifications", RFC 5337, 761 August 2008. 763 [RFC5890] Klensin, J., "Internationalizing Domain Names in 764 Applications (IDNA definitions)", RFC 5890, June 2010. 766 [RFC5891] Klensin, J., "Internationalized Domain Names in 767 Applications (IDNA): Protocol", RFC 5891, August 2010. 769 8.2. Informative References 771 [EAI Deployment] 772 Yao, J., Lee, X., and S. Steel, "Advice for EAI 773 deployment", draft 5335, December 2010. 775 [EAI addresses] 776 Steel, S., Yao, J., and Mark. Davis, "Advice for non-ASCII 777 & ASCII addresses", draft 5335, December 2010. 779 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 780 Extensions (MIME) Part One: Format of Internet Message 781 Bodies", RFC 2045, November 1996. 783 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 784 Part Three: Message Header Extensions for Non-ASCII Text", 785 RFC 2047, November 1996. 787 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 788 of Large and Binary MIME Messages", RFC 3030, 789 December 2000. 791 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 792 Transport Layer Security", RFC 3207, February 2002. 794 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 795 for Authentication", RFC 4954, July 2007. 797 [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized 798 Email Addresses", RFC 5336, September 2008. 800 Authors' Addresses 802 Jiankang YAO 803 CNNIC 804 No.4 South 4th Street, Zhongguancun 805 Beijing 807 Phone: +86 10 58813007 808 Email: yaojk@cnnic.cn 810 Wei MAO 811 CNNIC 812 No.4 South 4th Street, Zhongguancun 813 Beijing 815 Phone: +86 10 58812230 816 Email: maowei_ietf@cnnic.cn