RFC 6531

SMTP Extension for Internationalized Email

📅 published February 2012, from ietf

RFC 6531: SMTP Extension for Internationalized Email 💌

Okay bestie, this is RFC 6531 🎀 from the Internet Engineering Task Force (IETF), and it's giving Standards Track, so it's the real deal 💅. It was written by J. Yao and W. Mao from CNNIC 🌸, published in February 2012 ✨, and it has ISSN 2070-1721. It obsoletes RFC 5336 🦋, so it's basically the glow-up of that older spec.

Abstract ✨

Okay so the whole point of this doc is an SMTP extension that lets email messages with internationalized email addresses or header information get transported and delivered 💌🫶

Status of This Memo 📜

This is an Internet Standards Track document ✨

This document is a product of the Internet Engineering Task Force (IETF) 🌈 It represents the consensus of the IETF community, and it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 If you want more info on Internet Standards, check out Section 2 of RFC 5741 🧚

Info about the current status of this document, any errata, and how to give feedback on it lives at http://www.rfc-editor.org/info/rfc6531 🍓

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the date this document was published. Please actually read these, bestie, because they spell out your rights and restrictions for this document 🙈 Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 💅

This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008 😭 The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from whoever controls that copyright, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process 🚫 The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🦋

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
  1.2.  Changes Made to Other Specifications . . . . . . . . . . .  3
2.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  4
3.  Mail Transport-Level Protocol  . . . . . . . . . . . . . . . .  4
  3.1.  Framework for the Internationalization Extension . . . . .  4
  3.2.  The SMTPUTF8 Extension . . . . . . . . . . . . . . . . . .  5
  3.3.  Extended Mailbox Address Syntax  . . . . . . . . . . . . .  7
  3.4.  MAIL Command Parameter Usage . . . . . . . . . . . . . . .  8
  3.5.  Non-ASCII Addresses and Reply-Codes  . . . . . . . . . . .  9
  3.6.  Body Parts and SMTP Extensions . . . . . . . . . . . . . .  9
  3.7.  Additional ESMTP Changes and Clarifications  . . . . . . . 10
    3.7.1.  The Initial SMTP Exchange  . . . . . . . . . . . . . . 10
    3.7.2.  Mail eXchangers  . . . . . . . . . . . . . . . . . . . 10
    3.7.3.  Trace Information  . . . . . . . . . . . . . . . . . . 11
    3.7.4.  UTF-8 Strings in Replies . . . . . . . . . . . . . . . 11
4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
  4.1.  SMTP Service Extensions Registry . . . . . . . . . . . . . 13
  4.2.  SMTP Enhanced Status Code Registry . . . . . . . . . . . . 13
  4.3.  WITH Protocol Types Sub-Registry of the Mail
        Transmission Types Registry  . . . . . . . . . . . . . . . 15
5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
  7.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
  7.2.  Informative References . . . . . . . . . . . . . . . . . . 18

1. Introduction 🌷

So this doc defines an extension to the Simple Mail Transfer Protocol [RFC5321] 💌 It lets servers advertise that they can accept and process internationalized email addresses (see Section 1.1) and internationalized email headers [RFC6532] ✨

There's an extended overview of the extension model for internationalized email addresses and email headers in RFC 6530 [RFC6530], which this spec calls "the framework document" 📚 To really get this spec, you need a solid understanding of that doc and of the base Internet email specs [RFC5321] [RFC5322] 🧠

1.1. Terminology 🔤

Okay so these are the special BCP 14 key words that the doc uses, and they're interpreted as described in RFC 2119 [RFC2119] 🫶 The key words are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 💅

"UTF-8 string" and "UTF-8 character" refer to Unicode characters, which may or may not be members of the ASCII subset, encoded in UTF-8 [RFC3629], which is a standard Unicode Encoding Form 🌈 Every other specialized term in this spec is defined either in the framework document or in the base Internet email specs. Specifically, "ASCII address", "internationalized email address", "non-ASCII address", "SMTPUTF8", "internationalized message", and "message" are used according to the definitions in the framework document [RFC6530] 🦋

