idnits 2.17.1 draft-yao-ima-smtpext-00.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 383. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 IMA extension keyword MAY transmit a mailbox name as an internationalized string in UTF-8 form. It MAY transmit the domain part of that string in either punycode (derived from the IDNA process) or UTF-8 form. If it sends the domain in UTF-8 form, the original SMTP client SHOULD first verify that the string is valid for a domain name according to IDNA rules. As required by RFC 2821, it MUST not attempt to parse, evaluate, or transform the local part in any way. If the IMA SMTP extension is not offered by the Server, the SMTP Client MUST not transmit an internationalized address. Instead, it MUST either return the message to the user as undeliverable or replace it. If it is replaced, the replacement MUST be either the ASCII-only address specified with the ALT-ADDRESS parameter or with an address obtained from another source that conforms to the syntax rules of RFC 2821. -- 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 26, 2005) is 6787 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Ldh-str' is mentioned on line 198, but not defined == Unused Reference: 'ASCII' is defined on line 286, but no explicit reference was found in the text == Unused Reference: 'RFC3492' is defined on line 327, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 347, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' == Outdated reference: A later version (-01) exists of draft-klensin-ima-framework-00 -- Possible downref: Normative reference to a draft: ref. 'IMA-overview' -- No information found for draft-yeh-utf8headers - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IMA-utf8header' ** 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) == Outdated reference: A later version (-01) exists of draft-yoneya-ima-downgrade-00 Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 11 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 CNNIC 4 Expires: March 30, 2006 September 26, 2005 6 SMTP extension for internationalized email address 7 draft-yao-ima-smtpext-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on March 30, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 The internationalized email address (IMA) should be solved in the 41 transport-level, which is an architecturally desirable approach. 42 This document specifies the use of SMTP extension for 43 internationalized email address (IMA) delivery. And also mention 44 about the backward compatible mechanism for downgrade procedure, as 45 specified in an associated specification. The protocol propoesed 46 here is MTA-level solution which is feasible, architecturally more 47 elegant, and not as difficult to deploy in relevant communities. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Role of this specification . . . . . . . . . . . . . . . . 3 53 1.2. Proposal Context . . . . . . . . . . . . . . . . . . . . . 3 54 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Mail Transport-level Protocol . . . . . . . . . . . . . . . . 4 56 2.1. Framework for the Internationalization Extension . . . . . 4 57 2.2. The Address Internationalization Service Extension . . . . 4 58 2.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 5 59 2.4. The ALT-ADDRESS parameter . . . . . . . . . . . . . . . . 5 60 2.5. Additional ESMTP Changes and Clarifications . . . . . . . 6 61 2.5.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 6 62 2.5.2. Trace Fields . . . . . . . . . . . . . . . . . . . . . 6 63 3. Implementation Advice . . . . . . . . . . . . . . . . . . . . 6 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 5. Security considerations . . . . . . . . . . . . . . . . . . . 7 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 Intellectual Property and Copyright Statements . . . . . . . . . . 10 73 1. Introduction 75 1.1. Role of this specification 77 An overview document [IMA-overview] specifies the requirements for, 78 and components of, full internationalization of electronic mail. 79 This document specifies an element of that work, specifically the 80 definition of an SMTP extension [RFC1869] for internationalized email 81 address (IMA) transport delivery. 83 1.2. Proposal Context 85 In order to use internationalized email addresses, we need to 86 internationalize both the domain part and the local part of email 87 address. Domain part of email addresses may be internationalized 88 through IDNA [RFC3490]. But the local part of email address still 89 remains as non-internationalized. 91 The syntax of Internet email addresses is restricted to a subset of 92 7-bit ASCII for the domain-part, with a less-restricted subset for 93 the local-part. These restrictions are specified in RFC 2821 94 [RFC2821]. To be able to deliver internationalized email through 95 SMTP servers, we need to upgrade SMTP server to able to carry 96 internationalized email address. Since older servers and the mail- 97 reading clients and other systems that are downstream from them will 98 not be prepared to handle these extended addresses, an SMTP extension 99 is specified to identify and protect the addressing mechanism. 101 This specification describes a change to the email transport 102 mechanism that permits internationalized addresses in both the 103 envelope and header fields of messages. The context for the change 104 is described in [IMA-overview] and the details of the header changes 105 are described in [IMA-utf8header], 107 1.3. Terminology 109 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", 110 and "MAY" in this document are to be interpreted as described in RFC 111 2119 [RFC2119]. 113 All specialized terms used in this specification are defined in the 114 IMA overview [IMA-overview] or in [RFC2821] and [RFC2822]. 116 This document is being discussed on the ima mailing list. See 117 https://www1.ietf.org/mailman/listinfo/ima for information about 118 subscribing. The list's archive is at 119 http://www1.ietf.org/mail-archive/web/ima/index.html. 121 2. Mail Transport-level Protocol 123 2.1. Framework for the Internationalization Extension 125 The following service extension is defined: 127 1. The name of the SMTP service extension is "Internationalized 128 eMail Address"; 129 2. The EHLO keyword value associated with this extension is "IMA"; 130 3. No parameter values are defined for this EHLO keyword value. In 131 order to permit future (although unanticipated) extensions, the 132 EHLO response MUST NOT contain any parameters for that keyword. 133 If a parameter appears, the SMTP client that is conformant to 134 this version of this specification MUST treat the ESMTP response 135 as if the IMA keyword did not appear. 136 4. An optional parameter is added to the SMTP MAIL and RCPT 137 commands. This parameter is named ALT-ADDRESS. It requires an 138 argument as a substitute for the internationalized (UTF-8 coded) 139 address, which is discussed in [IMA-downgrading]. This all-ASCII 140 address MAY incorporate the IDNA "punycode" form if the domain 141 name is internationalized. No algorithmic transformation is 142 specified for the local-part; in the general case, it may 143 identify a completely separate mailbox from the one identified in 144 the primary command argument. The domain part of the ALT-ADDRESS 145 may either be the same one as in the primary address (or its 146 punycode equivalent) or may be completely different. 147 5. No additional SMTP verbs are defined by this extension. 148 6. Servers offering this extension MUST provide support for, and 149 announce, the 8BITMIME extension [RFC1652]. 151 2.2. The Address Internationalization Service Extension 153 An SMTP Server that announces this extension MUST be prepared to 154 accept a UTF-8 string [RFC3629] in any position in which RFC 2821 155 specifies that a "mailbox" may appear. That string must be parsed 156 only as specified in RFC 2821, i.e., by separating the mailbox into 157 source route, local part and domain part, using only the characters 158 colon (U+003A), comma (U+002C), and at-sign (U+0040) as specified 159 there. Once isolated by this parsing process, the local part MUST be 160 treated as opaque unless the SMTP Server is the final delivery MTA. 161 Any domain names that are to be looked up in the DNS MUST be 162 processed into punycode form as specified in IDNA [RFC3490] unless 163 they are already in that form. Any domain names that are to be 164 compared to local strings SHOULD be checked for validity and then 165 MUST be compared as specified in IDNA. 167 An SMTP Client that receives the IMA extension keyword MAY transmit a 168 mailbox name as an internationalized string in UTF-8 form. It MAY 169 transmit the domain part of that string in either punycode (derived 170 from the IDNA process) or UTF-8 form. If it sends the domain in 171 UTF-8 form, the original SMTP client SHOULD first verify that the 172 string is valid for a domain name according to IDNA rules. As 173 required by RFC 2821, it MUST not attempt to parse, evaluate, or 174 transform the local part in any way. If the IMA SMTP extension is 175 not offered by the Server, the SMTP Client MUST not transmit an 176 internationalized address. Instead, it MUST either return the 177 message to the user as undeliverable or replace it. If it is 178 replaced, the replacement MUST be either the ASCII-only address 179 specified with the ALT-ADDRESS parameter or with an address obtained 180 from another source that conforms to the syntax rules of RFC 2821. 182 2.3. Extended Mailbox Address Syntax 184 RFC 2821, section 4.1.2, defines the syntax of a mailbox as 186 Mailbox = Local-part "@" Domain 188 Local-part = Dot-string / Quoted-string 189 ; MAY be case-sensitive 191 Dot-string = Atom *("." Atom) 193 Atom = 1*atext 195 Quoted-string = DQUOTE *qcontent DQUOTE 197 Domain = (sub-domain 1*("." sub-domain)) / address-literal 198 sub-domain = Let-dig [Ldh-str] 200 The key changes made by this specification are, informally, to 202 o Change the definition of "sub-domain" to permit either the 203 definition above or a UTF-8 string representing a DNS label that 204 is conformant with IDNA [RFC3490]. That label MUST NOT contain 205 the characters "@" or ".", even though those characters can 206 normally be inserted into a DNS label. 207 o Change the definition of "Atom" to permit either the definition 208 above or a UTF-8 string. That string MUST NOT contain any of the 209 ASCII characters (either graphics or controls) that are not 210 permitted in "atext"; it is otherwise unrestricted. 212 2.4. The ALT-ADDRESS parameter 214 If the IMA extension is offered, the syntax of the SMTP MAIL and RCPT 215 commands is extended to support the optional "ALT-ADDRESS" parameter, 216 which is specified in an associated document [IMA-downgrading]. 218 2.5. Additional ESMTP Changes and Clarifications 220 The mail transport process involves addresses ("mailboxes") and 221 domain names in contexts in addition to the MAIL and RCPT commands 222 and extended alternatives to them. In general, the rule is that, 223 when RFC 2821 specifies a mailbox, this document expects UTF-8 to be 224 used for the entire string; when RFC 2821 specifies a domain name, 225 the name should be in punycode form if its raw form is non-ASCII. 227 The following subsections list and discuss all of the relevant cases. 229 Support and use of this extension requires support for 8BITMIME. 231 2.5.1. The Initial SMTP Exchange 233 When an SMTP or ESMTP connection is opened, the server sends a 234 "banner" response consisting of the 220 reply code and some 235 information. The client then sends the EHLO command. Since the 236 client cannot know whether the server supports internationalized 237 addresses until after it receives the response from EHLO, any domain 238 names that appear in this dialogue, or in responses to EHLO, must be 239 in hostname form, i.e., internationalized ones must be in punycode 240 form. 242 2.5.2. Trace Fields 244 Internationalized domain names in Received fields should be 245 transmitted in punycode form. Addresses in "for" clauses need 246 further examination and might be treated differently depending on 247 [IMA-utf8header]. The reasoning in the introductory portion of [IMA- 248 overview] strongly suggests that these addresses be in UTF-8 form, 249 rather than some specialized encoding. 251 3. Implementation Advice 253 In the absence of this extension, SMTP clients and servers are 254 constrained to using only those addresses permitted by RFC 2821. The 255 local parts of those addresses may be made up of any ASCII 256 characters, although certain of them must be quoted as specified 257 there. It is notable in an internationalization context that there 258 is a long history on some systems of using overstruck ASCII 259 characters (a character, a backspace, and another character) within a 260 quoted string to approximate non-ASCII characters. This form of 261 internationalization should be phased out as this extension becomes 262 widely deployed but backward-compatibility considerations require 263 that it continue to be supported. 265 4. IANA Considerations 267 IANA is requested to add "IMA" to the SMTP extensions registry with 268 the entry pointing to this specification for its definition. 270 5. Security considerations 272 See the extended security considerations discussion in [IMA-overview] 274 6. Acknowledgements 276 Much of the text in the initial version of this document was derived 277 or copied from [Klensin-emailaddr] with the permission of the author. 278 Significant comments and suggestions were received from Xiaodong LEE, 279 Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other members of the JET 280 team and were incorporated into the document. 282 7. References 284 7.1. Normative References 286 [ASCII] American National Standards Institute (formerly United 287 States of America Standards Institute), "USA Code for 288 Information Interchange", ANSI X3.4-1968, 1968. 290 ANSI X3.4-1968 has been replaced by newer versions with 291 slight modifications, but the 1968 version remains 292 definitive for the Internet. 294 [IMA-overview] 295 Klensin, J. and Y. Ko, "Overview and Framework of 296 Internationalized Email Address Delivery", 297 draft-klensin-ima-framework-00 (work in progress), 298 October 2005. 300 [IMA-utf8header] 301 Klensin, J. and J. Yeh, "Transmission of Email Headers in 302 UTF-8 Encoding", draft-yeh-utf8headers-00 (work in 303 progress), October 2005. 305 [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 307 Crocker, "SMTP Service Extension for 8bit-MIMEtransport", 308 RFC 1652, July 1994. 310 [RFC1869] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 311 Crocker, "SMTP Service Extensions", STD 10, RFC 1869, 312 November 1995. 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, March 1997. 317 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 318 April 2001. 320 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 321 April 2001. 323 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 324 "Internationalizing Domain Names in Applications (IDNA)", 325 RFC 3490, March 2003. 327 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 328 for Internationalized Domain Names in Applications 329 (IDNA)", RFC 3492, March 2003. 331 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 332 10646", RFC 3629, November 2003. 334 7.2. Informative References 336 [IMA-downgrading] 337 YONEYA, Y. and K. Fujiwara, "Downgrade Mechanism for 338 Internationalized Email Address (IMA)", 339 draft-yoneya-ima-downgrade-00 (work in progress), 340 October 2005. 342 [Klensin-emailaddr] 343 Klensin, J., "Internationalization of Email Addresses", 344 draft-klensin-emailaddr-i18n-03 (work in progress), 345 July 2005. 347 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 348 Extensions (MIME) Part One: Format of Internet Message 349 Bodies", RFC 2045, November 1996. 351 Author's Address 353 Jiankang YAO (editor) 354 CNNIC 355 No.4 South 4th Street, Zhongguancun 356 Beijing 358 Phone: +86 10 58813007 359 Email: yaojk@cnnic.cn 361 Intellectual Property Statement 363 The IETF takes no position regarding the validity or scope of any 364 Intellectual Property Rights or other rights that might be claimed to 365 pertain to the implementation or use of the technology described in 366 this document or the extent to which any license under such rights 367 might or might not be available; nor does it represent that it has 368 made any independent effort to identify any such rights. Information 369 on the procedures with respect to rights in RFC documents can be 370 found in BCP 78 and BCP 79. 372 Copies of IPR disclosures made to the IETF Secretariat and any 373 assurances of licenses to be made available, or the result of an 374 attempt made to obtain a general license or permission for the use of 375 such proprietary rights by implementers or users of this 376 specification can be obtained from the IETF on-line IPR repository at 377 http://www.ietf.org/ipr. 379 The IETF invites any interested party to bring to its attention any 380 copyrights, patents or patent applications, or other proprietary 381 rights that may cover technology that may be required to implement 382 this standard. Please address the information to the IETF at 383 ietf-ipr@ietf.org. 385 Disclaimer of Validity 387 This document and the information contained herein are provided on an 388 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 389 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 390 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 391 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 392 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 393 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 395 Copyright Statement 397 Copyright (C) The Internet Society (2005). This document is subject 398 to the rights, licenses and restrictions contained in BCP 78, and 399 except as set forth therein, the authors retain all their rights. 401 Acknowledgment 403 Funding for the RFC Editor function is currently provided by the 404 Internet Society.