| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | Internet Engineering Task Force (IETF) J. Yao |
| 8 | Request for Comments: 6531 W. Mao |
| 9 | Obsoletes: 5336 CNNIC |
| 10 | Category: Standards Track February 2012 |
| 11 | ISSN: 2070-1721 |
| 12 | |
| 13 | |
| 14 | SMTP Extension for Internationalized Email |
| 15 | |
| 16 | Abstract |
| 17 | |
| 18 | This document specifies an SMTP extension for transport and delivery |
| 19 | of email messages with internationalized email addresses or header |
| 20 | information. |
| 21 | |
| 22 | Status of This Memo |
| 23 | |
| 24 | This is an Internet Standards Track document. |
| 25 | |
| 26 | This document is a product of the Internet Engineering Task Force |
| 27 | (IETF). It represents the consensus of the IETF community. It has |
| 28 | received public review and has been approved for publication by the |
| 29 | Internet Engineering Steering Group (IESG). Further information on |
| 30 | Internet Standards is available in Section 2 of RFC 5741. |
| 31 | |
| 32 | Information about the current status of this document, any errata, |
| 33 | and how to provide feedback on it may be obtained at |
| 34 | http://www.rfc-editor.org/info/rfc6531. |
| 35 | |
| 36 | Copyright Notice |
| 37 | |
| 38 | Copyright (c) 2012 IETF Trust and the persons identified as the |
| 39 | document authors. All rights reserved. |
| 40 | |
| 41 | This document is subject to BCP 78 and the IETF Trust's Legal |
| 42 | Provisions Relating to IETF Documents |
| 43 | (http://trustee.ietf.org/license-info) in effect on the date of |
| 44 | publication of this document. Please review these documents |
| 45 | carefully, as they describe your rights and restrictions with respect |
| 46 | to this document. Code Components extracted from this document must |
| 47 | include Simplified BSD License text as described in Section 4.e of |
| 48 | the Trust Legal Provisions and are provided without warranty as |
| 49 | described in the Simplified BSD License. |
| 50 | |
| 51 | This document may contain material from IETF Documents or IETF |
| 52 | Contributions published or made publicly available before November |
| 53 | 10, 2008. The person(s) controlling the copyright in some of this |
| 54 | material may not have granted the IETF Trust the right to allow |
| 55 | |
| 56 | |
| 57 | |
| 58 | Yao & Mao Standards Track [Page 1] |
| 59 | |
| 60 | RFC 6531 SMTP Extension for SMTPUTF8 February 2012 |
| 61 | |
| 62 | |
| 63 | modifications of such material outside the IETF Standards Process. |
| 64 | Without obtaining an adequate license from the person(s) controlling |
| 65 | the copyright in such materials, this document may not be modified |
| 66 | outside the IETF Standards Process, and derivative works of it may |
| 67 | not be created outside the IETF Standards Process, except to format |
| 68 | it for publication as an RFC or to translate it into languages other |
| 69 | than English. |
| 70 | |
| 71 | Table of Contents |
| 72 | |
| 73 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 |
| 74 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 |
| 75 | 1.2. Changes Made to Other Specifications . . . . . . . . . . . 3 |
| 76 | 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 |
| 77 | 3. Mail Transport-Level Protocol . . . . . . . . . . . . . . . . 4 |
| 78 | 3.1. Framework for the Internationalization Extension . . . . . 4 |
| 79 | 3.2. The SMTPUTF8 Extension . . . . . . . . . . . . . . . . . . 5 |
| 80 | 3.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 7 |
| 81 | 3.4. MAIL Command Parameter Usage . . . . . . . . . . . . . . . 8 |
| 82 | 3.5. Non-ASCII Addresses and Reply-Codes . . . . . . . . . . . 9 |
| 83 | 3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 9 |
| 84 | 3.7. Additional ESMTP Changes and Clarifications . . . . . . . 10 |
| 85 | 3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 10 |
| 86 | 3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 10 |
| 87 | 3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 11 |
| 88 | 3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 11 |
| 89 | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 |
| 90 | 4.1. SMTP Service Extensions Registry . . . . . . . . . . . . . 13 |
| 91 | 4.2. SMTP Enhanced Status Code Registry . . . . . . . . . . . . 13 |
| 92 | 4.3. WITH Protocol Types Sub-Registry of the Mail |
| 93 | Transmission Types Registry . . . . . . . . . . . . . . . 15 |
| 94 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 |
| 95 | 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 96 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 |
| 97 | 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 |
| 98 | 7.2. Informative References . . . . . . . . . . . . . . . . . . 18 |
| 99 | |
| 100 | |
| 101 | |
| 102 | |
| 103 | |
| 104 | |
| 105 | |
| 106 | |
| 107 | |
| 108 | |
| 109 | |
| 110 | |
| 111 | |
| 112 | |
| 113 | |
| 114 | Yao & Mao Standards Track [Page 2] |
| 115 | |
| 116 | RFC 6531 SMTP Extension for SMTPUTF8 February 2012 |
| 117 | |
| 118 | |
| 119 | 1. Introduction |
| 120 | |
| 121 | The document defines a Simple Mail Transfer Protocol [RFC5321] |
| 122 | extension so servers can advertise the ability to accept and process |
| 123 | internationalized email addresses (see Section 1.1) and |
| 124 | internationalized email headers [RFC6532]. |
| 125 | |
| 126 | An extended overview of the extension model for internationalized |
| 127 | email addresses and the email header appears in RFC 6530 [RFC6530], |
| 128 | referred to as "the framework document" in this specification. A |
| 129 | thorough understanding of the information in that document and in the |
| 130 | base Internet email specifications [RFC5321] [RFC5322] is necessary |
| 131 | to understand and implement this specification. |
| 132 | |
| 133 | 1.1. Terminology |
| 134 | |
| 135 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| 136 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| 137 | document are to be interpreted as described in RFC 2119 [RFC2119]. |
| 138 | |
| 139 | The terms "UTF-8 string" or "UTF-8 character" are used to refer to |
| 140 | Unicode characters, which may or may not be members of the ASCII |
| 141 | subset, in UTF-8 [RFC3629], a standard Unicode Encoding Form. All |
| 142 | other specialized terms used in this specification are defined in the |
| 143 | framework document or in the base Internet email specifications. In |
| 144 | particular, the terms "ASCII address", "internationalized email |
| 145 | address", "non-ASCII address", "SMTPUTF8", "internationalized |
| 146 | message", and "message" are used in this document according to the |
| 147 | definitions in the framework document [RFC6530]. |
| 148 | |
| 149 | Strings referred to in this document, including ASCII strings, MUST |
| 150 | be expressed in UTF-8. |
| 151 | |
| 152 | This specification uses Augmented BNF (ABNF) rules [RFC5234]. Some |
| 153 | basic rules in this document are identified in Section 3.3 as being |
| 154 | defined (under the same names) in RFC 5234 [RFC5234], RFC 5321 |
| 155 | [RFC5321], RFC 5890 [RFC5890], or RFC 6532 [RFC6532]. |
| 156 | |
| 157 | 1.2. Changes Made to Other Specifications |
| 158 | |
| 159 | This specification extends some syntax rules defined in RFC 5321 and |
| 160 | permits internationalized email addresses in the envelope and in |
| 161 | trace fields, but it does not modify RFC 5321. It permits data |
| 162 | formats defined in RFC 6532 [RFC6532], but it does not modify RFC |
| 163 | 5322. It does require that the 8BITMIME extension [RFC6152] be |
| 164 | announced by the SMTPUTF8-aware SMTP server and used with |
| 165 | "BODY=8BITMIME" by the SMTPUTF8-aware SMTP client, but it does not |
| 166 | modify the 8BITMIME specification in any way. |
| 167 | |
| 168 | |
| 169 | |
| 170 | Yao & Mao Standards Track [Page 3] |
| 171 | |
| 172 | RFC 6531 SMTP Extension for SMTPUTF8 February 2012 |
| 173 | |
| 174 | |
| 175 | This specification replaces an earlier, experimental, approach to the |
| 176 | same problem [RFC5336]. Section 6 of RFC 6530 [RFC6530] describes |
| 177 | the changes in approach between RFC 5336 [RFC5336] and this |
| 178 | specification. Anyone trying to convert an implementation from the |
| 179 | experimental specification to the specification in this document will |
| 180 | need to review those changes carefully. |
| 181 | |
| 182 | 2. Overview of Operation |
| 183 | |
| 184 | This document specifies an element of the email internationalization |
| 185 | work, specifically the definition of an SMTP extension for |
| 186 | internationalized email. The extension is identified with the token |
| 187 | "SMTPUTF8". |
| 188 | |
| 189 | The internationalized email headers specification [RFC6532] provides |
| 190 | the details of email header features enabled by this extension. |
| 191 | |
| 192 | 3. Mail Transport-Level Protocol |
| 193 | |
| 194 | 3.1. Framework for the Internationalization Extension |
| 195 | |
| 196 | The following service extension is defined: |
| 197 | |
| 198 | 1. The name of the SMTP service extension is "Internationalized |
| 199 | Email". |
| 200 | |
| 201 | 2. The EHLO keyword value associated with this extension is |
| 202 | "SMTPUTF8". |
| 203 | |
| 204 | 3. No parameter values are defined for this EHLO keyword value. In |
| 205 | order to permit future (although unanticipated) extensions, the |
| 206 | EHLO response MUST NOT contain any parameters for this keyword. |
| 207 | The SMTPUTF8-aware SMTP client MUST ignore any parameters if |
| 208 | they appear for this keyword; that is, the SMTPUTF8-aware SMTP |
| 209 | client MUST behave as if the parameters do not appear. If an |
| 210 | SMTP server includes SMTPUTF8 in its EHLO response, it MUST be |
| 211 | fully compliant with this version of this specification. |
| 212 | |
| 213 | 4. One OPTIONAL parameter, SMTPUTF8, is added to the MAIL command. |
| 214 | The parameter does not accept a value. If this parameter is set |
| 215 | in the MAIL command, it indicates that the SMTP client is |
| 216 | SMTPUTF8-aware. Its presence also asserts that the envelope |
| 217 | includes the non-ASCII address, the message being sent is an |
| 218 | internationalized message, or the message being sent needs the |
| 219 | SMTPUTF8 support. |
| 220 | |
| 221 | |
| 222 | |
| 223 | |
| 224 | |
| 225 | |
| 226 | Yao & Mao Standards Track [Page 4] |
| 227 | |
| 228 | RFC 6531 SMTP Extension for SMTPUTF8 February 2012 |
| 229 | |
| 230 | |
| 231 | 5. The maximum length of a MAIL command line is increased by 10 |
| 232 | characters to accommodate the possible addition of the SMTPUTF8 |
| 233 | parameter. |
| 234 | |
| 235 | 6. One OPTIONAL parameter, SMTPUTF8, is added to the VERIFY (VRFY) |
| 236 | and EXPAND (EXPN) commands. The SMTPUTF8 parameter does not |
| 237 | accept a value. The parameter indicates that the SMTP client |
| 238 | can accept Unicode characters in UTF-8 encoding in replies from |
| 239 | the VRFY and EXPN commands. |
| 240 | |
| 241 | 7. No additional SMTP verbs are defined by this extension. |
| 242 | |
| 243 | 8. Servers offering this extension MUST provide support for, and |
| 244 | announce, the 8BITMIME extension [RFC6152]. |
| 245 | |
| 246 | 9. The reverse-path and forward-path of the SMTP MAIL and RCPT |
| 247 | commands are extended to allow Unicode characters encoded in |
| 248 | UTF-8 in mailbox names (addresses). |
| 249 | |
| 250 | 10. The mail message body is extended as specified in RFC 6532 |
| 251 | [RFC6532]. |
| 252 | |
| 253 | 11. The SMTPUTF8 extension is valid on the submission port |
| 254 | [RFC6409]. It may also be used with the Local Mail Transfer |
| 255 | Protocol (LMTP) [RFC2033]. When these protocols are used, their |
| 256 | use should be reflected in the trace field WITH keywords as |
| 257 | appropriate [RFC3848]. |
| 258 | |
| 259 | 3.2. The SMTPUTF8 Extension |
| 260 | |
| 261 | An SMTP server that announces the SMTPUTF8 extension MUST be prepared |
| 262 | to accept a UTF-8 string [RFC3629] in any position in which RFC 5321 |
| 263 | specifies that a <mailbox> can appear. Although the characters in |
| 264 | the <local-part> are permitted to contain non-ASCII characters, the |
| 265 | actual parsing of the <local-part> and the delimiters used are |
| 266 | unchanged from the base email specification [RFC5321]. Any domain |
| 267 | name to be looked up in the DNS MUST conform to and be processed as |
| 268 | specified for Internationalizing Domain Names in Applications (IDNA) |
| 269 | [RFC5890]. When doing lookups, the SMTPUTF8-aware SMTP client or |
| 270 | server MUST either use a Unicode-aware DNS library, or transform the |
| 271 | internationalized domain name to A-label form (i.e., a fully- |
| 272 | qualified domain name that contains one or more A-labels but no |
| 273 | U-labels) as specified in RFC 5890 [RFC5890]. |
| 274 | |
| 275 | An SMTP client that receives the SMTPUTF8 extension keyword in |
| 276 | response to the EHLO command MAY transmit mailbox names within SMTP |
| 277 | commands as internationalized strings in UTF-8 form. It MAY send a |
| 278 | UTF-8 header [RFC6532] (which may also include mailbox names in |
| 279 | |
| 280 | |
| 281 | |
| 282 | Yao & Mao Standards Track [Page 5] |
| 283 | |
| 284 | RFC 6531 SMTP Extension for SMTPUTF8 February 2012 |
| 285 | |
| 286 | |
| 287 | UTF-8). It MAY transmit the domain parts of mailbox names within |
| 288 | SMTP commands or the message header as A-labels or U-labels |
| 289 | [RFC5890]. The presence of the SMTPUTF8 extension does not change |
| 290 | the server-relaying behaviors described in RFC 5321. |
| 291 | |
| 292 | If the SMTPUTF8 SMTP extension is not offered by the SMTP server, the |
| 293 | SMTPUTF8-aware SMTP client MUST NOT transmit an internationalized |
| 294 | email address and MUST NOT transmit a mail message containing |
| 295 | internationalized mail headers as described in RFC 6532 [RFC6532] at |
| 296 | any level within its MIME structure [RFC2045]. (For this paragraph, |
| 297 | the internationalized domain name in A-label form as specified in |
| 298 | IDNA definitions [RFC5890] is not considered to be |
| 299 | "internationalized".) Instead, if an SMTPUTF8-aware SMTP client |
| 300 | (sender) attempts to transfer an internationalized message and |
| 301 | encounters an SMTP server that does not support the extension, the |
| 302 | best action for it to take depends on other conditions. In |
| 303 | particular: |
| 304 | |
| 305 | o If it is a Message Submission Agent (MSA) [RFC6409] [RFC5598], it |
| 306 | MAY choose its own way to deal with this scenario using the wide |
| 307 | discretion for changing addresses or otherwise fixing up and |
| 308 | transforming messages allowed by RFC 6409. As long as the |
| 309 | resulting message conforms to the requirements of RFC 5321 (i.e., |
| 310 | without the SMTPUTF8 extension), the details of that |
| 311 | transformation are outside the scope of this document. |
| 312 | |
| 313 | o If it is not an MSA or is an MSA and does not choose to transform |
| 314 | the message to one that does not require the SMTPUTF8 extension, |
| 315 | it SHOULD reject the message. As usual, this can be done either |
| 316 | by generating an appropriate reply during the SMTP transaction or |
| 317 | by accepting the message and then generating and transmitting a |
| 318 | non-delivery notification. If the latter choice is made, the |
| 319 | notification process MUST conform to the requirements of RFC 5321, |
| 320 | RFC 3464 [RFC3464], and RFC 6533 [RFC6533]. |
| 321 | |
| 322 | o As specified in Section 2.2.3 of RFC 5321, an SMTP client with |
| 323 | additional information and/or knowledge of special circumstances |
| 324 | MAY choose to requeue the message and try later and/or try an |
| 325 | alternate MX host as specified in that section. |
| 326 | |
| 327 | This document applies when an SMTPUTF8-aware SMTP client or server |
| 328 | supports the SMTPUTF8 extension. For all other cases, and for |
| 329 | addresses and messages that do not require an SMTPUTF8 extension, |
| 330 | SMTPUTF8-aware SMTP clients and servers do not change the behavior |
| 331 | specified in RFC 5321 [RFC5321]. |
| 332 | |
| 333 | |
| 334 | |
| 335 | |
| 336 | |
| 337 | |
| 338 | Yao & Mao Standards Track [Page 6] |
| 339 | |
| 340 | RFC 6531 SMTP Extension for SMTPUTF8 February 2012 |
| 341 | |
| 342 | |
| 343 | If an SMTPUTF8-aware SMTP server advertises the Delivery Status |
| 344 | Notification (DSN) [RFC3461] extension, it MUST implement RFC 6533 |
| 345 | [RFC6533]. |
| 346 | |
| 347 | 3.3. Extended Mailbox Address Syntax |
| 348 | |
| 349 | RFC 5321, Section 4.1.2, defines the syntax of a <Mailbox> entirely |
| 350 | in terms of ASCII characters. This document extends <Mailbox> to add |
| 351 | support of non-ASCII characters. |
| 352 | |
| 353 | The key changes made by this specification include: |
| 354 | |
| 355 | o The <Mailbox> ABNF rule is imported from RFC 5321 and updated in |
| 356 | order to support the internationalized email address. Other |
| 357 | related rules are imported from RFC 5321, RFC 5234, RFC 5890, and |
| 358 | RFC 6532, or are extended in this document. |
| 359 | |
| 360 | o The definition of <sub-domain> is extended to permit both the RFC |
| 361 | 5321 definition and a UTF-8 string in a DNS label that conforms |
| 362 | with IDNA definitions [RFC5890]. |
| 363 | |
| 364 | o The definition of <atext> is extended to permit both the RFC 5321 |
| 365 | definition and a UTF-8 string. That string MUST NOT contain any |
| 366 | of the ASCII graphics or control characters. |
| 367 | |
| 368 | The following ABNF rules imported from RFC 5321, Section 4.1.2, are |
| 369 | updated directly or indirectly by this document: |
| 370 | |
| 371 | o <Mailbox> |
| 372 | |
| 373 | o <Local-part> |
| 374 | |
| 375 | o <Dot-string> |
| 376 | |
| 377 | o <Quoted-string> |
| 378 | |
| 379 | o <QcontentSMTP> |
| 380 | |
| 381 | o <Domain> |
| 382 | |
| 383 | o <Atom> |
| 384 | |
| 385 | The following ABNF rule will be imported from RFC 6532, Section 3.1, |
| 386 | directly: |
| 387 | |
| 388 | o <UTF8-non-ascii> |
| 389 | |
| 390 | |
| 391 | |
| 392 | |
| 393 | |
| 394 | Yao & Mao Standards Track [Page 7] |
| 395 | |
| 396 | RFC 6531 SMTP Extension for SMTPUTF8 February 2012 |
| 397 | |
| 398 | |
| 399 | The following ABNF rule will be imported from RFC 5234, Appendix B.1, |
| 400 | directly: |
| 401 | |
| 402 | o <DQUOTE> |
| 403 | |
| 404 | The following ABNF rule will be imported from RFC 5890, Section |
| 405 | 2.3.2.1, directly: |
| 406 | |
| 407 | o <U-label> |
| 408 | |
| 409 | The following rules are extended in ABNF [RFC5234] as follows. |
| 410 | |
| 411 | sub-domain =/ U-label |
| 412 | ; extend the definition of sub-domain in RFC 5321, Section 4.1.2 |
| 413 | |
| 414 | atext =/ UTF8-non-ascii |
| 415 | ; extend the implicit definition of atext in |
| 416 | ; RFC 5321, Section 4.1.2, which ultimately points to |
| 417 | ; the actual definition in RFC 5322, Section 3.2.3 |
| 418 | |
| 419 | qtextSMTP =/ UTF8-non-ascii |
| 420 | ; extend the definition of qtextSMTP in RFC 5321, Section 4.1.2 |
| 421 | |
| 422 | esmtp-value =/ UTF8-non-ascii |
| 423 | ; extend the definition of esmtp-value in RFC 5321, Section 4.1.2 |
| 424 | |
| 425 | 3.4. MAIL Command Parameter Usage |
| 426 | |
| 427 | If the envelope or message being sent requires the capabilities of |
| 428 | the SMTPUTF8 extension, the SMTPUTF8-aware SMTP client MUST supply |
| 429 | the SMTPUTF8 parameter with the MAIL command. If this parameter is |
| 430 | provided, it MUST not accept a value. If the SMTPUTF8-aware SMTP |
| 431 | client is aware that neither the envelope nor the message being sent |
| 432 | requires any of the SMTPUTF8 extension capabilities, it SHOULD NOT |
| 433 | supply the SMTPUTF8 parameter with the MAIL command. |
| 434 | |
| 435 | Because there is no guarantee that a next-hop SMTP server will |
| 436 | support the SMTPUTF8 extension, use of the SMTPUTF8 extension always |
| 437 | carries a risk of transmission failure. In fact, during the early |
| 438 | stages of deployment for the SMTPUTF8 extension, the risk will be |
| 439 | quite high. Hence, there is a distinct near-term advantage for |
| 440 | ASCII-only messages to be sent without using this extension. The |
| 441 | long-term advantage of casting ASCII [ASCII] characters (0x7f and |
| 442 | below) as UTF-8 form is that it permits pure-Unicode environments. |
| 443 | |
| 444 | |
| 445 | |
| 446 | |
| 447 | |
| 448 | |
| 449 | |
| 450 | Yao & Mao Standards Track [Page 8] |
| 451 | |
| 452 | RFC 6531 SMTP Extension for SMTPUTF8 February 2012 |
| 453 | |
| 454 | |
| 455 | 3.5. Non-ASCII Addresses and Reply-Codes |
| 456 | |
| 457 | An SMTPUTF8-aware SMTP client MUST NOT send an internationalized |
| 458 | message to an SMTP server that does not support SMTPUTF8. If the |
| 459 | SMTP server does not support this option, then the SMTPUTF8-aware |
| 460 | SMTP client has three choices according to Section 3.2 of this |
| 461 | specification. |
| 462 | |
| 463 | The three-digit reply-codes used in this section are based on their |
| 464 | meanings as defined in RFC 5321. |
| 465 | |
| 466 | When messages are rejected because the RCPT command requires an ASCII |
| 467 | address, the reply-code 553 is returned with the meaning "mailbox |
| 468 | name not allowed". When messages are rejected because the MAIL |
| 469 | command requires an ASCII address, the reply-code 550 is returned |
| 470 | with the meaning "mailbox unavailable". When the SMTPUTF8-aware SMTP |
| 471 | server supports enhanced mail system status codes [RFC3463], reply- |
| 472 | code "X.6.7" [RFC5248] (see Section 4) is used, meaning "Non-ASCII |
| 473 | addresses not permitted for that sender/recipient". |
| 474 | |
| 475 | When messages are rejected for other reasons, the server follows the |
| 476 | model of the base email specification in RFC 5321; this extension |
| 477 | does not change those circumstances or reply messages. |
| 478 | |
| 479 | If a message is rejected after the final "." of the DATA command |
| 480 | because one or more recipients are unable to accept and process a |
| 481 | message with internationalized email headers, the reply-code "554" is |
| 482 | used with the meaning "Transaction failed". If the SMTPUTF8-aware |
| 483 | SMTP server supports enhanced mail system status codes [RFC3463], |
| 484 | reply code "X.6.9" [RFC5248] (see Section 4) is used to indicate this |
| 485 | condition, meaning "UTF-8 header message cannot be transmitted to one |
| 486 | or more recipients, so the message must be rejected". |
| 487 | |
| 488 | The SMTPUTF8-aware SMTP servers are encouraged to detect that |
| 489 | recipients cannot accept internationalized messages and generate an |
| 490 | error after the RCPT command rather than waiting until after the DATA |
| 491 | command to issue an error. |
| 492 | |
| 493 | 3.6. Body Parts and SMTP Extensions |
| 494 | |
| 495 | The MAIL command parameter SMTPUTF8 asserts that a message is an |
| 496 | internationalized message or the message being sent needs the |
| 497 | SMTPUTF8 support. There is still a chance that a message being sent |
| 498 | via the MAIL command with the SMTPUTF8 parameter is not an |
| 499 | internationalized message. An SMTPUTF8-aware SMTP client or server |
| 500 | that requires accurate knowledge of whether a message is |
| 501 | internationalized needs to parse all message header fields and MIME |
| 502 | |
| 503 | |
| 504 | |
| 505 | |
| 506 | Yao & Mao Standards Track [Page 9] |
| 507 | |
| 508 | RFC 6531 SMTP Extension for SMTPUTF8 February 2012 |
| 509 | |
| 510 | |
| 511 | header fields [RFC2045] in the message body. However, this |
| 512 | specification does not require that the SMTPUTF8-aware SMTP client or |
| 513 | server inspects the message. |
| 514 | |
| 515 | Although this specification requires that SMTPUTF8-aware SMTP servers |
| 516 | support the 8BITMIME extension [RFC6152] to ensure that servers have |
| 517 | adequate handling capability for 8-bit data, it does not require non- |
| 518 | ASCII body parts in the MIME message as specified in RFC 2045. The |
| 519 | SMTPUTF8 extension MAY be used as follows (assuming it is appropriate |
| 520 | given the body content): |
| 521 | |
| 522 | - with the BODY=8BITMIME parameter [RFC6152], or |
| 523 | |
| 524 | - with the BODY=BINARYMIME parameter, if the SMTP server advertises |
| 525 | BINARYMIME [RFC3030]. |
| 526 | |
| 527 | 3.7. Additional ESMTP Changes and Clarifications |
| 528 | |
| 529 | The information carried in the mail transport process involves |
| 530 | addresses ("mailboxes") and domain names in various contexts in |
| 531 | addition to the MAIL and RCPT commands and extended alternatives to |
| 532 | them. In general, the rule is that, when RFC 5321 specifies a |
| 533 | mailbox, this SMTP extension requires UTF-8 form to be used for the |
| 534 | entire string. When RFC 5321 specifies a domain name, the |
| 535 | internationalized domain name SHOULD be in U-label form if the |
| 536 | SMTPUTF8 extension is supported; otherwise, it SHOULD be in A-label |
| 537 | form. |
| 538 | |
| 539 | The following subsections list and discuss all of the relevant cases. |
| 540 | |
| 541 | 3.7.1. The Initial SMTP Exchange |
| 542 | |
| 543 | When an SMTP connection is opened, the SMTP server sends a "greeting" |
| 544 | response consisting of the 220 reply-code and some information. The |
| 545 | SMTP client then sends the EHLO command. Since the SMTP client |
| 546 | cannot know whether the SMTP server supports SMTPUTF8 until after it |
| 547 | receives the response to the EHLO, the SMTPUTF8-aware SMTP client |
| 548 | MUST send only ASCII (LDH label or A-label [RFC5890]) domains in the |
| 549 | EHLO command. If the SMTPUTF8-aware SMTP server provides domain |
| 550 | names in the EHLO response, they MUST be in the form of LDH labels or |
| 551 | A-labels. |
| 552 | |
| 553 | 3.7.2. Mail eXchangers |
| 554 | |
| 555 | If multiple DNS MX records are used to specify multiple servers for a |
| 556 | domain (as described in Section 5 of RFC 5321 [RFC5321]), it is |
| 557 | strongly advised that all or none of them SHOULD support the SMTPUTF8 |
| 558 | |
| 559 | |
| 560 | |
| 561 | |
| 562 | Yao & Mao Standards Track [Page 10] |
| 563 | |
| 564 | RFC 6531 SMTP Extension for SMTPUTF8 February 2012 |
| 565 | |
| 566 | |
| 567 | extension. Otherwise, unexpected rejections can happen during |
| 568 | temporary or permanent failures, which users might perceive as |
| 569 | serious reliability issues. |
| 570 | |
| 571 | 3.7.3. Trace Information |
| 572 | |
| 573 | The trace information <Return-path-line>, <Time-stamp-line>, and |
| 574 | their related rules are defined in Section 4.4 of RFC 5321 [RFC5321]. |
| 575 | This document updates <Mailbox> and <Domain> to support non-ASCII |
| 576 | characters. When the SMTPUTF8 extension is used, the 'Reverse-path' |
| 577 | clause of the Return-path-line may include an internationalized |
| 578 | domain name that uses the U-label form. Also, the 'Stamp' clause of |
| 579 | the Time-stamp-line may include an internationalized domain name that |
| 580 | uses the U-label form. |
| 581 | |
| 582 | If the messages that include trace fields are sent by an SMTPUTF8- |
| 583 | aware SMTP client or relay server without the SMTPUTF8 parameter |
| 584 | included in the MAIL commands, trace field values must conform to RFC |
| 585 | 5321 regardless of the SMTP server's capability. |
| 586 | |
| 587 | When an SMTPUTF8-aware SMTP server adds a trace field to a message |
| 588 | that was or will be transmitted with the SMTPUTF8 parameter included |
| 589 | in the MAIL commands, that server SHOULD use the U-label form for |
| 590 | internationalized domain names in the new trace field. |
| 591 | |
| 592 | The protocol value of the 'WITH' clause when this extension is used |
| 593 | is one of the SMTPUTF8 values specified in the "IANA Considerations" |
| 594 | section of this document. |
| 595 | |
| 596 | 3.7.4. UTF-8 Strings in Replies |
| 597 | |
| 598 | 3.7.4.1. MAIL Command |
| 599 | |
| 600 | If an SMTP client follows this specification and sends any MAIL |
| 601 | commands containing the SMTPUTF8 parameter, the SMTPUTF8-aware SMTP |
| 602 | server is permitted to use UTF-8 characters in the email address |
| 603 | associated with 251 and 551 reply-codes, and the SMTP client MUST be |
| 604 | able to accept and process them. If a given MAIL command does not |
| 605 | include the SMTPUTF8 parameter, the SMTPUTF8-aware SMTP server MUST |
| 606 | NOT return a 251 or 551 response containing a non-ASCII mailbox. |
| 607 | Instead, it MUST transform such responses into 250 or 550 responses |
| 608 | that do not contain non-ASCII addresses. |
| 609 | |
| 610 | 3.7.4.2. VRFY and EXPN Commands and the SMTPUTF8 Parameter |
| 611 | |
| 612 | If the SMTPUTF8 parameter is transmitted with the VRFY and EXPN |
| 613 | commands, it indicates that the SMTP client can accept UTF-8 strings |
| 614 | in replies to those commands. The parameter with the VRFY and EXPN |
| 615 | |
| 616 | |
| 617 | |
| 618 | Yao & Mao Standards Track [Page 11] |
| 619 | |
| 620 | RFC 6531 SMTP Extension for SMTPUTF8 February 2012 |
| 621 | |
| 622 | |
| 623 | commands SHOULD only be used after the SMTP client sees the EHLO |
| 624 | response with the SMTPUTF8 keyword. This allows an SMTPUTF8-aware |
| 625 | SMTP server to use UTF-8 strings in mailbox names and full names that |
| 626 | occur in replies, without concern that the SMTP client might be |
| 627 | confused by them. An SMTP client that conforms to this specification |
| 628 | MUST accept and correctly process replies to the VRFY and EXPN |
| 629 | commands that contain UTF-8 strings. However, an SMTPUTF8-aware SMTP |
| 630 | server MUST NOT use UTF-8 strings in replies if the SMTP client does |
| 631 | not specifically allow such replies by transmitting this parameter |
| 632 | with the VRFY and EXPN commands. |
| 633 | |
| 634 | Most replies do not require that a mailbox name be included in the |
| 635 | returned text, and therefore a UTF-8 string is not needed in them. |
| 636 | Some replies, notably those resulting from successful execution of |
| 637 | the VRFY and EXPN commands, do include the mailbox. |
| 638 | |
| 639 | VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to: |
| 640 | |
| 641 | vrfy = "VRFY" SP String |
| 642 | [ SP "SMTPUTF8" ] CRLF |
| 643 | ; String may include Non-ASCII characters |
| 644 | |
| 645 | expn = "EXPN" SP String |
| 646 | [ SP "SMTPUTF8" ] CRLF |
| 647 | ; String may include Non-ASCII characters |
| 648 | |
| 649 | The SMTPUTF8 parameter does not accept a value. If the reply to a |
| 650 | VRFY or EXPN command requires a UTF-8 string, but the SMTP client did |
| 651 | not use the SMTPUTF8 parameter, then the SMTPUTF8-aware SMTP server |
| 652 | MUST use either the reply-code 252 or 550. Reply-code 252, defined |
| 653 | in RFC 5321 [RFC5321], means "Cannot VRFY user, but will accept the |
| 654 | message and attempt the delivery". Reply-code 550, also defined in |
| 655 | RFC 5321 [RFC5321], means "Requested action not taken: mailbox |
| 656 | unavailable". When the SMTPUTF8-aware SMTP server supports enhanced |
| 657 | mail system status codes [RFC3463], the enhanced reply-code as |
| 658 | specified below is used. Using the SMTPUTF8 parameter with a VRFY or |
| 659 | EXPN command enables UTF-8 replies for that command only. |
| 660 | |
| 661 | If a normal success response (i.e., 250) is returned, the response |
| 662 | MAY include the full name of the user and MUST include the mailbox of |
| 663 | the user. It MUST be in either of the following forms: |
| 664 | |
| 665 | User Name <Mailbox> |
| 666 | ; Mailbox is defined in Section 3.3 of this document. |
| 667 | ; User Name can contain non-ASCII characters. |
| 668 | |
| 669 | Mailbox |
| 670 | ; Mailbox is defined in Section 3.3 of this document. |
| 671 | |
| 672 | |
| 673 | |
| 674 | Yao & Mao Standards Track [Page 12] |
| 675 | |
| 676 | RFC 6531 SMTP Extension for SMTPUTF8 February 2012 |
| 677 | |
| 678 | |
| 679 | If the SMTP reply requires UTF-8 strings, but a UTF-8 string is not |
| 680 | allowed in the reply, and the SMTPUTF8-aware SMTP server supports |
| 681 | enhanced mail system status codes [RFC3463], the enhanced reply-code |
| 682 | is "X.6.8" [RFC5248] (see Section 4), meaning "A reply containing a |
| 683 | UTF-8 string is required to show the mailbox name, but that form of |
| 684 | response is not permitted by the SMTP client". |
| 685 | |
| 686 | If the SMTP client does not support the SMTPUTF8 extension, but |
| 687 | receives a UTF-8 string in a reply, it may not be able to properly |
| 688 | report the reply to the user, and some clients might mishandle that |
| 689 | reply. Internationalized messages in replies are only allowed in the |
| 690 | commands under the situations described above. |
| 691 | |
| 692 | Although UTF-8 strings are needed to represent email addresses in |
| 693 | responses under the rules specified in this section, this extension |
| 694 | does not permit the use of UTF-8 strings for any other purposes. |
| 695 | SMTPUTF8-aware SMTP servers MUST NOT include non-ASCII characters in |
| 696 | replies except in the limited cases specifically permitted in this |
| 697 | section. |
| 698 | |
| 699 | 4. IANA Considerations |
| 700 | |
| 701 | 4.1. SMTP Service Extensions Registry |
| 702 | |
| 703 | IANA has added a new value "SMTPUTF8" to the "SMTP Service Extension" |
| 704 | registry of the "Mail Parameters" registry, according to the |
| 705 | following data: |
| 706 | |
| 707 | +----------+---------------------------------+-----------+ |
| 708 | | Keywords | Description | Reference | |
| 709 | +----------+---------------------------------+-----------+ |
| 710 | | SMTPUTF8 | Internationalized email address | [RFC6531] | |
| 711 | +----------+---------------------------------+-----------+ |
| 712 | |
| 713 | 4.2. SMTP Enhanced Status Code Registry |
| 714 | |
| 715 | The code definitions in this document replace those specified in RFC |
| 716 | 5336, following the guidance in Sections 3.5 and 3.7.4.2 of this |
| 717 | document, and based on RFC 5248 [RFC5248]. IANA has updated the |
| 718 | "Simple Mail Transfer Protocol (SMTP) Enhanced Status Code Registry" |
| 719 | with the following data: |
| 720 | |
| 721 | |
| 722 | |
| 723 | |
| 724 | |
| 725 | |
| 726 | |
| 727 | |
| 728 | |
| 729 | |
| 730 | Yao & Mao Standards Track [Page 13] |
| 731 | |
| 732 | RFC 6531 SMTP Extension for SMTPUTF8 February 2012 |
| 733 | |
| 734 | |
| 735 | Code: X.6.7 |
| 736 | Sample Text: Non-ASCII addresses not permitted for that |
| 737 | sender/recipient |
| 738 | Associated basic status code: 550, 553 |
| 739 | Description: This indicates the reception of a MAIL or RCPT command |
| 740 | that non-ASCII addresses are not permitted. |
| 741 | Defined: RFC 6531 (Standards Track) |
| 742 | Submitter: Jiankang YAO |
| 743 | Change controller: ima@ietf.org |
| 744 | |
| 745 | |
| 746 | Code: X.6.8 |
| 747 | Sample Text: UTF-8 string reply is required, but not permitted by |
| 748 | the SMTP client |
| 749 | Associated basic status code: 252, 550, 553 |
| 750 | Description: This indicates that a reply containing a UTF-8 string |
| 751 | is required to show the mailbox name, but that form of |
| 752 | response is not permitted by the SMTP client. |
| 753 | Defined: RFC 6531 (Standards Track) |
| 754 | Submitter: Jiankang YAO |
| 755 | Change controller: ima@ietf.org |
| 756 | |
| 757 | |
| 758 | Code: X.6.9 |
| 759 | Sample Text: UTF-8 header message cannot be transferred to one or |
| 760 | more recipients, so the message must be rejected |
| 761 | Associated basic status code: 550 |
| 762 | Description: This indicates that transaction failed after the |
| 763 | final "." of the DATA command. |
| 764 | Defined: RFC 6531 (Standards Track) |
| 765 | Submitter: Jiankang YAO |
| 766 | Change controller: ima@ietf.org |
| 767 | |
| 768 | |
| 769 | Code: X.6.10 |
| 770 | Description: This is a duplicate of X.6.8 and is thus deprecated. |
| 771 | |
| 772 | |
| 773 | |
| 774 | |
| 775 | |
| 776 | |
| 777 | |
| 778 | |
| 779 | |
| 780 | |
| 781 | |
| 782 | |
| 783 | |
| 784 | |
| 785 | |
| 786 | Yao & Mao Standards Track [Page 14] |
| 787 | |
| 788 | RFC 6531 SMTP Extension for SMTPUTF8 February 2012 |
| 789 | |
| 790 | |
| 791 | 4.3. WITH Protocol Types Sub-Registry of the Mail Transmission Types |
| 792 | Registry |
| 793 | |
| 794 | IANA has modified or added the following entries in the "WITH |
| 795 | protocol types" sub-registry under the "Mail Transmission Types" |
| 796 | registry. |
| 797 | |
| 798 | +--------------+------------------------------+---------------------+ |
| 799 | | WITH | Description | Reference | |
| 800 | | protocol | | | |
| 801 | | types | | | |
| 802 | +--------------+------------------------------+---------------------+ |
| 803 | | UTF8SMTP | ESMTP with SMTPUTF8 | [RFC6531] | |
| 804 | | UTF8SMTPA | ESMTP with SMTPUTF8 and AUTH | [RFC4954] [RFC6531] | |
| 805 | | UTF8SMTPS | ESMTP with SMTPUTF8 and | [RFC3207] [RFC6531] | |
| 806 | | | STARTTLS | | |
| 807 | | UTF8SMTPSA | ESMTP with SMTPUTF8 and both | [RFC3207] [RFC4954] | |
| 808 | | | STARTTLS and AUTH | [RFC6531] | |
| 809 | | UTF8LMTP | LMTP with SMTPUTF8 | [RFC6531] | |
| 810 | | UTF8LMTPA | LMTP with SMTPUTF8 and AUTH | [RFC4954] [RFC6531] | |
| 811 | | UTF8LMTPS | LMTP with SMTPUTF8 and | [RFC3207] [RFC6531] | |
| 812 | | | STARTTLS | | |
| 813 | | UTF8LMTPSA | LMTP with SMTPUTF8 and both | [RFC3207] [RFC4954] | |
| 814 | | | STARTTLS and AUTH | [RFC6531] | |
| 815 | +--------------+------------------------------+---------------------+ |
| 816 | |
| 817 | 5. Security Considerations |
| 818 | |
| 819 | The extended security considerations discussion in the framework |
| 820 | document [RFC6530] applies here. |
| 821 | |
| 822 | More security considerations are discussed below: |
| 823 | |
| 824 | Beyond the use inside the email global system (in SMTP envelopes and |
| 825 | message headers), internationalized email addresses will also show up |
| 826 | inside other cases, in particular: |
| 827 | |
| 828 | o the logging systems of SMTP transactions and other logs to monitor |
| 829 | the email systems; |
| 830 | |
| 831 | o the trouble ticket systems used by security teams to manage |
| 832 | security incidents, when an email address is involved; |
| 833 | |
| 834 | In order to avoid problems that could cause loss of data, this will |
| 835 | likely require extending these systems to support full UTF-8, or |
| 836 | require providing an adequate mechanism for mapping non-ASCII strings |
| 837 | to ASCII. |
| 838 | |
| 839 | |
| 840 | |
| 841 | |
| 842 | Yao & Mao Standards Track [Page 15] |
| 843 | |
| 844 | RFC 6531 SMTP Extension for SMTPUTF8 February 2012 |
| 845 | |
| 846 | |
| 847 | Another security aspect to be considered is related to the ability by |
| 848 | security team members to quickly understand, read, and identify email |
| 849 | addresses from the logs, when they are tracking an incident. |
| 850 | Mechanisms to automatically and quickly provide the origin or |
| 851 | ownership of an internationalized email address SHALL be implemented |
| 852 | for use by log readers that cannot easily read non-ASCII information. |
| 853 | |
| 854 | The SMTP commands VRFY and EXPN are sometimes used in SMTP |
| 855 | transactions where there is no message to transfer (by tools used to |
| 856 | take automated actions in case potential spam messages are |
| 857 | identified). Sections 3.5 and 7.3 of RFC 5321 give detailed |
| 858 | descriptions of use and possible behaviors. Implementation of |
| 859 | internationalized addresses can also affect logs and actions by these |
| 860 | tools. |
| 861 | |
| 862 | 6. Acknowledgements |
| 863 | |
| 864 | This document revises RFC 5336 [RFC5336] based on the result of the |
| 865 | Email Address Internationalization (EAI) working group's discussion. |
| 866 | Many EAI working group members did tests and implementations to move |
| 867 | this document to the Standards Track. Significant comments and |
| 868 | suggestions were received from Xiaodong LEE, Nai-Wen HSU, Yangwoo KO, |
| 869 | Yoshiro YONEYA, and other members of JET and were incorporated into |
| 870 | the specification. Additional important comments and suggestions, |
| 871 | and often specific text, were contributed by many members of the |
| 872 | working group and design team. Those contributions include material |
| 873 | from John C. Klensin, Charles Lindsey, Dave Crocker, Harald Tveit |
| 874 | Alvestrand, Marcos Sanz, Chris Newman, Martin Duerst, Edmon Chung, |
| 875 | Tony Finch, Kari Hurtta, Randall Gellens, Frank Ellermann, Alexey |
| 876 | Melnikov, Pete Resnick, S. Moonesamy, Soobok Lee, Shawn Steele, |
| 877 | Alfred Hoenes, Miguel Garcia, Magnus Westerlund, Joseph Yee, and Lars |
| 878 | Eggert. Of course, none of the individuals are necessarily |
| 879 | responsible for the combination of ideas represented here. |
| 880 | |
| 881 | Thanks a lot to Dave Crocker for his comments and helping with ABNF |
| 882 | refinement. |
| 883 | |
| 884 | 7. References |
| 885 | |
| 886 | 7.1. Normative References |
| 887 | |
| 888 | [ASCII] American National Standards Institute (formerly United |
| 889 | States of America Standards Institute), "USA Code for |
| 890 | Information Interchange", ANSI X3.4-1968, 1968. |
| 891 | |
| 892 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| 893 | Requirement Levels", BCP 14, RFC 2119, March 1997. |
| 894 | |
| 895 | |
| 896 | |
| 897 | |
| 898 | Yao & Mao Standards Track [Page 16] |
| 899 | |
| 900 | RFC 6531 SMTP Extension for SMTPUTF8 February 2012 |
| 901 | |
| 902 | |
| 903 | [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service |
| 904 | Extension for Delivery Status Notifications (DSNs)", |
| 905 | RFC 3461, January 2003. |
| 906 | |
| 907 | [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", |
| 908 | RFC 3463, January 2003. |
| 909 | |
| 910 | [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format |
| 911 | for Delivery Status Notifications", RFC 3464, |
| 912 | January 2003. |
| 913 | |
| 914 | [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO |
| 915 | 10646", RFC 3629, November 2003. |
| 916 | |
| 917 | [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types |
| 918 | Registration", RFC 3848, July 2004. |
| 919 | |
| 920 | [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax |
| 921 | Specifications: ABNF", STD 68, RFC 5234, January 2008. |
| 922 | |
| 923 | [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced |
| 924 | Mail System Status Codes", RFC 5248, June 2008. |
| 925 | |
| 926 | [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, |
| 927 | October 2008. |
| 928 | |
| 929 | [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, |
| 930 | October 2008. |
| 931 | |
| 932 | [RFC5890] Klensin, J., "Internationalizing Domain Names in |
| 933 | Applications (IDNA definitions)", RFC 5890, June 2010. |
| 934 | |
| 935 | [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP |
| 936 | Service Extension for 8-bit MIME Transport", STD 71, |
| 937 | RFC 6152, March 2011. |
| 938 | |
| 939 | [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", |
| 940 | STD 72, RFC 6409, November 2011. |
| 941 | |
| 942 | [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for |
| 943 | Internationalized Email", RFC 6530, February 2012. |
| 944 | |
| 945 | [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized |
| 946 | Email Headers", RFC 6532, February 2012. |
| 947 | |
| 948 | [RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, Ed., |
| 949 | "Internationalized Delivery Status and Disposition |
| 950 | Notifications", RFC RFC6533, February 2012. |
| 951 | |
| 952 | |
| 953 | |
| 954 | Yao & Mao Standards Track [Page 17] |
| 955 | |
| 956 | RFC 6531 SMTP Extension for SMTPUTF8 February 2012 |
| 957 | |
| 958 | |
| 959 | 7.2. Informative References |
| 960 | |
| 961 | [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, |
| 962 | October 1996. |
| 963 | |
| 964 | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail |
| 965 | Extensions (MIME) Part One: Format of Internet Message |
| 966 | Bodies", RFC 2045, November 1996. |
| 967 | |
| 968 | [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission |
| 969 | of Large and Binary MIME Messages", RFC 3030, |
| 970 | December 2000. |
| 971 | |
| 972 | [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over |
| 973 | Transport Layer Security", RFC 3207, February 2002. |
| 974 | |
| 975 | [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension |
| 976 | for Authentication", RFC 4954, July 2007. |
| 977 | |
| 978 | [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized |
| 979 | Email Addresses", RFC 5336, September 2008. |
| 980 | |
| 981 | [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, |
| 982 | July 2009. |
| 983 | |
| 984 | Authors' Addresses |
| 985 | |
| 986 | Jiankang YAO |
| 987 | CNNIC |
| 988 | No.4 South 4th Street, Zhongguancun |
| 989 | Beijing |
| 990 | China |
| 991 | |
| 992 | Phone: +86 10 58813007 |
| 993 | EMail: yaojk@cnnic.cn |
| 994 | |
| 995 | |
| 996 | Wei MAO |
| 997 | CNNIC |
| 998 | No.4 South 4th Street, Zhongguancun |
| 999 | Beijing |
| 1000 | China |
| 1001 | |
| 1002 | Phone: +86 10 58812230 |
| 1003 | EMail: maowei_ietf@cnnic.cn |
| 1004 | |
| 1005 | |
| 1006 | |
| 1007 | |
| 1008 | |
| 1009 | |
| 1010 | Yao & Mao Standards Track [Page 18] |
| 1011 | |