Strings in this doc, including ASCII strings, MUST be expressed in UTF-8 💜

This spec uses Augmented BNF (ABNF) rules [RFC5234] 🍓 Some basic rules are identified in Section 3.3 as being defined, under the same names, in RFC 5234 [RFC5234], RFC 5321 [RFC5321], RFC 5890 [RFC5890], or RFC 6532 [RFC6532] ✨

1.2. Changes Made to Other Specifications 🔄

This spec extends some syntax rules from RFC 5321 and allows internationalized email addresses in the envelope and in trace fields, but it does not modify RFC 5321 🙌 It permits data formats from RFC 6532 [RFC6532], but it does not modify RFC 5322 💅 It does require that the 8BITMIME extension [RFC6152] be announced by the SMTPUTF8-aware SMTP server and used with BODY=8BITMIME by the SMTPUTF8-aware SMTP client, but it doesn't modify the 8BITMIME specification in any way 🎀

This spec replaces an earlier, experimental, approach to the same problem [RFC5336] 🧚 Section 6 of RFC 6530 [RFC6530] describes the changes in approach between RFC 5336 [RFC5336] and this spec. Anyone converting an implementation from the experimental spec to this one will need to review those changes carefully 👀

2. Overview of Operation 🗺️

This doc specifies one piece of the email internationalization work, namely the definition of an SMTP extension for internationalized email 💖 The extension is identified with the token SMTPUTF8 ✨

The internationalized email headers spec [RFC6532] gives the details of the email header features that this extension turns on 🌸

3. Mail Transport-Level Protocol 🚚

3.1. Framework for the Internationalization Extension 🎀

Here's the service extension being defined:

  1. The name of the SMTP service extension is "Internationalized Email" 💌
  2. The EHLO keyword value for this extension is SMTPUTF8 ✨
  3. No parameter values are defined for this EHLO keyword value 🙅 But to leave room for future (even if unanticipated) extensions, the EHLO response MUST NOT contain any parameters for this keyword. The SMTPUTF8-aware SMTP client MUST ignore any parameters that do appear for this keyword, which means it MUST behave as if those parameters aren't there 🫠 And if an SMTP server includes SMTPUTF8 in its EHLO response, it MUST be fully compliant with this version of this specification 💅
  4. One OPTIONAL parameter, SMTPUTF8, is added to the MAIL command. It doesn't accept a value. If it's set in the MAIL command, it means the SMTP client is SMTPUTF8-aware 🧚 Its presence also asserts that the envelope includes a non-ASCII address, that the message being sent is an internationalized message, or that the message being sent needs SMTPUTF8 support 👑
  5. The maximum length of a MAIL command line goes up by 10 characters to make room for the possible SMTPUTF8 parameter 📏
  6. One OPTIONAL parameter, SMTPUTF8, is added to the VERIFY (VRFY) and EXPAND (EXPN) commands. It doesn't accept a value either. It indicates that the SMTP client can accept Unicode characters in UTF-8 encoding in replies from the VRFY and EXPN commands 🦋
  7. No additional SMTP verbs are defined by this extension 🙂
  8. Servers offering this extension MUST provide support for, and announce, the 8BITMIME extension [RFC6152] 🫶
  9. The reverse-path and forward-path of the SMTP MAIL and RCPT commands are extended so they can use Unicode characters encoded in UTF-8 in mailbox names (addresses) 🌈
  10. The mail message body is extended as specified in RFC 6532 [RFC6532] 💜
  11. The SMTPUTF8 extension is valid on the submission port [RFC6409] 🍓 It may also be used with the Local Mail Transfer Protocol (LMTP) [RFC2033]. When these protocols are used, their use should be reflected in the trace field WITH keywords as appropriate [RFC3848] ✨

3.2. The SMTPUTF8 Extension 💅

