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