idnits 2.17.1 draft-ietf-eai-smtpext-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 952. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 963. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 970. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 976. 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 : ---------------------------------------------------------------------------- == 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 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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 8, 2008) is 5946 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFCXXXX' is mentioned on line 648, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-eai-dsn-03 ** Obsolete normative reference: RFC 4952 (ref. 'EAI-framework') (Obsoleted by RFC 6530) == Outdated reference: A later version (-12) exists of draft-ietf-eai-utf8headers-07 ** Obsolete normative reference: RFC 1652 (Obsoleted by RFC 6152) ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4409 (Obsoleted by RFC 6409) == Outdated reference: A later version (-05) exists of draft-hansen-4468upd-mailesc-registry-02 == Outdated reference: A later version (-12) exists of draft-ietf-eai-downgrade-04 Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Yao, Ed. 3 Internet-Draft W. Mao, Ed. 4 Updates: RFC4952 CNNIC 5 (if approved) January 8, 2008 6 Intended status: Experimental 7 Expires: July 11, 2008 9 SMTP extension for internationalized email address 10 draft-ietf-eai-smtpext-10.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 11, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document specifies an SMTP extension for transport and delivery 44 of email messages with internationalized email addresses or header 45 information. Communication with systems that do not implement this 46 specification is specified in another document. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Role of this specification . . . . . . . . . . . . . . . . 3 52 1.2. Proposal Context . . . . . . . . . . . . . . . . . . . . . 3 53 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Mail Transport-level Protocol . . . . . . . . . . . . . . . . 4 55 2.1. Framework for the Internationalization Extension . . . . . 4 56 2.2. The UTF8SMTP Extension . . . . . . . . . . . . . . . . . . 5 57 2.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 6 58 2.4. The ALT-ADDRESS Parameter . . . . . . . . . . . . . . . . 8 59 2.5. ALT-ADDRESS Parameter Usage and Response Codes . . . . . . 9 60 2.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 10 61 2.7. Additional ESMTP Changes and Clarifications . . . . . . . 11 62 2.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 11 63 2.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 11 64 2.7.3. Trace Information . . . . . . . . . . . . . . . . . . 11 65 2.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 12 66 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 69 6. Change History . . . . . . . . . . . . . . . . . . . . . . . . 15 70 6.1. draft-ietf-eai-smtpext: Version 00 . . . . . . . . . . . . 15 71 6.2. draft-ietf-eai-smtpext: Version 01 . . . . . . . . . . . . 16 72 6.3. draft-ietf-eai-smtpext: Version 02 . . . . . . . . . . . . 16 73 6.4. draft-ietf-eai-smtpext: Version 03 . . . . . . . . . . . . 16 74 6.5. draft-ietf-eai-smtpext: Version 04 . . . . . . . . . . . . 16 75 6.6. draft-ietf-eai-smtpext: Version 05 . . . . . . . . . . . . 16 76 6.7. draft-ietf-eai-smtpext: Version 06 . . . . . . . . . . . . 16 77 6.8. draft-ietf-eai-smtpext: Version 07 . . . . . . . . . . . . 17 78 6.9. draft-ietf-eai-smtpext: Version 08 . . . . . . . . . . . . 17 79 6.10. draft-ietf-eai-smtpext: Version 09 . . . . . . . . . . . . 17 80 6.11. draft-ietf-eai-smtpext: Version 10 . . . . . . . . . . . . 17 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 7.1. Normative References . . . . . . . . . . . . . . . . . . . 17 83 7.2. Informative References . . . . . . . . . . . . . . . . . . 19 84 Appendix A. Material Updating RFC 4952 . . . . . . . . . . . . . 19 85 A.1. Conventional Message and Internationalized Message . . . . 19 86 A.2. LMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 87 A.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 20 88 A.4. Implementation Advice . . . . . . . . . . . . . . . . . . 20 89 A.5. Applicability of SMTP Extension to Additional Uses . . . . 20 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 91 Intellectual Property and Copyright Statements . . . . . . . . . . 22 93 1. Introduction 95 An internationalized email address includes two parts, the local part 96 and the domain part. The ways email addresses are used by protocols 97 are different from the ways domain names are used. The most critical 98 difference is that emails are delivered through a chain of clients 99 and servers while domain names are resolved by name servers looking 100 up those names in their own tables. In addition to this, the 101 extended email transport protocol [RFC2821] provides a negotiation 102 mechanism with which clients can discover server capabilities and 103 make decisions for further processing. An extended overview of the 104 extension model for internationalized addresses and headers appears 105 in [EAI-framework], referred to as "the framework document" or just 106 as "Framework" elsewhere in this specification. This document 107 specifies an SMTP extension to permit internationalized email 108 addresses in envelopes, and UNICODE characters (encoded in UTF-8) in 109 headers. 111 1.1. Role of this specification 113 The framework document specifies the requirements for, and describes 114 components of, full internationalization of electronic mail. A 115 thorough understanding of the information in that document and in the 116 base Internet email specifications [RFC2821] [RFC2822] is necessary 117 to understand and implement this specification. 119 This document specifies an element of the email internationalization 120 work, specifically the definition of an SMTP extension [RFC2821] for 121 internationalized email address transport delivery. 123 1.2. Proposal Context 125 This specification describes an optional extension to the email 126 transport mechanism that permits non-ASCII [ASCII] characters in both 127 the envelope and header fields of messages. The EAI-utf8header 128 specification [EAI-utf8header] provides the details of how and where 129 non-ASCII characters are permitted in the header fields of messages. 130 The context for the change is described in the framework document. 132 1.3. Terminology 134 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 135 and "MAY" in this specification are to be interpreted as described in 136 RFC 2119 [RFC2119]. 138 The terms "conventional message" and "internationalized message" are 139 defined in an appendix to this specification. The terms "UTF-8 140 string" or "UTF-8 character" are used informally to refer to Unicode 141 characters encoded in UTF-8 [RFC3629]. All other specialized terms 142 used in this specification are defined in the framework document or 143 in the base Internet email specifications [RFC2821] [RFC2822]. In 144 particular, the terms "ASCII address", "internationalized email 145 address", "non-ASCII address", "i18mail address", "UTF8SMTP", 146 "message" and "mailing list" are used in this document according to 147 the definitions in the framework one. 149 This specification defines only those ABNF [RFC4234] syntax rules 150 that are different from those of the base email specifications 151 [RFC2821][RFC2822] and, where the earlier rules are upgraded or 152 extended, gives them new names. When the new rule is a small 153 modification to the older one, it is typically given a name starting 154 with "u". Rules that are undefined here may be found in the base 155 email specifications under the same names. 157 [[anchor4: NOTE TO RFC EDITOR: Please remove the following text 158 before publication.]] 159 This specification is being discussed on the EAI mailing list. See 160 https://www1.ietf.org/mailman/listinfo/ima for information about 161 subscribing. The list's archive is at 162 http://www1.ietf.org/mail-archive/web/ima/index.html. 164 2. Mail Transport-level Protocol 166 2.1. Framework for the Internationalization Extension 168 The following service extension is defined: 170 1. The name of the SMTP service extension is "Email Address 171 Internationalization". 172 2. The EHLO keyword value associated with this extension is 173 "UTF8SMTP". 174 3. No parameter values are defined for this EHLO keyword value. In 175 order to permit future (although unanticipated) extensions, the 176 EHLO response MUST NOT contain any parameters for that keyword. 177 Clients MUST ignore any parameters, that is, clients MUST behave 178 as if the parameters do not appear. If a server includes 179 UTF8SMTP in its EHLO response, it MUST be fully compliant with 180 this version of this specification. 181 4. One optional parameter, ALT-ADDRESS, is added to the MAIL and 182 RCPT commands of SMTP. ALT-ADDRESS specifies an all-ASCII 183 address which can be used as a substitute for the corresponding 184 primary (i18mail) address when downgrading. More discussion of 185 the use of this parameter appears in [EAI-framework] and 186 [EAI-downgrading]. 188 5. One optional parameter "UTF8REPLY" is added to the VRFY and EXPN 189 commands. The parameter UTF8REPLY has no value. The parameter 190 indicates that the SMTP client can accept Unicode characters in 191 UTF-8 encoding in replies from the VRFY and EXPN commands. 192 6. No additional SMTP verbs are defined by this extension. 193 7. Servers offering this extension MUST provide support for, and 194 announce, the 8BITMIME extension [RFC1652]. 195 8. The reverse-path and forward-path of the SMTP MAIL and RCPT 196 commands are extended to allow Unicode characters encoded in 197 UTF-8 in mailbox names (addresses). 198 9. The mail message body is extended as specified in 199 [EAI-utf8header]. 200 10. The maximum length of MAIL and RCPT command lines is increased 201 by 460 characters by the possible addition of the ALT-ADDRESS 202 keyword and value. 203 11. The UTF8SMTP extension is valid on the submission port 204 [RFC4409]. 206 2.2. The UTF8SMTP Extension 208 An SMTP Server that announces this extension MUST be prepared to 209 accept a UTF-8 string [RFC3629] in any position in which RFC 2821 210 specifies that a mailbox can appear. That string MUST be parsed only 211 as specified in RFC 2821, i.e., by separating the mailbox into source 212 route, local part and domain part, using only the characters colon 213 (U+003A), comma (U+002C), and at-sign (U+0040) as specified there. 214 Once isolated by this parsing process, the local part MUST be treated 215 as opaque unless the SMTP Server is the final delivery MTA. Any 216 domain names that are to be looked up in the DNS MUST first be 217 processed into the form specified in IDNA [RFC3490] by means of the 218 ToASCII() operation unless they are already in that form. Any domain 219 names that are to be compared to local strings SHOULD be checked for 220 validity and then MUST be compared as specified in section 3.4 of 221 IDNA. 223 An SMTP Client that receives the UTF8SMTP extension keyword in 224 response to the "EHLO" command MAY transmit mailbox names within SMTP 225 commands as internationalized strings in UTF-8 form. It MAY send a 226 UTF-8 header [EAI-utf8header] (which may also include mailbox names 227 in UTF-8). It MAY transmit the domain parts of mailbox names within 228 SMTP commands or the message header in either the form of ACE labels 229 as specified in IDNA [RFC3490] or as UTF-8 strings. All labels in 230 domain parts of mailbox names which are IDNs (either UTF-8 or ACE 231 strings) MUST be valid. If the original client submits a message to 232 a Message Submission Server ("MSA") [RFC4409], it is the 233 responsibility of the MSA that all domain labels are valid; otherwise 234 it is the original client's responsibility. The presence of the 235 UTF8SMTP extension does not change the requirement of RFC 2821 that 236 servers relaying mail MUST NOT attempt to parse, evaluate, or 237 transform the local part in any way. 239 If the UTF8SMTP SMTP extension is not offered by the Server, the SMTP 240 client MUST NOT transmit an internationalized address and MUST NOT 241 transmit a mail message containing internationalized mail headers as 242 described in [EAI-utf8header] at any level within its MIME structure. 243 Instead, if an SMTP client (SMTP sender) attempts to transfer a 244 internationalized message and encounters a server that does not 245 support the extension, it MUST make one of the following four 246 choices: 248 1. If and only if the SMTP client (sender) is a Message Submission 249 Server ("MSA") [RFC4409], it MAY, consistent with the general 250 provisions for changes by such servers, rewrite the envelope, 251 headers, or message material to make them entirely ASCII and 252 consistent with the provisions of RFC 2821 [RFC2821] and RFC 2822 253 [RFC2822]. 254 2. Either reject the message during the SMTP transaction or accept 255 the message and then generate and transmit a notification of non- 256 deliverability. Such notification MUST be done as specified in 257 RFC 2821 [RFC2821], RFC 3464 [RFC3464], and the EAI DSN 258 specification [EAI-dsn]. 259 3. Find an alternate route to the destination that permits UTF8SMTP. 260 That route may be discovered by trying alternate MX hosts (using 261 preference rules as specified in RFC 2821) or using other means 262 available to the SMTP-sender. 263 4. If and only if ASCII addresses are available for all addresses 264 that appear in the return path and the specific forward paths 265 being attempted, downgrade the message to an all-ASCII form as 266 specified in [EAI-downgrading]. An ASCII address is considered 267 to be "available" for a particular address if the original 268 address in the envelope is in ASCII or if an ALT-ADDRESS 269 parameter is specified for a UTF8SMTP address. 271 The difference between "choice 1" and "choice 4" is that "choice 1" 272 is constrained by Message Submission [RFC4409], while "choice 4" is 273 constrained by [EAI-downgrading]. 275 2.3. Extended Mailbox Address Syntax 277 RFC 2821, section 4.1.2, defines the syntax of a mailbox entirely in 278 terms of ASCII characters, using the production for a mailbox and 279 those on which it depends. 281 The key changes made by this specification are, informally, to 282 o Change the definition of "sub-domain" to permit either the 283 definition above or a UTF-8 string representing a DNS label that 284 is conformant with IDNA [RFC3490]. 285 o Change the definition of "Atom" to permit either the definition 286 above or a UTF-8 string. That string MUST NOT contain any of the 287 ASCII characters (either graphics or controls) that are not 288 permitted in "atext"; it is otherwise unrestricted. 290 According to the description above, the syntax of an 291 internationalized email mailbox name (address) is defined in ABNF 292 [RFC4234] as 294 uMailbox = uLocal-part "@" uDomain 295 ; Replace Mailbox in RFC 2821, section 4.1.2 297 uLocal-part = uDot-string / uQuoted-string 298 ; MAY be case-sensitive 299 ; Replace Local-part in RFC 2821, section 4.1.2 301 uDot-string = uAtom *("." uAtom) 302 ; Replace Dot-string in RFC 2821, section 4.1.2 304 uAtom = 1*ucharacter 305 ; Replace Atom in RFC 2821, section 4.1.2 307 ucharacter = atext / UTF8-xtra-char 308 ; Replace character in RFC 2821, section 4.1.2 309 ; atext is defined in RFC 2822 311 uQuoted-string = DQUOTE *uqcontent DQUOTE 312 ; Replace Quoted-string in RFC 2821, section 4.1.2 313 ; DQUOTE is Double Quote defined in RFC 4234 315 uqcontent = qcontent / UTF8-xtra-char 316 ; qcontent is defined in RFC 2822, section 3.2.5 318 uDomain = (sub-udomain 1*("." sub-udomain)) / address-literal 319 ; Replace Domain in RFC 2821, section 4.1.2 320 ; address-literal is defined in RFC2821 section 4.1.2 322 sub-udomain = uLet-dig [uLdh-str] 323 ; Replace sub-domain in RFC 2821, section 4.1.2 325 uLet-dig = Let-dig / UTF8-xtra-char 326 ; Let-dig is defined in RFC 2821, section 4.1.3 328 uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-xtra-char) uLet-dig 329 ; Replace Ldh-str in RFC 2821, section 4.1.3 331 UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 332 ; UTF8-2, UTF8-3 and UTF8-4 are two, three, or four 333 ; octet UTF-8 characters, as defined in RFC 3629 335 The value of "udomain" SHOULD be verified by applying the tests 336 specified as part of IDNA [RFC3490]. If that verification fails, the 337 email address with that udomain MUST NOT be regarded as a valid email 338 address. 340 2.4. The ALT-ADDRESS Parameter 342 If the UTF8SMTP extension is offered, the syntax of the SMTP MAIL and 343 RCPT commands is extended to support the optional esmtp-keyword "ALT- 344 ADDRESS". That keyword specifies an alternate all-ASCII address 345 which may be used when downgrading. If the ALT-ADDRESS esmtp-keyword 346 is used, it MUST have an associated esmtp-value (ALT-ADDRESS-esmtp- 347 value, which is defined below). 349 While it may be tempting to consider ALT-ADDRESS as a general-purpose 350 second-chance address, such behavior is not defined here. Instead, 351 in this specification ALT-ADDRESS only has meaning when the 352 associated primary address is non-ASCII and the message is 353 downgraded. This restriction allows for future extension of the 354 specification even though no such extensions are currently 355 anticipated. 357 Based on the definition of mail-parameters in [RFC2821], the ALT- 358 ADDRESS parameter usage in the commands of "MAIL" and "RCPT" is 359 defined as follows. The following definitions are given in the same 360 format as used in RFC 2821. 362 "MAIL FROM:" ("<>" / uReverse-path) [ SP Mail-parameters ] CRLF 363 ; Update the MAIL command in RFC 2821, section 4.1.1.2. 364 ; A new parameter defined by the ABNF non-terminal 365 ; is added. It complies 366 ; with the syntax specified for in RFC 2821. 368 "RCPT TO:" ("" / "" / 369 uForward-Path) [ SP Rcpt-parameters ] CRLF 370 ; Update RCPT command in RFC 2821, section 4.1.1.3. 371 ; A new parameter defined by the ABNF non-terminal 372 ; is added. It complies 373 ; with the syntax specified for . 374 ; uDomain is defined in section 2.3 of this document 376 uReverse-path = uPath 377 ; Replace Reverse-path in RFC 2821, section 4.1.2 379 uForward-path = uPath 380 ; Replace Forward-path in RFC 2821, section 4.1.2 382 uPath = "<" [ A-d-l ":" ] uMailbox ">" 383 ; Replace Path in RFC 2821, section 4.1.2 384 ; A-d-l is defined in RFC 2821, section 4.1.2 385 ; uMailbox is defined in section 2.3 of this document 387 ALT-ADDRESS-parameter="ALT-ADDRESS=" ALT-ADDRESS-value 389 ALT-ADDRESS-value=xtext 390 ; The value is a mailbox name encoded as xtext. 391 ; xtext is defined in RFC 3461, section 4.2 393 The ALT-ADDRESS-parameter MUST NOT appear more than once in any MAIL 394 or RCPT command. ALT-ADDRESS-esmtp-value MUST be an all-ASCII email 395 address before xtext encoding. 397 2.5. ALT-ADDRESS Parameter Usage and Response Codes 399 An "internationalized message" as defined in the appendix of this 400 specification MUST NOT be sent to an SMTP server that does not 401 support UTF8SMTP. Such a message MAY be rejected by a server if it 402 lacks ALT-ADDRESSes as discussed in Section 2.2 of this 403 specification. 405 The three-digit reply codes used in this section are consistent with 406 their meanings as defined in RFC 2821. 408 When messages are rejected because the RCPT command requires an ALT- 409 ADDRESS, the response code 553 is used with the meaning "mailbox name 410 not allowed". When messages are rejected for other reasons, such as 411 the MAIL command requiring an ALT-ADDRESS, the response code 550 is 412 used with the meaning "mailbox unavailable". When the server 413 supports enhanced mail system status codes [RFC3463], response code 414 "5.6.x" [SMTP-codes] is used, meaning that "The ALT-ADDRESS is 415 required but not specified". 417 If the response code is issued after the final "." of the DATA 418 command, the response code "554" is used with the meaning 419 "Transaction failed". When the server supports enhanced mail system 420 status codes [RFC3463], response code "5.6.z" [SMTP-codes] is used, 421 meaning that "UTF8SMTP downgrade failed". 423 [[anchor7: RFC Editor: please insert the proper error codes for 424 "5.6.x" and "5.6.z" after IANA has made the relevant assignments.]] 426 2.6. Body Parts and SMTP Extensions 428 There is no ESMTP parameter to assert that a message is an 429 internationalized message. An SMTP server that requires accurate 430 knowledge of whether a message is internationalized is required to 431 parse all message header fields and MIME header fields in the message 432 body. 434 While this specification requires that servers support the 8BITMIME 435 extension [RFC1652] to ensure that servers have adequate handling 436 capability for 8-bit data and to avoid a number of complex encoding 437 problems, the use of internationalized addresses obviously does not 438 require non-ASCII body parts in the MIME message. The UTF8SMTP 439 extension MAY be used with the BODY=8BITMIME parameter if that is 440 appropriate given the body content or, if the server advertises 441 BINARYMIME [RFC3030] and the BODY=BINARYMIME is appropriate, with the 442 BODY=BINARYMIME parameter. 444 Assuming that the server advertises UTF8SMTP and 8BITMIME, and 445 receives at least one non-ASCII address, with or without ALT-ADDRESS, 446 the precise interpretation of "No 'Body' parameter", "BODY=8BITMIME", 447 and "BODY=BINARYMIME" in the MAIL command is: 448 1. If there is no "Body" parameter, the header contains UTF-8 449 characters but all the body parts are in ASCII (possibly as the 450 result of a Content-transfer-encoding). 451 2. If a BODY=8BITMIME parameter is present, the header contains 452 UTF-8 characters and some or all of the body parts contain 8-bit 453 line-oriented data. 454 3. If a BODY=BINARYMIME parameter is present, the header contains 455 UTF-8 characters and some or all body parts contain binary data 456 without restriction as to line lengths or delimiters. 458 2.7. Additional ESMTP Changes and Clarifications 460 The information carried in the mail transport process involves 461 addresses ("mailboxes") and domain names in contexts in addition to 462 the MAIL and RCPT commands and extended alternatives to them. In 463 general, the rule is that, when RFC 2821 specifies a mailbox, this 464 specification expects UTF-8 to be used for the entire string; when 465 RFC 2821 specifies a domain name, the name SHOULD be in the form of 466 ACE labels if its raw form is non-ASCII. 468 The following subsections list and discuss all of the relevant cases. 470 2.7.1. The Initial SMTP Exchange 472 When an SMTP connection is opened, the server normally sends a 473 "greeting" response consisting of the '220' reply code and some 474 information. The client then sends the EHLO command. Since the 475 client cannot know whether the server supports UTF8SMTP until after 476 it receives the response from EHLO, any domain names that appear in 477 this dialogue, or in responses to EHLO, MUST be in the hostname form, 478 i.e., internationalized ones MUST be in the form of ACE labels. 480 2.7.2. Mail eXchangers 482 Organizations often authorize multiple servers to accept mail 483 addressed to them. For example, the organization may itself operate 484 more than one server, and may also or instead have an agreement with 485 other organizations to accept mail as a backup. Authorized servers 486 are generally listed in MX records as described in RFC2821. When 487 more than one server accepts mail for the domain-part of a mailbox, 488 it is strongly advised that either all or none of them support the 489 UTF8SMTP extension. Otherwise, surprising downgrades can happen 490 during temporary failures, which is not a good thing. 492 2.7.3. Trace Information 494 When an SMTP server receives a message for delivery or further 495 processing, it MUST insert trace ("time stamp" or "Received") 496 information at the beginning of the message content. "Time stamp" or 497 "Received" appears in the form of "Received:" lines. The most 498 important use of Received: lines is for debugging mail faults. When 499 the delivery SMTP server makes the "final delivery" of a message, it 500 inserts a return-path line at the beginning of the mail data. The 501 primary purpose of the Return-path is to designate the address to 502 which messages indicating non-delivery or other mail system failures 503 are to be sent. For the trace information, this memo updates the 504 time stamp line and the return path line [RFC2821] formally defined 505 as follows: 507 uReturn-path-line = "Return-Path:" FWS uReverse-path 508 ; Replaces Return-path-line in section 4.4 of RFC2821 509 ; uReverse-path is defined in Section 2.3 of this document 511 uTime-stamp-line = "Received:" FWS uStamp 512 ; Replaces Time-stamp-line in section 4.4 of RFC2821 514 uStamp = From-domain By-domain uOpt-info ";" FWS date-time 515 ; Replaces Stamp in section 4.4 of RFC2821 517 uOpt-info = [Via] [With] [ID] [uFor] 518 ; Replaces Opt-info in section 4.4 of RFC2821 519 ; The protocol value for With will allow a UTF8SMTP value 521 uFor = "FOR" ( FWS (uPath / uMailbox) ) CFWS 522 ; Replaces For in section 4.4 of RFC2821 523 ; uPath and uMailbox are defined in Sections 2.4 and 524 ; 2.3, respectively, of this document 526 [[anchor11: Note: The FOR parameter has been changed to match the 527 definition in RFC2821bis, permitting only one address in the For 528 clause. The group working on that document reached mailing list 529 consensus that the syntax in RFC 2821 that permitted more than one 530 address was simply a mistake.]] 531 Except in the 'uFor' and 'uReverse-path' line where non-ASCII domain 532 names may be used, internationalized domain names in Received fields 533 MUST be transmitted in the form of ACE labels. The protocol value of 534 the WITH clause when this extension is used is one of the UTF8SMTP 535 values specified in the "IANA Considerations" section of this 536 document. 538 2.7.4. UTF-8 Strings in Replies 540 2.7.4.1. MAIL and RCPT Commands 542 If the client issues the RCPT command containing non-ASCII 543 characters, the SMTP server is permitted to use UTF-8 characters in 544 the email address associated with 251 and 551 response codes. 546 If an SMTP client follows this specification and sends any RCPT 547 commands containing non-ASCII addresses, it MUST be able to accept 548 and process 251 or 551 replies containing UTF-8 email addresses. If 549 a given RCPT command does not include a non-ASCII envelope address, 550 the server MUST NOT return a 251 or 551 response containing a non- 551 ASCII mailbox. Instead, it MUST transform such responses into 250 or 552 550 responses that do not contain addresses. 554 2.7.4.2. VRFY and EXPN Commands and the UTF8REPLY Parameter 556 If the VRFY and EXPN commands are transmitted with the optional 557 parameter "UTF8REPLY", it indicates the client can accept UTF-8 558 strings in replies from those commands. This allows the server to 559 use UTF-8 strings in mailbox names and full names which occur in 560 replies without concern that the client might be confused by them. 561 An SMTP client that conforms to this specification MUST accept and 562 correctly process replies from the VRFY and EXPN commands that 563 contain UTF-8 strings. However the SMTP server MUST NOT use UTF-8 564 strings in replies if the SMTP client does not specifically allow 565 such replies by transmitting this parameter. Most replies do not 566 require that a mailbox name be included in the returned text and 567 therefore UTF-8 is not needed in them. Some replies, notably those 568 resulting from successful execution of the VRFY and EXPN commands, do 569 include the mailbox, making the provisions of this section important. 571 VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to: 573 "VRFY" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF 574 ; uLocal-part and uMailbox are defined in 575 : Section 2.3 of this document 577 "EXPN" SP ( uLocal-part / uMailbox ) [ SP "UTF8REPLY" ] CRLF 578 ; uLocal-part and uMailbox are defined in 579 ; Section 2.3 of this document 581 The "UTF8REPLY" parameter does not use a value. If the reply to a 582 VERIFY (VRFY) or EXPAND (EXPN) command requires UTF-8, but the SMTP 583 client does not use the "UTF8REPLY" parameter, then either reply code 584 252 or reply code 550 is used. Response code 252, defined in 585 [RFC2821], means "Cannot VRFY user, but will accept the message and 586 attempt the delivery". Response code 550, also defined in [RFC2821], 587 means "Requested action not taken: mailbox unavailable". When the 588 server supports enhanced mail system status codes [RFC3463], the 589 enhanced response code as specified below is used. Using the 590 "UTF8REPLY" parameter with a VERIFY (VRFY) or EXPAND (EXPN) command 591 enables UTF-8 replies for that command only. 593 If a normal success response (i.e., 250) is returned, the response 594 MAY include the full name of the user and MUST include the mailbox of 595 the user. It MUST be in either of the following forms: 597 User Name 598 ; uMailbox is defined in section 2.3 of this document 599 ; User Name can contain non-ASCII characters. 601 uMailbox 602 ; uMailbox is defined in section 2.3 of this document 604 If the SMTP reply requires UTF-8 strings, but UTF-8 is not allowed in 605 the reply, and the server supports enhanced mail system status codes 606 [RFC3463], the enhanced response code is either "5.6.y" or "2.6.y" 607 [SMTP-codes], meaning "A reply containing a UTF-8 string is required 608 to show the mailbox name, but that form of response is not permitted 609 by the client". 611 If the SMTP Client does not support the UTF8SMTP extension, but 612 receives a UTF-8 string in a reply, it may not be able to properly 613 report the reply to the user, and some clients might crash. 614 Internationalized messages in replies are only allowed in the 615 commands under the situations described above. Under any other 616 circumstances, UTF-8 text MUST NOT appear in the reply. 618 Although UTF-8 is needed to represent email addresses in responses 619 under the rules specified in this section, this extension does not 620 permit the use of UTF-8 for any other purposes. SMTP servers MUST 621 NOT include non-ASCII characters in replies except in the limited 622 cases specifically permitted in this section. 624 [[anchor14: RFC Editor: please insert the proper error codes for 625 "5.6.y" and "2.6.y" after IANA has made the relevant assignments.]] 627 3. IANA Considerations 629 IANA is requested to add "UTF8SMTP" to the SMTP extensions registry 630 with the entry pointing to this specification for its definition. 632 IANA is requested to assign the proper error codes for "5.6.x", 633 "5.6.z", "5.6.y" and "2.6.y", following the guidance in Section 2.5, 634 and based on [SMTP-codes] and enter them in the appropriate registry. 636 The "Mail Transmission Types" registry is requested to be updated to 637 include the following new entries: 639 +---------------+----------------------------+----------------------+ 640 | WITH protocol | Description | Reference | 641 | types | | | 642 +---------------+----------------------------+----------------------+ 643 | UTF8SMTP | UTF8SMTP with Service | [RFCXXXX] | 644 | | Extensions | | 645 | UTF8SMTPA | UTF8SMTP with SMTP AUTH | [RFC4954] [RFCXXXX] | 646 | UTF8SMTPS | UTF8SMTP with STARTTLS | [RFC3207] [RFCXXXX] | 647 | UTF8SMTPSA | UTF8SMTP with both | [RFC3207] [RFC4954] | 648 | | STARTTLS and SMTP AUTH | [RFCXXXX] | 649 +---------------+----------------------------+----------------------+ 651 4. Security Considerations 653 See the extended security considerations discussion in the framework 654 document [EAI-framework]. 656 5. Acknowledgements 658 Much of the text in the initial version of this specification was 659 derived or copied from [Klensin-emailaddr] with the permission of the 660 author. Significant comments and suggestions were received from 661 Xiaodong LEE, Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other 662 members of the JET team and were incorporated into the specification. 663 Additional important comments and suggestions, and often specific 664 text, were contributed by many members of the WG and design team. 665 Those contributions include material from John C Klensin, Charles 666 Lindsey, Dave Crocker, Harald Tveit Alvestrand, Marcos Sanz, Chris 667 Newman, Martin Duerst, Edmon Chung, Tony Finch, Kari Hurtta, Randall 668 Gellens, Frank Ellermann, Alexey Melnikov, Pete Resnick, S. 669 Moonesamy, and Soobok Lee. Of course, none of the individuals are 670 necessarily responsible for the combination of ideas represented 671 here. 673 6. Change History 675 [[anchor18: RFC Editor: Please remove this section.]] 677 6.1. draft-ietf-eai-smtpext: Version 00 679 This version supercedes draft-yao-ima-smtpext-03.txt. It refines the 680 ABNF definition of the internationalized email address. It 681 represents as the EAI working group document. 683 6.2. draft-ietf-eai-smtpext: Version 01 685 o Upgraded to reflect discussions during IETF 66. 686 o Remove the atomic parameter. 687 o Add the new section of "the Suggestion of the value of the ALT- 688 ADDRESS parameter". 690 6.3. draft-ietf-eai-smtpext: Version 02 692 o Upgraded to reflect the recent discussion of the ima@ietf.org 693 mailing list. 694 o Add the section of "Body Parts and SMTP Extensions". 695 o Add the new section of "Change History". 696 o Add the subsection about SMTP extensions for DSN. 698 6.4. draft-ietf-eai-smtpext: Version 03 700 o Update the syntax related to mailbox. 701 o Update the trace field section. 702 o Add the new section about message retry. 703 o Update the subsection about SMTP extensions for DSN. 705 6.5. draft-ietf-eai-smtpext: Version 04 707 o Refine some syntax. 708 o Delete "Message Header Label" section. 709 o Change "bounce" to "reject". 711 6.6. draft-ietf-eai-smtpext: Version 05 713 o Refine the abstract. 714 o Delete "The Suggestion of the Value of the ALT-ADDRESS parameter" 715 section. 716 o Move original section 2.7.4 and 2.7.5 to section 3 with the name 717 "Issues with other parts of the email system". 718 o Add the new section "LMTP". 719 o Refine some text according to suggestions from the EAI mailing 720 list discussion 721 o Remove the section "Mailing List Question" 723 6.7. draft-ietf-eai-smtpext: Version 06 725 o Delete the section about message retry. 726 o Add the new subsection about Mail eXchangers 727 o Add the new section about "UTF-8 Reply" 728 o Refine some response code for the section "Using the ALT-ADDRESS 729 parameter" 731 6.8. draft-ietf-eai-smtpext: Version 07 733 o Rename the section 2.5 734 o Refine sthe section 2.7 736 6.9. draft-ietf-eai-smtpext: Version 08 738 o Refine some texts and update some references 740 6.10. draft-ietf-eai-smtpext: Version 09 742 o Add the appendix 743 o Move section 3.1, 3.2 and section 5 to Appendix 744 o Remove section 3.3 and section 4 745 o Add the new term definitions of conventional message and 746 international message in the appendix 747 o Refine some texts according to suggestions from the EAI mailing 748 list discussion during WG Last call 749 o Use the same reference for ASCII as RFC 2821. 750 o General editorial revision and cleanup, including extensive 751 modifications to the XML to produce a version that has better odds 752 of getting through the various checkers and validators. 754 6.11. draft-ietf-eai-smtpext: Version 10 756 o Refine the text 757 o Add some text about "ALT-ADDRESS" in the section 2.4 758 o Add the appendix A.5 760 7. References 762 7.1. Normative References 764 [ASCII] American National Standards Institute (formerly United 765 States of America Standards Institute), "USA Code for 766 Information Interchange", ANSI X3.4-1968, 1968. 768 [EAI-dsn] Newman, C. and A. Melnikov, "SMTP extensions for DSNs", 769 draft-ietf-eai-dsn-03.txt (work in progress), 770 September 2007. 772 [EAI-framework] 773 Klensin, J. and Y. Ko, "Overview and Framework for 774 Internationalized Email", RFC 4952, July 2007. 776 [EAI-utf8header] 777 Abel, Y., "Transmission of Email Headers in UTF-8 778 Encoding", draft-ietf-eai-utf8headers-07.txt (work in 779 progress), September 2007. 781 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 782 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 783 RFC 1652, July 1994. 785 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 786 Requirement Levels", BCP 14, RFC 2119, March 1997. 788 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 789 April 2001. 791 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 792 April 2001. 794 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 795 Extension for Delivery Status Notifications (DSNs)", 796 RFC 3461, January 2003. 798 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 799 RFC 3463, January 2003. 801 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 802 for Delivery Status Notifications", RFC 3464, 803 January 2003. 805 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 806 "Internationalizing Domain Names in Applications (IDNA)", 807 RFC 3490, March 2003. 809 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 810 10646", RFC 3629, November 2003. 812 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 813 Specifications: ABNF", RFC 4234, October 2005. 815 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 816 RFC 4409, April 2006. 818 [SMTP-codes] 819 Hansen , T. and J. KLensin, "A Registry for SMTP Enhanced 820 Mail System Status Codes", 821 draft-hansen-4468upd-mailesc-registry-02 (work in 822 progress), July 2007. 824 7.2. Informative References 826 [EAI-downgrading] 827 YONEYA, Y., Ed. and K. Fujiwara, Ed., "Downgrading 828 mechanism for Internationalized eMail Address", 829 draft-ietf-eai-downgrade-04 (work in progress), 7 2007. 831 [Klensin-emailaddr] 832 Klensin, J., "Internationalization of Email Addresses", 833 draft-klensin-emailaddr-i18n-03 (work in progress), 834 July 2005. 836 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 837 October 1996. 839 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 840 of Large and Binary MIME Messages", RFC 3030, 841 December 2000. 843 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 844 Transport Layer Security", RFC 3207, February 2002. 846 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 847 for Authentication", RFC 4954, July 2007. 849 Appendix A. Material Updating RFC 4952 851 RFC 4952, the Overview and Framework document covering this set of 852 extensions for internationalized email [EAI-framework], was completed 853 before this specification, which specifies a particular part of the 854 protocol set. This appendix, which is normative, contains material 855 that would have been incorporated into RFC 4952 had it been delayed 856 until the work described in the rest of this specification was 857 completed and that should be included in any update to RFC 4952. 859 A.1. Conventional Message and Internationalized Message 861 o A conventional message is one that does not use any extension 862 defined in this document or in the UTF8header specification 863 [EAI-utf8header], and strictly conformant to RFC 2822 [RFC2822]. 864 o An internationalized message is a message utilizing one or more of 865 the extensions defined in this specification or in the UTF8header 866 specification [EAI-utf8header], so that it is no longer conformant 867 to the RFC 2822 specification of a message. 869 A.2. LMTP 871 LMTP [RFC2033] may be used as the final delivery agent. In such 872 cases, LMTP may be arranged to deliver the mail to the mail store. 873 The mail store may not have UTF8SMTP capability. LMTP need to be 874 updated to deal with these situations. 876 A.3. SMTP Service Extension for DSNs 878 The existing draft standard Delivery status notifications 879 (DSNs)[RFC3461] is limited to ASCII text in the machine readable 880 portions of the protocol. "International Delivery and Disposition 881 Notifications" [EAI-dsn] adds a new address type for international 882 email addresses so an original recipient address with non-ASCII 883 characters can be correctly preserved even after downgrading. If an 884 SMTP server advertises both the UTF8SMTP and the DSN extension, that 885 server MUST implement EAI-dsn [EAI-dsn] including support for the 886 ORCPT parameter. 888 A.4. Implementation Advice 890 In the absence of this extension, SMTP clients and servers are 891 constrained to using only those addresses permitted by RFC 2821. The 892 local parts of those addresses MAY be made up of any ASCII 893 characters, although some of them MUST be quoted as specified there. 894 It is notable in an internationalization context that there is a long 895 history on some systems of using overstruck ASCII characters (a 896 character, a backspace, and another character) within a quoted string 897 to approximate non-ASCII characters. This form of 898 internationalization SHOULD be phased out as this extension becomes 899 widely deployed but backward-compatibility considerations require 900 that it continue to be supported. 902 A.5. Applicability of SMTP Extension to Additional Uses 904 Among other protocol changes, the SMTP extension allows an optional 905 alternate address to be supplied with the MAIL and RCPT commands. 906 For the purposes of this set of specifications, this alternate 907 address only has meaning when the primary address contains UTF-8 908 characters and the message is downgraded. While it may be tempting 909 to consider the alternate address as a general-purpose second-chance 910 address, to be used whenever the primary address is rejected, such 911 behavior is not defined here. This restriction allows for future 912 extensions to be developed which create such a general-purpose 913 second-chance address, although no specific work on such an extension 914 is currently anticipated. Note that any such extension needs to 915 consider the question of what the RFC 974 sequencing rules mean when 916 different possible servers support different sets of ESMTP options 917 (or, in this case, addresses). The answer to this question may also 918 imply updates to [RFC2821]. 920 Authors' Addresses 922 Jiankang YAO (editor) 923 CNNIC 924 No.4 South 4th Street, Zhongguancun 925 Beijing 927 Phone: +86 10 58813007 928 Email: yaojk@cnnic.cn 930 Wei MAO (editor) 931 CNNIC 932 No.4 South 4th Street, Zhongguancun 933 Beijing 935 Phone: +86 10 58813055 936 Email: maowei_ietf@cnnic.cn 938 Full Copyright Statement 940 Copyright (C) The IETF Trust (2008). 942 This document is subject to the rights, licenses and restrictions 943 contained in BCP 78, and except as set forth therein, the authors 944 retain all their rights. 946 This document and the information contained herein are provided on an 947 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 948 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 949 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 950 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 951 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 952 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 954 Intellectual Property 956 The IETF takes no position regarding the validity or scope of any 957 Intellectual Property Rights or other rights that might be claimed to 958 pertain to the implementation or use of the technology described in 959 this document or the extent to which any license under such rights 960 might or might not be available; nor does it represent that it has 961 made any independent effort to identify any such rights. Information 962 on the procedures with respect to rights in RFC documents can be 963 found in BCP 78 and BCP 79. 965 Copies of IPR disclosures made to the IETF Secretariat and any 966 assurances of licenses to be made available, or the result of an 967 attempt made to obtain a general license or permission for the use of 968 such proprietary rights by implementers or users of this 969 specification can be obtained from the IETF on-line IPR repository at 970 http://www.ietf.org/ipr. 972 The IETF invites any interested party to bring to its attention any 973 copyrights, patents or patent applications, or other proprietary 974 rights that may cover technology that may be required to implement 975 this standard. Please address the information to the IETF at 976 ietf-ipr@ietf.org. 978 Acknowledgment 980 Funding for the RFC Editor function is provided by the IETF 981 Administrative Support Activity (IASA).