Okay so, if an SMTP server announces SMTPUTF8, it MUST be prepared to accept a UTF-8 string [RFC3629] in any position where RFC 5321 says a <mailbox> can show up 🎀 Non-ASCII characters are allowed in the <local-part> too, but the parsing and the delimiters are exactly the same as the base email spec [RFC5321]. Nothing new there, just vibes 💖 Any domain name that's going to get looked up in the DNS MUST conform to and be processed as specified for Internationalizing Domain Names in Applications (IDNA) [RFC5890]. When doing lookups, the SMTPUTF8-aware SMTP client or server MUST either use a Unicode-aware DNS library, or transform the internationalized domain name to A-label form (i.e., a fully-qualified domain name that contains one or more A-labels but no U-labels) as specified in RFC 5890 [RFC5890] ✨

An SMTP client that gets the SMTPUTF8 extension keyword back in response to the EHLO command MAY transmit mailbox names within SMTP commands as internationalized strings in UTF-8 form 🦋 It MAY send a UTF-8 header [RFC6532] (which may also include mailbox names in UTF-8). It MAY transmit the domain parts of mailbox names within SMTP commands or the message header as A-labels or U-labels [RFC5890]. The presence of the SMTPUTF8 extension does not change the server-relaying behaviors described in RFC 5321 🌸

If the SMTP server doesn't offer the SMTPUTF8 extension, the SMTPUTF8-aware SMTP client MUST NOT transmit an internationalized email address, and it MUST NOT transmit a mail message containing internationalized mail headers as described in RFC 6532 [RFC6532] at any level within its MIME structure [RFC2045] 🙈 (For this paragraph, the internationalized domain name in A-label form as specified in IDNA definitions [RFC5890] is not considered to be "internationalized".) So if an SMTPUTF8-aware SMTP client (sender) tries to send an internationalized message and runs into a server that doesn't support the extension, the best move depends on other conditions. In particular:

  • If it is a Message Submission Agent (MSA) [RFC6409] [RFC5598], it MAY choose its own way to deal with this scenario using the wide discretion for changing addresses or otherwise fixing up and transforming messages allowed by RFC 6409. As long as the resulting message conforms to the requirements of RFC 5321 (i.e., without the SMTPUTF8 extension), the details of that transformation are outside the scope of this document. 🧚
  • If it is not an MSA, or is an MSA and does not choose to transform the message into one that doesn't require the SMTPUTF8 extension, it SHOULD reject the message. As usual, this can be done either by generating an appropriate reply during the SMTP transaction or by accepting the message and then generating and transmitting a non-delivery notification. If the latter choice is made, the notification process MUST conform to the requirements of RFC 5321, RFC 3464 [RFC3464], and RFC 6533 [RFC6533]. 💅
  • As specified in Section 2.2.3 of RFC 5321, an SMTP client with additional information and/or knowledge of special circumstances MAY choose to requeue the message and try later and/or try an alternate MX host as specified in that section. 🌈

This document applies when an SMTPUTF8-aware SMTP client or server supports the SMTPUTF8 extension. For all other cases, and for addresses and messages that don't require an SMTPUTF8 extension, SMTPUTF8-aware SMTP clients and servers don't change the behavior specified in RFC 5321 [RFC5321] 👑

If an SMTPUTF8-aware SMTP server advertises the Delivery Status Notification (DSN) [RFC3461] extension, it MUST implement RFC 6533 [RFC6533] 🔥

3.3. Extended Mailbox Address Syntax 🎀

RFC 5321, Section 4.1.2, defines the syntax of a <Mailbox> entirely in terms of ASCII characters. This document extends <Mailbox> to add support for non-ASCII characters ✨

The key changes made by this specification include:

  • The <Mailbox> ABNF rule is imported from RFC 5321 and updated in order to support the internationalized email address. Other related rules are imported from RFC 5321, RFC 5234, RFC 5890, and RFC 6532, or are extended in this document. 🦋
  • The definition of <sub-domain> is extended to permit both the RFC 5321 definition and a UTF-8 string in a DNS label that conforms with IDNA definitions [RFC5890]. 🌸
  • The definition of <atext> is extended to permit both the RFC 5321 definition and a UTF-8 string. That string MUST NOT contain any of the ASCII graphics or control characters. 🙈

