RFC 5336
SMTP Extension for Internationalized Email Addresses
RFC 5336: SMTP Extension for Internationalized Email Addresses 🎀
Okay bestie, this one is RFC 5336 from the Network Working Group 💌. It was written by J. Yao, Ed. and W. Mao, Ed., both from CNNIC 🌏. It's labelled Experimental and dated September 2008 📅. It updates RFC 2821, RFC 2822 and RFC 4952, and it doesn't obsolete anything 🧁.
Status of This Memo ✨
So this memo defines an Experimental Protocol for the Internet community 🧪. It is not an Internet standard of any kind. They're literally asking for discussion and suggestions for improvement 🙏, and the memo can be distributed freely with no limits 🦋.
Abstract 🌸
This document is all about an SMTP extension for moving email messages around, both transporting and delivering them, when the addresses or header info are internationalized 💅. If a system doesn't implement this spec, the details of how it talks to those systems live in a different document 📄. This one updates some syntaxes and rules from RFC 2821 and RFC 2822, and it also has some material that updates RFC 4952 🔥.
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Role of This Specification . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4
3. Mail Transport-Level Protocol . . . . . . . . . . . . . . . . 4
3.1. Framework for the Internationalization Extension . . . . . 4
3.2. The UTF8SMTP Extension . . . . . . . . . . . . . . . . . . 5
3.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 7
3.4. The ALT-ADDRESS Parameter . . . . . . . . . . . . . . . . 9
3.5. ALT-ADDRESS Parameter Usage and Response Codes . . . . . . 10
3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 11
3.7. Additional ESMTP Changes and Clarifications . . . . . . . 11
3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 12
3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 12
3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 12
3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Material Updating RFC 4952 . . . . . . . . . . . . . 20
A.1. Conventional Message and Internationalized Message . . . . 20
A.2. LMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
A.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 20
A.4. Implementation Advice . . . . . . . . . . . . . . . . . . 20
A.5. Applicability of SMTP Extension to Additional Uses . . . . 211. Introduction 💖
Okay so an internationalized email address has two parts, the local part and the domain part 💅. Email addresses get used by protocols in different ways than domain names do, and the biggest difference is that email gets delivered through a whole chain of clients and servers 🚚. Domain names, on the other hand, are resolved by name servers that just look things up in their own tables 📋. On top of that, the Simple Mail Transfer Protocol [RFC2821] has a negotiation mechanism for service extensions, so clients can figure out what the server can do and make decisions from there 🧠. The extended overview of the extension model for internationalized addresses and headers is in [RFC4952], which is called "the framework document" or just "Framework" later in this spec 🖼️. So this document defines an SMTP extension that lets internationalized email addresses go in envelopes, plus UNICODE characters (encoded in UTF-8) [RFC3629] in headers 🌈.
1.1. Role of This Specification 🎀
The framework document is the one that lays out the requirements for, and describes the components of, full internationalization of electronic mail 🗺️. You really need to understand that document and the base Internet email specifications [RFC2821] [RFC2822] before you can understand and implement this spec, so don't skip them 📚.
This document covers one piece of the email internationalization work 🧩. Specifically, it defines an SMTP extension [RFC2821] for transport and delivery of internationalized email addresses 📨.
1.2. Terminology 🦋
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🔑.
The terms "conventional message" and "internationalized message" are defined in an appendix to this spec 📎. "UTF-8 string" or "UTF-8 character" is used informally to mean Unicode characters encoded in UTF-8 [RFC3629] 🍓. Every other specialized term is defined in the framework document or in the base Internet email specifications [RFC2821] [RFC2822] 📖. In particular, "ASCII address", "internationalized email address", "non-ASCII address", "i18mail address", "UTF8SMTP", "message", and "mailing list" all mean what the framework document says they mean 🫶.
This spec only defines the Augmented BNF (ABNF) [RFC5234] rules that are different from the base email specifications [RFC2821][RFC2822] 🧮. When a rule gets upgraded or extended, it gets a new name too 🏷️. If the new rule is a small tweak of the older one, its name typically starts with "u" ✨. Any rules that aren't defined here may be found in the base email specifications under the same names 🔍.
2. Overview of Operation 🌷
This spec describes an optional extension to the email transport mechanism 💫. It lets non-ASCII [ASCII] characters show up in both the envelope and the header fields of messages, and those characters are encoded with UTF-8 [RFC3629] 🌏. The extension is identified by the token UTF8SMTP 🏷️. To give information that might be needed for downgrading, an optional alternate ASCII address may be needed if an SMTP client tries to transfer an internationalized message and runs into a server that doesn't support this extension 🙈.
The EAI UTF-8 header specification [RFC5335] gives all the details on how and where non-ASCII characters are allowed in the header fields of messages 📜. The context for all of this is in the framework document 🧚.
3. Mail Transport-Level Protocol 🚀
3.1. Framework for the Internationalization Extension 🧸
Here's the service extension that gets defined:
- The name of the SMTP service extension is "Email Address Internationalization" 🏷️.
- The EHLO keyword value for this extension is
UTF8SMTP💌. - No parameter values are defined for this EHLO keyword value 🙅. But in order to allow future (even if unanticipated) extensions, the EHLO response MUST NOT contain any parameters for that keyword 🚫. Clients MUST ignore any parameters, which means clients MUST behave as if those parameters don't appear at all 👀. And if a server puts
UTF8SMTPin its EHLO response, it MUST be fully compliant with this version of the specification 💯. - One optional parameter,
ALT-ADDRESS, gets added to the MAIL and RCPT commands of SMTP 🎁.ALT-ADDRESSspecifies an all-ASCII address that can be used as a substitute for the matching primary (i18mail) address when downgrading 🔄. More discussion of how to use this parameter is in [RFC4952] and [Downgrade] 📚. - One optional parameter, "UTF8REPLY", gets added to the VRFY and EXPN commands 🌸. The UTF8REPLY parameter has no value. What it does is say the SMTP client can accept Unicode characters in UTF-8 encoding in replies from VRFY and EXPN commands 💜.
- No additional SMTP verbs are defined by this extension 🙌.
- Servers offering this extension MUST provide support for, and announce, the 8BITMIME extension [RFC1652] 📢.
- The reverse-path and forward-path of the SMTP MAIL and RCPT commands are extended so they can carry Unicode characters encoded in UTF-8 in mailbox names (addresses) 🌈.
- The mail message body is extended as specified in [RFC5335] 🦋.
- The maximum length of MAIL and RCPT command lines goes up by 460 characters, because the
ALT-ADDRESSkeyword and value might get added 📏. - The UTF8SMTP extension is valid on the submission port [RFC4409] 📮✨.
3.2. The UTF8SMTP Extension 💖
Okay bestie, so an SMTP server that announces this extension MUST be prepared to accept a UTF-8 string [RFC3629] in any spot where RFC 2821 says a mailbox can show up 🦋. That string MUST be parsed only the way RFC 2821 describes, which means splitting the mailbox into source route, local part, and domain part, using only the colon (U+003A), comma (U+002C), and at-sign (U+0040) like it says there ✨. Once it's been isolated, the local part MUST be treated as opaque unless the SMTP server is the final delivery Mail Transfer Agent (MTA) 🫶. Any domain names that need a DNS lookup MUST first be processed into the form from "Internationalizing Domain Names in Applications (IDNA)" [RFC3490], using the ToASCII() operation, unless they're already in that form 🌸. Any domain names that are going to be compared to local strings SHOULD be checked for validity first, and then MUST be compared as specified in Section 3.4 of IDNA 💅.
An SMTP client that gets the UTF8SMTP extension keyword back in response to the EHLO command MAY send mailbox names inside SMTP commands as internationalized strings in UTF-8 form 🎀. It MAY send a UTF-8 header [RFC5335], which can also include mailbox names in UTF-8 🌈. It MAY send the domain parts of mailbox names, whether inside SMTP commands or in the message header, as either ACE (ASCII Compatible Encoding) labels (as specified in IDNA [RFC3490]) or as UTF-8 strings 🍓. Every label in a domain part that is an IDN (either a UTF-8 or ACE string) MUST be valid 😭. If the original client submits a message to a Message Submission Server ("MSA") [RFC4409], then it's the MSA's job to make sure all domain labels are valid. Otherwise, that job belongs to the original client 👑. Having the UTF8SMTP extension doesn't change the RFC 2821 rule that servers relaying mail MUST NOT attempt to parse, evaluate, or transform the local part in any way 🔥.
If the UTF8SMTP SMTP extension isn't offered by the server, the SMTP client MUST NOT transmit an internationalized address, and MUST NOT transmit a mail message containing internationalized mail headers as described in [RFC5335] at any level within its MIME structure 🙈. (For this paragraph, an internationalized domain name written as ACE labels from IDNA [RFC3490] doesn't count as "internationalized".) Instead, if an SMTP client (SMTP sender) tries to send an internationalized message and runs into a server that doesn't support the extension, it MUST make one of the following four choices 💀:
- If and only if the SMTP client (sender) is a Message Submission Server ("MSA") [RFC4409], it MAY, consistent with the general provisions for changes by such servers, rewrite the envelope, headers, or message material so they're entirely ASCII and consistent with the provisions of RFC 2821 [RFC2821] and RFC 2822 [RFC2822] ✨.
- It may either reject the message during the SMTP transaction, or accept the message and then generate and send a notification of non-deliverability. That notification MUST be done as specified in RFC 2821 [RFC2821], RFC 3464 [RFC3464], and the EAI delivery status notification (DSN) specification [RFC5337] 🦋.
- It may find an alternate route to the destination that permits UTF8SMTP. That route can be discovered by trying alternate Mail eXchanger (MX) hosts (using the preference rules from RFC 2821), or by using other means available to the SMTP-sender 🧚.
- If and only if ASCII addresses are available for every address that shows up in the return path and the specific forward paths being attempted, it may downgrade the message to an all-ASCII form as specified in [Downgrade]. An ASCII address counts as "available" for a particular address if the original address in the envelope is already ASCII, or if an ALT-ADDRESS parameter is specified for a UTF8SMTP address 💜.
The difference between choice 1 and choice 4 is that choice 1 is constrained by Message Submission [RFC4409], while choice 4 is constrained by [Downgrade] 🌸.
3.3. Extended Mailbox Address Syntax 🎀
RFC 2821, Section 4.1.2, defines the syntax of a mailbox entirely in terms of ASCII characters, using the production for a mailbox and the productions it depends on 💅.
Informally, the key changes this specification makes are to:
- Change the definition of "sub-domain" so it can be either the definition above or a UTF-8 string representing a DNS label that conforms to IDNA [RFC3490] ✨.
- Change the definition of "Atom" so it can be either the definition above or a UTF-8 string. That string MUST NOT contain any of the ASCII characters (graphics or controls) that aren't allowed in "atext", but other than that it's totally unrestricted 🔥.
Based on the description above, the syntax of an internationalized email mailbox name (address) is defined in ABNF [RFC5234] like this 🦋:
uMailbox = uLocal-part "@" uDomain
; Replace Mailbox in RFC 2821, Section 4.1.2
uLocal-part = uDot-string / uQuoted-string
; MAY be case-sensitive
; Replace Local-part in RFC 2821, Section 4.1.2
uDot-string = uAtom *("." uAtom)
; Replace Dot-string in RFC 2821, Section 4.1.2
uAtom = 1*ucharacter
; Replace Atom in RFC 2821, Section 4.1.2
ucharacter = atext / UTF8-non-ascii
atext = <See Section 3.2.4 of RFC 2822>
uQuoted-string = DQUOTE *uqcontent DQUOTE
; Replace Quoted-string in RFC 2821, Section 4.1.2
DQUOTE = <See appendix B.1 of RFC 5234>
uqcontent = qcontent / UTF8-non-ascii
qcontent = <See Section 3.2.5 of RFC 2822>
uDomain = (sub-udomain 1*("." sub-udomain)) / address-literal
; Replace Domain in RFC 2821, Section 4.1.2
address-literal = <See Section 4.1.2 of RFC 2822>
sub-udomain = uLet-dig [uLdh-str]
; Replace sub-domain in RFC 2821, Section 4.1.2
uLet-dig = Let-dig / UTF8-non-ascii
Let-dig = <See Section 4.1.3 of RFC 2821>
uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-non-ascii) uLet-dig
; Replace Ldh-str in RFC 2821, Section 4.1.3
UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = <See Section 4 of RFC 3629>
UTF8-3 = <See Section 4 of RFC 3629>
UTF8-4 = <See Section 4 of RFC 3629>The value of "uDomain" SHOULD be verified by applying the tests specified as part of IDNA [RFC3490]. If that verification fails, then the email address with that uDomain MUST NOT be regarded as a valid email address 😭.
3.4. The ALT-ADDRESS Parameter 🧚
If the UTF8SMTP extension is offered, the syntax of the SMTP MAIL and RCPT commands gets extended to support the optional esmtp-keyword "ALT-ADDRESS" 🌈. That keyword specifies an alternate all-ASCII address that may be used when downgrading. If the ALT-ADDRESS esmtp-keyword is used, it MUST have an associated esmtp-value (ALT-ADDRESS-esmtp-value, which is defined below) 💖.
It might be tempting to think of ALT-ADDRESS as a general-purpose second-chance address, but that behavior is not defined here 🙈. Instead, in this specification ALT-ADDRESS only has meaning when the associated primary address is non-ASCII and the message is downgraded. This restriction leaves room for future extension of the specification, even though no such extensions are currently anticipated 🍓.
Based on the definition of mail-parameters in [RFC2821], the ALT-ADDRESS parameter usage in the MAIL and RCPT commands is defined as follows. These definitions are written in the same format RFC 2821 uses 💜.
"MAIL FROM:" ("<>" / uReverse-path) [ SP Mail-parameters ] CRLF
; Update the MAIL command in RFC 2821, Section 4.1.1.2.
; A new parameter defined by the ABNF non-terminal
; <ALT-ADDRESS-parameter> is added. It complies
; with the syntax specified for <esmtp-param> in RFC 2821.
"RCPT TO:" ("<Postmaster@" uDomain ">" / "<Postmaster>" /
uForward-path) [ SP Rcpt-parameters ] CRLF
; Update RCPT command in RFC 2821, Section 4.1.1.3.
; A new parameter defined by the ABNF non-terminal
; <ALT-ADDRESS-parameter> is added. It complies
; with the syntax specified for <esmtp-param>.
; uDomain is defined in Section 3.3 of this document.
uReverse-path = uPath
; Replace Reverse-path in RFC 2821, Section 4.1.2.
uForward-path = uPath
; Replace Forward-path in RFC 2821, Section 4.1.2.
uPath = "<" [ A-d-l ":" ] uMailbox ">"
; Replace Path in RFC 2821, Section 4.1.2.
; uMailbox is defined in Section 3.3 of this document.
A-d-l = <See Section 4.1.2 of RFC 2821>
ALT-ADDRESS-parameter = "ALT-ADDRESS=" ALT-ADDRESS-value
ALT-ADDRESS-value = xtext
; The value is a mailbox name encoded as xtext.
xtext = <See Section 4.2 of RFC 3461>The ALT-ADDRESS-parameter MUST NOT appear more than once in any MAIL or RCPT command. ALT-ADDRESS-esmtp-value MUST be an all-ASCII email address before xtext encoding 🫶.
3.5. ALT-ADDRESS Parameter Usage and Response Codes 👑
An "internationalized message" (as defined in the appendix of this specification) MUST NOT be sent to an SMTP server that doesn't support UTF8SMTP 🔥. Such a message MAY be rejected by a server if it lacks ALT-ADDRESSes, as discussed in Section 3.2 of this specification 🌸.
The three-digit reply codes used in this section mean what RFC 2821 says they mean 💅.
When messages are rejected because the RCPT command needs an ALT-ADDRESS, the response code 553 is used, meaning "mailbox name not allowed" 🦋. When messages are rejected for other reasons, like the MAIL command needing an ALT-ADDRESS, the response code 550 is used, meaning "mailbox unavailable" 😭. When the server supports enhanced mail system status codes [RFC3463], the response code X.6.7 [RFC5248] is used, meaning that "The ALT-ADDRESS is required but not specified" ✨.
If the response code is issued after the final "." of the DATA command, the response code 554 is used, meaning "Transaction failed" 💀. When the server supports enhanced mail system status codes [RFC3463], the response code X.6.9 [RFC5248] is used, meaning that "UTF8SMTP downgrade failed" 🫶.
3.6. Body Parts and SMTP Extensions ✨
Okay bestie, tea incoming ☕ there is literally no ESMTP parameter that says "hey, this message is internationalized" 🙈 So if an SMTP server really needs to know whether a message is internationalized, it is required to parse all message header fields and MIME header fields in the message body. Every single one 💀
This spec says servers have to support the 8BITMIME extension [RFC1652]. That way they can handle 8-bit data and dodge a pile of complicated encoding problems 🧩 Using internationalized addresses obviously doesn't mean the MIME message has to have non-ASCII body parts, though. The UTF8SMTP extension MAY be used with the BODY=8BITMIME parameter if that fits the body content, or with the BODY=BINARYMIME parameter if the server advertises BINARYMIME [RFC3030] and that fits too 🦋
So, assuming the server advertises UTF8SMTP and 8BITMIME and gets at least one non-ASCII address (with or without ALT-ADDRESS), here's the precise lowdown on what "No BODY parameter", "BODY=8BITMIME", and "BODY=BINARYMIME" mean in the MAIL command:
- If there is no BODY parameter, the header has UTF-8 characters, but all the body parts are ASCII (maybe because of a content-transfer-encoding) 🌸
- If there's a BODY=8BITMIME parameter, the header has UTF-8 characters, and some or all of the body parts contain 8-bit line-oriented data 💜
- If there's a BODY=BINARYMIME parameter, the header has UTF-8 characters, and some or all body parts contain binary data with no restrictions on line lengths or delimiters 🔥
3.7. Additional ESMTP Changes and Clarifications 🎀
The mail transport process carries addresses ("mailboxes") and domain names in lots of places, not just the MAIL and RCPT commands and their extended alternatives. The general rule is this: when RFC 2821 specifies a mailbox, this specification expects UTF-8 to be used for the entire string. When RFC 2821 specifies a domain name, the name SHOULD be in the form of ACE labels if its raw form is non-ASCII 💅
The following subsections list and discuss all of the relevant cases 👑
3.7.1. The Initial SMTP Exchange 🌈
When an SMTP connection opens, the server normally sends a "greeting" response made of the 220 response code and some info. Then the client sends the EHLO command. Here's the catch: the client can't know whether the server supports UTF8SMTP until it gets the response to EHLO. So any domain names that show up in this dialogue, or in responses to EHLO, MUST be in the hostname form. Put another way, internationalized ones MUST be in the form of ACE labels ✨
3.7.2. Mail eXchangers 💌
Organizations often authorize multiple servers to accept their mail. The organization might run more than one server itself, or it might have an agreement with other organizations to take mail as a backup 🫶 Authorized servers are generally listed in MX records, as described in RFC 2821. When more than one server accepts mail for the domain-part of a mailbox, it is strongly advised that either all or none of them support the UTF8SMTP extension. Otherwise, surprising downgrades can happen during temporary failures, and users might see that as a serious reliability issue 😭
3.7.3. Trace Information 🕵️♀️
When an SMTP server receives a message for delivery or further processing, it MUST insert trace ("time stamp" or "Received") information at the beginning of the message content. That info shows up as "Received:" lines, and the biggest reason they exist is debugging mail faults 🔍 When the delivery SMTP server makes the "final delivery" of a message, it inserts a Return-path line at the beginning of the mail data. The Return-path's main job is to name the address where non-delivery notices and other mail system failures get sent 📬 For the trace info, this memo updates the time stamp line and the return path line [RFC2821]. Here's how they're formally defined now:
uReturn-path-line = "Return-Path:" FWS uReverse-path <CRLF>
; Replaces Return-path-line in Section 4.4 of RFC 2821
; uReverse-path is defined in Section 3.3 of this document
uTime-stamp-line = "Received:" FWS uStamp <CRLF>
; Replaces Time-stamp-line in Section 4.4 of RFC 2821
uStamp = From-domain By-domain uOpt-info ";" FWS date-time
; Replaces Stamp in Section 4.4 of RFC 2821
uOpt-info = [Via] [With] [ID] [uFor]
; Replaces Opt-info in Section 4.4 of RFC 2821
; The protocol value for With will allow a UTF8SMTP value
uFor = "FOR" ( FWS (uPath / uMailbox) ) CFWS
; Replaces For in Section 4.4 of RFC 2821
; uPath and uMailbox are defined in Sections 2.4 and
; 2.3, respectively, of this documentNote: The FOR parameter has been changed to match the definition in [RFC2821bis], so it only permits one address in the For clause 🙅♀️ The group working on that document reached mailing list consensus that the RFC 2821 syntax allowing more than one address was simply a mistake. Oops 🙈
Except in the 'uFor' clause and the 'uReverse-path' value, where non-ASCII domain names may be used, internationalized domain names in Received fields MUST be transmitted in the form of ACE labels. When this extension is used, the protocol value of the WITH clause is one of the UTF8SMTP values listed in the "IANA Considerations" section of this document 🌸
3.7.4. UTF-8 Strings in Replies 💬
3.7.4.1. MAIL and RCPT Commands 💖
If the client issues a RCPT command containing non-ASCII characters, the SMTP server is permitted to use UTF-8 characters in the email address associated with 251 and 551 response codes 🦋
If an SMTP client follows this specification and sends any RCPT commands containing non-ASCII addresses, it MUST be able to accept and process 251 or 551 responses containing UTF-8 email addresses. Now, if a given RCPT command does not include a non-ASCII envelope address, the server MUST NOT return a 251 or 551 response containing a non-ASCII mailbox. Instead, it MUST transform such responses into 250 or 550 responses that do not contain addresses 🧚
3.7.4.2. VRFY and EXPN Commands and the UTF8REPLY Parameter 🔮
If the VRFY and EXPN commands are sent with an optional "UTF8REPLY" parameter, it means the client can accept UTF-8 strings in replies to those commands. This lets the server put UTF-8 strings in mailbox names and full names in replies without worrying that the client will get confused 🌈 An SMTP client that conforms to this specification MUST accept and correctly process replies from the VRFY and EXPN commands that contain UTF-8 strings. But here's the key bit: the SMTP server MUST NOT use UTF-8 strings in replies if the SMTP client doesn't specifically allow them by sending this parameter. Most replies don't need a mailbox name in the returned text, so UTF-8 isn't needed there. Some replies, though, especially the ones from successfully executing VRFY and EXPN, do include the mailbox, which is why this section matters so much 😤
VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to:
"VRFY" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF
; uLocal-part and uMailbox are defined in
; Section 3.3 of this document.
"EXPN" SP ( uLocal-part / uMailbox ) [ SP "UTF8REPLY" ] CRLF
; uLocal-part and uMailbox are defined in
; Section 3.3 of this document.The "UTF8REPLY" parameter doesn't take a value. If the reply to a VERIFY (VRFY) or EXPAND (EXPN) command needs UTF-8, but the SMTP client doesn't use the "UTF8REPLY" parameter, then the server MUST use either the response code 252 or 550. Response code 252, defined in [RFC2821], means "Cannot VRFY user, but will accept the message and attempt the delivery". Response code 550, also defined in [RFC2821], means "Requested action not taken: mailbox unavailable". When the server supports enhanced mail system status codes [RFC3463], it uses the enhanced response code specified below. Using the "UTF8REPLY" parameter with a VERIFY (VRFY) or EXPAND (EXPN) command turns on UTF-8 replies for that command only 🎀
If a normal success response (i.e., 250) comes back, the response MAY include the full name of the user, and it MUST include the mailbox of the user. It MUST be in either of the following forms:
User Name <uMailbox>
; uMailbox is defined in Section 3.3 of this document.
; User Name can contain non-ASCII characters.
uMailbox
; uMailbox is defined in Section 3.3 of this document.If the SMTP reply needs UTF-8 strings, but UTF-8 isn't allowed in the reply, and the server supports enhanced mail system status codes [RFC3463], the enhanced response code is either "X.6.8" or "X.6.10" [RFC5248]. That 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 client" 🙃
If the SMTP client doesn't support the UTF8SMTP extension but gets a UTF-8 string in a reply, it may not be able to report the reply properly to the user, and some clients might crash 💀 Internationalized messages in replies are only allowed in the commands and situations described above. In any other circumstance, UTF-8 text MUST NOT appear in the reply.
Even though UTF-8 is needed to represent email addresses in responses under the rules in this section, this extension doesn't allow UTF-8 for any other purpose. SMTP servers MUST NOT include non-ASCII characters in replies, except in the limited cases this section specifically permits 🌸✨
4. IANA Considerations ✨
okay so IANA gets a little homework here, bestie 📋🎀 They're adding a brand new UTF8SMTP keyword to the SMTP Service Extension subregistry of the Mail Parameters registry. Here's the entry:
+----------+---------------------------------+-----------+
| Keywords | Description | Reference |
+----------+---------------------------------+-----------+
| UTF8SMTP | Internationalized email address | [RFC5336] |
+----------+---------------------------------+-----------+Next up, the SMTP Enhanced Status Code subregistry gets four new codes 💅 This follows the guidance in Sections 3.5 and 3.7.4.2 of this document, and it's built on [RFC5248]. Here's the tea on each one:
Code: X.6.7
Sample Text: The ALT-ADDRESS is required but not specified
Associated basic status code: 553, 550
Description: This indicates the reception of a MAIL or RCPT
command that required an ALT-ADDRESS parameter
but such parameter was not present.
Defined: RFC 5336 (Experimental track)
Submitter: Jiankang YAO
Change controller: IESG.Code: X.6.8
Sample Text: UTF-8 string reply is required,
but not permitted by the client
Associated basic status code: 553, 550
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 client.
Defined: RFC 5336. (Experimental track)
Submitter: Jiankang YAO
Change controller: IESG.Code: X.6.9
Sample Text: UTF8SMTP downgrade failed
Associated basic status code: 550
Description: This indicates that transaction failed
after the final "." of the DATA command.
Defined: RFC 5336. (Experimental track)
Submitter: Jiankang YAO
Change controller: IESG.Code: X.6.10
Sample Text: UTF-8 string reply is required,
but not permitted by the client
Associated basic status code: 252
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 client.
Defined: RFC 5336. (Experimental track)
Submitter: Jiankang YAO
Change controller: IESG.And the "Mail Transmission Types" registry under Mail Parameters is asked to pick up these new entries 🦋 Four flavours of UTF8SMTP, all with their own combos of extensions:
+---------------+----------------------------+----------------------+
| WITH protocol | Description | Reference |
| types | | |
+---------------+----------------------------+----------------------+
| UTF8SMTP | UTF8SMTP with Service | [RFC5336] |
| | Extensions | |
| UTF8SMTPA | UTF8SMTP with SMTP AUTH | [RFC4954] [RFC5336] |
| UTF8SMTPS | UTF8SMTP with STARTTLS | [RFC3207] [RFC5336] |
| UTF8SMTPSA | UTF8SMTP with both | [RFC3207] [RFC4954] |
| | STARTTLS and SMTP AUTH | [RFC5336] |
+---------------+----------------------------+----------------------+5. Security Considerations 🔐
Okay, security is serious business, so no cap, this one is a big deal 😭 The extended security discussion lives in the framework document, so go read [RFC4952] for the full picture. Don't skip it, periodt.
6. Acknowledgements 🫶
This spec has a huge fan club. A lot of the early text was derived or copied from [Emailaddr], and the author gave permission for that, which is so generous 💜 Significant comments and suggestions came from Xiaodong LEE, Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and the rest of the JET team, and they all got folded in. Then tons of WG and design team members pitched in with comments, suggestions, and often whole chunks of text. Those contributions include 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, and Lars Eggert. Of course, none of these individuals are necessarily responsible for the combination of ideas represented here 🌸
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.
- [RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
- [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
- [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.
- [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
- [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
- [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.
- [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", BCP 138, RFC 5248, June 2008.
- [RFC5335] Abel, Y., Ed., "Internationalized Email Headers", RFC 5335, September 2008.
- [RFC5337] Newman, C. and A. Melnikov, Ed., "Internationalized Delivery Status and Disposition Notifications", RFC 5337, September 2008.
7.2. Informative References
- [Downgrade] Fujiwara, K. and Y. Yoneya, "Downgrading mechanism for Email Address Internationalization", Work in Progress, July 2008.
- [Emailaddr] Klensin, J., "Internationalization of Email Addresses", Work in Progress, July 2005.
- [RFC0974] Partridge, C., "Mail routing and the domain system", RFC 974, January 1986.
- [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.
- [RFC2821bis] Klensin, J., "Simple Mail Transfer Protocol", Work in Progress, July 2008.
- [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., Ed. and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, July 2007.
Appendix A. Material Updating RFC 4952 🌈
This appendix is normative, so it's officially part of the spec, bestie 💖 RFC 4952, the overview and framework doc for this whole set of internationalized email extensions, was finished before this spec, which nails down one specific part of the protocol. This appendix holds material that would have been put into RFC 4952 if that doc had been held back until this work was done. It should be included in any update to RFC 4952.
A.1. Conventional Message and Internationalized Message
- A conventional message is one that does not use any extension defined in this document or in the UTF-8 header specification [RFC5335], and which is strictly conformant to RFC 2822 [RFC2822].
- An internationalized message is a message utilizing one or more of the extensions defined in this specification or in the UTF-8 header specification [RFC5335], so that it is no longer conformant to the RFC 2822 specification of a message.
A.2. LMTP
LMTP [RFC2033] may be used as the final delivery agent. In such cases, LMTP may be arranged to deliver the mail to the mail store. The mail store may not have UTF8SMTP capability. LMTP needs to be updated to deal with these situations 🧚
A.3. SMTP Service Extension for DSNs
The existing Draft Standard regarding delivery status notifications (DSNs) [RFC3461] is limited to ASCII text in the machine readable portions of the protocol. "International Delivery Status and Disposition Notifications" [RFC5337] adds a new address type for international email addresses, so an original recipient address with non-ASCII characters can be correctly preserved even after downgrading. If an SMTP server advertises both the UTF8SMTP and the DSN extension, that server MUST implement EAI DSN [RFC5337] including support for the ORCPT parameter. This part is a big deal, so pay attention ✨
A.4. Implementation Advice
In the absence of this extension, SMTP clients and servers are constrained to using only those addresses permitted by RFC 2821. The local parts of those addresses MAY be made up of any ASCII characters, although some of them MUST be quoted as specified there. It is notable in an internationalization context that there is a long history on some systems of using overstruck ASCII characters (a character, a backspace, and another character) within a quoted string to approximate non-ASCII characters. This form of internationalization SHOULD be phased out as this extension becomes widely deployed, but backward-compatibility considerations require that it continue to be supported 🍓
A.5. Applicability of SMTP Extension to Additional Uses 🦋
okay so this bit is about what the SMTP extension is NOT for, which is lowkey just as important 💅 The extension lets you tack an optional alternate address onto the MAIL and RCPT commands. But for this set of specs, that alternate address only means something when the primary address has UTF-8 characters AND the message gets downgraded 🍓
bestie, don't get it twisted. It might be tempting to treat the alternate address as a general-purpose backup that you try whenever the primary one gets rejected. That behavior is NOT defined here 🙅♀️ The restriction is intentional, because it leaves room for future extensions to build that general-purpose second-chance address. No specific work on that is currently anticipated, though 😭
One more thing: any extension like that would have to figure out what the [RFC0974] sequencing rules mean when different servers support different sets of ESMTP options (or, in this case, addresses). The answer might also end up updating [RFC2821] 🧚 so keep an eye on that one ✨
Authors' Addresses 🎀
Jiankang YAO (editor)
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
Phone: +86 10 58813007
EMail: yaojk@cnnic.cnWei MAO (editor)
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing
Phone: +86 10 58812230
EMail: maowei_ietf@cnnic.cnFull Copyright Statement ⚖️
Copyright (C) The IETF Trust (2008) 🌈
This document is subject to the rights, licenses and restrictions contained in BCP 78. Except as set forth therein, the authors keep all their rights 💜
This document and the information in it are provided on an "AS IS" basis. THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 💀
Intellectual Property 🔥
The IETF doesn't take a position on whether any Intellectual Property Rights (or other rights someone might claim) are valid or how far they reach. That covers the implementation or use of the tech in this doc, and it also covers whether any license under those rights is available or might be. It also doesn't claim to have done any independent digging to find such rights 🫶 If you want the procedures for rights in RFC documents, look in BCP 78 and BCP 79 ✨
Copies of IPR disclosures sent to the IETF Secretariat, and any assurances of licenses that will be made available, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr. The same goes for the result of any attempt to get a general license or permission for implementers or users of this spec to use those proprietary rights 👑
The IETF invites anyone interested to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 🦋 Thank you for reading the whole thing, bestie 🩷
📦 where this page comes from
- ietf: rfc5336 2008-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms