idnits 2.17.1 draft-ietf-eai-rfc5336bis-08.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 lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 (March 7, 2011) is 4799 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 687, but not defined == Unused Reference: 'RFC5891' is defined on line 856, but no explicit reference was found in the text == Unused Reference: 'RFC5336' is defined on line 892, 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 (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Yao 3 Internet-Draft W. Mao 4 Obsoletes: RFC5336 CNNIC 5 (if approved) March 7, 2011 6 Updates: RFC5321 and 5322 7 (if approved) 8 Intended status: Standards Track 9 Expires: September 8, 2011 11 SMTP Extension for Internationalized Email Address 12 draft-ietf-eai-rfc5336bis-08.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. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 8, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Role of This Specification . . . . . . . . . . . . . . . . 4 68 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.3. Updates to Other Specifications . . . . . . . . . . . . . 5 70 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 71 3. Mail Transport-Level Protocol . . . . . . . . . . . . . . . . 5 72 3.1. Framework for the Internationalization Extension . . . . . 5 73 3.2. The UTF8SMTPbis Extension . . . . . . . . . . . . . . . . 6 74 3.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 7 75 3.4. MAIL Command Parameter Usage . . . . . . . . . . . . . . . 10 76 3.5. Non-ASCII addresses and Reply-codes . . . . . . . . . . . 10 77 3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 11 78 3.7. Additional ESMTP Changes and Clarifications . . . . . . . 11 79 3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 11 80 3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 12 81 3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 12 82 3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 14 83 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 85 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 86 7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 18 87 7.1. draft-yao-eai-rfc5336bis: Version 00 . . . . . . . . . . . 18 88 7.2. draft-ietf-eai-rfc5336bis: Version 00 . . . . . . . . . . 19 89 7.3. draft-ietf-eai-rfc5336bis: Version 01 . . . . . . . . . . 19 90 7.4. draft-ietf-eai-rfc5336bis: Version 02 . . . . . . . . . . 19 91 7.5. draft-ietf-eai-rfc5336bis: Version 03 . . . . . . . . . . 19 92 7.6. draft-ietf-eai-rfc5336bis: Version 04 . . . . . . . . . . 19 93 7.7. draft-ietf-eai-rfc5336bis: Version 05 . . . . . . . . . . 19 94 7.8. draft-ietf-eai-rfc5336bis: Version 06 . . . . . . . . . . 19 95 7.9. draft-ietf-eai-rfc5336bis: Version 07 . . . . . . . . . . 19 96 7.10. draft-ietf-eai-rfc5336bis: Version 08 . . . . . . . . . . 19 97 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 98 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 99 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 102 1. Introduction 104 The Simple Mail Transfer Protocol [RFC5321] provides a negotiation 105 mechanism about service extension by which SMTP clients can discover 106 SMTP server capabilities and make decisions for further processing. 107 This document uses this mechanism and specifies an SMTP extension to 108 permit internationalized email addresses (see Section 1.2) in the 109 SMTP envelope, and Unicode characters encoded in UTF-8 [RFC3629] in 110 the headers. An extended overview of the extension model for 111 internationalized email addresses and the email header appears in 112 [RFC4952bis], referred to as "the framework document" or just as 113 "framework" elsewhere in this specification. 115 [[anchor1: Note in Draft and to RFC Editor: The keyword represented 116 in this document by "UTF8SMTPbis" (and in the XML source 117 byUTF8SMTPbis) is a placeholder. The actual keyword will be assigned 118 when the standards track SMTP extension in this series [RFC5336bis- 119 SMTP] is approved for publication and should be substituted here. 120 This paragraph should be treated as normative reference to that SMTP 121 extension draft, creating a reference hold until it is approved by 122 the IESG. This paragraph should be removed before RFC publication.]] 124 1.1. Role of This Specification 126 The framework document [RFC4952bis] specifies the requirements for, 127 and describes components of, full internationalization of electronic 128 mail. A thorough understanding of the information in that document 129 and in the base Internet email specifications [RFC5321] [RFC5322] is 130 necessary to understand and implement this specification. 132 This document specifies an element of the email internationalization 133 work, specifically the definition of an SMTP extension for 134 internationalized email address transport delivery. 136 1.2. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to 140 be interpreted as described in RFC 2119 [RFC2119]. 142 The terms "UTF-8 string" or "UTF-8 character" are used to refer to 143 Unicode characters encoded in UTF-8. All other specialized terms 144 used in this specification are defined in the framework document or 145 in the base Internet email specifications. In particular, the terms 146 "ASCII address", "internationalized email address", "non-ASCII 147 address", "UTF8SMTPbis", "internationalized message", and "message" 148 are used in this document according to the definitions in the 149 framework document. 151 Non-ASCII characters or strings referred in this document MUST be 152 expressed in UTF-8, a standard Unicode Encoding Form. 154 This specification uses Augmented BNF (ABNF) rules [RFC5234], with 155 some modifications. The modified rules are defined in this 156 specification. When a new rule has a name starting with "u", it is a 157 small modification to an older rule. Rules that are undefined here 158 can be found from [RFC5234] or [RFC5321] or [RFC5322] under the same 159 names. 161 1.3. Updates to Other Specifications 163 This specification modifies RFC 5321 by permitting internationalized 164 email address in the envelop. It also updates some syntax rules 165 defined in RFC 5321. It modifies RFC 5322 by permitting data formats 166 defined in [RFC5335bis]. It does not modify the 8BITMIME 167 specification [RFC6152] in any way, but it does require that the 168 8BITMIME extension be announced by the EAI-aware SMTP server and used 169 with "BODY=8BMITMIME". 171 2. Overview of Operation 173 This specification describes an optional extension to the email 174 transport mechanism that permits non-ASCII characters in both the 175 envelope and header fields of messages, which are encoded in UTF-8. 176 The extension is identified with the token "UTF8SMTPbis". 178 The EAI UTF-8 header specification [RFC5335bis] provides the details 179 of email header features enabled by this extension 181 3. Mail Transport-Level Protocol 183 3.1. Framework for the Internationalization Extension 185 The following service extension is defined: 186 1. The name of the SMTP service extension is "Email Address 187 Internationalization". 188 2. The EHLO keyword value associated with this extension is 189 "UTF8SMTPbis". 190 3. No parameter values are defined for this EHLO keyword value. In 191 order to permit future (although unanticipated) extensions, the 192 EHLO response MUST NOT contain any parameters for this keyword. 193 The EAI-aware SMTP client MUST reject any parameters if they 194 appear for this keyword; that is, the EAI-aware SMTP client MUST 195 behave as if the parameters do not appear. If an SMTP server 196 includes UTF8SMTPbis in its EHLO response, it MUST be fully 197 compliant with this version of this specification. 198 4. One OPTIONAL parameter "UTF8SMTPbis" is added to the MAIL 199 command. The parameter has no value. If this parameter is set 200 in the MAIL command, it indicates that the SMTP client is EAI- 201 aware and asserts that the envelop includes the non-ASCII 202 address or the message being sent is internationalized message 203 or the message being sent needs the UTF8SMTPbis support. 204 5. The maximum length of a MAIL command line is increased by 12 205 characters by the possible addition of the UTF8SMTPbis 206 parameter. [[anchor6: RFC Editor: the number '12' will be 207 replaced by the new number (1 space + length of the new keyword 208 supposed to replace "UTF8SMTPbis").]] 209 6. One OPTIONAL parameter "UTF8SMTPbis" is added to the VRFY and 210 EXPN commands. The parameter UTF8SMTPbis has no value. The 211 parameter indicates that the SMTP client can accept Unicode 212 characters in UTF-8 encoding in replies from the VRFY and EXPN 213 commands. 214 7. No additional SMTP verbs are defined by this extension. 215 8. Servers offering this extension MUST provide support for, and 216 announce, the 8BITMIME extension [RFC6152]. 217 9. The reverse-path and forward-path of the SMTP MAIL and RCPT 218 commands are extended to allow Unicode characters encoded in 219 UTF-8 in mailbox names (addresses). 220 10. The mail message body is extended as specified in [RFC5335bis]. 221 11. The UTF8SMTPbis extension is valid on the submission port 222 [RFC4409], and can be used with LMTP [RFC2033]. 224 3.2. The UTF8SMTPbis Extension 226 An SMTP server that announces this UTF8SMTPbis extension MUST be 227 prepared to accept a UTF-8 string [RFC3629] in any position in which 228 RFC 5321 specifies that a can appear. Although the 229 characters in the are permitted to contain non-ASCII 230 characters, actual parsing of the , and the delimiters 231 used, are unchanged from the base email specification [RFC5321]. Any 232 domain names to be looked up in the DNS MUST allow for [RFC5890] 233 behavior. When doing lookups, the EAI-aware SMTP server MUST either 234 use a Unicode aware DNS library, or transform it to A-label defined 235 in [RFC5890]. 237 An SMTP client that receives the UTF8SMTPbis extension keyword in 238 response to the EHLO command MAY transmit mailbox names within SMTP 239 commands as internationalized strings in UTF-8 form. It MAY send a 240 UTF-8 header [RFC5335bis] (which may also include mailbox names in 241 UTF-8). It MAY transmit the domain parts of mailbox names within 242 SMTP commands or the message header as A-labels or U-labels 243 [RFC5890]. The presence of the UTF8SMTPbis extension does not change 244 RFC 5321 server relaying behaviors. 246 If the UTF8SMTPbis SMTP extension is not offered by the SMTP server, 247 the EAI-aware SMTP client MUST NOT transmit an internationalized 248 email address and MUST NOT transmit a mail message containing 249 internationalized mail headers as described in [RFC5335bis] at any 250 level within its MIME structure [RFC2045] and [RFC2047]. (For this 251 paragraph, the internationalized domain name in the form of A-labels 252 as specified in IDNA definitions [RFC5890] is not considered to be 253 "internationalized".) Instead, if an EAI-aware SMTP client (EAI- 254 aware SMTP sender) attempts to transfer an internationalized message 255 and encounters an SMTP server that does not support the extension, it 256 MUST make one of the following three choices and the priority order 257 is 1, 2 and 3. 259 1. It MAY either reject the message during the SMTP transaction or 260 accept the message and then generate and transmit a notification 261 of non-deliverability. Such notification MUST be done as 262 specified in RFC 5321 [RFC5321], RFC 3464 [RFC3464], and the EAI 263 delivery status notification (DSN) specification [RFC5337bis]. 264 2. If and only if the EAI-aware SMTP client (sender) is a Message 265 Submission Agent ("MSA") [RFC4409] [RFC5598], it MAY rewrite the 266 envelope, headers, or message material to make them entirely 267 ASCII [ASCII] and consistent with the provisions of RFC 5321 268 [RFC5321] and RFC 5322 [RFC5322]. 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. 291 The key changes made by this specification include: 293 o Change the definition of to permit both the RFC 5321 294 definition and a UTF-8 string representing a DNS label that is 295 conformed with IDNA definitions [RFC5890]. 296 o Change 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 characters (either graphics or controls) that are not 299 permitted in ; it is otherwise unrestricted. 301 According to the description above, the syntax of an 302 internationalized email mailbox name (address) is defined in ABNF 303 [RFC5234] as follows. 305 uMailbox = uLocal-part "@" ( uDomain / address-literal ) 306 ; Replace Mailbox in RFC 5321, Section 4.1.2 308 address-literal = 310 uLocal-part = uDot-string / uQuoted-string 311 ; MAY be case-sensitive 312 ; Replace Local-part in RFC 5321, Section 4.1.2 314 uDot-string = uAtom *("." uAtom) 315 ; Replace Dot-string in RFC 5321, Section 4.1.2 317 uAtom = 1*ucharacter 318 ; Replace Atom in RFC 5321, Section 4.1.2 320 ucharacter = atext / UTF8-non-ascii 322 atext = 323 ; Same definition with atext in RFC 5321, Section 4.1.2 325 uQuoted-string = DQUOTE *uQcontentSMTP DQUOTE 326 ; Replace Quoted-string in RFC 5321, Section 4.1.2 328 DQUOTE = 330 uQcontentSMTP = qtextSMTP / quoted-pairSMTP / UTF8-non-ascii 332 qtextSMTP = 334 quoted-pairSMTP = 336 uDomain = sub-udomain *("." sub-udomain) 337 ; Replace Domain in RFC 5321, Section 4.1.2 339 sub-udomain = uLet-dig [uLdh-str] 340 ; Replace sub-domain in RFC 5321, Section 4.1.2 342 uLet-dig = Let-dig / UTF8-non-ascii 344 Let-dig = 346 uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-non-ascii) uLet-dig 347 ; Replace Ldh-str in RFC 5321, Section 4.1.2 349 UTF8-non-ascii = 351 3.4. MAIL Command Parameter Usage 353 If the envelope or message being sent requires the capabilities of 354 the UTF8SMTPbis extension, the SMTP client MUST supply the 355 UTF8SMTPbis parameter with the MAIL command. If this parameter is 356 provided, it MUST have no value. If the SMTP client is aware that 357 neither the envelope nor the message being sent requires any of the 358 UTF8SMTPbis extension capabilities, it SHOULD NOT supply the 359 UTF8SMTPbis parameter with the MAIL command. 361 Because there is no guarantee that a next-hop SMTP server will 362 support the UTF8SMTPbis extension, use of the UTF8SMTPbis extension 363 always carries a risk of transmission failure. In fact, during the 364 early stages of deployment for the UTF8SMTPbis extension, the risk 365 will be quite high. Hence there is a distinct near-term advantage 366 for ASCII-only messages to be sent without using this extension. The 367 long-term advantage of casting ASCII [ASCII] characters(0x7f and 368 below) as UTF-8 form is that it permits pure-Unicode environments. 370 This specification does not require that the EAI-aware SMTP client 371 inspect the message or otherwise go to extraordinary lengths to 372 assure itself whether the UTF8SMTPbis extension is REQUIRED for the 373 particular message. 375 3.5. Non-ASCII addresses and Reply-codes 377 An EAI-aware SMTP client MUST only send an internationalized message 378 to an SMTP server that supports UTF8SMTPbis. If the SMTP server does 379 not support this option, then the EAI-aware SMTP client has three 380 choices according to section 3.2 of this specification and MAY choose 381 to reject the internationalized message. 383 The three-digit Reply-codes used in this section are based on their 384 meanings as defined in RFC 5321. 386 When messages are rejected because the RCPT command requires an ASCII 387 address, the reply-code 553 is returned with the meaning "mailbox 388 name not allowed". When messages are rejected because the MAIL 389 command requires an ASCII address, the reply-code 550 is returned 390 with the meaning "mailbox unavailable". When the EAI-aware SMTP 391 server supports enhanced mail system status codes [RFC3463], reply- 392 code "X.6.7" [RFC5248] is used, meaning that "non-ASCII addresses not 393 permitted for that sender/recipient". 395 When messages are rejected for other reasons, the server SHOULD 396 follow the model of the base email specifications [RFC5321]; this 397 extension does not change those circumstances or reply messages. 399 If the reply-code is issued after the final "." of the DATA command, 400 the reply-code "554" is used with the meaning "Transaction failed". 401 When the EAI-aware SMTP server supports enhanced mail system status 402 codes [RFC3463], reply-code "X.6.9" [RFC5248] is used, meaning that 403 "UTF-8 header message can not be transmitted to one or more 404 recipients, so the message MUST be rejected". 406 3.6. Body Parts and SMTP Extensions 408 The MAIL command parameter UTF8SMTPbis asserts that a message is an 409 internationalized message or the message being sent needs the 410 UTF8SMTPbis support. The message being sent via the MAIL command 411 with the UTF8SMTPbis parameter has still a chance of that the message 412 transmitted is not an internationalized message. An EAI-aware SMTP 413 client or server that requires accurate knowledge of whether a 414 message is internationalized needs to parse all message header fields 415 and MIME header fields [RFC2045] and [RFC2047] in the message body. 416 However, this specification does not require that the SMTP client or 417 server inspects the message. 419 While this specification requires that EAI-aware SMTP servers support 420 the 8BITMIME extension [RFC6152] to ensure that servers have adequate 421 handling capability for 8-bit data and to avoid a number of complex 422 encoding problems, the use of internationalized email addresses 423 obviously does not require non-ASCII body parts in the MIME message 424 in RFC 2045 and RFC 2047. The UTF8SMTPbis extension MAY be used with 425 the BODY=8BITMIME parameter [RFC6152] if that is appropriate given 426 the body content or, with the BODY=BINARYMIME parameter, if the SMTP 427 server advertises BINARYMIME [RFC3030] and that is appropriate. 429 3.7. Additional ESMTP Changes and Clarifications 431 The information carried in the mail transport process involves 432 addresses ("mailboxes") and domain names in various contexts in 433 addition to the MAIL and RCPT commands and extended alternatives to 434 them. In general, the rule is that, when RFC 5321 specifies a 435 mailbox, this SMTP extension requires UTF-8 form to be used for the 436 entire string; when RFC 5321 specifies a domain name, the name SHOULD 437 be in the form of A-label if this domain name is an internationalized 438 domain name[RFC5890]. 440 The following subsections list and discuss all of the relevant cases. 442 3.7.1. The Initial SMTP Exchange 444 When an SMTP connection is opened, the SMTP server sends a "greeting" 445 response consisting of the 220 reply-code and some information. The 446 SMTP client then sends the EHLO command. Since the SMTP client 447 cannot know whether the SMTP server supports UTF8SMTPbis until after 448 it receives the response from EHLO, the EAI-aware SMTP client MUST 449 send only ASCII (LDH label or A-label [RFC5890] ) domains in the EHLO 450 command and that, if the EAI-aware SMTP server provides domain names 451 in the EHLO response, they MUST be in the form of LDH labels or 452 A-labels. 454 3.7.2. Mail eXchangers 456 If multiple DNS MX records are used to specify multiple servers for a 457 domain in section 5 of [RFC5321], it is strongly advised that all or 458 none of them SHOULD support the UTF8SMTPbis extension. Otherwise, 459 surprising rejections can happen during temporary or permanent 460 failures, which users might perceive as serious reliability issues. 461 In order to avoid the possible surprising rejections, the EAI-aware 462 email system MAY also implement the advice in EAI addresses advice 463 document [EAI addresses] and EAI deployment advice document [EAI 464 Deployment]. 466 3.7.3. Trace Information 468 For the trace information [RFC5321], this memo updates the time stamp 469 line and the return path line [RFC5321] formally defined as follows: 471 uReturn-path-line = "Return-Path:" FWS uReverse-path 472 ; Replaces Return-path-line in Section 4.4 of RFC 5321 474 uReverse-path = uPath / "<>" 475 ; Replace Reverse-path in RFC 5321, section 4.1.2 477 uPath = "<" [ A-d-l ":" ] uMailbox ">" 478 ; Replace Path in RFC 5321, section 4.1.2 479 ; uMailbox is defined in section 3.3 of this document 481 A-d-l = 483 uTime-stamp-line = "Received:" FWS uStamp 484 ; Replaces Time-stamp-line in Section 4.4 of RFC 5321 486 uStamp = From-domain By-domain uOpt-info [CFWS] ";" FWS date-time 487 ; Replaces Stamp in Section 4.4 of RFC 5321 489 From-domain = 491 By-domain = 493 date-time = 494 ; Same definition with date-time in Section 4.4 of RFC 5321 496 uOpt-info = [Via] [With] [ID] [uFor] 497 [Additional-Registered-Clauses] 498 ; Replaces Opt-info in Section 4.4 of RFC 5321 499 ; The protocol value for With will allow a UTF8SMTPbis value 501 Via = 503 With = 505 ID = 507 Additional-Registered-Clauses = 509 uFor = CFWS "FOR" FWS ( uPath / uMailbox) 510 ; Replaces For in Section 4.4 of RFC 5321 511 ; uMailbox is defined in section 3.3 of this document 513 Except in the 'uFor' clause and 'uReverse-path' value where 514 internationalized domain name with the U-label form MAY be used, 515 internationalized domain names in Received fields MUST be transmitted 516 in the form of A-labels. The protocol value of the WITH clause when 517 this extension is used is one of the UTF8SMTPbis values specified in 518 the "IANA Considerations" section of this document. 520 3.7.4. UTF-8 Strings in Replies 522 3.7.4.1. MAIL and RCPT Commands 524 If an SMTP client follows this specification and sends any MAIL 525 commands containing the UTF8SMTPbis parameter or any RCPT commands 526 containing non-ASCII addresses, the EAI-aware SMTP server is 527 permitted to use UTF-8 characters in the email address associated 528 with 251 and 551 reply-codes, and the SMTP client MUST be able to 529 accept and process them. If a given MAIL command does not include 530 the UTF8SMTPbis parameter or a given RCPT command does not include a 531 non-ASCII envelope address, the EAI-aware SMTP server MUST NOT return 532 a 251 or 551 response containing a non-ASCII mailbox. Instead, it 533 MUST transform such responses into 250 or 550 responses that do not 534 contain non-ASCII addresses. 536 3.7.4.2. VRFY and EXPN Commands and the UTF8SMTPbis Parameter 538 If the VRFY and EXPN commands are transmitted with the parameter 539 "UTF8SMTPbis", it indicates the SMTP client can accept UTF-8 strings 540 in replies to those commands. This parameter for the VRFY and EXPN 541 commands SHOULD only be used after the SMTP client sees the EHLO 542 response with the UTF8SMTPbis keyword. This allows the EAI-aware 543 SMTP server to use UTF-8 strings in mailbox names and full names that 544 occur in replies without concern that the SMTP client might be 545 confused by them. An SMTP client that conforms to this specification 546 MUST accept and correctly process replies from the VRFY and EXPN 547 commands that contain UTF-8 strings. However, the EAI-aware SMTP 548 server MUST NOT use UTF-8 strings in replies if the SMTP client does 549 not specifically allow such replies by transmitting this parameter. 550 Most replies do not require that a mailbox name be included in the 551 returned text, and therefore UTF-8 string is not needed in them. 552 Some replies, notably those resulting from successful execution of 553 the VRFY and EXPN commands, do include the mailbox. 555 VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to: 557 vrfy = "VRFY" SP uString 558 [ SP "UTF8SMTPbis" ] CRLF 560 expn = "EXPN" SP uString 561 [ SP "UTF8SMTPbis" ] CRLF 563 uString = uAtom / uQuoted-string 564 ; uAtom and uQuoted-string are defined in 565 ; Section 3.3 of this document. 567 The "UTF8SMTPbis" parameter does not use a value. If the reply to a 568 VERIFY (VRFY) or EXPAND (EXPN) command requires UTF-8 string, but the 569 SMTP client did not use the "UTF8SMTPbis" parameter, then the EAI- 570 aware SMTP server MUST use either the reply-code 252 or 550. Reply- 571 code 252, defined in [RFC5321], means "Cannot VRFY user, but will 572 accept the message and attempt the delivery". Reply-code 550, also 573 defined in [RFC5321], means "Requested action not taken: mailbox 574 unavailable". When the EAI-aware SMTP server supports enhanced mail 575 system status codes [RFC3463], the enhanced reply-code as specified 576 below is used. Using the "UTF8SMTPbis" parameter with a VERIFY 577 (VRFY) or EXPAND (EXPN) command enables UTF-8 replies for that 578 command only. 580 If a normal success response (i.e., 250) is returned, the response 581 MAY include the full name of the user and MUST include the mailbox of 582 the user. It MUST be in either of the following forms: 584 User Name 585 ; uMailbox is defined in Section 3.3 of this document. 586 ; User Name can contain non-ASCII characters. 588 uMailbox 589 ; uMailbox is defined in Section 3.3 of this document. 591 If the SMTP reply requires UTF-8 strings, but UTF-8 string is not 592 allowed in the reply, and the EAI-aware SMTP server supports enhanced 593 mail system status codes [RFC3463], the enhanced reply-code is 594 "X.6.8" [RFC5248], meaning "A reply containing a UTF-8 string is 595 REQUIRED to show the mailbox name, but that form of response is not 596 permitted by the SMTP client". 598 If the SMTP client does not support the UTF8SMTPbis extension, but 599 receives a UTF-8 string in a reply, it may not be able to properly 600 report the reply to the user, and some clients might crash. 601 Internationalized messages in replies are only allowed in the 602 commands under the situations described above. Under any other 603 circumstances, UTF-8 string MUST NOT appear in the reply. 605 Although UTF-8 form is needed to represent email addresses in 606 responses under the rules specified in this section, this extension 607 does not permit the use of UTF-8 string for any other purposes. EAI- 608 aware SMTP servers MUST NOT include non-ASCII characters in replies 609 except in the limited cases specifically permitted in this section. 611 4. IANA Considerations 613 IANA SHOULD add a new value "UTF8SMTPbis" to the SMTP Service 614 Extension subregistry of the Mail Parameters registry, according to 615 the following data: 617 +-------------+---------------------------------+-----------+ 618 | Keywords | Description | Reference | 619 +-------------+---------------------------------+-----------+ 620 | UTF8SMTPbis | Internationalized email address | [RFCXXXX] | 621 +-------------+---------------------------------+-----------+ 623 This document updates the values to the SMTP Enhanced Status Code 624 subregistry of the Mail Parameters registry, following the guidance 625 in Sections 3.5 and 3.7.4.2 of this document, and being based on 626 [RFC5248]. The registration data is as follows: 628 Code: X.6.7 629 Sample Text: non-ASCII addresses not permitted 630 for that sender/recipient 631 Associated basic status code: 550, 553 632 Description: This indicates the reception of a MAIL or RCPT 633 command that non-ASCII addresses are not permitted 634 Defined: RFC XXXX (Standard track) 635 Submitter: Jiankang YAO 636 Change controller: ima@ietf.org 638 Code: X.6.8 639 Sample Text: UTF-8 string reply is required, 640 but not permitted by the SMTP client 641 Associated basic status code: 252, 550, 553 642 Description: This indicates that a reply containing a UTF-8 643 string is required to show the mailbox name, 644 but that form of response is not 645 permitted by the SMTP client. 646 Defined: RFC XXXX (Standard track) 647 Submitter: Jiankang YAO 648 Change controller: ima@ietf.org 650 Code: X.6.9 651 Sample Text: UTF-8 header message can not be transferred 652 to one or more recipient so the message 653 must be rejected 654 Associated basic status code: 550 655 Description: This indicates that transaction failed 656 after the final "." of the DATA command. 657 Defined: RFC XXXX (Standard track) 658 Submitter: Jiankang YAO 659 Change controller: ima@ietf.org 660 Code: X.6.10 661 Description: This is a duplicate of X.6.8 and 662 SHOULD be deprecated for further use. 664 The following entries SHOULD be updated or added in the "Mail 665 Transmission Types" registry under the Mail Parameters registry. 667 +--------------+-------------------------------+--------------------+ 668 | WITH | Description | Reference | 669 | protocol | | | 670 | types | | | 671 +--------------+-------------------------------+--------------------+ 672 | UTF8SMTP | ESMTP with UTF8SMTP | [RFCXXXX] | 673 | UTF8SMTPA | ESMTP with UTF8SMTP and SMTP | [RFC4954] | 674 | | AUTH | [RFCXXXX] | 675 | UTF8SMTPS | ESMTP with UTF8SMTP and | [RFC3207] | 676 | | STARTTLS | [RFCXXXX] | 677 | UTF8SMTPSA | ESMTP with UTF8SMTP and both | [RFC3207] | 678 | | STARTTLS and SMTP AUTH | [RFC4954] | 679 | | | [RFCXXXX] | 680 | UTF8LMTP | LMTP with UTF8SMTP | [RFCXXXX] | 681 | UTF8LMTPA | LMTP with UTF8SMTP and SMTP | [RFC4954] | 682 | | AUTH | [RFCXXXX] | 683 | UTF8LMTPS | LMTP with UTF8SMTP and | [RFC3207] | 684 | | STARTTLS | [RFCXXXX] | 685 | UTF8LMTPSA | LMTP with UTF8SMTP and both | [RFC3207] | 686 | | STARTTLS and LMTP AUTH | [RFC4954] | 687 | | | [RFCXXXX] | 688 +--------------+-------------------------------+--------------------+ 690 5. Security Considerations 692 The extended security considerations discussion in the framework 693 document [RFC4952bis] will be applied here. 695 More security considerations are discussed below: 697 Beyond the use inside the email global system (in SMTP envelopes and 698 message headers), internationalized email addresses will also show up 699 inside other cases, in particular: 701 o the logging systems of SMTP transactions and other logs to monitor 702 the email systems; 703 o the trouble ticket systems used by Security Teams to manage 704 security incidents, when an email address is involved; 706 This will likely require extending support for full UTF-8 also into 707 these systems, in order to avoid problems, which could cause also 708 important loss of data, or require to provide an adequate mechanism 709 to map non-ASCII strings into them. 711 Another security aspect to be considered is related to the ability by 712 security team members to quickly understand, read and identify email 713 addresses from the logs, when they are tracking an incident. 714 Mechanims to automatically and quickly provide the origin or 715 ownership of an internationalized email address SHALL be implemented 716 for use also by log readers which cannot read easily non-ASCII 717 information. 719 The SMTP commands VRFY and EXPN are sometimes used in SMTP 720 transactions where there is no message to transfer (by tools used to 721 take automated actions in case potential spam messages are 722 identified). RFC 5321 section 3.5 and 7.3 give some detailed 723 description of use and possible behaviours. Implementation of 724 internationalized addrsses can affect also logs and actions by these 725 tools. 727 6. Acknowledgements 729 This document revised the [RFC5336]document based on the EAI WG's 730 discussion result. Many EAI WG members did some tests and 731 implementations to move this document to the Standard Track document. 732 Significant comments and suggestions were received from Xiaodong LEE, 733 Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other members of the JET 734 team and were incorporated into the specification. Additional 735 important comments and suggestions, and often specific text, were 736 contributed by many members of the WG and design team. Those 737 contributions include material from John C Klensin, Charles Lindsey, 738 Dave Crocker, Harald Tveit Alvestrand, Marcos Sanz, Chris Newman, 739 Martin Duerst, Edmon Chung, Tony Finch, Kari Hurtta, Randall Gellens, 740 Frank Ellermann, Alexey Melnikov, Pete Resnick, S. Moonesamy, Soobok 741 Lee, Shawn Steele, Alfred Hoenes, Miguel Garcia, Magnus Westerlund, 742 and Lars Eggert. Of course, none of the individuals are necessarily 743 responsible for the combination of ideas represented here. 745 7. Change History 747 [[anchor14: RFC Editor: Please remove this section.]] 749 7.1. draft-yao-eai-rfc5336bis: Version 00 751 Applied errata suggested by Alfred Hoenes. 753 7.2. draft-ietf-eai-rfc5336bis: Version 00 755 Applied the changes suggested by the EAI new charter. 757 7.3. draft-ietf-eai-rfc5336bis: Version 01 759 Applied the changes suggested by 78 IETF EAI meeting. 761 7.4. draft-ietf-eai-rfc5336bis: Version 02 763 remove the appendix since rfc4952bis has added this material 765 improve the text 767 remove the text about no body parameter 769 7.5. draft-ietf-eai-rfc5336bis: Version 03 771 improve the text 773 7.6. draft-ietf-eai-rfc5336bis: Version 04 775 update the abstract 777 improve the text 779 7.7. draft-ietf-eai-rfc5336bis: Version 05 781 improve the text based on AD and Co-chairs 783 7.8. draft-ietf-eai-rfc5336bis: Version 06 785 update the iana consideration 787 7.9. draft-ietf-eai-rfc5336bis: Version 07 789 improve the iana consideration 791 7.10. draft-ietf-eai-rfc5336bis: Version 08 793 improve the texts 795 add the mail parameter 797 add the new section about mail command parameter usage 799 update the security consideration 801 8. References 803 8.1. Normative References 805 [ASCII] American National Standards Institute (formerly United 806 States of America Standards Institute), "USA Code for 807 Information Interchange", ANSI X3.4-1968, 1968. 809 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 810 October 1996. 812 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 813 Requirement Levels", BCP 14, RFC 2119, March 1997. 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 [RFC5891] Klensin, J., "Internationalized Domain Names in 857 Applications (IDNA): Protocol", RFC 5891, August 2010. 859 [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP 860 Service Extension for 8-bit MIME Transport", STD 71, 861 RFC 6152, March 2011. 863 8.2. Informative References 865 [EAI Deployment] 866 Yao, J., Lee, X., and S. Steel, "Advice for EAI 867 deployment", draft eai-deployment, December 2010. 869 [EAI addresses] 870 Steel, S., Yao, J., and Mark. Davis, "Advice for non-ASCII 871 & ASCII addresses", draft eai-address-advice, 872 December 2010. 874 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 875 Extensions (MIME) Part One: Format of Internet Message 876 Bodies", RFC 2045, November 1996. 878 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 879 Part Three: Message Header Extensions for Non-ASCII Text", 880 RFC 2047, November 1996. 882 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 883 of Large and Binary MIME Messages", RFC 3030, 884 December 2000. 886 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 887 Transport Layer Security", RFC 3207, February 2002. 889 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 890 for Authentication", RFC 4954, July 2007. 892 [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized 893 Email Addresses", RFC 5336, September 2008. 895 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 896 July 2009. 898 Authors' Addresses 900 Jiankang YAO 901 CNNIC 902 No.4 South 4th Street, Zhongguancun 903 Beijing 905 Phone: +86 10 58813007 906 Email: yaojk@cnnic.cn 908 Wei MAO 909 CNNIC 910 No.4 South 4th Street, Zhongguancun 911 Beijing 913 Phone: +86 10 58812230 914 Email: maowei_ietf@cnnic.cn