The following ABNF rules imported from RFC 5321, Section 4.1.2, are updated directly or indirectly by this document:

  • <Mailbox>
  • <Local-part>
  • <Dot-string>
  • <Quoted-string>
  • <QcontentSMTP>
  • <Domain>
  • <Atom>

The following ABNF rule will be imported from RFC 6532, Section 3.1, directly:

  • <UTF8-non-ascii>

The following ABNF rule will be imported from RFC 5234, Appendix B.1, directly:

  • <DQUOTE>

The following ABNF rule will be imported from RFC 5890, Section 2.3.2.1, directly:

  • <U-label>

The following rules are extended in ABNF [RFC5234] as follows. 🧚

sub-domain   =/  U-label
 ; extend the definition of sub-domain in RFC 5321, Section 4.1.2

atext   =/  UTF8-non-ascii
 ; extend the implicit definition of atext in
 ; RFC 5321, Section 4.1.2, which ultimately points to
 ; the actual definition in RFC 5322, Section 3.2.3

qtextSMTP  =/ UTF8-non-ascii
 ; extend the definition of qtextSMTP in RFC 5321, Section 4.1.2

esmtp-value  =/ UTF8-non-ascii
 ; extend the definition of esmtp-value in RFC 5321, Section 4.1.2

3.4. MAIL Command Parameter Usage 💖

If the envelope or message being sent requires the capabilities of the SMTPUTF8 extension, the SMTPUTF8-aware SMTP client MUST supply the SMTPUTF8 parameter with the MAIL command. If this parameter is provided, it MUST not accept a value. If the SMTPUTF8-aware SMTP client knows that neither the envelope nor the message being sent requires any of the SMTPUTF8 extension capabilities, it SHOULD NOT supply the SMTPUTF8 parameter with the MAIL command 🌸

Because there's no guarantee that a next-hop SMTP server will support the SMTPUTF8 extension, using it always carries a risk of transmission failure 😭 In fact, during the early stages of deployment, the risk will be quite high. So there's a distinct near-term advantage for ASCII-only messages to be sent without using this extension. The long-term advantage of casting ASCII [ASCII] characters (0x7f and below) as UTF-8 form is that it permits pure-Unicode environments 🌈

3.5. Non-ASCII Addresses and Reply-Codes 🦋

An SMTPUTF8-aware SMTP client MUST NOT send an internationalized message to an SMTP server that does not support SMTPUTF8. If the SMTP server doesn't support this option, then the SMTPUTF8-aware SMTP client has three choices according to Section 3.2 of this specification 🙈

The three-digit reply-codes used in this section are based on their meanings as defined in RFC 5321 ✨

When messages are rejected because the RCPT command requires an ASCII address, the reply-code 553 is returned with the meaning "mailbox name not allowed". When messages are rejected because the MAIL command requires an ASCII address, the reply-code 550 is returned with the meaning "mailbox unavailable". When the SMTPUTF8-aware SMTP server supports enhanced mail system status codes [RFC3463], reply-code "X.6.7" [RFC5248] (see Section 4) is used, meaning "Non-ASCII addresses not permitted for that sender/recipient" 💅

When messages are rejected for other reasons, the server follows the model of the base email specification in RFC 5321. This extension does not change those circumstances or reply messages 🌸

If a message is rejected after the final "." of the DATA command because one or more recipients are unable to accept and process a message with internationalized email headers, the reply-code 554 is used with the meaning "Transaction failed". If the SMTPUTF8-aware SMTP server supports enhanced mail system status codes [RFC3463], reply code "X.6.9" [RFC5248] (see Section 4) is used to indicate this condition, meaning "UTF-8 header message cannot be transmitted to one or more recipients, so the message must be rejected" 😭

