idnits 2.17.1 draft-ietf-eai-rfc5336bis-10.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 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2, 2011) is 4713 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 634, but not defined == Unused Reference: 'RFC5891' is defined on line 817, but no explicit reference was found in the text == Unused Reference: 'RFC5336' is defined on line 844, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' ** 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: 5 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 (if approved) CNNIC 5 Updates: RFC5321 and 5322 June 2, 2011 6 (if approved) 7 Intended status: Standards Track 8 Expires: December 4, 2011 10 SMTP Extension for Internationalized Email Address 11 draft-ietf-eai-rfc5336bis-10.txt 13 Abstract 15 This document specifies an SMTP extension for transport and delivery 16 of email messages with internationalized email addresses or header 17 information. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 4, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.1. Role of This Specification . . . . . . . . . . . . . . . . 4 67 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.3. Updates to Other Specifications . . . . . . . . . . . . . 5 69 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 70 3. Mail Transport-Level Protocol . . . . . . . . . . . . . . . . 5 71 3.1. Framework for the Internationalization Extension . . . . . 5 72 3.2. The UTF8SMTPbis Extension . . . . . . . . . . . . . . . . 6 73 3.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 7 74 3.4. MAIL Command Parameter Usage . . . . . . . . . . . . . . . 9 75 3.5. Non-ASCII addresses and Reply-codes . . . . . . . . . . . 9 76 3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 10 77 3.7. Additional ESMTP Changes and Clarifications . . . . . . . 10 78 3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 10 79 3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 11 80 3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 11 81 3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 11 82 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 84 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . 17 89 7.4. draft-ietf-eai-rfc5336bis: Version 02 . . . . . . . . . . 17 90 7.5. draft-ietf-eai-rfc5336bis: Version 03 . . . . . . . . . . 17 91 7.6. draft-ietf-eai-rfc5336bis: Version 04 . . . . . . . . . . 17 92 7.7. draft-ietf-eai-rfc5336bis: Version 05 . . . . . . . . . . 17 93 7.8. draft-ietf-eai-rfc5336bis: Version 06 . . . . . . . . . . 17 94 7.9. draft-ietf-eai-rfc5336bis: Version 07 . . . . . . . . . . 17 95 7.10. draft-ietf-eai-rfc5336bis: Version 08 . . . . . . . . . . 17 96 7.11. draft-ietf-eai-rfc5336bis: Version 09 . . . . . . . . . . 17 97 7.12. draft-ietf-eai-rfc5336bis: Version 10 . . . . . . . . . . 18 98 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 99 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 100 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 103 1. Introduction 105 The Simple Mail Transfer Protocol [RFC5321] provides a negotiation 106 mechanism about service extension by which SMTP clients can discover 107 SMTP server capabilities and make decisions for further processing. 108 This document uses this mechanism and specifies an SMTP extension to 109 permit internationalized email addresses (see section 1.2) in the 110 SMTP envelope, and Unicode characters encoded in UTF-8 [RFC3629] in 111 the headers. An extended overview of the extension model for 112 internationalized email addresses and the email header appears in 113 [RFC4952bis], referred to as "the framework document" or just as 114 "framework" elsewhere in this specification. 116 [[anchor1: Note in Draft and to RFC Editor: The keyword represented 117 in this document by "UTF8SMTPbis" (and in the XML source 118 byUTF8SMTPbis) is a placeholder. The actual keyword will be assigned 119 when the standards track SMTP extension in this series [RFC5336bis- 120 SMTP] is approved for publication and should be substituted here. 121 This paragraph should be treated as normative reference to that SMTP 122 extension draft, creating a reference hold until it is approved by 123 the IESG. This paragraph should be removed before RFC publication.]] 125 1.1. Role of This Specification 127 The framework document [RFC4952bis] specifies the requirements for, 128 and describes components of, full internationalization of electronic 129 mail. A thorough understanding of the information in that document 130 and in the base Internet email specifications [RFC5321] [RFC5322] is 131 necessary to understand and implement this specification. 133 This document specifies an element of the email internationalization 134 work, specifically the definition of an SMTP extension for 135 internationalized email address transport delivery. 137 1.2. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC 2119 [RFC2119]. 143 The terms "UTF-8 string" or "UTF-8 character" are used to refer to 144 Unicode characters encoded in UTF-8. All other specialized terms 145 used in this specification are defined in the framework document or 146 in the base Internet email specifications. In particular, the terms 147 "ASCII address", "internationalized email address", "non-ASCII 148 address", "UTF8SMTPbis", "internationalized message", and "message" 149 are used in this document according to the definitions in the 150 framework document. 152 Non-ASCII characters or strings referred in this document MUST be 153 expressed in UTF-8, a standard Unicode Encoding Form. 155 This specification uses Augmented BNF (ABNF) rules [RFC5234]. Some 156 basic rules in this document can be found from [RFC5234] or [RFC5321] 157 or [RFC5322] under the same names. 159 1.3. Updates to Other Specifications 161 This specification modifies RFC 5321 by permitting internationalized 162 email address in the envelope. It also updates some syntax rules 163 defined in RFC 5321. It modifies RFC 5322 by permitting data formats 164 defined in [RFC5335bis]. It does not modify the 8BITMIME 165 specification [RFC6152] in any way, but it does require that the 166 8BITMIME extension be announced by the EAI-aware SMTP server and used 167 with "BODY=8BMITMIME" by the EAI-aware SMTP client. 169 2. Overview of Operation 171 This specification describes an optional extension to the email 172 transport mechanism that permits non-ASCII characters in both the 173 envelope and header fields of messages, which are encoded in UTF-8. 174 The extension is identified with the token "UTF8SMTPbis". 176 The EAI UTF-8 header specification [RFC5335bis] provides the details 177 of email header features enabled by this extension 179 3. Mail Transport-Level Protocol 181 3.1. Framework for the Internationalization Extension 183 The following service extension is defined: 184 1. The name of the SMTP service extension is "Email Address 185 Internationalization". 186 2. The EHLO keyword value associated with this extension is 187 "UTF8SMTPbis". 188 3. No parameter values are defined for this EHLO keyword value. In 189 order to permit future (although unanticipated) extensions, the 190 EHLO response MUST NOT contain any parameters for this keyword. 191 The EAI-aware SMTP client MUST ignore any parameters if they 192 appear for this keyword; that is, the EAI-aware SMTP client MUST 193 behave as if the parameters do not appear. If an SMTP server 194 includes UTF8SMTPbis in its EHLO response, it MUST be fully 195 compliant with this version of this specification. 197 4. One OPTIONAL parameter "UTF8SMTPbis" is added to the MAIL 198 command. The parameter has no value. If this parameter is set 199 in the MAIL command, it indicates that the SMTP client is EAI- 200 aware and asserts that the envelope includes the non-ASCII 201 address or the message being sent is internationalized message 202 or the message being sent needs the UTF8SMTPbis support. 203 5. The maximum length of a MAIL command line is increased by 12 204 characters by the possible addition of the UTF8SMTPbis 205 parameter. [[anchor6: RFC Editor: the number '12' will be 206 replaced by the new number (1 space + length of the new keyword 207 supposed to replace "UTF8SMTPbis").]] 208 6. One OPTIONAL parameter "UTF8SMTPbis" is added to the VRFY and 209 EXPN commands. The parameter UTF8SMTPbis has no value. The 210 parameter indicates that the SMTP client can accept Unicode 211 characters in UTF-8 encoding in replies from the VRFY and EXPN 212 commands. 213 7. No additional SMTP verbs are defined by this extension. 214 8. Servers offering this extension MUST provide support for, and 215 announce, the 8BITMIME extension [RFC6152]. 216 9. The reverse-path and forward-path of the SMTP MAIL and RCPT 217 commands are extended to allow Unicode characters encoded in 218 UTF-8 in mailbox names (addresses). 219 10. The mail message body is extended as specified in [RFC5335bis]. 220 11. The UTF8SMTPbis extension is valid on the submission port 221 [RFC4409], and can be used with LMTP [RFC2033]. 223 3.2. The UTF8SMTPbis Extension 225 An SMTP server that announces this UTF8SMTPbis extension MUST be 226 prepared to accept a UTF-8 string [RFC3629] in any position in which 227 RFC 5321 specifies that a can appear. Although the 228 characters in the are permitted to contain non-ASCII 229 characters, actual parsing of the , and the delimiters 230 used, are unchanged from the base email specification [RFC5321]. Any 231 domain names to be looked up in the DNS MUST allow for [RFC5890] 232 behavior. When doing lookups, the EAI-aware SMTP client or server 233 MUST either use a Unicode aware DNS library, or transform it to 234 A-label defined in [RFC5890]. 236 An SMTP client that receives the UTF8SMTPbis extension keyword in 237 response to the EHLO command MAY transmit mailbox names within SMTP 238 commands as internationalized strings in UTF-8 form. It MAY send a 239 UTF-8 header [RFC5335bis] (which may also include mailbox names in 240 UTF-8). It MAY transmit the domain parts of mailbox names within 241 SMTP commands or the message header as A-labels or U-labels 242 [RFC5890]. The presence of the UTF8SMTPbis extension does not change 243 RFC 5321 server relaying behaviors. 245 If the UTF8SMTPbis SMTP extension is not offered by the SMTP server, 246 the EAI-aware SMTP client MUST NOT transmit an internationalized 247 email address and MUST NOT transmit a mail message containing 248 internationalized mail headers as described in [RFC5335bis] at any 249 level within its MIME structure [RFC2045] and [RFC2047]. (For this 250 paragraph, the internationalized domain name in the form of A-labels 251 as specified in IDNA definitions [RFC5890] is not considered to be 252 "internationalized".) Instead, if an EAI-aware SMTP client (EAI- 253 aware SMTP sender) attempts to transfer an internationalized message 254 and encounters an SMTP server that does not support the extension, it 255 MUST make one of the following three choices and the priority order 256 is 1, 2 and 3. 258 1. It MAY either reject the message during the SMTP transaction or 259 accept the message and then generate and transmit a notification 260 of non-deliverability. Such notification MUST be done as 261 specified in RFC 5321 [RFC5321], RFC 3464 [RFC3464], and the EAI 262 delivery status notification (DSN) specification [RFC5337bis]. 263 2. If and only if the EAI-aware SMTP client (sender) is a Message 264 Submission Agent ("MSA") [RFC4409] [RFC5598], MSA may choose its 265 own way to deal with this scenario according to the provisions of 266 [RFC4409] or its future versions. But the detailed specification 267 of this process and its results is outside the scope of this 268 document. 269 3. It MAY find an alternate route to the destination that permits 270 UTF8SMTPbis. That route MAY be discovered by trying alternate 271 Mail eXchanger (MX) hosts (using preference rules as specified in 272 RFC 5321) or using other means available to the EAI-aware SMTP 273 client. 275 This document applies only when an EAI-aware SMTP client is trying to 276 send an internationalized message to an EAI-aware SMTP server. For 277 all other cases, and for addresses and messages that do not require 278 an UTF8SMTPbis extension, EAI-aware SMTP clients and servers do not 279 change the behavior specified in [RFC5321]. 281 An EAI-aware MUA/MSA sending to a legacy SMTP server [RFC5321] and 282 [RFC5322] MAY convert an ASCII@U-label [RFC5890] address into the 283 format of ASCII@A-label [RFC5890] if the email address is in the 284 format of ASCII@U-label. 286 3.3. Extended Mailbox Address Syntax 288 RFC 5321, section 4.1.2, defines the syntax of a entirely 289 in terms of ASCII characters. This document will make to 290 support non-ASCII characters. 292 The key changes made by this specification include: 294 o In order to update the to support the internationalized 295 email address, the ABNF rule will be importted from RFC 296 5321 directly, and other related rules are importted from RFC 297 5321, RFC 5234, RFC 5890 or RFC 5335bis, or are extended in this 298 document. 299 o Extend the definition of to permit both the RFC 5321 300 definition and a UTF-8 string in a DNS label that is conforming 301 with IDNA definitions [RFC5890]. 302 o Extend the definition of to permit both the RFC 5321 303 definition and a UTF-8 string. That string MUST NOT contain any 304 of the ASCII graphics or controls characters. 306 The following ABNF rules will be importted from RFC 5321, section 307 4.1.2 directly: 308 o 309 o 310 o 311 o 312 o 313 o 314 o 316 The following ABNF rule will be importted from RFC 5335bis, section 317 4.1 directly: 318 o 320 The following ABNF rule will be importted from RFC 5234, appendix B.1 321 directly: 322 o 324 The following ABNF rule will be importted from RFC 5890, section 325 2.3.2.1 directly: 326 o 328 The following rules are extended in ABNF [RFC5234] as follows. 330 sub-domain =/ U-label 331 ; extend the defintion of sub-domain in RFC5321, section 4.1.2 333 atext =/ UTF8-non-ascii 334 ; extend the defintion of atext in RFC5321, section 4.1.2 336 quoted-pairSMTP =/ %d92 UTF8-non-ascii 337 ; extend the defintion of quoted-pairSMTP in RFC5321, section 4.1.2 339 qtextSMTP =/ UTF8-non-ascii 340 ; extend the defintion of qtextSMTP in RFC5321, section 4.1.2 342 3.4. MAIL Command Parameter Usage 344 If the envelope or message being sent requires the capabilities of 345 the UTF8SMTPbis extension, the EAI-aware SMTP client MUST supply the 346 UTF8SMTPbis parameter with the MAIL command. If this parameter is 347 provided, it MUST have no value. If the EAI-aware SMTP client is 348 aware that neither the envelope nor the message being sent requires 349 any of the UTF8SMTPbis extension capabilities, it SHOULD NOT supply 350 the UTF8SMTPbis parameter with the MAIL command. 352 Because there is no guarantee that a next-hop SMTP server will 353 support the UTF8SMTPbis extension, use of the UTF8SMTPbis extension 354 always carries a risk of transmission failure. In fact, during the 355 early stages of deployment for the UTF8SMTPbis extension, the risk 356 will be quite high. Hence there is a distinct near-term advantage 357 for ASCII-only messages to be sent without using this extension. The 358 long-term advantage of casting ASCII [ASCII] characters(0x7f and 359 below) as UTF-8 form is that it permits pure-Unicode environments. 361 This specification does not require that the EAI-aware SMTP client 362 inspect the message or otherwise go to extraordinary lengths to 363 assure itself whether the UTF8SMTPbis extension is REQUIRED for the 364 particular message. 366 3.5. Non-ASCII addresses and Reply-codes 368 An EAI-aware SMTP client MUST only send an internationalized message 369 to an SMTP server that supports UTF8SMTPbis. If the SMTP server does 370 not support this option, then the EAI-aware SMTP client has three 371 choices according to section 3.2 of this specification. 373 The three-digit Reply-codes used in this section are based on their 374 meanings as defined in RFC 5321. 376 When messages are rejected because the RCPT command requires an ASCII 377 address, the reply-code 553 is returned with the meaning "mailbox 378 name not allowed". When messages are rejected because the MAIL 379 command requires an ASCII address, the reply-code 550 is returned 380 with the meaning "mailbox unavailable". When the EAI-aware SMTP 381 server supports enhanced mail system status codes [RFC3463], reply- 382 code "X.6.7" [RFC5248] is used, meaning that "non-ASCII addresses not 383 permitted for that sender/recipient". 385 When messages are rejected for other reasons, the server follows the 386 model of the base email specifications in RFC 5321; this extension 387 does not change those circumstances or reply messages. 389 If the reply-code is issued after the final "." of the DATA command, 390 the reply-code "554" is used with the meaning "Transaction failed". 391 When the EAI-aware SMTP server supports enhanced mail system status 392 codes [RFC3463], reply-code "X.6.9" [RFC5248] is used, meaning that 393 "UTF-8 header message can not be transmitted to one or more 394 recipients, so the message MUST be rejected". 396 3.6. Body Parts and SMTP Extensions 398 The MAIL command parameter UTF8SMTPbis asserts that a message is an 399 internationalized message or the message being sent needs the 400 UTF8SMTPbis support. The message being sent via the MAIL command 401 with the UTF8SMTPbis parameter has still a chance of that the message 402 transmitted is not an internationalized message. An EAI-aware SMTP 403 client or server that requires accurate knowledge of whether a 404 message is internationalized needs to parse all message header fields 405 and MIME header fields [RFC2045] and [RFC2047] in the message body. 406 However, this specification does not require that the EAI-aware SMTP 407 client or server inspects the message. 409 While this specification requires that EAI-aware SMTP servers support 410 the 8BITMIME extension [RFC6152] to ensure that servers have adequate 411 handling capability for 8-bit data and to avoid a number of complex 412 encoding problems, the use of internationalized email addresses 413 obviously does not require non-ASCII body parts in the MIME message 414 in RFC 2045 and RFC 2047. The UTF8SMTPbis extension MAY be used with 415 the BODY=8BITMIME parameter [RFC6152] if that is appropriate given 416 the body content or, with the BODY=BINARYMIME parameter, if the SMTP 417 server advertises BINARYMIME [RFC3030] and that is appropriate. 419 3.7. Additional ESMTP Changes and Clarifications 421 The information carried in the mail transport process involves 422 addresses ("mailboxes") and domain names in various contexts in 423 addition to the MAIL and RCPT commands and extended alternatives to 424 them. In general, the rule is that, when RFC 5321 specifies a 425 mailbox, this SMTP extension requires UTF-8 form to be used for the 426 entire string; when RFC 5321 specifies a domain name, the name SHOULD 427 be in the form of A-label if this domain name is an internationalized 428 domain name[RFC5890]. 430 The following subsections list and discuss all of the relevant cases. 432 3.7.1. The Initial SMTP Exchange 434 When an SMTP connection is opened, the SMTP server sends a "greeting" 435 response consisting of the 220 reply-code and some information. The 436 SMTP client then sends the EHLO command. Since the SMTP client 437 cannot know whether the SMTP server supports UTF8SMTPbis until after 438 it receives the response from EHLO, the EAI-aware SMTP client MUST 439 send only ASCII (LDH label or A-label [RFC5890] ) domains in the EHLO 440 command and that, if the EAI-aware SMTP server provides domain names 441 in the EHLO response, they MUST be in the form of LDH labels or 442 A-labels. 444 3.7.2. Mail eXchangers 446 If multiple DNS MX records are used to specify multiple servers for a 447 domain in section 5 of [RFC5321], it is strongly advised that all or 448 none of them SHOULD support the UTF8SMTPbis extension. Otherwise, 449 surprising rejections can happen during temporary or permanent 450 failures, which users might perceive as serious reliability issues. 452 3.7.3. Trace Information 454 The trace information , and their 455 related rules have been defined in in section 4.4 of RFC 5321 456 [RFC5321]. This document has updated and to 457 support non-ASCII characters. So Return-path-line may include the 458 'Reverse-path' clause where internationalized domain name with the 459 U-label form may be used. Time-stamp-line may include the 'For' 460 clause where the internationalized domain name with the U-label form 461 may be used. 463 Except in the 'For' clause and 'Reverse-path' clause where 464 internationalized domain name with the U-label form MAY be used, 465 internationalized domain names in Received fields MUST be transmitted 466 in the form of A-labels. The protocol value of the 'WITH' clause 467 when this extension is used is one of the UTF8SMTPbis values 468 specified in the "IANA Considerations" section of this document. 470 3.7.4. UTF-8 Strings in Replies 472 3.7.4.1. MAIL Command 474 If an SMTP client follows this specification and sends any MAIL 475 commands containing the UTF8SMTPbis parameter, the EAI-aware SMTP 476 server is permitted to use UTF-8 characters in the email address 477 associated with 251 and 551 reply-codes, and the SMTP client MUST be 478 able to accept and process them. If a given MAIL command does not 479 include the UTF8SMTPbis parameter, the EAI-aware SMTP server MUST NOT 480 return a 251 or 551 response containing a non-ASCII mailbox. 481 Instead, it MUST transform such responses into 250 or 550 responses 482 that do not contain non-ASCII addresses. 484 3.7.4.2. VRFY and EXPN Commands and the UTF8SMTPbis Parameter 486 If the VRFY and EXPN commands are transmitted with the parameter 487 "UTF8SMTPbis", it indicates the SMTP client can accept UTF-8 strings 488 in replies to those commands. This parameter for the VRFY and EXPN 489 commands SHOULD only be used after the SMTP client sees the EHLO 490 response with the UTF8SMTPbis keyword. This allows the EAI-aware 491 SMTP server to use UTF-8 strings in mailbox names and full names that 492 occur in replies without concern that the SMTP client might be 493 confused by them. An SMTP client that conforms to this specification 494 MUST accept and correctly process replies from the VRFY and EXPN 495 commands that contain UTF-8 strings. However, the EAI-aware SMTP 496 server MUST NOT use UTF-8 strings in replies if the SMTP client does 497 not specifically allow such replies by transmitting this parameter. 498 Most replies do not require that a mailbox name be included in the 499 returned text, and therefore UTF-8 string is not needed in them. 500 Some replies, notably those resulting from successful execution of 501 the VRFY and EXPN commands, do include the mailbox. 503 VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to: 505 vrfy = "VRFY" SP String 506 [ SP "UTF8SMTPbis" ] CRLF 507 ; String may include UTF-8 characters 509 expn = "EXPN" SP String 510 [ SP "UTF8SMTPbis" ] CRLF 511 ; String may include UTF-8 characters 513 The "UTF8SMTPbis" parameter does not use a value. If the reply to a 514 VERIFY (VRFY) or EXPAND (EXPN) command requires UTF-8 string, but the 515 SMTP client did not use the "UTF8SMTPbis" parameter, then the EAI- 516 aware SMTP server MUST use either the reply-code 252 or 550. Reply- 517 code 252, defined in [RFC5321], means "Cannot VRFY user, but will 518 accept the message and attempt the delivery". Reply-code 550, also 519 defined in [RFC5321], means "Requested action not taken: mailbox 520 unavailable". When the EAI-aware SMTP server supports enhanced mail 521 system status codes [RFC3463], the enhanced reply-code as specified 522 below is used. Using the "UTF8SMTPbis" parameter with a VERIFY 523 (VRFY) or EXPAND (EXPN) command enables UTF-8 replies for that 524 command only. 526 If a normal success response (i.e., 250) is returned, the response 527 MAY include the full name of the user and MUST include the mailbox of 528 the user. It MUST be in either of the following forms: 530 User Name 531 ; Mailbox is defined in section 3.3 of this document. 532 ; User Name can contain non-ASCII characters. 534 Mailbox 535 ; Mailbox is defined in section 3.3 of this document. 537 If the SMTP reply requires UTF-8 strings, but UTF-8 string is not 538 allowed in the reply, and the EAI-aware SMTP server supports enhanced 539 mail system status codes [RFC3463], the enhanced reply-code is 540 "X.6.8" [RFC5248], meaning "A reply containing a UTF-8 string is 541 REQUIRED to show the mailbox name, but that form of response is not 542 permitted by the SMTP client". 544 If the SMTP client does not support the UTF8SMTPbis extension, but 545 receives a UTF-8 string in a reply, it may not be able to properly 546 report the reply to the user, and some clients might crash. 547 Internationalized messages in replies are only allowed in the 548 commands under the situations described above. Under any other 549 circumstances, UTF-8 string MUST NOT appear in the reply. 551 Although UTF-8 form is needed to represent email addresses in 552 responses under the rules specified in this section, this extension 553 does not permit the use of UTF-8 string for any other purposes. EAI- 554 aware SMTP servers MUST NOT include non-ASCII characters in replies 555 except in the limited cases specifically permitted in this section. 557 4. IANA Considerations 559 IANA is requested to add a new value "UTF8SMTPbis" to the SMTP 560 Service Extension subregistry of the Mail Parameters registry, 561 according to the following data: 563 +-------------+---------------------------------+-----------+ 564 | Keywords | Description | Reference | 565 +-------------+---------------------------------+-----------+ 566 | UTF8SMTPbis | Internationalized email address | [RFCXXXX] | 567 +-------------+---------------------------------+-----------+ 569 This document updates the values to the SMTP Enhanced Status Code 570 subregistry of the Mail Parameters registry, following the guidance 571 in Sections 3.5 and 3.7.4.2 of this document, and being based on 572 [RFC5248]. The registration data is as follows: 574 Code: X.6.7 575 Sample Text: non-ASCII addresses not permitted 576 for that sender/recipient 577 Associated basic status code: 550, 553 578 Description: This indicates the reception of a MAIL or RCPT 579 command that non-ASCII addresses are not permitted 580 Defined: RFC XXXX (Standard track) 581 Submitter: Jiankang YAO 582 Change controller: ima@ietf.org 584 Code: X.6.8 585 Sample Text: UTF-8 string reply is required, 586 but not permitted by the SMTP client 587 Associated basic status code: 252, 550, 553 588 Description: This indicates that a reply containing a UTF-8 589 string is required to show the mailbox name, 590 but that form of response is not 591 permitted by the SMTP client. 592 Defined: RFC XXXX (Standard track) 593 Submitter: Jiankang YAO 594 Change controller: ima@ietf.org 596 Code: X.6.9 597 Sample Text: UTF-8 header message can not be transferred 598 to one or more recipient so the message 599 must be rejected 600 Associated basic status code: 550 601 Description: This indicates that transaction failed 602 after the final "." of the DATA command. 603 Defined: RFC XXXX (Standard track) 604 Submitter: Jiankang YAO 605 Change controller: ima@ietf.org 607 Code: X.6.10 608 Description: This is a duplicate of X.6.8 and 609 is thus deprecated. 611 The following entries SHOULD be updated or added in the "Mail 612 Transmission Types" registry under the Mail Parameters registry. 614 +--------------+-------------------------------+--------------------+ 615 | WITH | Description | Reference | 616 | protocol | | | 617 | types | | | 618 +--------------+-------------------------------+--------------------+ 619 | UTF8SMTP | ESMTP with UTF8SMTP | [RFCXXXX] | 620 | UTF8SMTPA | ESMTP with UTF8SMTP and SMTP | [RFC4954] | 621 | | AUTH | [RFCXXXX] | 622 | UTF8SMTPS | ESMTP with UTF8SMTP and | [RFC3207] | 623 | | STARTTLS | [RFCXXXX] | 624 | UTF8SMTPSA | ESMTP with UTF8SMTP and both | [RFC3207] | 625 | | STARTTLS and SMTP AUTH | [RFC4954] | 626 | | | [RFCXXXX] | 627 | UTF8LMTP | LMTP with UTF8SMTP | [RFCXXXX] | 628 | UTF8LMTPA | LMTP with UTF8SMTP and SMTP | [RFC4954] | 629 | | AUTH | [RFCXXXX] | 630 | UTF8LMTPS | LMTP with UTF8SMTP and | [RFC3207] | 631 | | STARTTLS | [RFCXXXX] | 632 | UTF8LMTPSA | LMTP with UTF8SMTP and both | [RFC3207] | 633 | | STARTTLS and LMTP AUTH | [RFC4954] | 634 | | | [RFCXXXX] | 635 +--------------+-------------------------------+--------------------+ 637 5. Security Considerations 639 The extended security considerations discussion in the framework 640 document [RFC4952bis] will be applied here. 642 More security considerations are discussed below: 644 Beyond the use inside the email global system (in SMTP envelopes and 645 message headers), internationalized email addresses will also show up 646 inside other cases, in particular: 648 o the logging systems of SMTP transactions and other logs to monitor 649 the email systems; 650 o the trouble ticket systems used by Security Teams to manage 651 security incidents, when an email address is involved; 653 In order to avoid problems that could cause loss of data, this will 654 likely require extending these systems to support full UTF-8, or to 655 require to provide an adequate mechanisms for mapping non-ASCII 656 strings to ASCII. 658 Another security aspect to be considered is related to the ability by 659 security team members to quickly understand, read and identify email 660 addresses from the logs, when they are tracking an incident. 662 Mechanims to automatically and quickly provide the origin or 663 ownership of an internationalized email address SHALL be implemented 664 for use also by log readers which cannot read easily non-ASCII 665 information. 667 The SMTP commands VRFY and EXPN are sometimes used in SMTP 668 transactions where there is no message to transfer (by tools used to 669 take automated actions in case potential spam messages are 670 identified). RFC 5321 section 3.5 and 7.3 give some detailed 671 description of use and possible behaviours. Implementation of 672 internationalized addrsses can affect also logs and actions by these 673 tools. 675 6. Acknowledgements 677 This document revised the [RFC5336]document based on the EAI WG's 678 discussion result. Many EAI WG members did some tests and 679 implementations to move this document to the Standard Track document. 680 Significant comments and suggestions were received from Xiaodong LEE, 681 Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other members of the JET 682 team and were incorporated into the specification. Additional 683 important comments and suggestions, and often specific text, were 684 contributed by many members of the WG and design team. Those 685 contributions include material from John C Klensin, Charles Lindsey, 686 Dave Crocker, Harald Tveit Alvestrand, Marcos Sanz, Chris Newman, 687 Martin Duerst, Edmon Chung, Tony Finch, Kari Hurtta, Randall Gellens, 688 Frank Ellermann, Alexey Melnikov, Pete Resnick, S. Moonesamy, Soobok 689 Lee, Shawn Steele, Alfred Hoenes, Miguel Garcia, Magnus Westerlund, 690 and Lars Eggert. Of course, none of the individuals are necessarily 691 responsible for the combination of ideas represented here. 693 Thanks a lot to Dave Crocker for his comments and helping of ABNF 694 refinement. 696 7. Change History 698 [[anchor14: RFC Editor: Please remove this section.]] 700 7.1. draft-yao-eai-rfc5336bis: Version 00 702 Applied errata suggested by Alfred Hoenes. 704 7.2. draft-ietf-eai-rfc5336bis: Version 00 706 Applied the changes suggested by the EAI new charter. 708 7.3. draft-ietf-eai-rfc5336bis: Version 01 710 Applied the changes suggested by 78 IETF EAI meeting. 712 7.4. draft-ietf-eai-rfc5336bis: Version 02 714 remove the appendix since rfc4952bis has added this material 716 improve the text 718 remove the text about no body parameter 720 7.5. draft-ietf-eai-rfc5336bis: Version 03 722 improve the text 724 7.6. draft-ietf-eai-rfc5336bis: Version 04 726 update the abstract 728 improve the text 730 7.7. draft-ietf-eai-rfc5336bis: Version 05 732 improve the text based on AD and Co-chairs 734 7.8. draft-ietf-eai-rfc5336bis: Version 06 736 update the iana consideration 738 7.9. draft-ietf-eai-rfc5336bis: Version 07 740 improve the iana consideration 742 7.10. draft-ietf-eai-rfc5336bis: Version 08 744 improve the texts 746 add the mail parameter 748 add the new section about mail command parameter usage 750 update the security consideration 752 7.11. draft-ietf-eai-rfc5336bis: Version 09 754 improve the texts 756 7.12. draft-ietf-eai-rfc5336bis: Version 10 758 refine the ABNF definitions 760 improve the texts 762 8. References 764 8.1. Normative References 766 [ASCII] American National Standards Institute (formerly United 767 States of America Standards Institute), "USA Code for 768 Information Interchange", ANSI X3.4-1968, 1968. 770 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 771 October 1996. 773 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 774 Requirement Levels", BCP 14, RFC 2119, March 1997. 776 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 777 RFC 3463, January 2003. 779 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 780 for Delivery Status Notifications", RFC 3464, 781 January 2003. 783 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 784 10646", RFC 3629, November 2003. 786 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 787 RFC 4409, April 2006. 789 [RFC4952bis] 790 Klensin, J. and Y. Ko, "Overview and Framework for 791 Internationalized Email", I-D rfc4952bis, September 2010. 793 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 794 Specifications: ABNF", STD 68, RFC 5234, January 2008. 796 [RFC5248] Hansen , T. and J. Klensin, "A Registry for SMTP Enhanced 797 Mail System Status Codes", RFC 5248, June 2008. 799 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 800 October 2008. 802 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 803 October 2008. 805 [RFC5335bis] 806 Abel, Y. and S. Steel, "Internationalized Email Headers", 807 I-D rfc5335bis, March 2011. 809 [RFC5337bis] 810 Hansen, T., Ed., Newman, C., and A. Melnikov, Ed., 811 "Internationalized Delivery Status and Disposition 812 Notifications", I-D 5337bis, October 2010. 814 [RFC5890] Klensin, J., "Internationalizing Domain Names in 815 Applications (IDNA definitions)", RFC 5890, June 2010. 817 [RFC5891] Klensin, J., "Internationalized Domain Names in 818 Applications (IDNA): Protocol", RFC 5891, August 2010. 820 [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP 821 Service Extension for 8-bit MIME Transport", STD 71, 822 RFC 6152, March 2011. 824 8.2. Informative References 826 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 827 Extensions (MIME) Part One: Format of Internet Message 828 Bodies", RFC 2045, November 1996. 830 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 831 Part Three: Message Header Extensions for Non-ASCII Text", 832 RFC 2047, November 1996. 834 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 835 of Large and Binary MIME Messages", RFC 3030, 836 December 2000. 838 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 839 Transport Layer Security", RFC 3207, February 2002. 841 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 842 for Authentication", RFC 4954, July 2007. 844 [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized 845 Email Addresses", RFC 5336, September 2008. 847 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 848 July 2009. 850 Authors' Addresses 852 Jiankang YAO 853 CNNIC 854 No.4 South 4th Street, Zhongguancun 855 Beijing 857 Phone: +86 10 58813007 858 Email: yaojk@cnnic.cn 860 Wei MAO 861 CNNIC 862 No.4 South 4th Street, Zhongguancun 863 Beijing 865 Phone: +86 10 58812230 866 Email: maowei_ietf@cnnic.cn