idnits 2.17.1 draft-ietf-eai-rfc5336bis-07.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 4, 2010) is 4885 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 796, but no explicit reference was found in the text == Unused Reference: 'RFC5336' is defined on line 806, 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 4, 2010 6 Updates: RFC5321 and 5322 7 (if approved) 8 Intended status: Standards Track 9 Expires: June 7, 2011 11 SMTP Extension for Internationalized Email Address 12 draft-ietf-eai-rfc5336bis-07.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 7, 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 7.8. draft-ietf-eai-rfc5336bis: Version 06 . . . . . . . . . . 17 94 7.9. draft-ietf-eai-rfc5336bis: Version 07 . . . . . . . . . . 17 95 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 97 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 100 1. Introduction 102 The Simple Mail Transfer Protocol [RFC5321] provides a negotiation 103 mechanism about service extension with which clients can discover 104 server capabilities and make decisions for further processing. This 105 document use this mechanism to support an internationalized email 106 address. An extended overview of the extension model for 107 internationalized addresses and headers appears in [RFC4952bis], 108 referred to as "the framework document" or just as "framework" 109 elsewhere in this specification. This document specifies an SMTP 110 extension to permit internationalized email addresses in envelopes, 111 and UNICODE characters (encoded in UTF-8) [RFC3629] in headers. 113 1.1. Role of This Specification 115 The framework document specifies the requirements for, and describes 116 components of, full internationalization of the electronic mail. A 117 thorough understanding of the information in that document and in the 118 base Internet email specifications [RFC5321] [RFC5322] is necessary 119 to understand and implement this specification. 121 This document specifies an element of the email internationalization 122 work, specifically the definition of an SMTP extension for 123 internationalized email address transport delivery. 125 1.2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [RFC2119]. 131 The terms "UTF-8 string" or "UTF-8 character" are used informally to 132 refer to Unicode characters encoded in UTF-8. All other specialized 133 terms used in this specification are defined in the framework 134 document or in the base Internet email specifications. In 135 particular, the terms "ASCII address", "internationalized email 136 address", "non-ASCII address", "i18mail address", 137 "UTF8SMTPbis","conventional message", "internationalized message", 138 "message", and "mailing list" are used in this document according to 139 the definitions in the framework document. 141 This specification defines only those Augmented BNF (ABNF) [RFC5234] 142 syntax rules that are different from those of the base email 143 specifications and, where the earlier rules are upgraded or extended, 144 gives them new names. When the new rule is a small modification to 145 the older one, it is typically given a name starting with "u". Rules 146 that are undefined here may be found in the base email specifications 147 under the same names. 149 2. Overview of Operation 151 This specification describes an optional extension to the email 152 transport mechanism that permits non-ASCII [ASCII] characters in both 153 the envelope and header fields of messages, which are encoded with 154 UTF-8 characters. The extension is identified with the token 155 "UTF8SMTPbis". 157 The EAI UTF-8 header specification [RFC5335bis] provides the details 158 of how and where non-ASCII characters are permitted in the header 159 fields of messages. The context for this specification is described 160 in the framework document. 162 3. Mail Transport-Level Protocol 164 3.1. Framework for the Internationalization Extension 166 The following service extension is defined: 167 1. The name of the SMTP service extension is "Email Address 168 Internationalization". 169 2. The EHLO keyword value associated with this extension is 170 "UTF8SMTPbis". 171 3. No parameter values are defined for this EHLO keyword value. In 172 order to permit future (although unanticipated) extensions, the 173 EHLO response MUST NOT contain any parameters for that keyword. 174 Clients MUST reject any parameters; that is, clients MUST behave 175 as if the parameters do not appear. If a server includes 176 UTF8SMTPbis in its EHLO response, it MUST be fully compliant with 177 this version of this specification. 178 4. One optional parameter "UTF8REPLY" is added to the VRFY and EXPN 179 commands. The parameter UTF8REPLY has no value. The parameter 180 indicates that the SMTP client can accept Unicode characters in 181 UTF-8 encoding in replies from the VRFY and EXPN commands. 182 5. No additional SMTP verbs are defined by this extension. 183 6. Servers offering this extension MUST provide support for, and 184 announce, the 8BITMIME extension [RFC1652]. 185 7. The reverse-path and forward-path of the SMTP MAIL and RCPT 186 commands are extended to allow Unicode characters encoded in 187 UTF-8 in mailbox names (addresses). 188 8. The mail message body is extended as specified in [RFC5335bis]. 189 9. The UTF8SMTPbis extension is valid on the submission port 190 [RFC4409], and can be used with LMTP [RFC2033]. 192 3.2. The UTF8SMTPbis Extension 194 An SMTP server that announces this extension MUST be prepared to 195 accept a UTF-8 string [RFC3629] in any position in which RFC 5321 196 specifies that a mailbox can appear. That string MUST be parsed only 197 as specified in [RFC5321], i.e., by separating the mailbox into 198 source route, local part, and domain part, using only the characters 199 colon (U+003A), comma (U+002C), and at-sign (U+0040) as specified 200 there. Once isolated by this parsing process, the local part MUST be 201 treated as opaque unless the SMTP server is the final delivery Mail 202 Transfer Agent (MTA). Any domain names to be looked up in the DNS 203 MUST allow for [RFC5890] behavior. When doing lookups, the server 204 MUST either use a Unicode aware DNS library, or transform it to 205 A-label defined in [RFC5890]. Any domain names that are to be 206 compared to local strings SHOULD be checked for validity and then 207 MUST be compared as specified in section 3 of [RFC5891]. 209 An SMTP client that receives the UTF8SMTPbis extension keyword in 210 response to the EHLO command MAY transmit mailbox names within SMTP 211 commands as internationalized strings in UTF-8 form. It MAY send a 212 UTF-8 header [RFC5335bis] (which may also include mailbox names in 213 UTF-8). It MAY transmit the domain parts of mailbox names within 214 SMTP commands or the message header as A-labels or U-labels 215 [RFC5890]. All labels in domain parts of mailbox names which are IDN 216 forms of A-labels or U-labels MUST be valid. When a Mail User 217 Agent(MUA) submits a message to a Message Submission Server 218 ("MSA")[RFC4409], it is the responsibility of the MSA to ensure that 219 all domain labels are valid. The presence of the UTF8SMTPbis 220 extension does not change the requirement of RFC 5321 that servers 221 relaying mail MUST NOT attempt to parse, evaluate, or transform the 222 local part in any way. 224 If the UTF8SMTPbis SMTP extension is not offered by the server, the 225 SMTP client MUST NOT transmit an internationalized address and MUST 226 NOT transmit a mail message containing internationalized mail headers 227 as described in [RFC5335bis] at any level within its MIME structure 228 [RFC2045] and [RFC2047]. (For this paragraph, the internationalized 229 domain name in the form of A-labels as specified in IDNA definitions 230 [RFC5890] is not considered to be "internationalized".) Instead, if 231 an SMTP client (SMTP sender) attempts to transfer an 232 internationalized message and encounters a server that does not 233 support the extension, it MUST make one of the following three 234 choices: 236 1. If and only if the SMTP client (sender) is a Message Submission 237 Server ("MSA") [RFC4409], it MAY, consistent with the general 238 provisions for changes by such servers, rewrite the envelope, 239 headers, or message material to make them entirely ASCII and 240 consistent with the provisions of RFC 5321 [RFC5321] and RFC 5322 241 [RFC5322]. 243 2. It may either reject the message during the SMTP transaction or 244 accept the message and then generate and transmit a notification 245 of non-deliverability. Such notification MUST be done as 246 specified in RFC 5321 [RFC5321], RFC 3464 [RFC3464], and the EAI 247 delivery status notification (DSN) specification [RFC5337bis]. 248 3. It may find an alternate route to the destination that permits 249 UTF8SMTPbis. That route may be discovered by trying alternate 250 Mail eXchanger (MX) hosts (using preference rules as specified in 251 RFC 5321) or using other means available to the SMTP-sender. 253 This document applies only when an UTF8SMTPbis-aware client is trying 254 to send an internationalized message to an UTF8SMTPbis-aware server. 255 For all other cases, and for addresses and messages that do not 256 require an UTF8SMTPbis extension, SMTP clients and servers are 257 expected to behave exactly as specified in [RFC5321]. 259 A UTF8SMTPbis aware MUA/MSA sending to a legacy SMTP server [RFC5321] 260 and [RFC5322] MAY convert an ASCII@non-ASCII address into the format 261 of ASCII@A-label [RFC5890] if the email address is in the format of 262 ASCII@non-ASCII. 264 3.3. Extended Mailbox Address Syntax 266 RFC 5321, Section 4.1.2, defines the syntax of a mailbox entirely in 267 terms of ASCII characters, using the production for a mailbox and 268 those productions on which it depends. 270 The key changes made by this specification are, informally, to 271 o Change the definition of "Domain" to permit either the RFC 5321 272 definition above or a UTF-8 string representing a DNS label that 273 is conformant with IDNA definitions [RFC5890]. 274 o Change the definition of "Local-part" to permit either the 275 definition above or a UTF-8 string. That string MUST NOT contain 276 any of the ASCII characters (either graphics or controls) that are 277 not permitted in "atext"; it is otherwise unrestricted. 279 According to the description above, the syntax of an 280 internationalized email mailbox name (address) is defined in ABNF 281 [RFC5234] as follows. 283 uMailbox = uLocal-part "@" ( uDomain / address-literal ) 284 ; Replace Mailbox in RFC 5321, Section 4.1.2 286 address-literal = 288 uLocal-part = uDot-string / uQuoted-string 289 ; MAY be case-sensitive 290 ; Replace Local-part in RFC 5321, Section 4.1.2 292 uDot-string = uAtom *("." uAtom) 293 ; Replace Dot-string in RFC 5321, Section 4.1.2 295 uAtom = 1*ucharacter 296 ; Replace Atom in RFC 5321, Section 4.1.2 298 ucharacter = atext / UTF8-non-ascii 300 atext = 302 uQuoted-string = DQUOTE *uqcontent DQUOTE 303 ; Replace Quoted-string in RFC 5321, Section 4.1.2 305 DQUOTE = 307 uqcontent = qcontent / UTF8-non-ascii 309 qcontent = 311 uDomain = sub-udomain *("." sub-udomain) 312 ; Replace Domain in RFC 5321, Section 4.1.2 314 sub-udomain = uLet-dig [uLdh-str] 315 ; Replace sub-domain in RFC 5321, Section 4.1.2 317 uLet-dig = Let-dig / UTF8-non-ascii 319 Let-dig = 321 uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-non-ascii) uLet-dig 322 ; Replace Ldh-str in RFC 5321, Section 4.1.2 324 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 326 UTF8-2 = 328 UTF8-3 = 330 UTF8-4 = 332 The value of "uDomain" SHOULD be verified by IDNA definitions 333 [RFC5890]. If that verification fails, the email address with that 334 uDomain MUST NOT be regarded as a valid email address. 336 3.4. UTF8 addresses and Response Codes 338 An internationalized message MUST NOT be sent to an SMTP server that 339 does not support UTF8SMTPbis. Such a message should be rejected by a 340 server if it lacks the support of UTF8SMTPbis. 342 The three-digit reply codes used in this section are consistent with 343 their meanings as defined in RFC 5321. 345 When messages are rejected because the RCPT command requires an ASCII 346 address, the response code 553 is used with the meaning "mailbox name 347 not allowed". When messages are rejected for other reasons, such as 348 the MAIL command requiring an ASCII address, the response code 550 is 349 used with the meaning "mailbox unavailable". When the server 350 supports enhanced mail system status codes [RFC3463], response code 351 "X.6.7" [RFC5248] is used, meaning that "UTF-8 addresses not 352 permitted for that sender/recipient". 354 If the response code is issued after the final "." of the DATA 355 command, the response code "554" is used with the meaning 356 "Transaction failed". When the server supports enhanced mail system 357 status codes [RFC3463], response code "X.6.9" [RFC5248] is used, 358 meaning that "UTF-8 header message can not be transferred to one or 359 more recipient so the message must be rejected". 361 3.5. Body Parts and SMTP Extensions 363 There is no ESMTP parameter to assert that a message is an 364 internationalized message. An SMTP server that requires accurate 365 knowledge of whether a message is internationalized is required to 366 parse all message header fields and MIME header fields [RFC2045] and 367 [RFC2047] in the message body. 369 While this specification requires that servers support the 8BITMIME 370 extension [RFC1652] to ensure that servers have adequate handling 371 capability for 8-bit data and to avoid a number of complex encoding 372 problems, the use of internationalized addresses obviously does not 373 require non-ASCII body parts in the MIME message [RFC2045] and 374 [RFC2047]. The UTF8SMTPbis extension MAY be used with the 375 BODY=8BITMIME parameter if that is appropriate given the body content 376 or, with the BODY=BINARYMIME parameter, if the server advertises 377 BINARYMIME [RFC3030] and that is appropriate. 379 Assuming that the server advertises UTF8SMTPbis and 8BITMIME, and 380 receives at least one non-ASCII address, the precise interpretation 381 of "BODY=8BITMIME", and "BODY=BINARYMIME" in the MAIL command is: 382 1. If a BODY=8BITMIME parameter is present, the header contains 383 UTF-8 characters, and some or all of the body parts contain 8-bit 384 line-oriented data. 385 2. If a BODY=BINARYMIME parameter is present, the header contains 386 UTF-8 characters, and some or all body parts contain binary data 387 without restriction as to line lengths or delimiters. 389 3.6. Additional ESMTP Changes and Clarifications 391 The information carried in the mail transport process involves 392 addresses ("mailboxes") and domain names in various contexts in 393 addition to the MAIL and RCPT commands and extended alternatives to 394 them. In general, the rule is that, when RFC 5321 specifies a 395 mailbox, this specification expects UTF-8 to be used for the entire 396 string; when RFC 5321 specifies a domain name, the name SHOULD be in 397 the form of A-label if its raw form is non-ASCII. 399 The following subsections list and discuss all of the relevant cases. 401 3.6.1. The Initial SMTP Exchange 403 When an SMTP connection is opened, the server normally sends a 404 "greeting" response consisting of the 220 response code and some 405 information. The client then sends the EHLO command. Since the 406 client cannot know whether the server supports UTF8SMTPbis until 407 after it receives the response from EHLO, the client must send only 408 ASCII (LDH label [RFC5890] or A-label) domains in the EHLO command 409 and that, if the server provides domain names in the EHLO response, 410 they must be in the form of LDH labels or A-labels. 412 3.6.2. Mail eXchangers 414 Organizations often authorize multiple servers to accept mail 415 addressed to them. For example, the organization may itself operate 416 more than one server, and may also or instead have an agreement with 417 other organizations to accept mail as a backup. Authorized servers 418 are generally listed in MX records as described in RFC 5321. When 419 more than one server accepts mail for the domain-part of a mailbox, 420 it is strongly advised that either all or none of them support the 421 UTF8SMTPbis extension. Otherwise, surprising rejections can happen 422 during temporary failures, which users might perceive as a serious 423 reliability issue. In order to avoid the possible surprising 424 rejections, you may also implement the advice in EAI addresses advice 425 document [EAI addresses] and EAI deployment advice document [EAI 426 Deployment]. 428 3.6.3. Trace Information 430 When an SMTP server receives a message for delivery or further 431 processing, RFC 5321 requires that it MUST insert trace ("time stamp" 432 or "Received") information at the beginning of the message content. 433 For the trace information, this memo updates the time stamp line and 434 the return path line [RFC5321] formally defined as follows: 436 uReturn-path-line = "Return-Path:" FWS uReverse-path 437 ; Replaces Return-path-line in Section 4.4 of RFC 5321 439 uReverse-path = uPath / "<>" 440 ; Replace Reverse-path in RFC 5321, section 4.1.2 442 uPath = "<" [ A-d-l ":" ] uMailbox ">" 443 ; Replace Path in RFC 5321, section 4.1.2 444 ; uMailbox is defined in section 3.3 of this document 446 A-d-l = 448 uTime-stamp-line = "Received:" FWS uStamp 449 ; Replaces Time-stamp-line in Section 4.4 of RFC 5321 451 uStamp = From-domain By-domain uOpt-info [CFWS] ";" FWS date-time 452 ; Replaces Stamp in Section 4.4 of RFC 5321 454 From-domain = 456 By-domain = 458 date-time = 460 uOpt-info = [Via] [With] [ID] [uFor] 461 [Additional-Registered-Clauses] 462 ; Replaces Opt-info in Section 4.4 of RFC 5321 463 ; The protocol value for With will allow a UTF8SMTPbis value 465 Via = 467 With = 469 ID = 471 Additional-Registered-Clauses = 473 uFor = CFWS "FOR" FWS ( uPath / uMailbox) 474 ; Replaces For in Section 4.4 of RFC 5321 475 ; uMailbox is defined in section 3.3 of this document 477 Except in the 'uFor' clause and 'uReverse-path' value where non-ASCII 478 domain names may be used, internationalized domain names in Received 479 fields MUST be transmitted in the form of A-labels. The protocol 480 value of the WITH clause when this extension is used is one of the 481 UTF8SMTPbis values specified in the "IANA Considerations" section of 482 this document. 484 3.6.4. UTF-8 Strings in Replies 486 3.6.4.1. RCPT Commands 488 If an SMTP client follows this specification and sends any RCPT 489 commands containing non-ASCII addresses, the SMTP server is permitted 490 to use UTF-8 characters in the email address associated with 251 and 491 551 response codes, and the client MUST be able to accept and process 492 them. If a given RCPT command does not include a non-ASCII envelope 493 address, the server MUST NOT return a 251 or 551 response containing 494 a non-ASCII mailbox. Instead, it MUST transform such responses into 495 250 or 550 responses that do not contain non-ASCII addresses. 497 3.6.4.2. VRFY and EXPN Commands and the UTF8REPLY Parameter 499 If the VRFY and EXPN commands are transmitted with the optional 500 parameter "UTF8REPLY", it indicates the client can accept UTF-8 501 strings in replies to those commands. This allows the server to use 502 UTF-8 strings in mailbox names and full names that occur in replies 503 without concern that the client might be confused by them. An SMTP 504 client that conforms to this specification MUST accept and correctly 505 process replies from the VRFY and EXPN commands that contain UTF-8 506 strings. However, the SMTP server MUST NOT use UTF-8 strings in 507 replies if the SMTP client does not specifically allow such replies 508 by transmitting this parameter. Most replies do not require that a 509 mailbox name be included in the returned text, and therefore UTF-8 is 510 not needed in them. Some replies, notably those resulting from 511 successful execution of the VRFY and EXPN commands, do include the 512 mailbox, making the provisions of this section important. 514 VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to: 516 vrfy = "VRFY" SP ( uLocal-part / uMailbox ) 517 [ SP "UTF8REPLY" ] CRLF 518 ; uLocal-part and uMailbox are defined in 519 ; Section 3.3 of this document. 521 expn = "EXPN" SP ( uLocal-part / uMailbox ) 522 [ SP "UTF8REPLY" ] CRLF 523 ; uLocal-part and uMailbox are defined in 524 ; Section 3.3 of this document. 526 The "UTF8REPLY" parameter does not use a value. If the reply to a 527 VERIFY (VRFY) or EXPAND (EXPN) command requires UTF-8, but the SMTP 528 client did not use the "UTF8REPLY" parameter, then the server MUST 529 use either the response code 252 or 550. Response code 252, defined 530 in [RFC5321], means "Cannot VRFY user, but will accept the message 531 and attempt the delivery". Response code 550, also defined in 532 [RFC5321], means "Requested action not taken: mailbox unavailable". 533 When the server supports enhanced mail system status codes [RFC3463], 534 the enhanced response code as specified below is used. Using the 535 "UTF8REPLY" parameter with a VERIFY (VRFY) or EXPAND (EXPN) command 536 enables UTF-8 replies for that command only. 538 If a normal success response (i.e., 250) is returned, the response 539 MAY include the full name of the user and MUST include the mailbox of 540 the user. It MUST be in either of the following forms: 542 User Name 543 ; uMailbox is defined in Section 3.3 of this document. 544 ; User Name can contain non-ASCII characters. 546 uMailbox 547 ; uMailbox is defined in Section 3.3 of this document. 549 If the SMTP reply requires UTF-8 strings, but UTF-8 is not allowed in 550 the reply, and the server supports enhanced mail system status codes 551 [RFC3463], the enhanced response code is "X.6.8" [RFC5248], meaning 552 "A reply containing a UTF-8 string is required to show the mailbox 553 name, but that form of response is not permitted by 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 should add 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: 550, 553 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: ima@ietf.org 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: 252, 550, 553 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: ima@ietf.org 607 Code: X.6.9 608 Sample Text: UTF-8 header message can not be transferred 609 to one or more recipient so the message 610 must be rejected 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: ima@ietf.org 617 Code: X.6.10 618 Description: This is a duplicate of X.6.8 and 619 SHOULD be deprecated for further use. 621 The following entries SHOULD be updated or added in the "Mail 622 Transmission Types" registry under the Mail Parameters registry. 624 +--------------+-------------------------------+--------------------+ 625 | WITH | Description | Reference | 626 | protocol | | | 627 | types | | | 628 +--------------+-------------------------------+--------------------+ 629 | UTF8SMTP | ESMTP with UTF8SMTP | [RFCXXXX] | 630 | UTF8SMTPA | ESMTP with UTF8SMTP and SMTP | [RFC4954] | 631 | | AUTH | [RFCXXXX] | 632 | UTF8SMTPS | ESMTP with UTF8SMTP and | [RFC3207] | 633 | | STARTTLS | [RFCXXXX] | 634 | UTF8SMTPSA | ESMTP with UTF8SMTP and both | [RFC3207] | 635 | | STARTTLS and SMTP AUTH | [RFC4954] | 636 | | | [RFCXXXX] | 637 | UTF8LMTP | LMTP with UTF8SMTP | [RFCXXXX] | 638 | UTF8LMTPA | LMTP with UTF8SMTP and SMTP | [RFC4954] | 639 | | AUTH | [RFCXXXX] | 640 | UTF8LMTPS | LMTP with UTF8SMTP and | [RFC3207] | 641 | | STARTTLS | [RFCXXXX] | 642 | UTF8LMTPSA | LMTP with UTF8SMTP and both | [RFC3207] | 643 | | STARTTLS and LMTP AUTH | [RFC4954] | 644 | | | [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 7.8. draft-ietf-eai-rfc5336bis: Version 06 710 update the iana consideration 712 7.9. draft-ietf-eai-rfc5336bis: Version 07 714 improve the iana consideration 716 8. References 718 8.1. Normative References 720 [ASCII] American National Standards Institute (formerly United 721 States of America Standards Institute), "USA Code for 722 Information Interchange", ANSI X3.4-1968, 1968. 724 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 725 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 726 RFC 1652, July 1994. 728 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 729 October 1996. 731 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 732 Requirement Levels", BCP 14, RFC 2119, March 1997. 734 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 735 RFC 3463, January 2003. 737 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 738 for Delivery Status Notifications", RFC 3464, 739 January 2003. 741 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 742 10646", RFC 3629, November 2003. 744 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 745 RFC 4409, April 2006. 747 [RFC4952bis] 748 Klensin, J. and Y. Ko, "Overview and Framework for 749 Internationalized Email", RFC 4952, July 2010. 751 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 752 Specifications: ABNF", STD 68, RFC 5234, January 2008. 754 [RFC5248] Hansen , T. and J. Klensin, "A Registry for SMTP Enhanced 755 Mail System Status Codes", RFC 5248, June 2008. 757 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 758 October 2008. 760 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 761 October 2008. 763 [RFC5335bis] 764 Abel, Y. and S. Steel, "Internationalized Email Headers", 765 RFC 5335, December 2010. 767 [RFC5337bis] 768 Newman, C. and A. Melnikov, Ed., "Internationalized 769 Delivery Status and Disposition Notifications", RFC 5337, 770 August 2008. 772 [RFC5890] Klensin, J., "Internationalizing Domain Names in 773 Applications (IDNA definitions)", RFC 5890, June 2010. 775 [RFC5891] Klensin, J., "Internationalized Domain Names in 776 Applications (IDNA): Protocol", RFC 5891, August 2010. 778 8.2. Informative References 780 [EAI Deployment] 781 Yao, J., Lee, X., and S. Steel, "Advice for EAI 782 deployment", draft 5335, December 2010. 784 [EAI addresses] 785 Steel, S., Yao, J., and Mark. Davis, "Advice for non-ASCII 786 & ASCII addresses", draft 5335, December 2010. 788 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 789 Extensions (MIME) Part One: Format of Internet Message 790 Bodies", RFC 2045, November 1996. 792 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 793 Part Three: Message Header Extensions for Non-ASCII Text", 794 RFC 2047, November 1996. 796 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 797 of Large and Binary MIME Messages", RFC 3030, 798 December 2000. 800 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 801 Transport Layer Security", RFC 3207, February 2002. 803 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 804 for Authentication", RFC 4954, July 2007. 806 [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized 807 Email Addresses", RFC 5336, September 2008. 809 Authors' Addresses 811 Jiankang YAO 812 CNNIC 813 No.4 South 4th Street, Zhongguancun 814 Beijing 816 Phone: +86 10 58813007 817 Email: yaojk@cnnic.cn 819 Wei MAO 820 CNNIC 821 No.4 South 4th Street, Zhongguancun 822 Beijing 824 Phone: +86 10 58812230 825 Email: maowei_ietf@cnnic.cn