idnits 2.17.1 draft-ietf-eai-rfc5336bis-01.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 (August 11, 2010) is 5000 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 599, but not defined == Unused Reference: 'RFC0974' is defined on line 710, 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 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: 5 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) August 11, 2010 6 Updates: RFC5321 and 5322 7 (if approved) 8 Intended status: Standards Track 9 Expires: February 12, 2011 11 SMTP Extension for Internationalized Email Address 12 draft-ietf-eai-rfc5336bis-01.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 5321 and RFC 5322. 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 February 12, 2011. 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 . . . . . . . . . . . . 8 77 3.5. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 8 78 3.6. Additional ESMTP Changes and Clarifications . . . . . . . 9 79 3.6.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 9 80 3.6.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 10 81 3.6.3. Trace Information . . . . . . . . . . . . . . . . . . 10 82 3.6.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 11 83 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 85 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 86 7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 15 87 7.1. draft-yao-eai-rfc5336bis: Version 00 . . . . . . . . . . . 15 88 7.2. draft-ietf-eai-rfc5336bis: Version 00 . . . . . . . . . . 15 89 7.3. draft-ietf-eai-rfc5336bis: Version 01 . . . . . . . . . . 15 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 92 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 93 Appendix A. Additional Material . . . . . . . . . . . . . . . . . 17 94 A.1. Conventional Message and Internationalized Message . . . . 17 95 A.2. LMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 A.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 18 97 A.4. Implementation Advice . . . . . . . . . . . . . . . . . . 18 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 100 1. Introduction 102 An internationalized email address includes two parts, the local part 103 and the domain part. The ways email addresses are used by protocols 104 are different from the ways domain names are used. The most critical 105 difference is that emails are delivered through a chain of clients 106 and servers, while domain names are resolved by name servers looking 107 up those names in their own tables. In addition to this, the Simple 108 Mail Transfer Protocol [RFC5321] provides a negotiation mechanism 109 about service extension with which clients can discover server 110 capabilities and make decisions for further processing. An extended 111 overview of the extension model for internationalized addresses and 112 headers appears in [RFC4952bis], referred to as "the framework 113 document" or just as "Framework" elsewhere in this specification. 114 This document specifies an SMTP extension to permit internationalized 115 email addresses in envelopes, and UNICODE characters (encoded in 116 UTF-8) [RFC3629] in headers. 118 1.1. Role of This Specification 120 The framework document specifies the requirements for, and describes 121 components of, full internationalization of electronic mail. A 122 thorough understanding of the information in that document and in the 123 base Internet email specifications [RFC5321] [RFC5322] is necessary 124 to understand and implement this specification. 126 This document specifies an element of the email internationalization 127 work, specifically the definition of an SMTP extension [RFC5321] for 128 internationalized email address transport delivery. 130 1.2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119]. 136 The terms "conventional message" and "internationalized message" are 137 defined in an appendix to this specification. The terms "UTF-8 138 string" or "UTF-8 character" are used informally to refer to Unicode 139 characters encoded in UTF-8 [RFC3629]. All other specialized terms 140 used in this specification are defined in the framework document or 141 in the base Internet email specifications [RFC5321] [RFC5322]. In 142 particular, the terms "ASCII address", "internationalized email 143 address", "non-ASCII address", "i18mail address", "UTF8SMTPbis", 144 "message", and "mailing list" are used in this document according to 145 the definitions in the framework document. 147 This specification defines only those Augmented BNF (ABNF) [RFC5234] 148 syntax rules that are different from those of the base email 149 specifications [RFC5321][RFC5322] and, where the earlier rules are 150 upgraded or extended, gives them new names. When the new rule is a 151 small modification to the older one, it is typically given a name 152 starting with "u". Rules that are undefined here may be found in the 153 base email specifications under the same names. 155 2. Overview of Operation 157 This specification describes an optional extension to the email 158 transport mechanism that permits non-ASCII [ASCII] characters in both 159 the envelope and header fields of messages, which are encoded with 160 UTF-8 [RFC3629] characters. The extension is identified with the 161 token "UTF8SMTPbis". In order to provide information that may be 162 needed in downgrading, an optional alternate ASCII address may be 163 needed if an SMTP client attempts to transfer an internationalized 164 message and encounters a server that does not support this extension. 166 The EAI UTF-8 header specification [RFC5335bis] provides the details 167 of how and where non-ASCII characters are permitted in the header 168 fields of messages. The context for this specification is described 169 in the framework document. 171 3. Mail Transport-Level Protocol 173 3.1. Framework for the Internationalization Extension 175 The following service extension is defined: 176 1. The name of the SMTP service extension is "Email Address 177 Internationalization". 178 2. The EHLO keyword value associated with this extension is 179 "UTF8SMTPbis". 180 3. No parameter values are defined for this EHLO keyword value. In 181 order to permit future (although unanticipated) extensions, the 182 EHLO response MUST NOT contain any parameters for that keyword. 183 Clients MUST ignore any parameters; that is, clients MUST behave 184 as if the parameters do not appear. If a server includes 185 UTF8SMTPbis in its EHLO response, it MUST be fully compliant with 186 this version of this specification. 187 4. One optional parameter "UTF8REPLY" is added to the VRFY and EXPN 188 commands. The parameter UTF8REPLY has no value. The parameter 189 indicates that the SMTP client can accept Unicode characters in 190 UTF-8 encoding in replies from the VRFY and EXPN commands. 192 5. No additional SMTP verbs are defined by this extension. 193 6. Servers offering this extension MUST provide support for, and 194 announce, the 8BITMIME extension [RFC1652]. 195 7. The reverse-path and forward-path of the SMTP MAIL and RCPT 196 commands are extended to allow Unicode characters encoded in 197 UTF-8 in mailbox names (addresses). 198 8. The mail message body is extended as specified in [RFC5335bis]. 199 9. The UTF8SMTPbis extension is valid on the submission port 200 [RFC4409]. 202 3.2. The UTF8SMTPbis Extension 204 An SMTP server that announces this extension MUST be prepared to 205 accept a UTF-8 string [RFC3629] in any position in which RFC 5321 206 specifies that a mailbox can appear. That string MUST be parsed only 207 as specified in RFC 5321, i.e., by separating the mailbox into source 208 route, local part, and domain part, using only the characters colon 209 (U+003A), comma (U+002C), and at-sign (U+0040) as specified there. 210 Once isolated by this parsing process, the local part MUST be treated 211 as opaque unless the SMTP server is the final delivery Mail Transfer 212 Agent (MTA). Any domain names to be looked up in the DNS MUST allow 213 for [RFC5890] behavior. When doing lookups, the server MUST either 214 use a Unicode aware DNS library, or transform it to A-label defined 215 in [RFC5890]. Any domain names that are to be compared to local 216 strings SHOULD be checked for validity and then MUST be compared as 217 specified in section 3 of [RFC5891]. 219 An SMTP client that receives the UTF8SMTPbis extension keyword in 220 response to the EHLO command MAY transmit mailbox names within SMTP 221 commands as internationalized strings in UTF-8 form. It MAY send a 222 UTF-8 header [RFC5335bis] (which may also include mailbox names in 223 UTF-8). It MAY transmit the domain parts of mailbox names within 224 SMTP commands or the message header as either ACE (ASCII Compatible 225 Encoding) labels (as specified in IDNA [RFC5890]) or UTF-8 strings. 226 All labels in domain parts of mailbox names which are IDNs (either 227 UTF-8 or ACE strings) MUST be valid. If the original client submits 228 a message to a Message Submission Server ("MSA") [RFC4409], it is the 229 responsibility of the MSA that all domain labels are valid; 230 otherwise, it is the original client's responsibility. The presence 231 of the UTF8SMTPbis extension does not change the requirement of RFC 232 5321 that servers relaying mail MUST NOT attempt to parse, evaluate, 233 or transform the local part in any way. 235 If the UTF8SMTPbis SMTP extension is not offered by the Server, the 236 SMTP client MUST NOT transmit an internationalized address and MUST 237 NOT transmit a mail message containing internationalized mail headers 238 as described in [RFC5335bis] at any level within its MIME structure. 239 (For this paragraph, the internationalized domain name in the form of 240 ACE labels as specified in IDNA [RFC5890] is not considered as 241 "internationalized".) Instead, if an SMTP client (SMTP sender) 242 attempts to transfer an internationalized message and encounters a 243 server that does not support the extension, it MUST make one of the 244 following three choices: 246 1. If and only if the SMTP client (sender) is a Message Submission 247 Server ("MSA") [RFC4409], it MAY, consistent with the general 248 provisions for changes by such servers, rewrite the envelope, 249 headers, or message material to make them entirely ASCII and 250 consistent with the provisions of RFC 5321 [RFC5321] and RFC 5322 251 [RFC5322]. 252 2. It may either reject the message during the SMTP transaction or 253 accept the message and then generate and transmit a notification 254 of non-deliverability. Such notification MUST be done as 255 specified in RFC 5321 [RFC5321], RFC 3464 [RFC3464], and the EAI 256 delivery status notification (DSN) specification [RFC5337bis]. 257 3. It may find an alternate route to the destination that permits 258 UTF8SMTPbis. That route may be discovered by trying alternate 259 Mail eXchanger (MX) hosts (using preference rules as specified in 260 RFC 5321) or using other means available to the SMTP-sender. 262 If a server advertises UTF8SMTP and the client does not recognize the 263 extension, the client may send a regular message [RFC5321] and 264 [RFC5322]. In this case, the client may continue to use the 265 [RFC5890] to transform the domain portion of an address to A-label 266 [RFC5890]. If the email address is in the format of ASCII@non-ASCII, 267 the legacy SMTP servers MUST reject the message with the 268 ASCII@non-ASCII if the non-ASCII domain part is not transformed into 269 the format of A-label by the client. UTF8SMTPbis servers MUST 270 recognize and decode the ACE label(s) as appropriate. 272 3.3. Extended Mailbox Address Syntax 274 RFC 5321, Section 4.1.2, defines the syntax of a mailbox entirely in 275 terms of ASCII characters, using the production for a mailbox and 276 those productions on which it depends. 278 The key changes made by this specification are, informally, to 279 o Change the definition of "sub-domain" to permit either the 280 definition above or a UTF-8 string representing a DNS label that 281 is conformant with IDNA [RFC5890]. 282 o Change the definition of "Atom" to permit either the definition 283 above or a UTF-8 string. That string MUST NOT contain any of the 284 ASCII characters (either graphics or controls) that are not 285 permitted in "atext"; it is otherwise unrestricted. 287 According to the description above, the syntax of an 288 internationalized email mailbox name (address) is defined in ABNF 289 [RFC5234] as follows. 291 uMailbox = uLocal-part "@" uDomain 292 ; uLocal-part and uDomain defined 293 ; in RFC 5335bis, Section 4. 295 The value of "uDomain" SHOULD be verified by IDNA [RFC5890]. If that 296 verification fails, the email address with that uDomain MUST NOT be 297 regarded as a valid email address. 299 3.4. UTF8 addresses and Response Codes 301 An "internationalized message" as defined in the appendix of this 302 specification MUST NOT be sent to an SMTP server that does not 303 support UTF8SMTPbis. Such a message should be rejected by a server 304 if it lacks the support of UTF8SMTPbis. 306 The three-digit reply codes used in this section are consistent with 307 their meanings as defined in RFC 5321. 309 When messages are rejected because the RCPT command requires an ASCII 310 address, the response code 553 is used with the meaning "mailbox name 311 not allowed". When messages are rejected for other reasons, such as 312 the MAIL command requiring an ASCII address, the response code 550 is 313 used with the meaning "mailbox unavailable". When the server 314 supports enhanced mail system status codes [RFC3463], response code 315 "X.6.7" [RFC5248] is used, meaning that "UTF-8 addresses not 316 permitted for that sender/recipient". 318 If the response code is issued after the final "." of the DATA 319 command, the response code "554" is used with the meaning 320 "Transaction failed". When the server supports enhanced mail system 321 status codes [RFC3463], response code "X.6.9" [RFC5248] is used, 322 meaning that "UTF-8 header message can't be transferred to one or 323 more recipient so the message must be bounced". 325 3.5. Body Parts and SMTP Extensions 327 There is no ESMTP parameter to assert that a message is an 328 internationalized message. An SMTP server that requires accurate 329 knowledge of whether a message is internationalized is required to 330 parse all message header fields and MIME header fields in the message 331 body. 333 While this specification requires that servers support the 8BITMIME 334 extension [RFC1652] to ensure that servers have adequate handling 335 capability for 8-bit data and to avoid a number of complex encoding 336 problems, the use of internationalized addresses obviously does not 337 require non-ASCII body parts in the MIME message. The UTF8SMTPbis 338 extension MAY be used with the BODY=8BITMIME parameter if that is 339 appropriate given the body content or, with the BODY=BINARYMIME 340 parameter, if the server advertises BINARYMIME [RFC3030] and that is 341 appropriate. 343 Assuming that the server advertises UTF8SMTPbis and 8BITMIME, and 344 receives at least one non-ASCII address, the precise interpretation 345 of 'No BODY parameter', "BODY=8BITMIME", and "BODY=BINARYMIME" in the 346 MAIL command is: 347 1. If there is no BODY parameter, the header contains UTF-8 348 characters, but all the body parts are in ASCII (possibly as the 349 result of a content-transfer-encoding). 350 2. If a BODY=8BITMIME parameter is present, the header contains 351 UTF-8 characters, and some or all of the body parts contain 8-bit 352 line-oriented data. 353 3. If a BODY=BINARYMIME parameter is present, the header contains 354 UTF-8 characters, and some or all body parts contain binary data 355 without restriction as to line lengths or delimiters. 357 3.6. Additional ESMTP Changes and Clarifications 359 The information carried in the mail transport process involves 360 addresses ("mailboxes") and domain names in various contexts in 361 addition to the MAIL and RCPT commands and extended alternatives to 362 them. In general, the rule is that, when RFC 5321 specifies a 363 mailbox, this specification expects UTF-8 to be used for the entire 364 string; when RFC 5321 specifies a domain name, the name SHOULD be in 365 the form of ACE labels if its raw form is non-ASCII. 367 The following subsections list and discuss all of the relevant cases. 369 3.6.1. The Initial SMTP Exchange 371 When an SMTP connection is opened, the server normally sends a 372 "greeting" response consisting of the 220 response code and some 373 information. The client then sends the EHLO command. Since the 374 client cannot know whether the server supports UTF8SMTPbis until 375 after it receives the response from EHLO, any domain names that 376 appear in this dialogue, or in responses to EHLO, MUST be in the 377 hostname form, i.e., internationalized ones MUST be in the form of 378 ACE labels. 380 3.6.2. Mail eXchangers 382 Organizations often authorize multiple servers to accept mail 383 addressed to them. For example, the organization may itself operate 384 more than one server, and may also or instead have an agreement with 385 other organizations to accept mail as a backup. Authorized servers 386 are generally listed in MX records as described in RFC 5321. When 387 more than one server accepts mail for the domain-part of a mailbox, 388 it is strongly advised that either all or none of them support the 389 UTF8SMTPbis extension. Otherwise, surprising downgrades can happen 390 during temporary failures, which users might perceive as a serious 391 reliability issue. 393 3.6.3. Trace Information 395 When an SMTP server receives a message for delivery or further 396 processing, it MUST insert trace ("time stamp" or "Received") 397 information at the beginning of the message content. "Time stamp" or 398 "Received" appears in the form of "Received:" lines. The most 399 important use of Received: lines is for debugging mail faults. When 400 the delivery SMTP server makes the "final delivery" of a message, it 401 inserts a Return-path line at the beginning of the mail data. The 402 primary purpose of the Return-path is to designate the address to 403 which messages indicating non-delivery or other mail system failures 404 are to be sent. For the trace information, this memo updates the 405 time stamp line and the return path line [RFC5321] formally defined 406 as follows: 408 uReturn-path-line = "Return-Path:" FWS uReverse-path 409 ; Replaces Return-path-line in Section 4.4 of RFC 5321 410 ; uReverse-path is defined in Section 4 of RFC5335bis 412 uTime-stamp-line = "Received:" FWS uStamp 413 ; Replaces Time-stamp-line in Section 4.4 of RFC 5321 415 uStamp = From-domain By-domain uOpt-info ";" FWS date-time 416 ; Replaces Stamp in Section 4.4 of RFC 5321 418 uOpt-info = [Via] [With] [ID] [uFor] 419 ; Replaces Opt-info in Section 4.4 of RFC 5321 420 ; The protocol value for With will allow a UTF8SMTPbis value 422 uFor = "FOR" ( FWS (uPath / uMailbox) ) CFWS 423 ; Replaces For in Section 4.4 of RFC 5321 424 ; uMailbox is defined in section 3.3 of this document 426 uPath = "<" [ A-d-l ":" ] uMailbox ">" 427 ; Replace Path in RFC 5321, section 4.1.2 428 ; A-d-l is defined in RFC 5321, section 4.1.2 429 ; uMailbox is defined in section 3.3 of this document 431 Except in the 'uFor' clause and 'uReverse-path' value where non-ASCII 432 domain names may be used, internationalized domain names in Received 433 fields MUST be transmitted in the form of ACE labels. The protocol 434 value of the WITH clause when this extension is used is one of the 435 UTF8SMTPbis values specified in the "IANA Considerations" section of 436 this document. 438 3.6.4. UTF-8 Strings in Replies 440 3.6.4.1. MAIL and RCPT Commands 442 If the client issues a RCPT command containing non-ASCII characters, 443 the SMTP server is permitted to use UTF-8 characters in the email 444 address associated with 251 and 551 response codes. 446 If an SMTP client follows this specification and sends any RCPT 447 commands containing non-ASCII addresses, it MUST be able to accept 448 and process 251 or 551 responses containing UTF-8 email addresses. 449 If a given RCPT command does not include a non-ASCII envelope 450 address, the server MUST NOT return a 251 or 551 response containing 451 a non-ASCII mailbox. Instead, it MUST transform such responses into 452 250 or 550 responses that do not contain addresses. 454 3.6.4.2. VRFY and EXPN Commands and the UTF8REPLY Parameter 456 If the VRFY and EXPN commands are transmitted with the optional 457 parameter "UTF8REPLY", it indicates the client can accept UTF-8 458 strings in replies to those commands. This allows the server to use 459 UTF-8 strings in mailbox names and full names that occur in replies 460 without concern that the client might be confused by them. An SMTP 461 client that conforms to this specification MUST accept and correctly 462 process replies from the VRFY and EXPN commands that contain UTF-8 463 strings. However, the SMTP server MUST NOT use UTF-8 strings in 464 replies if the SMTP client does not specifically allow such replies 465 by transmitting this parameter. Most replies do not require that a 466 mailbox name be included in the returned text, and therefore UTF-8 is 467 not needed in them. Some replies, notably those resulting from 468 successful execution of the VRFY and EXPN commands, do include the 469 mailbox, making the provisions of this section important. 471 VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to: 473 "VRFY" SP ( uLocal-part / uMailbox ) [ SP "UTF8REPLY" ] CRLF 474 ; uLocal-part and uMailbox are defined in 475 ; Section 3.3 of this document. 477 "EXPN" SP ( uLocal-part / uMailbox ) [ SP "UTF8REPLY" ] CRLF 478 ; uLocal-part and uMailbox are defined in 479 ; Section 3.3 of this document. 481 The "UTF8REPLY" parameter does not use a value. If the reply to a 482 VERIFY (VRFY) or EXPAND (EXPN) command requires UTF-8, but the SMTP 483 client did not use the "UTF8REPLY" parameter, then the server MUST 484 use either the response code 252 or 550. Response code 252, defined 485 in [RFC5321], means "Cannot VRFY user, but will accept the message 486 and attempt the delivery". Response code 550, also defined in 487 [RFC5321], means "Requested action not taken: mailbox unavailable". 488 When the server supports enhanced mail system status codes [RFC3463], 489 the enhanced response code as specified below is used. Using the 490 "UTF8REPLY" parameter with a VERIFY (VRFY) or EXPAND (EXPN) command 491 enables UTF-8 replies for that command only. 493 If a normal success response (i.e., 250) is returned, the response 494 MAY include the full name of the user and MUST include the mailbox of 495 the user. It MUST be in either of the following forms: 497 User Name 498 ; uMailbox is defined in Section 3.3 of this document. 499 ; User Name can contain non-ASCII characters. 501 uMailbox 502 ; uMailbox is defined in Section 3.3 of this document. 504 If the SMTP reply requires UTF-8 strings, but UTF-8 is not allowed in 505 the reply, and the server supports enhanced mail system status codes 506 [RFC3463], the enhanced response code is either "X.6.8" or "X.6.10" 507 [RFC5248], meaning "A reply containing a UTF-8 string is required to 508 show the mailbox name, but that form of response is not permitted by 509 the client". 511 If the SMTP client does not support the UTF8SMTPbis extension, but 512 receives a UTF-8 string in a reply, it may not be able to properly 513 report the reply to the user, and some clients might crash. 514 Internationalized messages in replies are only allowed in the 515 commands under the situations described above. Under any other 516 circumstances, UTF-8 text MUST NOT appear in the reply. 518 Although UTF-8 is needed to represent email addresses in responses 519 under the rules specified in this section, this extension does not 520 permit the use of UTF-8 for any other purposes. SMTP servers MUST 521 NOT include non-ASCII characters in replies except in the limited 522 cases specifically permitted in this section. 524 4. IANA Considerations 526 IANA has added a new value "UTF8SMTPbis" to the SMTP Service 527 Extension subregistry of the Mail Parameters registry, according to 528 the following data: 530 +-------------+---------------------------------+-----------+ 531 | Keywords | Description | Reference | 532 +-------------+---------------------------------+-----------+ 533 | UTF8SMTPbis | Internationalized email address | [RFCXXXX] | 534 +-------------+---------------------------------+-----------+ 536 This document updates the values to the SMTP Enhanced Status Code 537 subregistry of the Mail Parameters registry, following the guidance 538 in Sections 3.4 and 3.6.4.2 of this document, and being based on 539 [RFC5248]. The registration data is as follows: 541 Code: X.6.7 542 Sample Text: UTF-8 addresses not permitted 543 for that sender/recipient 544 Associated basic status code: 553, 550 545 Description: This indicates the reception of a MAIL or RCPT 546 command that rUTF-8 addresses are not permitted 547 Defined: RFC XXXX (Standard track) 548 Submitter: Jiankang YAO 549 Change controller: IESG. 551 Code: X.6.8 552 Sample Text: UTF-8 string reply is required, 553 but not permitted by the client 554 Associated basic status code: 553, 550 555 Description: This indicates that a reply containing a UTF-8 556 string is required to show the mailbox name, 557 but that form of response is not 558 permitted by the client. 559 Defined: RFC XXXX (Standard track) 560 Submitter: Jiankang YAO 561 Change controller: IESG. 563 Code: X.6.9 564 Sample Text: UTF-8 header message can't be transferred 565 to one or more recipient so the message 566 must be bounced 567 Associated basic status code: 550 568 Description: This indicates that transaction failed 569 after the final "." of the DATA command. 570 Defined: RFC XXXX (Standard track) 571 Submitter: Jiankang YAO 572 Change controller: IESG. 574 Code: X.6.10 575 Sample Text: UTF-8 string reply is required, 576 but not permitted by the client 577 Associated basic status code: 252 578 Description: This indicates that a reply containing a UTF-8 579 string is required to show the mailbox name, 580 but that form of response is not 581 permitted by the client. 582 Defined: RFC XXXX (Standard track) 583 Submitter: Jiankang YAO 584 Change controller: IESG. 586 The "Mail Transmission Types" registry under the Mail Parameters 587 registry is requested to be updated to include the following new 588 entries: 590 +---------------+-----------------------------+---------------------+ 591 | WITH protocol | Description | Reference | 592 | types | | | 593 +---------------+-----------------------------+---------------------+ 594 | UTF8SMTPbis | UTF8SMTPbis with Service | [RFCXXXX] | 595 | | Extensions | | 596 | UTF8SMTPbisA | UTF8SMTPbis with SMTP AUTH | [RFC4954] [RFCXXXX] | 597 | UTF8SMTPbisS | UTF8SMTPbis with STARTTLS | [RFC3207] [RFCXXXX] | 598 | UTF8SMTPbisSA | UTF8SMTPbis with both | [RFC3207] [RFC4954] | 599 | | STARTTLS and SMTP AUTH | [RFCXXXX] | 600 +---------------+-----------------------------+---------------------+ 602 5. Security Considerations 604 See the extended security considerations discussion in the framework 605 document [RFC4952bis]. 607 6. Acknowledgements 609 Much of the text in the initial version of this specification was 610 derived or copied from [Emailaddr] with the permission of the author. 611 Significant comments and suggestions were received from Xiaodong LEE, 612 Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other members of the JET 613 team and were incorporated into the specification. Additional 614 important comments and suggestions, and often specific text, were 615 contributed by many members of the WG and design team. Those 616 contributions include material from John C Klensin, Charles Lindsey, 617 Dave Crocker, Harald Tveit Alvestrand, Marcos Sanz, Chris Newman, 618 Martin Duerst, Edmon Chung, Tony Finch, Kari Hurtta, Randall Gellens, 619 Frank Ellermann, Alexey Melnikov, Pete Resnick, S. Moonesamy, Soobok 620 Lee, Shawn Steele, Alfred Hoenes, Miguel Garcia, Magnus Westerlund, 621 and Lars Eggert. Of course, none of the individuals are necessarily 622 responsible for the combination of ideas represented here. 624 7. Change History 626 [[anchor11: RFC Editor: Please remove this section.]] 628 7.1. draft-yao-eai-rfc5336bis: Version 00 630 Applied errata suggested by Alfred Hoenes. 632 7.2. draft-ietf-eai-rfc5336bis: Version 00 634 Applied the changes suggested by the EAI new charter. 636 7.3. draft-ietf-eai-rfc5336bis: Version 01 638 Applied the changes suggested by 78 IETF EAI meeting. 640 8. References 642 8.1. Normative References 644 [ASCII] American National Standards Institute (formerly United 645 States of America Standards Institute), "USA Code for 646 Information Interchange", ANSI X3.4-1968, 1968. 648 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 649 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 650 RFC 1652, July 1994. 652 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 653 Requirement Levels", BCP 14, RFC 2119, March 1997. 655 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 656 Extension for Delivery Status Notifications (DSNs)", 657 RFC 3461, January 2003. 659 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 660 RFC 3463, January 2003. 662 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 663 for Delivery Status Notifications", RFC 3464, 664 January 2003. 666 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 667 10646", RFC 3629, November 2003. 669 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 670 RFC 4409, April 2006. 672 [RFC4952bis] 673 Klensin, J. and Y. Ko, "Overview and Framework for 674 Internationalized Email", RFC 4952, July 2007. 676 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 677 Specifications: ABNF", STD 68, RFC 5234, January 2008. 679 [RFC5248] Hansen , T. and J. Klensin, "A Registry for SMTP Enhanced 680 Mail System Status Codes", RFC 5248, June 2008. 682 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 683 October 2008. 685 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 686 October 2008. 688 [RFC5335bis] 689 Abel, Y., Ed., "Internationalized Email Headers", 690 RFC 5335, August 2008. 692 [RFC5337bis] 693 Newman, C. and A. Melnikov, Ed., "Internationalized 694 Delivery Status and Disposition Notifications", RFC 5337, 695 August 2008. 697 [RFC5890] Klensin, J., "Internationalizing Domain Names in 698 Applications (IDNA)", RFC 5890, June 2010. 700 [RFC5891] Klensin, J., "Internationalized Domain Names in 701 Applications (IDNA): Protocol", RFC 5891, August 2010. 703 8.2. Informative References 705 [Emailaddr] 706 Klensin, J., "Internationalization of Email Addresses", 707 draft-klensin-emailaddr-i18n-03 (work in progress), 708 July 2005. 710 [RFC0974] Partridge, C., "Mail routing and the domain system", 711 RFC 974, January 1986. 713 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 714 October 1996. 716 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 717 of Large and Binary MIME Messages", RFC 3030, 718 December 2000. 720 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 721 Transport Layer Security", RFC 3207, February 2002. 723 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 724 for Authentication", RFC 4954, July 2007. 726 Appendix A. Additional Material 728 A.1. Conventional Message and Internationalized Message 730 o A conventional message is one that does not use any extension 731 defined in this document or in the UTF-8 header specification 732 [RFC5335bis], and which is strictly conformant to RFC 5322 733 [RFC5322]. 734 o An internationalized message is a message utilizing one or more of 735 the extensions defined in this specification or in the UTF-8 736 header specification [RFC5335bis], so that it is no longer 737 conformant to the RFC 5322 specification of a message. 739 A.2. LMTP 741 LMTP [RFC2033] may be used as the final delivery agent. In such 742 cases, LMTP may be arranged to deliver the mail to the mail store. 743 The mail store may not have UTF8SMTPbis capability. LMTP needs to be 744 updated to deal with these situations. 746 A.3. SMTP Service Extension for DSNs 748 The existing Draft Standard regarding delivery status notifications 749 (DSNs) [RFC3461] is limited to ASCII text in the machine readable 750 portions of the protocol. "International Delivery and Disposition 751 Notifications" [RFC5337bis] adds a new address type for international 752 email addresses so an original recipient address with non-ASCII 753 characters can be correctly preserved even after downgrading. If an 754 SMTP server advertises both the UTF8SMTPbis and the DSN extension, 755 that server MUST implement EAI DSN [RFC5337bis] including support for 756 the ORCPT parameter. 758 A.4. Implementation Advice 760 In the absence of this extension, SMTP clients and servers are 761 constrained to using only those addresses permitted by RFC 5321. The 762 local parts of those addresses MAY be made up of any ASCII 763 characters, although some of them MUST be quoted as specified there. 764 It is notable in an internationalization context that there is a long 765 history on some systems of using overstruck ASCII characters (a 766 character, a backspace, and another character) within a quoted string 767 to approximate non-ASCII characters. This form of 768 internationalization SHOULD be phased out as this extension becomes 769 widely deployed, but backward-compatibility considerations require 770 that it continue to be supported. 772 Authors' Addresses 774 Jiankang YAO (editor) 775 CNNIC 776 No.4 South 4th Street, Zhongguancun 777 Beijing 779 Phone: +86 10 58813007 780 Email: yaojk@cnnic.cn 782 Wei MAO (editor) 783 CNNIC 784 No.4 South 4th Street, Zhongguancun 785 Beijing 787 Phone: +86 10 58812230 788 Email: maowei_ietf@cnnic.cn