idnits 2.17.1 draft-ietf-eai-rfc5336bis-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 11, 2011) is 4736 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 686, but not defined == Unused Reference: 'RFC5891' is defined on line 859, but no explicit reference was found in the text == Unused Reference: 'RFC5336' is defined on line 895, 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 April 11, 2011 6 (if approved) 7 Intended status: Standards Track 8 Expires: October 13, 2011 10 SMTP Extension for Internationalized Email Address 11 draft-ietf-eai-rfc5336bis-09.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 October 13, 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 . . . . . . . . . . . . . . . 10 75 3.5. Non-ASCII addresses and Reply-codes . . . . . . . . . . . 10 76 3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 11 77 3.7. Additional ESMTP Changes and Clarifications . . . . . . . 11 78 3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 11 79 3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 12 80 3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 12 81 3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 14 82 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 84 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 85 7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 18 86 7.1. draft-yao-eai-rfc5336bis: Version 00 . . . . . . . . . . . 18 87 7.2. draft-ietf-eai-rfc5336bis: Version 00 . . . . . . . . . . 19 88 7.3. draft-ietf-eai-rfc5336bis: Version 01 . . . . . . . . . . 19 89 7.4. draft-ietf-eai-rfc5336bis: Version 02 . . . . . . . . . . 19 90 7.5. draft-ietf-eai-rfc5336bis: Version 03 . . . . . . . . . . 19 91 7.6. draft-ietf-eai-rfc5336bis: Version 04 . . . . . . . . . . 19 92 7.7. draft-ietf-eai-rfc5336bis: Version 05 . . . . . . . . . . 19 93 7.8. draft-ietf-eai-rfc5336bis: Version 06 . . . . . . . . . . 19 94 7.9. draft-ietf-eai-rfc5336bis: Version 07 . . . . . . . . . . 19 95 7.10. draft-ietf-eai-rfc5336bis: Version 08 . . . . . . . . . . 19 96 7.11. draft-ietf-eai-rfc5336bis: Version 09 . . . . . . . . . . 20 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", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to 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 envelope. 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" by the SMTP client. 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 ignore 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 envelope 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 conforming 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 341 ; Note that uDomain may not be resolvable if sub-udomain is not a 342 ; valid U-Label or LDH Label as defined in RFC 5890 344 uLet-dig = Let-dig / UTF8-non-ascii 346 Let-dig = 348 uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-non-ascii) uLet-dig 349 ; Replace Ldh-str in RFC 5321, Section 4.1.2 351 UTF8-non-ascii = 353 3.4. MAIL Command Parameter Usage 355 If the envelope or message being sent requires the capabilities of 356 the UTF8SMTPbis extension, the SMTP client MUST supply the 357 UTF8SMTPbis parameter with the MAIL command. If this parameter is 358 provided, it MUST have no value. If the SMTP client is aware that 359 neither the envelope nor the message being sent requires any of the 360 UTF8SMTPbis extension capabilities, it SHOULD NOT supply the 361 UTF8SMTPbis parameter with the MAIL command. 363 Because there is no guarantee that a next-hop SMTP server will 364 support the UTF8SMTPbis extension, use of the UTF8SMTPbis extension 365 always carries a risk of transmission failure. In fact, during the 366 early stages of deployment for the UTF8SMTPbis extension, the risk 367 will be quite high. Hence there is a distinct near-term advantage 368 for ASCII-only messages to be sent without using this extension. The 369 long-term advantage of casting ASCII [ASCII] characters(0x7f and 370 below) as UTF-8 form is that it permits pure-Unicode environments. 372 This specification does not require that the EAI-aware SMTP client 373 inspect the message or otherwise go to extraordinary lengths to 374 assure itself whether the UTF8SMTPbis extension is REQUIRED for the 375 particular message. 377 3.5. Non-ASCII addresses and Reply-codes 379 An EAI-aware SMTP client MUST only send an internationalized message 380 to an SMTP server that supports UTF8SMTPbis. If the SMTP server does 381 not support this option, then the EAI-aware SMTP client has three 382 choices according to section 3.2 of this specification. 384 The three-digit Reply-codes used in this section are based on their 385 meanings as defined in RFC 5321. 387 When messages are rejected because the RCPT command requires an ASCII 388 address, the reply-code 553 is returned with the meaning "mailbox 389 name not allowed". When messages are rejected because the MAIL 390 command requires an ASCII address, the reply-code 550 is returned 391 with the meaning "mailbox unavailable". When the EAI-aware SMTP 392 server supports enhanced mail system status codes [RFC3463], reply- 393 code "X.6.7" [RFC5248] is used, meaning that "non-ASCII addresses not 394 permitted for that sender/recipient". 396 When messages are rejected for other reasons, the server follows the 397 model of the base email specifications in RFC 5321; this extension 398 does not change those circumstances or reply messages. 400 If the reply-code is issued after the final "." of the DATA command, 401 the reply-code "554" is used with the meaning "Transaction failed". 402 When the EAI-aware SMTP server supports enhanced mail system status 403 codes [RFC3463], reply-code "X.6.9" [RFC5248] is used, meaning that 404 "UTF-8 header message can not be transmitted to one or more 405 recipients, so the message MUST be rejected". 407 3.6. Body Parts and SMTP Extensions 409 The MAIL command parameter UTF8SMTPbis asserts that a message is an 410 internationalized message or the message being sent needs the 411 UTF8SMTPbis support. The message being sent via the MAIL command 412 with the UTF8SMTPbis parameter has still a chance of that the message 413 transmitted is not an internationalized message. An EAI-aware SMTP 414 client or server that requires accurate knowledge of whether a 415 message is internationalized needs to parse all message header fields 416 and MIME header fields [RFC2045] and [RFC2047] in the message body. 417 However, this specification does not require that the SMTP client or 418 server inspects the message. 420 While this specification requires that EAI-aware SMTP servers support 421 the 8BITMIME extension [RFC6152] to ensure that servers have adequate 422 handling capability for 8-bit data and to avoid a number of complex 423 encoding problems, the use of internationalized email addresses 424 obviously does not require non-ASCII body parts in the MIME message 425 in RFC 2045 and RFC 2047. The UTF8SMTPbis extension MAY be used with 426 the BODY=8BITMIME parameter [RFC6152] if that is appropriate given 427 the body content or, with the BODY=BINARYMIME parameter, if the SMTP 428 server advertises BINARYMIME [RFC3030] and that is appropriate. 430 3.7. Additional ESMTP Changes and Clarifications 432 The information carried in the mail transport process involves 433 addresses ("mailboxes") and domain names in various contexts in 434 addition to the MAIL and RCPT commands and extended alternatives to 435 them. In general, the rule is that, when RFC 5321 specifies a 436 mailbox, this SMTP extension requires UTF-8 form to be used for the 437 entire string; when RFC 5321 specifies a domain name, the name SHOULD 438 be in the form of A-label if this domain name is an internationalized 439 domain name[RFC5890]. 441 The following subsections list and discuss all of the relevant cases. 443 3.7.1. The Initial SMTP Exchange 445 When an SMTP connection is opened, the SMTP server sends a "greeting" 446 response consisting of the 220 reply-code and some information. The 447 SMTP client then sends the EHLO command. Since the SMTP client 448 cannot know whether the SMTP server supports UTF8SMTPbis until after 449 it receives the response from EHLO, the EAI-aware SMTP client MUST 450 send only ASCII (LDH label or A-label [RFC5890] ) domains in the EHLO 451 command and that, if the EAI-aware SMTP server provides domain names 452 in the EHLO response, they MUST be in the form of LDH labels or 453 A-labels. 455 3.7.2. Mail eXchangers 457 If multiple DNS MX records are used to specify multiple servers for a 458 domain in section 5 of [RFC5321], it is strongly advised that all or 459 none of them SHOULD support the UTF8SMTPbis extension. Otherwise, 460 surprising rejections can happen during temporary or permanent 461 failures, which users might perceive as serious reliability issues. 462 In order to avoid the possible surprising rejections, the EAI-aware 463 email system may also implement the advice in EAI addresses advice 464 document [EAI addresses] and EAI deployment advice document [EAI 465 Deployment]. 467 3.7.3. Trace Information 469 For the trace information [RFC5321], this memo updates the time stamp 470 line and the return path line [RFC5321] formally defined as follows: 472 uReturn-path-line = "Return-Path:" FWS uReverse-path CRLF 473 ; Replaces Return-path-line in Section 4.4 of RFC 5321 475 uReverse-path = uPath / "<>" 476 ; Replace Reverse-path in RFC 5321, section 4.1.2 478 uPath = "<" [ A-d-l ":" ] uMailbox ">" 479 ; Replace Path in RFC 5321, section 4.1.2 480 ; uMailbox is defined in section 3.3 of this document 482 A-d-l = 484 uTime-stamp-line = "Received:" FWS uStamp CRLF 485 ; Replaces Time-stamp-line in Section 4.4 of RFC 5321 487 uStamp = From-domain By-domain uOpt-info [CFWS] ";" FWS date-time 488 ; Replaces Stamp in Section 4.4 of RFC 5321 490 From-domain = 492 By-domain = 494 date-time = 495 ; Same definition with date-time in Section 4.4 of RFC 5321 497 uOpt-info = [Via] [With] [ID] [uFor] 498 [Additional-Registered-Clauses] 499 ; Replaces Opt-info in Section 4.4 of RFC 5321 500 ; The protocol value for With will allow a UTF8SMTPbis value 502 Via = 504 With = 506 ID = 508 Additional-Registered-Clauses = 510 uFor = CFWS "FOR" FWS ( uPath / uMailbox) 511 ; Replaces For in Section 4.4 of RFC 5321 512 ; uMailbox is defined in section 3.3 of this document 514 Except in the 'uFor' clause and 'uReverse-path' value where 515 internationalized domain name with the U-label form MAY be used, 516 internationalized domain names in Received fields MUST be transmitted 517 in the form of A-labels. The protocol value of the WITH clause when 518 this extension is used is one of the UTF8SMTPbis values specified in 519 the "IANA Considerations" section of this document. 521 3.7.4. UTF-8 Strings in Replies 523 3.7.4.1. MAIL Command 525 If an SMTP client follows this specification and sends any MAIL 526 commands containing the UTF8SMTPbis parameter, the EAI-aware SMTP 527 server is permitted to use UTF-8 characters in the email address 528 associated with 251 and 551 reply-codes, and the SMTP client MUST be 529 able to accept and process them. If a given MAIL command does not 530 include the UTF8SMTPbis parameter, the EAI-aware SMTP server MUST NOT 531 return a 251 or 551 response containing a non-ASCII mailbox. 532 Instead, it MUST transform such responses into 250 or 550 responses 533 that do not contain non-ASCII addresses. 535 3.7.4.2. VRFY and EXPN Commands and the UTF8SMTPbis Parameter 537 If the VRFY and EXPN commands are transmitted with the parameter 538 "UTF8SMTPbis", it indicates the SMTP client can accept UTF-8 strings 539 in replies to those commands. This parameter for the VRFY and EXPN 540 commands SHOULD only be used after the SMTP client sees the EHLO 541 response with the UTF8SMTPbis keyword. This allows the EAI-aware 542 SMTP server to use UTF-8 strings in mailbox names and full names that 543 occur in replies without concern that the SMTP client might be 544 confused by them. An SMTP client that conforms to this specification 545 MUST accept and correctly process replies from the VRFY and EXPN 546 commands that contain UTF-8 strings. However, the EAI-aware SMTP 547 server MUST NOT use UTF-8 strings in replies if the SMTP client does 548 not specifically allow such replies by transmitting this parameter. 549 Most replies do not require that a mailbox name be included in the 550 returned text, and therefore UTF-8 string is not needed in them. 551 Some replies, notably those resulting from successful execution of 552 the VRFY and EXPN commands, do include the mailbox. 554 VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to: 556 vrfy = "VRFY" SP uString 557 [ SP "UTF8SMTPbis" ] CRLF 559 expn = "EXPN" SP uString 560 [ SP "UTF8SMTPbis" ] CRLF 562 uString = uAtom / uQuoted-string 563 ; uAtom and uQuoted-string are defined in 564 ; Section 3.3 of this document. 566 The "UTF8SMTPbis" parameter does not use a value. If the reply to a 567 VERIFY (VRFY) or EXPAND (EXPN) command requires UTF-8 string, but the 568 SMTP client did not use the "UTF8SMTPbis" parameter, then the EAI- 569 aware SMTP server MUST use either the reply-code 252 or 550. Reply- 570 code 252, defined in [RFC5321], means "Cannot VRFY user, but will 571 accept the message and attempt the delivery". Reply-code 550, also 572 defined in [RFC5321], means "Requested action not taken: mailbox 573 unavailable". When the EAI-aware SMTP server supports enhanced mail 574 system status codes [RFC3463], the enhanced reply-code as specified 575 below is used. Using the "UTF8SMTPbis" parameter with a VERIFY 576 (VRFY) or EXPAND (EXPN) command enables UTF-8 replies for that 577 command only. 579 If a normal success response (i.e., 250) is returned, the response 580 MAY include the full name of the user and MUST include the mailbox of 581 the user. It MUST be in either of the following forms: 583 User Name 584 ; uMailbox is defined in Section 3.3 of this document. 585 ; User Name can contain non-ASCII characters. 587 uMailbox 588 ; uMailbox is defined in Section 3.3 of this document. 590 If the SMTP reply requires UTF-8 strings, but UTF-8 string is not 591 allowed in the reply, and the EAI-aware SMTP server supports enhanced 592 mail system status codes [RFC3463], the enhanced reply-code is 593 "X.6.8" [RFC5248], meaning "A reply containing a UTF-8 string is 594 REQUIRED to show the mailbox name, but that form of response is not 595 permitted by the SMTP client". 597 If the SMTP client does not support the UTF8SMTPbis extension, but 598 receives a UTF-8 string in a reply, it may not be able to properly 599 report the reply to the user, and some clients might crash. 600 Internationalized messages in replies are only allowed in the 601 commands under the situations described above. Under any other 602 circumstances, UTF-8 string MUST NOT appear in the reply. 604 Although UTF-8 form is needed to represent email addresses in 605 responses under the rules specified in this section, this extension 606 does not permit the use of UTF-8 string for any other purposes. EAI- 607 aware SMTP servers MUST NOT include non-ASCII characters in replies 608 except in the limited cases specifically permitted in this section. 610 4. IANA Considerations 612 IANA is requested to add a new value "UTF8SMTPbis" to the SMTP 613 Service Extension subregistry of the Mail Parameters registry, 614 according to the following data: 616 +-------------+---------------------------------+-----------+ 617 | Keywords | Description | Reference | 618 +-------------+---------------------------------+-----------+ 619 | UTF8SMTPbis | Internationalized email address | [RFCXXXX] | 620 +-------------+---------------------------------+-----------+ 622 This document updates the values to the SMTP Enhanced Status Code 623 subregistry of the Mail Parameters registry, following the guidance 624 in Sections 3.5 and 3.7.4.2 of this document, and being based on 625 [RFC5248]. The registration data is as follows: 627 Code: X.6.7 628 Sample Text: non-ASCII addresses not permitted 629 for that sender/recipient 630 Associated basic status code: 550, 553 631 Description: This indicates the reception of a MAIL or RCPT 632 command that non-ASCII addresses are not permitted 633 Defined: RFC XXXX (Standard track) 634 Submitter: Jiankang YAO 635 Change controller: ima@ietf.org 637 Code: X.6.8 638 Sample Text: UTF-8 string reply is required, 639 but not permitted by the SMTP client 640 Associated basic status code: 252, 550, 553 641 Description: This indicates that a reply containing a UTF-8 642 string is required to show the mailbox name, 643 but that form of response is not 644 permitted by the SMTP client. 645 Defined: RFC XXXX (Standard track) 646 Submitter: Jiankang YAO 647 Change controller: ima@ietf.org 649 Code: X.6.9 650 Sample Text: UTF-8 header message can not be transferred 651 to one or more recipient so the message 652 must be rejected 653 Associated basic status code: 550 654 Description: This indicates that transaction failed 655 after the final "." of the DATA command. 656 Defined: RFC XXXX (Standard track) 657 Submitter: Jiankang YAO 658 Change controller: ima@ietf.org 659 Code: X.6.10 660 Description: This is a duplicate of X.6.8 and 661 is thus deprecated. 663 The following entries SHOULD be updated or added in the "Mail 664 Transmission Types" registry under the Mail Parameters registry. 666 +--------------+-------------------------------+--------------------+ 667 | WITH | Description | Reference | 668 | protocol | | | 669 | types | | | 670 +--------------+-------------------------------+--------------------+ 671 | UTF8SMTP | ESMTP with UTF8SMTP | [RFCXXXX] | 672 | UTF8SMTPA | ESMTP with UTF8SMTP and SMTP | [RFC4954] | 673 | | AUTH | [RFCXXXX] | 674 | UTF8SMTPS | ESMTP with UTF8SMTP and | [RFC3207] | 675 | | STARTTLS | [RFCXXXX] | 676 | UTF8SMTPSA | ESMTP with UTF8SMTP and both | [RFC3207] | 677 | | STARTTLS and SMTP AUTH | [RFC4954] | 678 | | | [RFCXXXX] | 679 | UTF8LMTP | LMTP with UTF8SMTP | [RFCXXXX] | 680 | UTF8LMTPA | LMTP with UTF8SMTP and SMTP | [RFC4954] | 681 | | AUTH | [RFCXXXX] | 682 | UTF8LMTPS | LMTP with UTF8SMTP and | [RFC3207] | 683 | | STARTTLS | [RFCXXXX] | 684 | UTF8LMTPSA | LMTP with UTF8SMTP and both | [RFC3207] | 685 | | STARTTLS and LMTP AUTH | [RFC4954] | 686 | | | [RFCXXXX] | 687 +--------------+-------------------------------+--------------------+ 689 5. Security Considerations 691 The extended security considerations discussion in the framework 692 document [RFC4952bis] will be applied here. 694 More security considerations are discussed below: 696 Beyond the use inside the email global system (in SMTP envelopes and 697 message headers), internationalized email addresses will also show up 698 inside other cases, in particular: 700 o the logging systems of SMTP transactions and other logs to monitor 701 the email systems; 702 o the trouble ticket systems used by Security Teams to manage 703 security incidents, when an email address is involved; 705 In order to avoid problems that could cause loss of data, this will 706 likely require extending these systems to support full UTF-8, or to 707 require to provide an adequate mechanisms for mapping non-ASCII 708 strings to ASCII. 710 Another security aspect to be considered is related to the ability by 711 security team members to quickly understand, read and identify email 712 addresses from the logs, when they are tracking an incident. 713 Mechanims to automatically and quickly provide the origin or 714 ownership of an internationalized email address SHALL be implemented 715 for use also by log readers which cannot read easily non-ASCII 716 information. 718 The SMTP commands VRFY and EXPN are sometimes used in SMTP 719 transactions where there is no message to transfer (by tools used to 720 take automated actions in case potential spam messages are 721 identified). RFC 5321 section 3.5 and 7.3 give some detailed 722 description of use and possible behaviours. Implementation of 723 internationalized addrsses can affect also logs and actions by these 724 tools. 726 6. Acknowledgements 728 This document revised the [RFC5336]document based on the EAI WG's 729 discussion result. Many EAI WG members did some tests and 730 implementations to move this document to the Standard Track document. 731 Significant comments and suggestions were received from Xiaodong LEE, 732 Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other members of the JET 733 team and were incorporated into the specification. Additional 734 important comments and suggestions, and often specific text, were 735 contributed by many members of the WG and design team. Those 736 contributions include material from John C Klensin, Charles Lindsey, 737 Dave Crocker, Harald Tveit Alvestrand, Marcos Sanz, Chris Newman, 738 Martin Duerst, Edmon Chung, Tony Finch, Kari Hurtta, Randall Gellens, 739 Frank Ellermann, Alexey Melnikov, Pete Resnick, S. Moonesamy, Soobok 740 Lee, Shawn Steele, Alfred Hoenes, Miguel Garcia, Magnus Westerlund, 741 and Lars Eggert. Of course, none of the individuals are necessarily 742 responsible for the combination of ideas represented here. 744 7. Change History 746 [[anchor14: RFC Editor: Please remove this section.]] 748 7.1. draft-yao-eai-rfc5336bis: Version 00 750 Applied errata suggested by Alfred Hoenes. 752 7.2. draft-ietf-eai-rfc5336bis: Version 00 754 Applied the changes suggested by the EAI new charter. 756 7.3. draft-ietf-eai-rfc5336bis: Version 01 758 Applied the changes suggested by 78 IETF EAI meeting. 760 7.4. draft-ietf-eai-rfc5336bis: Version 02 762 remove the appendix since rfc4952bis has added this material 764 improve the text 766 remove the text about no body parameter 768 7.5. draft-ietf-eai-rfc5336bis: Version 03 770 improve the text 772 7.6. draft-ietf-eai-rfc5336bis: Version 04 774 update the abstract 776 improve the text 778 7.7. draft-ietf-eai-rfc5336bis: Version 05 780 improve the text based on AD and Co-chairs 782 7.8. draft-ietf-eai-rfc5336bis: Version 06 784 update the iana consideration 786 7.9. draft-ietf-eai-rfc5336bis: Version 07 788 improve the iana consideration 790 7.10. draft-ietf-eai-rfc5336bis: Version 08 792 improve the texts 794 add the mail parameter 796 add the new section about mail command parameter usage 798 update the security consideration 800 7.11. draft-ietf-eai-rfc5336bis: Version 09 802 improve the texts 804 8. References 806 8.1. Normative References 808 [ASCII] American National Standards Institute (formerly United 809 States of America Standards Institute), "USA Code for 810 Information Interchange", ANSI X3.4-1968, 1968. 812 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 813 October 1996. 815 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 816 Requirement Levels", BCP 14, RFC 2119, March 1997. 818 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 819 RFC 3463, January 2003. 821 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 822 for Delivery Status Notifications", RFC 3464, 823 January 2003. 825 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 826 10646", RFC 3629, November 2003. 828 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 829 RFC 4409, April 2006. 831 [RFC4952bis] 832 Klensin, J. and Y. Ko, "Overview and Framework for 833 Internationalized Email", I-D rfc4952bis, September 2010. 835 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 836 Specifications: ABNF", STD 68, RFC 5234, January 2008. 838 [RFC5248] Hansen , T. and J. Klensin, "A Registry for SMTP Enhanced 839 Mail System Status Codes", RFC 5248, June 2008. 841 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 842 October 2008. 844 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 845 October 2008. 847 [RFC5335bis] 848 Abel, Y. and S. Steel, "Internationalized Email Headers", 849 I-D rfc5335bis, March 2011. 851 [RFC5337bis] 852 Hansen, T., Ed., Newman, C., and A. Melnikov, Ed., 853 "Internationalized Delivery Status and Disposition 854 Notifications", I-D 5337bis, October 2010. 856 [RFC5890] Klensin, J., "Internationalizing Domain Names in 857 Applications (IDNA definitions)", RFC 5890, June 2010. 859 [RFC5891] Klensin, J., "Internationalized Domain Names in 860 Applications (IDNA): Protocol", RFC 5891, August 2010. 862 [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP 863 Service Extension for 8-bit MIME Transport", STD 71, 864 RFC 6152, March 2011. 866 8.2. Informative References 868 [EAI Deployment] 869 Yao, J., Lee, X., and S. Steel, "Advice for EAI 870 deployment", draft eai-deployment, December 2010. 872 [EAI addresses] 873 Steel, S., Yao, J., and Mark. Davis, "Advice for non-ASCII 874 & ASCII addresses", draft eai-address-advice, 875 December 2010. 877 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 878 Extensions (MIME) Part One: Format of Internet Message 879 Bodies", RFC 2045, November 1996. 881 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 882 Part Three: Message Header Extensions for Non-ASCII Text", 883 RFC 2047, November 1996. 885 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 886 of Large and Binary MIME Messages", RFC 3030, 887 December 2000. 889 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 890 Transport Layer Security", RFC 3207, February 2002. 892 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 893 for Authentication", RFC 4954, July 2007. 895 [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized 896 Email Addresses", RFC 5336, September 2008. 898 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 899 July 2009. 901 Authors' Addresses 903 Jiankang YAO 904 CNNIC 905 No.4 South 4th Street, Zhongguancun 906 Beijing 908 Phone: +86 10 58813007 909 Email: yaojk@cnnic.cn 911 Wei MAO 912 CNNIC 913 No.4 South 4th Street, Zhongguancun 914 Beijing 916 Phone: +86 10 58812230 917 Email: maowei_ietf@cnnic.cn