idnits 2.17.1 draft-ietf-eai-smtpext-08.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 883. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 894. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 901. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 907. 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 : ---------------------------------------------------------------------------- No issues found here. 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: An SMTP Client that receives the UTF8SMTP extension keyword in response to the "EHLO" command MAY transmit a mailbox name as an internationalized string in UTF-8 form and MAY send an UTF-8 header [EAI-utf8header]. It MAY transmit the domain part of that string in either the form of ACE labels specified in [RFC3490] or UTF-8 form. In the domain part of the mailbox string, if any of the labels are intended to be interpreted as non-ASCII (i.e., are IDNs), then the Message Submission Server ("MSA") [RFC4409] MUST take responsibility for ensuring that the labels are valid (whether they appear in native character or ACE form). The presence of the UTF8SMTP extension does not change the requirement of RFC 2821 that servers relaying mail MUST not attempt to parse, evaluate, or transform the local part in any way. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If an SMTP client follows this specification and sends any RCPT commands containing non-ASCII addresses, it MUST be able to accept and process 251 or 551 replies containing UTF-8 email addresses. If a given RCPT command does not include non-ASCII envelope addresses, the server MUST not return a 251 or 551 response containing a non-ASCII mailbox. Instead, it MUST transform such responses into 250 or 550 responses that do not contain addresses. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the VRFY and EXPN commands have the optional parameter "UTF8REPLY", it indicates the client can accept UTF-8 on replies of the VRFY and EXPN commands. Specially this allows to use UTF-8 on mailboxes and full names which occur on replies. The SMTP client following this specification MUST accept UTF-8 on replies of the VRFY and EXPN commands. However the SMTP server MUST not use UTF-8 on replies, if the SMTP client does not ask UTF-8 replies. Some replies include the mailbox, but usually most of replies do not require that the mailbox is included in it and therefore UTF-8 is not needed. The UTF8REPLY parameter on the VRFY and EXPN commands tells the SMTP server that the client is prepared for UTF-8 on SMTP replies. -- 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 (September 3, 2007) is 6074 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFCxxxx' is mentioned on line 645, but not defined == Unused Reference: 'ASCII' is defined on line 747, but no explicit reference was found in the text ** 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 1869 (Obsoleted by RFC 2821) ** 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) == Outdated reference: A later version (-12) exists of draft-ietf-eai-downgrade-04 == Outdated reference: A later version (-06) exists of draft-ietf-eai-dsn-03 == Outdated reference: A later version (-09) exists of draft-ietf-eai-imap-utf8-01 == Outdated reference: A later version (-09) exists of draft-ietf-eai-pop-01 -- Obsolete informational reference (is this intentional?): RFC 4409 (Obsoleted by RFC 6409) Summary: 8 errors (**), 0 flaws (~~), 12 warnings (==), 8 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 Intended status: Experimental CNNIC 5 Expires: March 6, 2008 September 3, 2007 7 SMTP extension for internationalized email address 8 draft-ietf-eai-smtpext-08.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on March 6, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document specifies the use of SMTP extension for 42 internationalized email address delivery. Communication with systems 43 that do not implement this specification is specified in another 44 document. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1. Role of this specification . . . . . . . . . . . . . . . . 3 50 1.2. Proposal Context . . . . . . . . . . . . . . . . . . . . . 3 51 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Mail Transport-level Protocol . . . . . . . . . . . . . . . . 4 53 2.1. Framework for the Internationalization Extension . . . . . 4 54 2.2. The UTF8SMTP Extension . . . . . . . . . . . . . . . . . . 5 55 2.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 6 56 2.4. The ALT-ADDRESS parameter . . . . . . . . . . . . . . . . 8 57 2.5. ALT-ADDRESS parameter usage and response codes . . . . . . 9 58 2.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 9 59 2.7. Additional ESMTP Changes and Clarifications . . . . . . . 10 60 2.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 10 61 2.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 10 62 2.7.3. Trace Information . . . . . . . . . . . . . . . . . . 10 63 2.7.4. UTF-8 Reply . . . . . . . . . . . . . . . . . . . . . 11 64 3. Issues with Other Parts of the Email System . . . . . . . . . 13 65 3.1. LMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 3.2. SMTP Service Extension for DSNs . . . . . . . . . . . . . 13 67 3.3. POP and IMAP . . . . . . . . . . . . . . . . . . . . . . . 13 68 4. Potential problems . . . . . . . . . . . . . . . . . . . . . . 14 69 4.1. Impact many email related RFC . . . . . . . . . . . . . . 14 70 5. Implementation Advice . . . . . . . . . . . . . . . . . . . . 14 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 7. Security considerations . . . . . . . . . . . . . . . . . . . 15 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 74 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 15 75 9.1. draft-ietf-eai-smtpext: Version 00 . . . . . . . . . . . . 15 76 9.2. draft-ietf-eai-smtpext: Version 01 . . . . . . . . . . . . 15 77 9.3. draft-ietf-eai-smtpext: Version 02 . . . . . . . . . . . . 16 78 9.4. draft-ietf-eai-smtpext: Version 03 . . . . . . . . . . . . 16 79 9.5. draft-ietf-eai-smtpext: Version 04 . . . . . . . . . . . . 16 80 9.6. draft-ietf-eai-smtpext: Version 05 . . . . . . . . . . . . 16 81 9.7. draft-ietf-eai-smtpext: Version 06 . . . . . . . . . . . . 16 82 9.8. draft-ietf-eai-smtpext: Version 07 . . . . . . . . . . . . 16 83 9.9. draft-ietf-eai-smtpext: Version 08 . . . . . . . . . . . . 17 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 86 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 88 Intellectual Property and Copyright Statements . . . . . . . . . . 20 90 1. Introduction 92 Internationalized email address includes two parts, the local part 93 and the domain part. The ways email addresses are used by protocols 94 are different from the ways domain names are used. The most critical 95 difference is that emails are delivered through a chain of peering 96 clients and servers while domain names are resolved by name servers 97 by looking up their own tables. In addition to this, email transport 98 protocol ESMTP[RFC1869] provides a negotiation mechanism through 99 which clients can make decisions for further processing; please see 100 more in [EAI-framework]. Email addresses can exploit the SMTP 101 extension negotiation mechanism while Internationalized Domain 102 Name(IDN) does not have such a facility. This is also more 103 architecturally desirable approach. This document specifies an SMTP 104 extension to permit internationalized email addresses in envelopes, 105 and UTF-8 in headers. The protocol described here is an MTA solution 106 which is feasible, architecturally elegant, and not difficult to 107 deploy. 109 1.1. Role of this specification 111 The framework document [EAI-framework] specifies the requirements 112 for, and components of, full internationalization of electronic mail. 113 To understand and implement this specification, understanding the 114 context presented in [EAI-framework] is necessary. 116 This document specifies an element of that work, specifically the 117 definition of an SMTP extension [RFC1869] for the internationalized 118 email address transport delivery. 120 1.2. Proposal Context 122 This specification describes a change to the email transport 123 mechanism that permits non-ASCII characters in both the envelope and 124 header fields of messages while the specification in [EAI-utf8header] 125 specifies the details of how and where non-ASCII characters are 126 permitted in the header fields of messages. The context for the 127 change is described in [EAI-framework]. 129 1.3. Terminology 131 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 132 and "MAY" in this document are to be interpreted as described in RFC 133 2119 [RFC2119]. 135 All specialized terms used in this specification are defined in the 136 EAI framework [EAI-framework] or in [RFC2821] and [RFC2822]. The 137 terms "ASCII address", "internationalized email address", "non-ASCII 138 address", "i18mail address", "UTF8SMTP", "message" and "mailing list" 139 are used with the definitions from the [EAI-framework] document. 141 This document defines only those ABNF [RFC4234] syntax rules that are 142 different from those of the base email specifications 143 [RFC2821][RFC2822] and, where the earlier rules are upgraded or 144 extended, gives them new names. When the new rule is a small upgrade 145 to the older one, it is typically given a name starting with "u". 146 Rules that are undefined here may be found in the base email 147 documents under the same names. 149 [[anchor4: RFC EDITOR'S NOTE: The following text should be deleted 150 before publication.]] This document is being discussed on the EAI 151 mailing list. See https://www1.ietf.org/mailman/listinfo/ima for 152 information about subscribing. The list's archive is at 153 http://www1.ietf.org/mail-archive/web/ima/index.html. 155 2. Mail Transport-level Protocol 157 2.1. Framework for the Internationalization Extension 159 The following service extension is defined: 161 1. The name of the SMTP service extension is "Email Address 162 Internationalization"; 163 2. The EHLO keyword value associated with this extension is 164 "UTF8SMTP"; 165 3. No parameter values are defined for this EHLO keyword value. In 166 order to permit future (although unanticipated) extensions, the 167 EHLO response MUST NOT contain any parameters for that keyword. 168 Clients MUST ignore any parameters, that is, clients MUST behave 169 as if the parameters do not appear. If a server includes 170 UTF8SMTP in its EHLO response, it MUST be fully compliant with 171 this version of this specification. 172 4. One optional parameter, ALT-ADDRESS, is added to the SMTP MAIL 173 and RCPT commands. ALT-ADDRESS specifies an all-ASCII address 174 which can be used as a substitute for the i18mail addresses that 175 we call the primary address; you can learn more in 176 [EAI-framework] or [EAI-downgrading]. 177 5. One optional parameter "UTF8REPLY" is added to the VRFY and EXPN 178 commands. The parameter UTF8REPLY has no value. The parameter 179 indicates the SMTP client can accept UTF-8 on replies of the 180 VRFY and EXPN commands. 181 6. No additional SMTP verbs are defined by this extension. 182 7. Servers offering this extension MUST provide support for, and 183 announce, the 8BITMIME extension [RFC1652]. 185 8. The reverse-path and forward-path of SMTP MAIL and RCPT commands 186 are extended to allow UTF-8 characters in the specified mailbox 187 address. 188 9. The mail datum is extended in compliance with [EAI-utf8header] 189 10. The maximum length of a MAIL and RCPT command lines is increased 190 by 460 characters by the possible addition of the ALT-ADDRESS 191 keyword and value. 193 2.2. The UTF8SMTP Extension 195 An SMTP Server that announces this extension MUST be prepared to 196 accept a UTF-8 string [RFC3629] in any position in which RFC 2821 197 specifies that a "mailbox" MAY appear. That string MUST be parsed 198 only as specified in RFC 2821, i.e., by separating the mailbox into 199 source route, local part and domain part, using only the characters 200 colon (U+003A), comma (U+002C), and at-sign (U+0040) as specified 201 there. Once isolated by this parsing process, the local part MUST be 202 treated as opaque unless the SMTP Server is the final delivery MTA. 203 Any domain names that are to be looked up in the DNS MUST first be 204 processed into the form specified in IDNA [RFC3490] by means of the 205 ToASCII() operation unless they are already in that form. Any domain 206 names that are to be compared to local strings SHOULD be checked for 207 validity and then MUST be compared as specified in section 3.4 of 208 IDNA. 210 The UTF8SMTP extension is valid on the submission port [RFC4409]. 212 An SMTP Client that receives the UTF8SMTP extension keyword in 213 response to the "EHLO" command MAY transmit a mailbox name as an 214 internationalized string in UTF-8 form and MAY send an UTF-8 header 215 [EAI-utf8header]. It MAY transmit the domain part of that string in 216 either the form of ACE labels specified in [RFC3490] or UTF-8 form. 217 In the domain part of the mailbox string, if any of the labels are 218 intended to be interpreted as non-ASCII (i.e., are IDNs), then the 219 Message Submission Server ("MSA") [RFC4409] MUST take responsibility 220 for ensuring that the labels are valid (whether they appear in native 221 character or ACE form). The presence of the UTF8SMTP extension does 222 not change the requirement of RFC 2821 that servers relaying mail 223 MUST not attempt to parse, evaluate, or transform the local part in 224 any way. 226 If the UTF8SMTP SMTP extension is not offered by the Server, the SMTP 227 client MUST NOT transmit an internationalized address and MUST NOT 228 transmit a mail message which contains internationalized mail headers 229 [EAI-utf8header] at any level within its MIME structure. Instead, if 230 an SMTP client (SMTP sender) attempts to transfer a UTF8SMTP message 231 and encounters a server that does not support the extension, it MUST 232 make one of the following four choices: 234 1. If and only if the SMTP client (sender) is a Message Submission 235 Server[RFC4409], it MAY, consistent with the general provisions 236 for changes by such servers, rewrite the envelope, headers, or 237 message material to make them entirely ASCII and consistent with 238 the provisions of RFC 2821 [RFC2821] and RFC 2822 [RFC2822]. 239 2. Reject the message during the SMTP transaction or generate a 240 notification of non-deliverability, as specified in RFC 2821 241 [RFC2821] and RFC 3464 [RFC3464]. If the message content can be 242 returned without alteration, content should be returned as 243 specified in 2821 but, if a server is encountered along the 244 return path that cannot accept UTF8SMTP traffic, the content 245 should simply be abridged or dropped. 246 3. Find an alternate route to the destination that permits UTF8SMTP. 247 That route may be discovered by trying alternate MX hosts (using 248 preference rules as specified in RFC 2821) or using other means 249 available to the SMTP-sender. 250 4. If and only if ASCII addresses are available for all addresses 251 that appear in the return path and the specific forward paths 252 being attempted, downgrade the message to an all-ASCII form as 253 specified in [EAI-downgrading]. An ASCII address is considered 254 to be "available" for a particular address if the original 255 address in the envelope is in ASCII or if an ALT-Address 256 parameter is specified for a UTF8SMTP address. 258 2.3. Extended Mailbox Address Syntax 260 RFC 2821, section 4.1.2, defines the syntax of a mailbox entirely in 261 terms of ASCII characters, using the production for "Mailbox" and 262 those on which it depends. 264 The key changes made by this specification are, informally, to 266 o Change the definition of "sub-domain" to permit either the 267 definition above or a UTF-8 string representing a DNS label that 268 is conformant with IDNA [RFC3490]. 269 o Change the definition of "Atom" to permit either the definition 270 above or a UTF-8 string. That string MUST NOT contain any of the 271 ASCII characters (either graphics or controls) that are not 272 permitted in "atext"; it is otherwise unrestricted. 274 According to the description above, define the syntax of an 275 internationalized email mailbox with ABNF [RFC4234] as 276 uMailbox = uLocal-part "@" uDomain 277 ; Replace Mailbox in RFC 2821, section 4.1.2 279 uLocal-part = uDot-string / uQuoted-string 280 ; MAY be case-sensitive 281 ; Replace Local-part in RFC 2821, section 4.1.2 283 uDot-string = uAtom *("." uAtom) 284 ; Replace Dot-string in RFC 2821, section 4.1.2 286 uAtom = 1*ucharacter 287 ; Replace Atom in RFC 2821, section 4.1.2 289 ucharacter = atext / UTF8-xtra-char 290 ; Replace character in RFC 2821, section 4.1.2 291 ; atext is defined in RFC 2822 293 uQuoted-string = DQUOTE *uqcontent DQUOTE 294 ; Replace Quoted-string in RFC 2821, section 4.1.2 295 ; DQUOTE is Double Quote defined in RFC 4234 297 uqcontent = qcontent / UTF8-xtra-char 298 ; qcontent is defined in RFC 2822, section 3.2.5 300 uDomain = (sub-udomain 1*("." sub-udomain)) / address-literal 301 ; Replace Domain in RFC 2821, section 4.1.2 302 ; address-literal is defined in RFC2821 section 4.1.2 304 sub-udomain = uLet-dig [uLdh-str] 305 ; Replace sub-domain in RFC 2821, section 4.1.2 307 uLet-dig = Let-dig / UTF8-xtra-char 308 ; Let-dig is defined in RFC 2821, section 4.1.3 310 uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-xtra-char) uLet-dig 311 ; Replace Ldh-str in RFC 2821, section 4.1.3 313 UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 314 ; UTF8-2, UTF8-3 and UTF8-4 are defined in RFC 3629 316 The value of "udomain" SHOULD be verified with IDNA [RFC3490]; If 317 failed, the email address with that udomain can not be regarded as 318 the valid email address. 320 2.4. The ALT-ADDRESS parameter 322 If the UTF8SMTP extension is offered, the syntax of the SMTP MAIL and 323 RCPT commands is extended to support the optional esmtp-keyword "ALT- 324 ADDRESS", which specifies an alternate all-ASCII address which may be 325 used when downgrading. If the ALT-ADDRESS esmtp-keyword is used, it 326 MUST have an associated esmtp-value (ALT-ADDRESS-esmtp-value which is 327 defined below). 329 Based on the definition of mail-parameters in [RFC2821], the ALT- 330 ADDRESS parameter usage in the commands of "MAIL" and "RCPT" is 331 defined below. 333 "MAIL FROM:" ("<>" / uReverse-path) [ SP Mail-parameters ] CRLF 334 ; Update mail command in RFC 2821, section 4.1.1.2. 335 ; A new parameter defined by the ABNF non-terminal 336 ; is added. It complies 337 ; with the syntax specified by . 339 "RCPT TO:" ("" / "" / 340 uForward-Path) [ SP Rcpt-parameters ] CRLF 341 ; Update rcpt command in RFC 2821, section 4.1.1.3. 342 ; A new parameter defined by the ABNF non-terminal 343 ; is added. It complies 344 ; with the syntax specified by . 346 uReverse-path = uPath 347 ; Replace Reverse-path in RFC 2821, section 4.1.2 349 uForward-path = uPath 350 ; Replace Forward-path in RFC 2821, section 4.1.2 352 uPath = "<" [ A-d-l ":" ] uMailbox ">" 353 ; Replace Path in RFC 2821, section 4.1.2 354 ; A-d-l is defined in RFC 2821, section 4.1.2 355 ; uMailbox is defined in section 2.3 of this document 357 ALT-ADDRESS-parameter="ALT-ADDRESS=" ALT-ADDRESS-esmtp-value 359 ALT-ADDRESS-esmtp-value=xtext 360 ; Mailbox encoded as xtext. 361 ; xtext is defined in RFC 3461 [RFC3461], section 4.2 363 The ALT-ADDRESS-parameter MUST NOT appear more than once in any MAIL 364 or RCPT command. ALT-ADDRESS-esmtp-value MUST be an all-ASCII email 365 address before xtext encoding. 367 2.5. ALT-ADDRESS parameter usage and response codes 369 [EAI-utf8header] specifies "UTF8SMTP message" which requires UTF8SMTP 370 support. Such a message MUST NOT be sent to an SMTP server which 371 does not support UTF8SMTP. Such a message MAY be rejected due to 372 lack of the ALT-ADDRESS as discussed in section 2.2 of this document. 374 When messages are rejected because they require UTF8SMTP, the 375 response code "550" is used, defined in [RFC2821], meaning "mailbox 376 unavailable". If enhanced mail system status codes [RFC3463] are 377 used, the response code should be "5.6.x" [SMTP-codes], meaning that 378 "The alt-address is required but not specified". 380 If the response code is issued after the final "." of the DATA 381 command, the response code "554" is used, defined in [RFC2821], 382 meaning "Transaction failed". If enhanced mail system status codes 383 [RFC3463] are used, the response code should be "5.6.z" [SMTP-codes], 384 meaning that "UTF8SMTP downgrade failed". 386 [[anchor8: REMOVE THIS: IANA please assign the proper error codes for 387 "5.6.x" and "5.6.z".]] 389 2.6. Body Parts and SMTP Extensions 391 Since there is no ESMTP parameter which tells whether the message is 392 UTF8SMTP message, SMTP server needs to parse all message header 393 fields and MIME header fields in the message body to discover which 394 messages are UTF8SMTP. While this specification requires that 395 servers support the 8BITMIME extension [RFC1652] to ensure that 396 servers have adequate handling capability for 8-bit data and to avoid 397 a number of complex encoding problems, the use of internationalized 398 addresses obviously does not require non-ASCII body parts in the MIME 399 message. The UTF8SMTP extension MAY be used with the BODY=8BITMIME 400 parameter if that is appropriate given the body content or, if the 401 server advertises it and it is appropriate, with the BODY=BINARYMIME 402 parameter specified in [RFC3030]. 404 Assuming that the server advertises UTF8SMTP and 8BITMIME, and at 405 least one non-ASCII address, with or without ALT-ADDRESS, the precise 406 interpretation of "No 'Body' parameter", "BODY= 8BITMIME", and "BODY= 407 BINARYMIME" in the MAIL command is: 408 1. For No "Body" parameter, headers are in UTF-8, body parts are in 409 ASCII. 410 2. For BODY=8BITMIME parameter, headers are in UTF-8, some or all 411 body parts contain 8-bit line-oriented data. 413 3. For BODY=BINARYMIME parameter, headers are in UTF-8, some or all 414 body parts contain binary data without restriction as to line 415 lengths or delimiters. 417 2.7. Additional ESMTP Changes and Clarifications 419 The mail transport process involves addresses ("mailboxes") and 420 domain names in contexts in addition to the MAIL and RCPT commands 421 and extended alternatives to them. In general, the rule is that, 422 when RFC 2821 specifies a mailbox, this document expects UTF-8 to be 423 used for the entire string; when RFC 2821 specifies a domain name, 424 the name SHOULD be in the form of ACE labels if its raw form is non- 425 ASCII. 427 The following subsections list and discuss all of the relevant cases. 429 Support and use of this extension requires support for 8BITMIME. It 430 means that 8BITMIME MUST be advertised by the UTF8SMTP capable SMTP 431 server. 433 2.7.1. The Initial SMTP Exchange 435 When an SMTP or ESMTP connection is opened, the server normally sends 436 a "greeting" response consisting of the '220' reply code and some 437 information. The client then sends the EHLO command. Since the 438 client cannot know whether the server supports UTF8SMTP until after 439 it receives the response from EHLO, any domain names that appear in 440 this dialogue, or in responses to EHLO, MUST be in the hostname form, 441 i.e., internationalized ones MUST be in the form of ACE labels. 443 2.7.2. Mail eXchangers 445 Commonly, organizations authorize multiple servers to accept mail 446 addressed to them. For example, the organization may itself operate 447 more than one server, and may also or instead have an agreement with 448 other organizations to accept mail as a backup. Authorized servers 449 are generally listed in MX records [RFC2821]. When more than one 450 server accepts mail for the domain-part of a Mailbox, it is strongly 451 advised that either all or none of them support the UTF8SMTP 452 extension. Otherwise, surprising downgrades can happen during 453 temporary failures, which is not a good thing. 455 2.7.3. Trace Information 457 When an SMTP server receives a message for delivery or further 458 processing, it MUST insert trace ("time stamp" or "Received") 459 information at the beginning of the message content. Time stamp 460 appears in the form of "Received: lines". The most important use of 461 Received: lines is for debugging mail faults. When the delivery SMTP 462 server makes the "final delivery" of a message, it inserts a return- 463 path line at the beginning of the mail data. The primary purpose of 464 the Return-path is to designate the address to which messages 465 indicating non-delivery or other mail system failures are to be sent. 466 For the trace information, we update the time stamp line and the 467 return path line [RFC2821] formally defined as follows: 469 uReturn-path-line = "Return-Path:" FWS uReverse-path 470 ; Replaces Return-path-line in the section 4.4 of [RFC2821] 471 ; uReverse-path is defined in Section 2.3 473 uTime-stamp-line = "Received:" FWS uStamp 474 ; Replaces Time-stamp-line in the section 4.4 of [RFC2821] 476 uStamp = From-domain By-domain uOpt-info ";" FWS date-time 477 ; Replaces Stamp in the section 4.4 of [RFC2821] 479 uOpt-info = [Via] [With] [ID] [uFor] 480 ; Replaces Opt-info in the section 4.4 of [RFC2821] 481 ; [With]'s protocol value will allow UTF8SMTP value 483 uFor = "FOR" 1*( FWS (uPath / uMailbox) ) CFWS 484 ; Replaces For in the section 4.4 of [RFC2821] 485 ; uPath is defined in section 2.4 of this document 486 ; uMailbox is defined in section 2.3 of this document 488 [[anchor12: Note: Whether the FOR parameter is permitted to accept 489 more than one address is now under discussion as part of the 490 rfc2821bis effort. The multiple-address construction was introduced 491 with RFC 2821; it is not clear that it has been widely implemented or 492 that it is wise. Whatever decision is reached about RFC2821bis will 493 be reflected in the syntax of a future version of this document.]] 494 Except in the 'uFor' and 'uReverse-path' line where non-ASCII domain 495 name may be used, internationalized domain names in Received fields 496 MUST be transmitted in the form of ACE labels. The protocol value of 497 the WITH clause is UTF8SMTP when this extension is used. More 498 information is in the "IANA Considerations" section of this document. 500 2.7.4. UTF-8 Reply 502 If the client issues the RCPT command which contains non-ASCII 503 characters, the SMTP server is permitted to use UTF-8 characters in 504 the email address within 251 and 551 response codes. 506 If an SMTP client follows this specification and sends any RCPT 507 commands containing non-ASCII addresses, it MUST be able to accept 508 and process 251 or 551 replies containing UTF-8 email addresses. If 509 a given RCPT command does not include non-ASCII envelope addresses, 510 the server MUST not return a 251 or 551 response containing a non- 511 ASCII mailbox. Instead, it MUST transform such responses into 250 or 512 550 responses that do not contain addresses. 514 If the VRFY and EXPN commands have the optional parameter 515 "UTF8REPLY", it indicates the client can accept UTF-8 on replies of 516 the VRFY and EXPN commands. Specially this allows to use UTF-8 on 517 mailboxes and full names which occur on replies. The SMTP client 518 following this specification MUST accept UTF-8 on replies of the VRFY 519 and EXPN commands. However the SMTP server MUST not use UTF-8 on 520 replies, if the SMTP client does not ask UTF-8 replies. Some replies 521 include the mailbox, but usually most of replies do not require that 522 the mailbox is included in it and therefore UTF-8 is not needed. The 523 UTF8REPLY parameter on the VRFY and EXPN commands tells the SMTP 524 server that the client is prepared for UTF-8 on SMTP replies. 526 VERIFY (VRFY) and EXPAND (EXPN)command syntaxes are changed to: 528 "VRFY" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF; 529 ;uLocal-part is defined in section 2.3 of this document 530 ;uMailbox is defined in section 2.3 of this document 532 "EXPN" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF; 533 ;uLocal-part is defined in section 2.3 of this document 534 ;uMailbox is defined in section 2.3 of this document 536 This parameter "UTF8REPLY" does not have value. If SMTP reply 537 requires UTF-8, but SMTP client does not use "UTF8REPLY" parameter in 538 the VERIFY (VRFY) and EXPAND (EXPN) commands, the response code 252 539 is used, defined in [RFC2821], meaning "Cannot VRFY user, but will 540 accept the message and attempt the delivery". Also response code 550 541 may be used, meaning "Requested action not taken: mailbox 542 unavailable". If enhanced mail system status code [RFC3463] is used, 543 response codes given on below is used. "UTF8REPLY" on the VERIFY 544 (VRFY) or EXPAND (EXPN) commands enables UTF-8 for that command only. 546 If a normal (i.e., 250) response is returned, the response MAY 547 include the full name of the user and MUST include the mailbox of the 548 user. It MUST be in either of the following forms: 550 User Name 551 ; uMailbox is defined in section 2.3 of this document 552 ; User Name allows the non-ASCII character. 554 uMailbox 555 ; uMailbox is defined in section 2.3 of this document 557 If the SMTP reply requires UTF-8, but UTF-8 is not allowed on reply, 558 and enhanced mail system status code [RFC3463] is used, the response 559 code should be "5.6.y" or "2.6.y" [SMTP-codes], meaning that "The 560 UTF-8 reply required, but not allowed.". [[anchor13: REMOVE THIS: 561 IANA please assign the proper error codes for "5.6.y" and "2.6.y".]] 563 If the SMTP Client lack of the UTF8SMTP support receives the UTF-8 564 message on reply, it may crash. UTF-8 messages on reply are only 565 allowed in the commands under the situations described above. Under 566 any other circumstances, UTF-8 messages on the reply MUST NOT be 567 used. 569 Although UTF-8 is needed to represent email addresses in responses 570 under the rules specified in this section, this extension does not 571 permit the use of UTF-8 for any other purposes. SMTP servers MUST 572 NOT include non-ASCII characters except in the limited cases 573 specifically permitted in this section. 575 3. Issues with Other Parts of the Email System 577 3.1. LMTP 579 LMTP [RFC2033] may be used as the final delivery agent. In such 580 cases, LMTP may be arranged to deliver the mail to the mail store. 581 The mail store may not have UTF8SMTP capability. LMTP need to be 582 updated to deal with these situations. 584 3.2. SMTP Service Extension for DSNs 586 The existing draft standard Delivery status notifications 587 (DSNs)[RFC3461] is presently limited to US-ASCII text in the machine 588 readable portions of the protocol. "International Delivery and 589 Disposition Notifications" [EAI-dsn] adds a new address type for 590 international email addresses so an original recipient address with 591 non-US-ASCII characters can be correctly preserved even after 592 downgrading. If an SMTP server advertises both the UTF8SMTP and the 593 DSN extension, that server MUST implement EAI-dsn [EAI-dsn] including 594 support for the ORCPT parameter. 596 3.3. POP and IMAP 598 The [EAI-framework] has introduced two documents [EAI-pop] and 599 [EAI-imap] to how to use internationalized user names based on UTF-8 600 characters for the retrieval of messages from a mail server. 602 4. Potential problems 604 4.1. Impact many email related RFC 606 Internationalized email has implications for all processes and 607 protocols which examine, handle, generate, or otherwise deal with 608 mail. In particular, address parsing or validity checks, message 609 parsing or handling, etc. 611 5. Implementation Advice 613 In the absence of this extension, SMTP clients and servers are 614 constrained to using only those addresses permitted by RFC 2821. The 615 local parts of those addresses MAY be made up of any ASCII 616 characters, although some of them MUST be quoted as specified there. 617 It is notable in an internationalization context that there is a long 618 history on some systems of using overstruck ASCII characters (a 619 character, a backspace, and another character) within a quoted string 620 to approximate non-ASCII characters. This form of 621 internationalization SHOULD be phased out as this extension becomes 622 widely deployed but backward-compatibility considerations require 623 that it continue to be supported. 625 6. IANA Considerations 627 IANA is requested to add "UTF8SMTP" to the SMTP extensions registry 628 with the entry pointing to this specification for its definition. 630 IANA is requested to assign the proper error codes "5.6.x", "5.6.z", 631 "5.6.y" and "2.6.y" for this specification based on [SMTP-codes]. 633 The "Mail Transmission Types" registry is requested to be updated to 634 include the following new entries: 636 WITH protocol types Description Reference 637 ------------------- ---------------------------- --------- 638 UTF8SMTP UTF8SMTP with Service Extensions [RFCxxxx] 639 UTF8SMTPA UTF8SMTP with SMTP AUTH [RFC2554bis] 640 [RFCxxxx] 641 UTF8SMTPS UTF8SMTP with STARTTLS [RFC3207] 642 [RFCxxxx] 643 UTF8SMTPSA UTF8SMTP with both STARTTLS and [RFC3207] 644 SMTP AUTH [RFC2554bis] 645 [RFCxxxx] 647 [[anchor22: REMOVE THIS: where RFCxxxx represents the future RFC N0. 648 of this document. When this document is published as RFC and 649 assigned with a RFC No., "xxxx" should be replaced with 4-digits No.. 650 "RFC2554bis" should be replaced with the new RFC No. when the 651 "RFC2554bis" document is assigned with the new RFC No.]] 653 7. Security considerations 655 See the extended security considerations discussion in 656 [EAI-framework] 658 8. Acknowledgements 660 Much of the text in the initial version of this document was derived 661 or copied from [Klensin-emailaddr] with the permission of the author. 662 Significant comments and suggestions were received from Xiaodong LEE, 663 Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other members of the JET 664 team and were incorporated into the document. Special thanks to 665 those contributors for this version of the document, those include 666 (but not limited to) John C Klensin, Charles Lindsey, Dave Crocker, 667 Harald Tveit Alvestrand, Marcos Sanz, Chris Newman, Martin Duerst, 668 Edmon Chung, Tony Finch, Kari Hurtta, Randall Gellens, Frank 669 Ellermann, Alexey Melnikov. Of course, none of the individuals are 670 necessarily responsible for the combination of ideas represented 671 here. 673 9. Change History 675 [[anchor25: REMOVE THIS: This section is used for tracking the update 676 of this document. It may be useful to retain parts of it to 677 facilitate establishing dates and documents for the history of this 678 work.]] 680 9.1. draft-ietf-eai-smtpext: Version 00 682 This version supercedes draft-yao-ima-smtpext-03.txt. It refines the 683 ABNF definition of the internationalized email address. It 684 represents as the EAI working group document. 686 9.2. draft-ietf-eai-smtpext: Version 01 688 o Upgraded to reflect discussions during IETF 66. 689 o Remove the atomic parameter. 691 o Add the new section of "the Suggestion of the value of the ALT- 692 ADDRESS parameter". 694 9.3. draft-ietf-eai-smtpext: Version 02 696 o Upgraded to reflect the recent discussion of the ima@ietf.org 697 mailing list. 698 o Add the section of "Body Parts and SMTP Extensions". 699 o Add the new section of "Change History". 700 o Add the subsection about SMTP extensions for DSN. 702 9.4. draft-ietf-eai-smtpext: Version 03 704 o Update the syntax related to mailbox. 705 o Update the trace field section. 706 o Add the new section about message retry. 707 o Update the subsection about SMTP extensions for DSN. 709 9.5. draft-ietf-eai-smtpext: Version 04 711 o Refine some syntax. 712 o Delete "Message Header Label" section. 713 o Change "bounce" to "reject". 715 9.6. draft-ietf-eai-smtpext: Version 05 717 o Refine the abstract. 718 o Delete "The Suggestion of the Value of the ALT-ADDRESS parameter" 719 section. 720 o Move original section 2.7.4 and 2.7.5 to section 3 with the name 721 "Issues with other parts of the email system". 722 o Add the new section "LMTP". 723 o Refine some text according to suggestions from the EAI mailing 724 list discussion 725 o Remove the section "Mailing List Question" 727 9.7. draft-ietf-eai-smtpext: Version 06 729 o Delete the section about message retry. 730 o Add the new subsection about Mail eXchangers 731 o Add the new section about "UTF-8 Reply" 732 o Refine some response code for the section "Using the ALT-ADDRESS 733 parameter" 735 9.8. draft-ietf-eai-smtpext: Version 07 736 o Rename the section 2.5 737 o Refine sthe section 2.7 739 9.9. draft-ietf-eai-smtpext: Version 08 741 o Refine some texts and update some references 743 10. References 745 10.1. Normative References 747 [ASCII] Cerf, V., "ASCII format for network interchange", RFC 20, 748 October 1969. 750 [EAI-framework] 751 Klensin, J. and Y. Ko, "Overview and Framework for 752 Internationalized Email", RFC 4952, July 2007. 754 [EAI-utf8header] 755 Abel, Y., "Transmission of Email Headers in UTF-8 756 Encoding", draft-ietf-eai-utf8headers-07.txt (work in 757 progress), September 2007. 759 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 760 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 761 RFC 1652, July 1994. 763 [RFC1869] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 764 Crocker, "SMTP Service Extensions", STD 10, RFC 1869, 765 November 1995. 767 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 768 Requirement Levels", BCP 14, RFC 2119, March 1997. 770 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 771 April 2001. 773 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 774 April 2001. 776 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 777 Extension for Delivery Status Notifications (DSNs)", 778 RFC 3461, January 2003. 780 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 781 RFC 3463, January 2003. 783 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 784 for Delivery Status Notifications", RFC 3464, 785 January 2003. 787 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 788 "Internationalizing Domain Names in Applications (IDNA)", 789 RFC 3490, March 2003. 791 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 792 10646", RFC 3629, November 2003. 794 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 795 Specifications: ABNF", RFC 4234, October 2005. 797 10.2. Informative References 799 [EAI-downgrading] 800 YONEYA, Y., Ed. and K. Fujiwara, Ed., "Downgrading 801 mechanism for Internationalized eMail Address", 802 draft-ietf-eai-downgrade-04 (work in progress), 7 2007. 804 [EAI-dsn] Newman, C. and A. Melnikov, "SMTP extensions for DSNs", 805 draft-ietf-eai-dsn-03.txt (work in progress), 9 2007. 807 [EAI-imap] 808 Resnick, P. and C. Newman, "Considerations for IMAP in 809 Conjunction with Email Address Internationalization", 810 draft-ietf-eai-imap-utf8-01 (work in progress), 811 March 2007. 813 [EAI-mailing list] 814 Gellens, R. and E. Chung, "Mailing Lists and 815 Internationalized Email Addresses", 816 draft-ietf-eai-mailinglist-01.txt (work in progress), 817 January 2007. 819 [EAI-pop] Newman, C., "POP3 Support for UTF-8", 820 draft-ietf-eai-pop-01.txt (work in progress), 821 January 2007. 823 [Klensin-emailaddr] 824 Klensin, J., "Internationalization of Email Addresses", 825 draft-klensin-emailaddr-i18n-03 (work in progress), 826 July 2005. 828 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 829 October 1996. 831 [RFC2554bis] 832 Siemborski, R. and A. Melnikov, "SMTP Service Extension 833 for Authentication", draft-siemborski-rfc2554bis-09 (work 834 in progress), April 2007. 836 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission 837 of Large and Binary MIME Messages", RFC 3030, 838 December 2000. 840 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 841 Transport Layer Security", RFC 3207, February 2002. 843 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 844 RFC 4409, April 2006. 846 [SMTP-codes] 847 KLensin, J., "An IANA Registry for Extended SMTP Status 848 Codes", draft-klensin-smtp-code-registry-00 (work in 849 progress), April 2007. 851 Authors' Addresses 853 Jiankang YAO (editor) 854 CNNIC 855 No.4 South 4th Street, Zhongguancun 856 Beijing 858 Phone: +86 10 58813007 859 Email: yaojk@cnnic.cn 861 Wei MAO (editor) 862 CNNIC 863 No.4 South 4th Street, Zhongguancun 864 Beijing 866 Phone: +86 10 58813055 867 Email: maowei_ietf@cnnic.cn 869 Full Copyright Statement 871 Copyright (C) The IETF Trust (2007). 873 This document is subject to the rights, licenses and restrictions 874 contained in BCP 78, and except as set forth therein, the authors 875 retain all their rights. 877 This document and the information contained herein are provided on an 878 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 879 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 880 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 881 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 882 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 883 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 885 Intellectual Property 887 The IETF takes no position regarding the validity or scope of any 888 Intellectual Property Rights or other rights that might be claimed to 889 pertain to the implementation or use of the technology described in 890 this document or the extent to which any license under such rights 891 might or might not be available; nor does it represent that it has 892 made any independent effort to identify any such rights. Information 893 on the procedures with respect to rights in RFC documents can be 894 found in BCP 78 and BCP 79. 896 Copies of IPR disclosures made to the IETF Secretariat and any 897 assurances of licenses to be made available, or the result of an 898 attempt made to obtain a general license or permission for the use of 899 such proprietary rights by implementers or users of this 900 specification can be obtained from the IETF on-line IPR repository at 901 http://www.ietf.org/ipr. 903 The IETF invites any interested party to bring to its attention any 904 copyrights, patents or patent applications, or other proprietary 905 rights that may cover technology that may be required to implement 906 this standard. Please address the information to the IETF at 907 ietf-ipr@ietf.org. 909 Acknowledgment 911 Funding for the RFC Editor function is provided by the IETF 912 Administrative Support Activity (IASA).