The SMTPUTF8-aware SMTP servers are encouraged to detect that recipients cannot accept internationalized messages and generate an error after the RCPT command, rather than waiting until after the DATA command to issue an error 🧚

3.6. Body Parts and SMTP Extensions 🎀

The MAIL command parameter SMTPUTF8 asserts that a message is an internationalized message or that the message being sent needs the SMTPUTF8 support. There is still a chance that a message being sent via the MAIL command with the SMTPUTF8 parameter is not an internationalized message. An SMTPUTF8-aware SMTP client or server that requires accurate knowledge of whether a message is internationalized needs to parse all message header fields and MIME header fields [RFC2045] in the message body. However, this specification does not require that the SMTPUTF8-aware SMTP client or server inspects the message 👑

Although this specification requires that SMTPUTF8-aware SMTP servers support the 8BITMIME extension [RFC6152] to ensure that servers have adequate handling capability for 8-bit data, it does not require non-ASCII body parts in the MIME message as specified in RFC 2045. The SMTPUTF8 extension MAY be used as follows (assuming it is appropriate given the body content):

  • with the BODY=8BITMIME parameter [RFC6152], or
  • with the BODY=BINARYMIME parameter, if the SMTP server advertises BINARYMIME [RFC3030]. 🦋

3.7. Additional ESMTP Changes and Clarifications 🌈

The information carried in the mail transport process involves addresses ("mailboxes") and domain names in various contexts, in addition to the MAIL and RCPT commands and extended alternatives to them. In general, the rule is that when RFC 5321 specifies a mailbox, this SMTP extension requires UTF-8 form to be used for the entire string. When RFC 5321 specifies a domain name, the internationalized domain name SHOULD be in U-label form if the SMTPUTF8 extension is supported; otherwise, it SHOULD be in A-label form 💖

The following subsections list and discuss all of the relevant cases. 🧚

3.7.1. The Initial SMTP Exchange 🌸

When an SMTP connection is opened, the SMTP server sends a "greeting" response consisting of the 220 reply-code and some information. The SMTP client then sends the EHLO command. Since the SMTP client can't know whether the SMTP server supports SMTPUTF8 until after it receives the response to the EHLO, the SMTPUTF8-aware SMTP client MUST send only ASCII (LDH label or A-label [RFC5890]) domains in the EHLO command. If the SMTPUTF8-aware SMTP server provides domain names in the EHLO response, they MUST be in the form of LDH labels or A-labels 🙈

3.7.2. Mail eXchangers 🔥

If multiple DNS MX records are used to specify multiple servers for a domain (as described in Section 5 of RFC 5321 [RFC5321]), it is strongly advised that all or none of them SHOULD support the SMTPUTF8 extension. Otherwise, unexpected rejections can happen during temporary or permanent failures, which users might perceive as serious reliability issues 😭

3.7.3. Trace Information 🦋

okay so the trace fields, <Return-path-line> and <Time-stamp-line>, plus their related rules, are defined in Section 4.4 of RFC 5321 [RFC5321]. this document updates <Mailbox> and <Domain> so they can handle non-ASCII characters 🌸 when the SMTPUTF8 extension is in use, the 'Reverse-path' clause of the Return-path-line may include an internationalized domain name in the U-label form. the 'Stamp' clause of the Time-stamp-line can do the same thing ✨

if messages with trace fields get sent by an SMTPUTF8-aware SMTP client or relay server, but the MAIL commands didn't include the SMTPUTF8 parameter, then the trace field values MUST conform to RFC 5321, no matter what the SMTP server can do 💅

when an SMTPUTF8-aware SMTP server adds a trace field to a message that was or will be sent with the SMTPUTF8 parameter in the MAIL commands, that server SHOULD use the U-label form for internationalized domain names in the new trace field 🫶

and the protocol value of the 'WITH' clause, when this extension is used, is one of the SMTPUTF8 values listed in the "IANA Considerations" section of this document 🎀

3.7.4. UTF-8 Strings in Replies 🌈

3.7.4.1. MAIL Command

