idnits 2.17.1 draft-ietf-eai-rfc5336bis-14.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 draft header indicates that this document obsoletes RFC5336, but the abstract doesn't seem to mention this, which it should. 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 (October 6, 2011) is 4579 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 642, but not defined -- 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 (~~), 4 warnings (==), 4 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: 5336 (if approved) CNNIC 5 Intended status: Standards Track October 6, 2011 6 Expires: April 8, 2012 8 SMTP Extension for Internationalized Email 9 draft-ietf-eai-rfc5336bis-14.txt 11 Abstract 13 This document specifies an SMTP extension for transport and delivery 14 of email messages with internationalized email addresses or header 15 information. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 8, 2012. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 This document may contain material from IETF Documents or IETF 50 Contributions published or made publicly available before November 51 10, 2008. The person(s) controlling the copyright in some of this 52 material may not have granted the IETF Trust the right to allow 53 modifications of such material outside the IETF Standards Process. 54 Without obtaining an adequate license from the person(s) controlling 55 the copyright in such materials, this document may not be modified 56 outside the IETF Standards Process, and derivative works of it may 57 not be created outside the IETF Standards Process, except to format 58 it for publication as an RFC or to translate it into languages other 59 than English. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2. Updates to Other Specifications . . . . . . . . . . . . . 5 66 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 67 3. Mail Transport-Level Protocol . . . . . . . . . . . . . . . . 5 68 3.1. Framework for the Internationalization Extension . . . . . 5 69 3.2. The UTF8SMTPbis Extension . . . . . . . . . . . . . . . . 6 70 3.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 7 71 3.4. MAIL Command Parameter Usage . . . . . . . . . . . . . . . 9 72 3.5. Non-ASCII addresses and Reply-codes . . . . . . . . . . . 9 73 3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 10 74 3.7. Additional ESMTP Changes and Clarifications . . . . . . . 10 75 3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 11 76 3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 11 77 3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 11 78 3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 12 79 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 82 7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 16 83 7.1. draft-yao-eai-rfc5336bis: Version 00 . . . . . . . . . . . 17 84 7.2. draft-ietf-eai-rfc5336bis: Version 00 . . . . . . . . . . 17 85 7.3. draft-ietf-eai-rfc5336bis: Version 01 . . . . . . . . . . 17 86 7.4. draft-ietf-eai-rfc5336bis: Version 02 . . . . . . . . . . 17 87 7.5. draft-ietf-eai-rfc5336bis: Version 03 . . . . . . . . . . 17 88 7.6. draft-ietf-eai-rfc5336bis: Version 04 . . . . . . . . . . 17 89 7.7. draft-ietf-eai-rfc5336bis: Version 05 . . . . . . . . . . 17 90 7.8. draft-ietf-eai-rfc5336bis: Version 06 . . . . . . . . . . 17 91 7.9. draft-ietf-eai-rfc5336bis: Version 07 . . . . . . . . . . 17 92 7.10. draft-ietf-eai-rfc5336bis: Version 08 . . . . . . . . . . 17 93 7.11. draft-ietf-eai-rfc5336bis: Version 09 . . . . . . . . . . 18 94 7.12. draft-ietf-eai-rfc5336bis: Version 10 . . . . . . . . . . 18 95 7.13. draft-ietf-eai-rfc5336bis: Version 11 . . . . . . . . . . 18 96 7.14. draft-ietf-eai-rfc5336bis: Version 12 . . . . . . . . . . 18 97 7.15. draft-ietf-eai-rfc5336bis: Version 13 . . . . . . . . . . 18 98 7.16. draft-ietf-eai-rfc5336bis: Version 14 . . . . . . . . . . 18 99 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 100 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 101 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 104 1. Introduction 106 The document defines a Simple Mail Transfer Protocol [RFC5321] 107 extension so servers can advertise the ability to accept and process 108 internationalized email addresses (see section 1.1), and 109 internationalized email headers [RFC5335bis]. 111 An extended overview of the extension model for internationalized 112 email addresses and the email header appears in [RFC4952bis], 113 referred to as "the framework document" in this specification. A 114 thorough understanding of the information in that document and in the 115 base Internet email specifications [RFC5321] [RFC5322] is necessary 116 to understand and implement this specification. 118 [[anchor1: Note in Draft and to RFC Editor: The keyword represented 119 in this document by "UTF8SMTPbis" (and in the XML source 120 byUTF8SMTPbis) is a placeholder. The actual keyword will be assigned 121 when the standards track SMTP extension in this series [RFC5336bis- 122 SMTP] is approved for publication and should be substituted here. 123 This paragraph should be treated as normative reference to that SMTP 124 extension draft, creating a reference hold until it is approved by 125 the IESG. This paragraph should be removed before RFC publication.]] 127 1.1. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 The terms "UTF-8 string" or "UTF-8 character" are used to refer to 134 Unicode characters encoded in UTF-8. All other specialized terms 135 used in this specification are defined in the framework document or 136 in the base Internet email specifications. In particular, the terms 137 "ASCII address", "internationalized email address", "non-ASCII 138 address", "UTF8SMTPbis", "internationalized message", and "message" 139 are used in this document according to the definitions in the 140 framework document. 142 Non-ASCII characters or strings referred in this document MUST be 143 expressed in UTF-8, a standard Unicode Encoding Form. 145 This specification uses Augmented BNF (ABNF) rules [RFC5234]. Some 146 basic rules in this document can be found from [RFC5234] or [RFC5321] 147 under the same names. 149 1.2. Updates to Other Specifications 151 This specification extends some syntax rules defined in RFC 5321 and 152 permits internationalized email addresses in the envelope, but it 153 does not modify RFC 5321. It permits data formats defined in 154 [RFC5335bis], but it does not modify RFC 5322. It does require that 155 the 8BITMIME extension [RFC6152] be announced by the UTF8SMTPbis- 156 aware SMTP server and used with "BODY=8BMITMIME" by the UTF8SMTPbis- 157 aware SMTP client, but it does not modify the 8BITMIME specification 158 in any way. 160 This specification replaces an earlier, experimental, approach to the 161 same problem [RFC5336]. 163 2. Overview of Operation 165 This document specifies an element of the email internationalization 166 work, specifically the definition of an SMTP extension for 167 internationalized email. The extension is identified with the token 168 "UTF8SMTPbis". 170 The internationalized email headers specification [RFC5335bis] 171 provides the details of email header features enabled by this 172 extension 174 3. Mail Transport-Level Protocol 176 3.1. Framework for the Internationalization Extension 178 The following service extension is defined: 179 1. The name of the SMTP service extension is "Internationalized 180 Email". 181 2. The EHLO keyword value associated with this extension is 182 "UTF8SMTPbis". 183 3. No parameter values are defined for this EHLO keyword value. In 184 order to permit future (although unanticipated) extensions, the 185 EHLO response MUST NOT contain any parameters for this keyword. 186 The UTF8SMTPbis-aware SMTP client MUST ignore any parameters if 187 they appear for this keyword; that is, the UTF8SMTPbis-aware 188 SMTP client MUST behave as if the parameters do not appear. If 189 an SMTP server includes UTF8SMTPbis in its EHLO response, it 190 MUST be fully compliant with this version of this specification. 191 4. One OPTIONAL parameter "UTF8SMTPbis" is added to the MAIL 192 command. The parameter has no value. If this parameter is set 193 in the MAIL command, it indicates that the SMTP client is 194 UTF8SMTPbis-aware and asserts that the envelope includes the 195 non-ASCII address or the message being sent is internationalized 196 message or the message being sent needs the UTF8SMTPbis support. 197 5. The maximum length of a MAIL command line is increased by 13 198 characters by the possible addition of the UTF8SMTPbis 199 parameter. [[anchor5: RFC Editor: the number '13' will be 200 replaced by the new number (2 spaces + length of the new keyword 201 supposed to replace "UTF8SMTPbis").]] 202 6. One OPTIONAL parameter "UTF8SMTPbis" is added to the VRFY and 203 EXPN commands. The parameter UTF8SMTPbis has no value. The 204 parameter indicates that the SMTP client can accept Unicode 205 characters in UTF-8 encoding in replies from the VRFY and EXPN 206 commands. 207 7. No additional SMTP verbs are defined by this extension. 208 8. Servers offering this extension MUST provide support for, and 209 announce, the 8BITMIME extension [RFC6152]. 210 9. The reverse-path and forward-path of the SMTP MAIL and RCPT 211 commands are extended to allow Unicode characters encoded in 212 UTF-8 in mailbox names (addresses). 213 10. The mail message body is extended as specified in [RFC5335bis]. 214 11. The UTF8SMTPbis extension is valid on the submission port 215 [RFC4409], and can be used with LMTP [RFC2033]. 217 3.2. The UTF8SMTPbis Extension 219 An SMTP server that announces this UTF8SMTPbis extension MUST be 220 prepared to accept a UTF-8 string [RFC3629] in any position in which 221 RFC 5321 specifies that a can appear. Although the 222 characters in the are permitted to contain non-ASCII 223 characters, actual parsing of the , and the delimiters 224 used, are unchanged from the base email specification [RFC5321]. Any 225 domain name to be looked up in the DNS MUST allow for [RFC5890] 226 behavior. When doing lookups, the UTF8SMTPbis-aware SMTP client or 227 server MUST either use a Unicode aware DNS library, or transform the 228 internationalized domain name to the form of A-label as described in 229 [RFC5890]. 231 An SMTP client that receives the UTF8SMTPbis extension keyword in 232 response to the EHLO command MAY transmit mailbox names within SMTP 233 commands as internationalized strings in UTF-8 form. It MAY send a 234 UTF-8 header [RFC5335bis] (which may also include mailbox names in 235 UTF-8). It MAY transmit the domain parts of mailbox names within 236 SMTP commands or the message header as A-labels or U-labels 237 [RFC5890]. The presence of the UTF8SMTPbis extension does not change 238 RFC 5321 server relaying behaviors. 240 If the UTF8SMTPbis SMTP extension is not offered by the SMTP server, 241 the UTF8SMTPbis-aware SMTP client MUST NOT transmit an 242 internationalized email address and MUST NOT transmit a mail message 243 containing internationalized mail headers as described in 244 [RFC5335bis] at any level within its MIME structure [RFC2045] and 245 [RFC2047]. (For this paragraph, the internationalized domain name in 246 the form of A-labels as specified in IDNA definitions [RFC5890] is 247 not considered to be "internationalized".) Instead, if a 248 UTF8SMTPbis-aware SMTP client (UTF8SMTPbis-aware SMTP sender) 249 attempts to transfer an internationalized message and encounters an 250 SMTP server that does not support the extension, it MUST make one of 251 the following three choices and the priority order is 1, 2 and 3. 253 1. It MAY either reject the message during the SMTP transaction or 254 accept the message and then generate and transmit a notification 255 of non-deliverability. Such notification MUST be done as 256 specified in RFC 5321 [RFC5321], RFC 3464 [RFC3464], and the 257 internationalized delivery status and disposition notifications 258 specification [RFC5337bis]. 259 2. If and only if the UTF8SMTPbis-aware SMTP client (sender) is a 260 Message Submission Agent ("MSA") [RFC4409] [RFC5598], it may 261 choose its own way to deal with this scenario according to the 262 provisions of [RFC4409] or its future versions. But the detailed 263 specification of this process and its results are outside the 264 scope of this document. 265 3. It MAY find an alternate route to the destination that permits 266 UTF8SMTPbis. That route MAY be discovered by trying alternate 267 Mail eXchanger (MX) hosts (using preference rules as specified in 268 RFC 5321) or using other means available to the UTF8SMTPbis-aware 269 SMTP client. 271 This document applies when a UTF8SMTPbis-aware SMTP client or server 272 supports the UTF8SMTPbis extension. For all other cases, and for 273 addresses and messages that do not require a UTF8SMTPbis extension, 274 UTF8SMTPbis-aware SMTP clients and servers do not change the behavior 275 specified in [RFC5321]. 277 If a UTF8SMTPbis-aware SMTP server advertises the Delivery Status 278 Notification (DSN) [RFC3461] extension, it MUST implement 279 [RFC5337bis]. 281 3.3. Extended Mailbox Address Syntax 283 RFC 5321, section 4.1.2, defines the syntax of a entirely 284 in terms of ASCII characters. This document extends to add 285 support of non-ASCII characters. 287 The key changes made by this specification include: 288 o In order to update the to support the internationalized 289 email address, the ABNF rule will be imported from RFC 290 5321 directly, and other related rules are imported from RFC 5321, 291 RFC 5234, RFC 5890 or RFC 5335bis, or are extended in this 292 document. 293 o Extend the definition of to permit both the RFC 5321 294 definition and a UTF-8 string in a DNS label that is conforming 295 with IDNA definitions [RFC5890]. 296 o Extend the definition of to permit both the RFC 5321 297 definition and a UTF-8 string. That string MUST NOT contain any 298 of the ASCII graphics or controls characters. 300 The following ABNF rules imported from RFC 5321, section 4.1.2 are 301 updated directly or indirectly by this document: 302 o 303 o 304 o 305 o 306 o 307 o 308 o 310 The following ABNF rule will be imported from RFC 5335bis, section 311 4.1 directly: 312 o 314 The following ABNF rule will be imported from RFC 5234, appendix B.1 315 directly: 316 o 318 The following ABNF rule will be imported from RFC 5890, section 319 2.3.2.1 directly: 320 o 322 The following rules are extended in ABNF [RFC5234] as follows. 324 sub-domain =/ U-label 325 ; extend the definition of sub-domain in RFC5321, section 4.1.2 327 atext =/ UTF8-non-ascii 328 ; extend the implicit definition of atext in 329 ; RFC5321, Section 4.1.2, which ultimately points to 330 ; the actual definition in RFC5322, Section 3.2.3 332 qtextSMTP =/ UTF8-non-ascii 333 ; extend the definition of qtextSMTP in RFC5321, section 4.1.2 335 esmtp-value =/ UTF8-non-ascii 336 ; extend the definition of esmtp-value in RFC5321, section 4.1.2 338 3.4. MAIL Command Parameter Usage 340 If the envelope or message being sent requires the capabilities of 341 the UTF8SMTPbis extension, the UTF8SMTPbis-aware SMTP client MUST 342 supply the UTF8SMTPbis parameter with the MAIL command. If this 343 parameter is provided, it MUST have no value. If the UTF8SMTPbis- 344 aware SMTP client is aware that neither the envelope nor the message 345 being sent requires any of the UTF8SMTPbis extension capabilities, it 346 SHOULD NOT supply the UTF8SMTPbis parameter with the MAIL command. 348 Because there is no guarantee that a next-hop SMTP server will 349 support the UTF8SMTPbis extension, use of the UTF8SMTPbis extension 350 always carries a risk of transmission failure. In fact, during the 351 early stages of deployment for the UTF8SMTPbis extension, the risk 352 will be quite high. Hence there is a distinct near-term advantage 353 for ASCII-only messages to be sent without using this extension. The 354 long-term advantage of casting ASCII [ASCII] characters(0x7f and 355 below) as UTF-8 form is that it permits pure-Unicode environments. 357 3.5. Non-ASCII addresses and Reply-codes 359 A UTF8SMTPbis-aware SMTP client MUST only send an internationalized 360 message to an SMTP server that supports UTF8SMTPbis. If the SMTP 361 server does not support this option, then the UTF8SMTPbis-aware SMTP 362 client has three choices according to section 3.2 of this 363 specification. 365 The three-digit Reply-codes used in this section are based on their 366 meanings as defined in RFC 5321. 368 When messages are rejected because the RCPT command requires an ASCII 369 address, the reply-code 553 is returned with the meaning "mailbox 370 name not allowed". When messages are rejected because the MAIL 371 command requires an ASCII address, the reply-code 550 is returned 372 with the meaning "mailbox unavailable". When the UTF8SMTPbis-aware 373 SMTP server supports enhanced mail system status codes [RFC3463], 374 reply-code "X.6.7" [RFC5248] (see section 4)is used, meaning that 375 "non-ASCII addresses not permitted for that sender/recipient". 377 When messages are rejected for other reasons, the server follows the 378 model of the base email specifications in RFC 5321; this extension 379 does not change those circumstances or reply messages. 381 If a message is rejected after the final "." of the DATA command 382 because one or more recipient is unable to accept and process a 383 message with internationalized email headers, the reply-code "554" is 384 used with the meaning "Transaction failed". If the UTF8SMTPbis-aware 385 SMTP server supports enhanced mail system status codes [RFC3463], 386 reply code "X.6.9" [RFC5248] (see section 4) is used to indicate this 387 condition, meaning that "UTF-8 header message can not be transmitted 388 to one or more recipients, so the message MUST be rejected". 390 The UTF8SMTPbis-aware SMTP servers are encouraged to detect that 391 recipients can not accept internationalized messages and generate an 392 error after the RCPT command rather than waiting until after the DATA 393 command to issue an error. 395 3.6. Body Parts and SMTP Extensions 397 The MAIL command parameter UTF8SMTPbis asserts that a message is an 398 internationalized message or the message being sent needs the 399 UTF8SMTPbis support. The message being sent via the MAIL command 400 with the UTF8SMTPbis parameter has still a chance of that the message 401 transmitted is not an internationalized message. A UTF8SMTPbis-aware 402 SMTP client or server that requires accurate knowledge of whether a 403 message is internationalized needs to parse all message header fields 404 and MIME header fields [RFC2045] and [RFC2047] in the message body. 405 However, this specification does not require that the UTF8SMTPbis- 406 aware SMTP client or server inspects the message. 408 While this specification requires that UTF8SMTPbis-aware SMTP servers 409 support the 8BITMIME extension [RFC6152] to ensure that servers have 410 adequate handling capability for 8-bit data and to avoid a number of 411 complex encoding problems, the use of internationalized email 412 addresses obviously does not require non-ASCII body parts in the MIME 413 message in RFC 2045 and RFC 2047. The UTF8SMTPbis extension MAY be 414 used with the BODY=8BITMIME parameter [RFC6152] if that is 415 appropriate given the body content or, with the BODY=BINARYMIME 416 parameter, if the SMTP server advertises BINARYMIME [RFC3030] and 417 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 427 internationalized domain name SHOULD be in the form of U-label if the 428 UTF8SMTPbis extension is supported; otherwise, it SHOULD be in the 429 form of A-label. 431 The following subsections list and discuss all of the relevant cases. 433 3.7.1. The Initial SMTP Exchange 435 When an SMTP connection is opened, the SMTP server sends a "greeting" 436 response consisting of the 220 reply-code and some information. The 437 SMTP client then sends the EHLO command. Since the SMTP client 438 cannot know whether the SMTP server supports UTF8SMTPbis until after 439 it receives the response from EHLO, the UTF8SMTPbis-aware SMTP client 440 MUST send only ASCII (LDH label or A-label [RFC5890] ) domains in the 441 EHLO command and that, if the UTF8SMTPbis-aware SMTP server provides 442 domain names in the EHLO response, they MUST be in the form of LDH 443 labels or A-labels. 445 3.7.2. Mail eXchangers 447 If multiple DNS MX records are used to specify multiple servers for a 448 domain in section 5 of [RFC5321], it is strongly advised that all or 449 none of them SHOULD support the UTF8SMTPbis extension. Otherwise, 450 surprising rejections can happen during temporary or permanent 451 failures, which users might perceive as serious reliability issues. 453 3.7.3. Trace Information 455 The trace information , and their 456 related rules are defined in in section 4.4 of RFC 5321 [RFC5321]. 457 This document updates and to support non-ASCII 458 characters. When the UTF8SMTPbis extension is used, the 'Reverse- 459 path' clause of the Return-path-line may include an internationalized 460 domain name that uses the U-label form; The 'Stamp' clause of the 461 Time-stamp-line may include an internationalized domain name that 462 uses the U-label form. 464 If the messages that include trace fields are sent by an UTF8SMTPbis- 465 aware SMTP client or relay server without the UTF8SMTPbis parameter 466 at MAIL commands, trace field values must conform to RFC 5321 467 regardless of the SMTP server's capability. 469 When a UTF8SMTPbis-aware SMTP server adds a trace field to a message 470 that was or will be transmitted with the UTF8SMTPbis parameter at 471 MAIL commands, that server SHOULD use the U-label form for 472 internationalized domain names in that new trace field. 474 The protocol value of the 'WITH' clause when this extension is used 475 is one of the UTF8SMTPbis values specified in the "IANA 476 Considerations" section of this document. 478 3.7.4. UTF-8 Strings in Replies 480 3.7.4.1. MAIL Command 482 If an SMTP client follows this specification and sends any MAIL 483 commands containing the UTF8SMTPbis parameter, the UTF8SMTPbis-aware 484 SMTP server is permitted to use UTF-8 characters in the email address 485 associated with 251 and 551 reply-codes, and the SMTP client MUST be 486 able to accept and process them. If a given MAIL command does not 487 include the UTF8SMTPbis parameter, the UTF8SMTPbis-aware SMTP server 488 MUST NOT return a 251 or 551 response containing a non-ASCII mailbox. 489 Instead, it MUST transform such responses into 250 or 550 responses 490 that do not contain non-ASCII addresses. 492 3.7.4.2. VRFY and EXPN Commands and the UTF8SMTPbis Parameter 494 If the VRFY and EXPN commands are transmitted with the parameter 495 "UTF8SMTPbis", it indicates the SMTP client can accept UTF-8 strings 496 in replies to those commands. This parameter for the VRFY and EXPN 497 commands SHOULD only be used after the SMTP client sees the EHLO 498 response with the UTF8SMTPbis keyword. This allows the UTF8SMTPbis- 499 aware SMTP server to use UTF-8 strings in mailbox names and full 500 names that occur in replies without concern that the SMTP client 501 might be confused by them. An SMTP client that conforms to this 502 specification MUST accept and correctly process replies from the VRFY 503 and EXPN commands that contain UTF-8 strings. However, the 504 UTF8SMTPbis-aware SMTP server MUST NOT use UTF-8 strings in replies 505 if the SMTP client does not specifically allow such replies by 506 transmitting this parameter. Most replies do not require that a 507 mailbox name be included in the returned text, and therefore UTF-8 508 string is not needed in them. Some replies, notably those resulting 509 from successful execution of the VRFY and EXPN commands, do include 510 the mailbox. 512 VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to: 514 vrfy = "VRFY" SP String 515 [ SP "UTF8SMTPbis" ] CRLF 516 ; String may include Non-ASCII characters 518 expn = "EXPN" SP String 519 [ SP "UTF8SMTPbis" ] CRLF 520 ; String may include Non-ASCII characters 522 The "UTF8SMTPbis" parameter does not have a value. If the reply to a 523 VERIFY (VRFY) or EXPAND (EXPN) command requires a UTF-8 string, but 524 the SMTP client did not use the "UTF8SMTPbis" parameter, then the 525 UTF8SMTPbis-aware SMTP server MUST use either the reply-code 252 or 526 550. Reply-code 252, defined in [RFC5321], means "Cannot VRFY user, 527 but will accept the message and attempt the delivery". Reply-code 528 550, also defined in [RFC5321], means "Requested action not taken: 529 mailbox unavailable". When the UTF8SMTPbis-aware SMTP server 530 supports enhanced mail system status codes [RFC3463], the enhanced 531 reply-code as specified below is used. Using the "UTF8SMTPbis" 532 parameter with a VERIFY (VRFY) or EXPAND (EXPN) command enables UTF-8 533 replies for that command only. 535 If a normal success response (i.e., 250) is returned, the response 536 MAY include the full name of the user and MUST include the mailbox of 537 the user. It MUST be in either of the following forms: 539 User Name 540 ; Mailbox is defined in section 3.3 of this document. 541 ; User Name can contain non-ASCII characters. 543 Mailbox 544 ; Mailbox is defined in section 3.3 of this document. 546 If the SMTP reply requires UTF-8 strings, but UTF-8 string is not 547 allowed in the reply, and the UTF8SMTPbis-aware SMTP server supports 548 enhanced mail system status codes [RFC3463], the enhanced reply-code 549 is "X.6.8" [RFC5248] (see section 4), meaning "A reply containing a 550 UTF-8 string is REQUIRED to show the mailbox name, but that form of 551 response is not permitted by the SMTP client". 553 If the SMTP client does not support the UTF8SMTPbis extension, but 554 receives a UTF-8 string in a reply, it may not be able to properly 555 report the reply to the user, and some clients might mishandle that 556 reply. Internationalized messages in replies are only allowed in the 557 commands under the situations described above. 559 Although UTF-8 form is needed to represent email addresses in 560 responses under the rules specified in this section, this extension 561 does not permit the use of UTF-8 string for any other purposes. 562 UTF8SMTPbis-aware SMTP servers MUST NOT include non-ASCII characters 563 in replies except in the limited cases specifically permitted in this 564 section. 566 4. IANA Considerations 568 IANA is requested to add a new value "UTF8SMTPbis" to the SMTP 569 Service Extension subregistry of the Mail Parameters registry, 570 according to the following data: 572 +-------------+---------------------------------+-----------+ 573 | Keywords | Description | Reference | 574 +-------------+---------------------------------+-----------+ 575 | UTF8SMTPbis | Internationalized email address | [RFCXXXX] | 576 +-------------+---------------------------------+-----------+ 578 This document updates the values to the SMTP Enhanced Status Code 579 subregistry of the Mail Parameters registry, following the guidance 580 in Sections 3.5 and 3.7.4.2 of this document, and being based on 581 [RFC5248]. The registration data is as follows: 583 Code: X.6.7 584 Sample Text: non-ASCII addresses not permitted 585 for that sender/recipient 586 Associated basic status code: 550, 553 587 Description: This indicates the reception of a MAIL or RCPT 588 command that non-ASCII addresses are not permitted 589 Defined: RFC XXXX (Standard track) 590 Submitter: Jiankang YAO 591 Change controller: ima@ietf.org 593 Code: X.6.8 594 Sample Text: UTF-8 string reply is required, 595 but not permitted by the SMTP client 596 Associated basic status code: 252, 550, 553 597 Description: This indicates that a reply containing a UTF-8 598 string is required to show the mailbox name, 599 but that form of response is not 600 permitted by the SMTP client. 601 Defined: RFC XXXX (Standard track) 602 Submitter: Jiankang YAO 603 Change controller: ima@ietf.org 605 Code: X.6.9 606 Sample Text: UTF-8 header message can not be transferred 607 to one or more recipient so the message 608 must be rejected 609 Associated basic status code: 550 610 Description: This indicates that transaction failed 611 after the final "." of the DATA command. 612 Defined: RFC XXXX (Standard track) 613 Submitter: Jiankang YAO 614 Change controller: ima@ietf.org 615 Code: X.6.10 616 Description: This is a duplicate of X.6.8 and 617 is thus deprecated. 619 The following entries SHOULD be updated or added in the "Mail 620 Transmission Types" registry under the Mail Parameters registry. 622 +--------------+-------------------------------+--------------------+ 623 | WITH | Description | Reference | 624 | protocol | | | 625 | types | | | 626 +--------------+-------------------------------+--------------------+ 627 | UTF8SMTP | ESMTP with UTF8SMTP | [RFCXXXX] | 628 | UTF8SMTPA | ESMTP with UTF8SMTP and SMTP | [RFC4954] | 629 | | AUTH | [RFCXXXX] | 630 | UTF8SMTPS | ESMTP with UTF8SMTP and | [RFC3207] | 631 | | STARTTLS | [RFCXXXX] | 632 | UTF8SMTPSA | ESMTP with UTF8SMTP and both | [RFC3207] | 633 | | STARTTLS and SMTP AUTH | [RFC4954] | 634 | | | [RFCXXXX] | 635 | UTF8LMTP | LMTP with UTF8SMTP | [RFCXXXX] | 636 | UTF8LMTPA | LMTP with UTF8SMTP and SMTP | [RFC4954] | 637 | | AUTH | [RFCXXXX] | 638 | UTF8LMTPS | LMTP with UTF8SMTP and | [RFC3207] | 639 | | STARTTLS | [RFCXXXX] | 640 | UTF8LMTPSA | LMTP with UTF8SMTP and both | [RFC3207] | 641 | | STARTTLS and LMTP AUTH | [RFC4954] | 642 | | | [RFCXXXX] | 643 +--------------+-------------------------------+--------------------+ 645 5. Security Considerations 647 The extended security considerations discussion in the framework 648 document [RFC4952bis] will apply here. 650 More security considerations are discussed below: 652 Beyond the use inside the email global system (in SMTP envelopes and 653 message headers), internationalized email addresses will also show up 654 inside other cases, in particular: 656 o the logging systems of SMTP transactions and other logs to monitor 657 the email systems; 658 o the trouble ticket systems used by Security Teams to manage 659 security incidents, when an email address is involved; 661 In order to avoid problems that could cause loss of data, this will 662 likely require extending these systems to support full UTF-8, or to 663 require to provide an adequate mechanisms for mapping non-ASCII 664 strings to ASCII. 666 Another security aspect to be considered is related to the ability by 667 security team members to quickly understand, read and identify email 668 addresses from the logs, when they are tracking an incident. 669 Mechanisms to automatically and quickly provide the origin or 670 ownership of an internationalized email address SHALL be implemented 671 for use also by log readers which cannot read easily non-ASCII 672 information. 674 The SMTP commands VRFY and EXPN are sometimes used in SMTP 675 transactions where there is no message to transfer (by tools used to 676 take automated actions in case potential spam messages are 677 identified). RFC 5321 section 3.5 and 7.3 give some detailed 678 description of use and possible behaviours. Implementation of 679 internationalized addresses can affect also logs and actions by these 680 tools. 682 6. Acknowledgements 684 This document revised the [RFC5336]document based on the Email 685 Address Internationalization (EAI) WG's discussion result. Many EAI 686 WG members did some tests and implementations to move this document 687 to the Standard Track document. Significant comments and suggestions 688 were received from Xiaodong LEE, Nai-Wen Hsu, Yangwoo KO, Yoshiro 689 YONEYA, and other members of the JET team and were incorporated into 690 the specification. Additional important comments and suggestions, 691 and often specific text, were contributed by many members of the WG 692 and design team. Those contributions include material from John C 693 Klensin, Charles Lindsey, Dave Crocker, Harald Tveit Alvestrand, 694 Marcos Sanz, Chris Newman, Martin Duerst, Edmon Chung, Tony Finch, 695 Kari Hurtta, Randall Gellens, Frank Ellermann, Alexey Melnikov, Pete 696 Resnick, S. Moonesamy, Soobok Lee, Shawn Steele, Alfred Hoenes, 697 Miguel Garcia, Magnus Westerlund, Joseph Yee and Lars Eggert. Of 698 course, none of the individuals are necessarily responsible for the 699 combination of ideas represented here. 701 Thanks a lot to Dave Crocker for his comments and helping of ABNF 702 refinement. 704 7. Change History 706 [[anchor12: RFC Editor: Please remove this section.]] 708 7.1. draft-yao-eai-rfc5336bis: Version 00 710 Applied errata suggested by Alfred Hoenes. 712 7.2. draft-ietf-eai-rfc5336bis: Version 00 714 Applied the changes suggested by the EAI new charter. 716 7.3. draft-ietf-eai-rfc5336bis: Version 01 718 Applied the changes suggested by 78 IETF EAI meeting. 720 7.4. draft-ietf-eai-rfc5336bis: Version 02 722 remove the appendix since rfc4952bis has added this material 724 improve the text 726 remove the text about no body parameter 728 7.5. draft-ietf-eai-rfc5336bis: Version 03 730 improve the text 732 7.6. draft-ietf-eai-rfc5336bis: Version 04 734 update the abstract 736 improve the text 738 7.7. draft-ietf-eai-rfc5336bis: Version 05 740 improve the text based on AD and Co-chairs 742 7.8. draft-ietf-eai-rfc5336bis: Version 06 744 update the iana consideration 746 7.9. draft-ietf-eai-rfc5336bis: Version 07 748 improve the iana consideration 750 7.10. draft-ietf-eai-rfc5336bis: Version 08 752 improve the texts 754 add the mail parameter 755 add the new section about mail command parameter usage 757 update the security consideration 759 7.11. draft-ietf-eai-rfc5336bis: Version 09 761 improve the texts 763 7.12. draft-ietf-eai-rfc5336bis: Version 10 765 refine the ABNF definitions 767 improve the texts 769 7.13. draft-ietf-eai-rfc5336bis: Version 11 771 remove the update of RFC5321 and RFC5322 773 change the title from "SMTP Extension for Internationalized Email 774 Address" to "SMTP Extension for Internationalized Email" based on 775 Ernie's comment 777 the trace field of section 3.7.3 is updated to reflect the WG's 778 conclusion 780 improve the texts 782 7.14. draft-ietf-eai-rfc5336bis: Version 12 784 Update according to Chris Newman's comments 786 improve the texts 788 7.15. draft-ietf-eai-rfc5336bis: Version 13 790 Update the esmpt-value syntax according to Chris Newman's comments 792 improve the texts 794 7.16. draft-ietf-eai-rfc5336bis: Version 14 796 improve the texts 798 8. References 799 8.1. Normative References 801 [ASCII] American National Standards Institute (formerly United 802 States of America Standards Institute), "USA Code for 803 Information Interchange", ANSI X3.4-1968, 1968. 805 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 806 October 1996. 808 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 809 Requirement Levels", BCP 14, RFC 2119, March 1997. 811 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 812 Extension for Delivery Status Notifications (DSNs)", 813 RFC 3461, January 2003. 815 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 816 RFC 3463, January 2003. 818 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 819 for Delivery Status Notifications", RFC 3464, 820 January 2003. 822 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 823 10646", RFC 3629, November 2003. 825 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 826 RFC 4409, April 2006. 828 [RFC4952bis] 829 Klensin, J. and Y. Ko, "Overview and Framework for 830 Internationalized Email", I-D rfc4952bis, September 2010. 832 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 833 Specifications: ABNF", STD 68, RFC 5234, January 2008. 835 [RFC5248] Hansen , T. and J. Klensin, "A Registry for SMTP Enhanced 836 Mail System Status Codes", RFC 5248, June 2008. 838 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 839 October 2008. 841 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 842 October 2008. 844 [RFC5335bis] 845 Abel, Y. and S. Steel, "Internationalized Email Headers", 846 I-D rfc5335bis, March 2011. 848 [RFC5337bis] 849 Hansen, T., Ed., Newman, C., and A. Melnikov, Ed., 850 "Internationalized Delivery Status and Disposition 851 Notifications", I-D 5337bis, October 2010. 853 [RFC5890] Klensin, J., "Internationalizing Domain Names in 854 Applications (IDNA definitions)", RFC 5890, June 2010. 856 [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP 857 Service Extension for 8-bit MIME Transport", STD 71, 858 RFC 6152, March 2011. 860 8.2. Informative References 862 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 863 Extensions (MIME) Part One: Format of Internet Message 864 Bodies", RFC 2045, November 1996. 866 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 867 Part Three: Message Header Extensions for Non-ASCII Text", 868 RFC 2047, November 1996. 870 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 871 of Large and Binary MIME Messages", RFC 3030, 872 December 2000. 874 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 875 Transport Layer Security", RFC 3207, February 2002. 877 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 878 for Authentication", RFC 4954, July 2007. 880 [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized 881 Email Addresses", RFC 5336, September 2008. 883 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 884 July 2009. 886 Authors' Addresses 888 Jiankang YAO 889 CNNIC 890 No.4 South 4th Street, Zhongguancun 891 Beijing 893 Phone: +86 10 58813007 894 Email: yaojk@cnnic.cn 896 Wei MAO 897 CNNIC 898 No.4 South 4th Street, Zhongguancun 899 Beijing 901 Phone: +86 10 58812230 902 Email: maowei_ietf@cnnic.cn