okay this part is giving permission slip energy 😭 if an SMTP client follows this specification and sends any MAIL commands containing the SMTPUTF8 parameter, the SMTPUTF8-aware SMTP server is allowed to use UTF-8 characters in the email address tied to 251 and 551 reply-codes, and the SMTP client MUST be able to accept and process them 💖

if a MAIL command doesn't include the SMTPUTF8 parameter, then the SMTPUTF8-aware SMTP server MUST NOT return a 251 or 551 response with a non-ASCII mailbox. instead, it MUST turn those responses into 250 or 550 responses that don't contain non-ASCII addresses 🙈

3.7.4.2. VRFY and EXPN Commands and the SMTPUTF8 Parameter

ngl this one is so detailed 🤓 if the SMTPUTF8 parameter gets sent with the VRFY and EXPN commands, it tells the server the SMTP client can accept UTF-8 strings in replies to those commands 💜

the parameter with the VRFY and EXPN commands SHOULD only be used after the SMTP client sees the EHLO response with the SMTPUTF8 keyword. this lets an SMTPUTF8-aware SMTP server use UTF-8 strings in mailbox names and full names that show up in replies, without worrying that the client will get confused 🦋

an SMTP client that follows this specification MUST accept and correctly process replies to the VRFY and EXPN commands that contain UTF-8 strings. however, an SMTPUTF8-aware SMTP server MUST NOT use UTF-8 strings in replies if the SMTP client doesn't specifically allow them by sending this parameter with the VRFY and EXPN commands 🔥

most replies don't need a mailbox name in the returned text, so they don't need a UTF-8 string either. some replies, especially the ones from a successful VRFY or EXPN, do include the mailbox 🌸

the new command syntaxes for VRFY and EXPN are:

vrfy = "VRFY" SP String
  [ SP "SMTPUTF8" ] CRLF
 ; String may include Non-ASCII characters

expn = "EXPN" SP String
  [ SP "SMTPUTF8" ] CRLF
 ; String may include Non-ASCII characters

the SMTPUTF8 parameter doesn't take a value, fr 🧚 if the reply to a VRFY or EXPN command needs a UTF-8 string, but the SMTP client didn't use the SMTPUTF8 parameter, then the SMTPUTF8-aware SMTP server MUST use either the reply-code 252 or 550. reply-code 252, defined in RFC 5321 [RFC5321], means "Cannot VRFY user, but will accept the message and attempt the delivery". reply-code 550, also defined in RFC 5321 [RFC5321], means "Requested action not taken: mailbox unavailable" 💀 if the SMTPUTF8-aware SMTP server supports enhanced mail system status codes [RFC3463], then it uses the enhanced reply-code described below. using the SMTPUTF8 parameter with a VRFY or EXPN command enables UTF-8 replies for that command only 👑

if a normal success response (that's a 250) comes back, the response MAY include the user's full name and MUST include the user's mailbox. it MUST be in one of these two forms:

User Name <Mailbox>
 ; Mailbox is defined in Section 3.3 of this document.
 ; User Name can contain non-ASCII characters.

Mailbox
 ; Mailbox is defined in Section 3.3 of this document.

if the SMTP reply needs UTF-8 strings, but a UTF-8 string isn't allowed in the reply, and the SMTPUTF8-aware SMTP server supports enhanced mail system status codes [RFC3463], then the enhanced reply-code is "X.6.8" [RFC5248] (see Section 4). it means "A reply containing a UTF-8 string is required to show the mailbox name, but that form of response is not permitted by the SMTP client" 🙈

if an SMTP client doesn't support the SMTPUTF8 extension but still gets a UTF-8 string in a reply, it might not be able to report the reply to the user properly, and some clients might mishandle it. internationalized messages in replies are only allowed in the commands and situations described above 🌈

even though UTF-8 strings are needed to represent email addresses in responses under the rules in this section, this extension does not allow UTF-8 strings for any other purpose. SMTPUTF8-aware SMTP servers MUST NOT include non-ASCII characters in replies, except in the limited cases this section specifically permits 🛑💅

4. IANA Considerations ✨

4.1. SMTP Service Extensions Registry

IANA has added a new value "SMTPUTF8" to the "SMTP Service Extension" registry of the "Mail Parameters" registry, with the following data 🎀

+----------+---------------------------------+-----------+
| Keywords | Description                     | Reference |
+----------+---------------------------------+-----------+
| SMTPUTF8 | Internationalized email address | [RFC6531] |
+----------+---------------------------------+-----------+

4.2. SMTP Enhanced Status Code Registry

the code definitions in this document replace the ones specified in RFC 5336. they follow the guidance in Sections 3.5 and 3.7.4.2 of this document, and they're based on RFC 5248 [RFC5248] 🦋 IANA has updated the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Code Registry" with the following data:

 Code:        X.6.7
 Sample Text: Non-ASCII addresses not permitted for that
              sender/recipient
 Associated basic status code: 550, 553
 Description: This indicates the reception of a MAIL or RCPT command
              that non-ASCII addresses are not permitted.
 Defined:     RFC 6531 (Standards Track)
 Submitter:   Jiankang YAO
 Change controller: ima@ietf.org


 Code:        X.6.8
 Sample Text: UTF-8 string reply is required, but not permitted by
              the SMTP client
 Associated basic status code: 252, 550, 553
 Description: This indicates that a reply containing a UTF-8 string
              is required to show the mailbox name, but that form of
              response is not permitted by the SMTP client.
 Defined:     RFC 6531 (Standards Track)
 Submitter:   Jiankang YAO
 Change controller: ima@ietf.org


 Code:        X.6.9
 Sample Text: UTF-8 header message cannot be transferred to one or
              more recipients, so the message must be rejected
 Associated basic status code: 550
 Description: This indicates that transaction failed after the
              final "." of the DATA command.
 Defined:     RFC 6531 (Standards Track)
 Submitter:   Jiankang YAO
 Change controller: ima@ietf.org


 Code:        X.6.10
 Description: This is a duplicate of X.6.8 and is thus deprecated.

4.3. WITH Protocol Types Sub-Registry of the Mail Transmission Types Registry

IANA has modified or added the following entries in the "WITH protocol types" sub-registry under the "Mail Transmission Types" registry 💜

+--------------+------------------------------+---------------------+
| WITH         | Description                  | Reference           |
| protocol     |                              |                     |
| types        |                              |                     |
+--------------+------------------------------+---------------------+
| UTF8SMTP     | ESMTP with SMTPUTF8          | [RFC6531]           |
| UTF8SMTPA    | ESMTP with SMTPUTF8 and AUTH | [RFC4954] [RFC6531] |
| UTF8SMTPS    | ESMTP with SMTPUTF8 and      | [RFC3207] [RFC6531] |
|              | STARTTLS                     |                     |
| UTF8SMTPSA   | ESMTP with SMTPUTF8 and both | [RFC3207] [RFC4954] |
|              | STARTTLS and AUTH            | [RFC6531]           |
| UTF8LMTP     | LMTP with SMTPUTF8           | [RFC6531]           |
| UTF8LMTPA    | LMTP with SMTPUTF8 and AUTH  | [RFC4954] [RFC6531] |
| UTF8LMTPS    | LMTP with SMTPUTF8 and       | [RFC3207] [RFC6531] |
|              | STARTTLS                     |                     |
| UTF8LMTPSA   | LMTP with SMTPUTF8 and both  | [RFC3207] [RFC4954] |
|              | STARTTLS and AUTH            | [RFC6531]           |
+--------------+------------------------------+---------------------+

5. Security Considerations 🔐

this is the serious part, bestie, so pay attention 😭 the extended security considerations discussion in the framework document [RFC6530] applies here 🛡️

there are more security considerations too. beyond use inside the email global system (in SMTP envelopes and message headers), internationalized email addresses will also show up in other places, especially:

  • the logging systems of SMTP transactions and other logs used to monitor email systems;
  • the trouble ticket systems that security teams use to manage security incidents when an email address is involved;

to avoid problems that could cause data loss, this will likely require extending these systems to support full UTF-8, or providing an adequate mechanism for mapping non-ASCII strings to ASCII 🧐

another security aspect is the ability of security team members to quickly understand, read, and identify email addresses in logs while they're tracking an incident 👀 mechanisms that automatically and quickly provide the origin or ownership of an internationalized email address SHALL be implemented for use by log readers that can't easily read non-ASCII information 🚨

the SMTP commands VRFY and EXPN are sometimes used in SMTP transactions where there's no message to transfer (by tools that take automated actions when potential spam messages are identified). Sections 3.5 and 7.3 of RFC 5321 give detailed descriptions of their use and possible behaviors. implementing internationalized addresses can also affect the logs and actions of these tools 💀

6. Acknowledgements 🫶✨

okay bestie, this section is basically the big thank-you list 💖 This document revises RFC 5336 [RFC5336] based on what the Email Address Internationalization (EAI) working group talked through. Loads of EAI working group members ran tests and built implementations to get this document onto the Standards Track 🚀 Super helpful comments and suggestions came from Xiaodong LEE, Nai-Wen HSU, Yangwoo KO, Yoshiro YONEYA, and other members of JET, and they got folded right into the spec 🎀 Even more important comments and suggestions, and often whole chunks of actual text, came from a ton of working group and design team folks. That includes material from John C. Klensin, Charles Lindsey, Dave Crocker, Harald Tveit Alvestrand, Marcos Sanz, Chris Newman, Martin Duerst, Edmon Chung, Tony Finch, Kari Hurtta, Randall Gellens, Frank Ellermann, Alexey Melnikov, Pete Resnick, S. Moonesamy, Soobok Lee, Shawn Steele, Alfred Hoenes, Miguel Garcia, Magnus Westerlund, Joseph Yee, and Lars Eggert 🌸 Of course, none of these individuals is necessarily responsible for the combination of ideas that ended up here, so no pinning the blame on anyone 🙈

Thanks a lot to Dave Crocker for his comments and for helping with the ABNF refinement 💅🌈

7. References 📚

7.1. Normative References 💜

  • [ASCII]: American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968.
  • [RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3461]: Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
  • [RFC3463]: Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
  • [RFC3464]: Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
  • [RFC3629]: Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, November 2003.
  • [RFC3848]: Newman, C., "ESMTP and LMTP Transmission Types Registration", RFC 3848, July 2004.
  • [RFC5234]: Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
  • [RFC5248]: Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail System Status Codes", RFC 5248, June 2008.
  • [RFC5321]: Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
  • [RFC5322]: Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
  • [RFC5890]: Klensin, J., "Internationalizing Domain Names in Applications (IDNA definitions)", RFC 5890, June 2010.
  • [RFC6152]: Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, March 2011.
  • [RFC6409]: Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011.
  • [RFC6530]: Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012.
  • [RFC6532]: Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, February 2012.
  • [RFC6533]: Hansen, T., Ed., Newman, C., and A. Melnikov, Ed., "Internationalized Delivery Status and Disposition Notifications", RFC RFC6533, February 2012.

7.2. Informative References 🦋

  • [RFC2033]: Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.
  • [RFC2045]: Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
  • [RFC3030]: Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.
  • [RFC3207]: Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
  • [RFC4954]: Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.
  • [RFC5336]: Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008.
  • [RFC5598]: Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.

Authors' Addresses 🌟

Jiankang YAO CNNIC No.4 South 4th Street, Zhongguancun Beijing China

Phone: +86 10 58813007 EMail: yaojk@cnnic.cn

Wei MAO CNNIC No.4 South 4th Street, Zhongguancun Beijing China

Phone: +86 10 58812230 EMail: maowei_ietf@cnnic.cn

That's the whole spec, bestie! 🌈✨ RFC 6531 is a wrap 💅👑

📦 where this page comes from