7Internet Engineering Task Force (IETF) J. Yao
8Request for Comments: 6531 W. Mao
10Category: Standards Track February 2012
14 SMTP Extension for Internationalized Email
18 This document specifies an SMTP extension for transport and delivery
19 of email messages with internationalized email addresses or header
24 This is an Internet Standards Track document.
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.
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.
38 Copyright (c) 2012 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
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.
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
58Yao & Mao Standards Track [Page 1]
60RFC 6531 SMTP Extension for SMTPUTF8 February 2012
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
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
114Yao & Mao Standards Track [Page 2]
116RFC 6531 SMTP Extension for SMTPUTF8 February 2012
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].
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.
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].
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].
149 Strings referred to in this document, including ASCII strings, MUST
150 be expressed in UTF-8.
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].
1571.2. Changes Made to Other Specifications
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.
170Yao & Mao Standards Track [Page 3]
172RFC 6531 SMTP Extension for SMTPUTF8 February 2012
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.
1822. Overview of Operation
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
189 The internationalized email headers specification [RFC6532] provides
190 the details of email header features enabled by this extension.
1923. Mail Transport-Level Protocol
1943.1. Framework for the Internationalization Extension
196 The following service extension is defined:
198 1. The name of the SMTP service extension is "Internationalized
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.
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.
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
226Yao & Mao Standards Track [Page 4]
228RFC 6531 SMTP Extension for SMTPUTF8 February 2012
232 characters to accommodate the possible addition of the SMTPUTF8
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.
241 7. No additional SMTP verbs are defined by this extension.
243 8. Servers offering this extension MUST provide support for, and
244 announce, the 8BITMIME extension [RFC6152].
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).
250 10. The mail message body is extended as specified in RFC 6532
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].
2593.2. The SMTPUTF8 Extension
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].
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
282Yao & Mao Standards Track [Page 5]
284RFC 6531 SMTP Extension for SMTPUTF8 February 2012
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.
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
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.
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].
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.
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].
338Yao & Mao Standards Track [Page 6]
340RFC 6531 SMTP Extension for SMTPUTF8 February 2012
343 If an SMTPUTF8-aware SMTP server advertises the Delivery Status
344 Notification (DSN) [RFC3461] extension, it MUST implement RFC 6533
3473.3. Extended Mailbox Address Syntax
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.
353 The key changes made by this specification include:
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.
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].
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.
368 The following ABNF rules imported from RFC 5321, Section 4.1.2, are
369 updated directly or indirectly by this document:
385 The following ABNF rule will be imported from RFC 6532, Section 3.1,
394Yao & Mao Standards Track [Page 7]
396RFC 6531 SMTP Extension for SMTPUTF8 February 2012
399 The following ABNF rule will be imported from RFC 5234, Appendix B.1,
404 The following ABNF rule will be imported from RFC 5890, Section
409 The following rules are extended in ABNF [RFC5234] as follows.
412 ; extend the definition of sub-domain in RFC 5321, Section 4.1.2
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
420 ; extend the definition of qtextSMTP in RFC 5321, Section 4.1.2
423 ; extend the definition of esmtp-value in RFC 5321, Section 4.1.2
4253.4. MAIL Command Parameter Usage
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.
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.
450Yao & Mao Standards Track [Page 8]
452RFC 6531 SMTP Extension for SMTPUTF8 February 2012
4553.5. Non-ASCII Addresses and Reply-Codes
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
463 The three-digit reply-codes used in this section are based on their
464 meanings as defined in RFC 5321.
467 address, the reply-code 553 is returned with the meaning "mailbox
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".
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.
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".
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.
4933.6. Body Parts and SMTP Extensions
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
506Yao & Mao Standards Track [Page 9]
508RFC 6531 SMTP Extension for SMTPUTF8 February 2012
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.
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):
522 - with the BODY=8BITMIME parameter [RFC6152], or
524 - with the BODY=BINARYMIME parameter, if the SMTP server advertises
525 BINARYMIME [RFC3030].
5273.7. Additional ESMTP Changes and Clarifications
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
539 The following subsections list and discuss all of the relevant cases.
5413.7.1. The Initial SMTP Exchange
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
5533.7.2. Mail eXchangers
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
562Yao & Mao Standards Track [Page 10]
564RFC 6531 SMTP Extension for SMTPUTF8 February 2012
567 extension. Otherwise, unexpected rejections can happen during
568 temporary or permanent failures, which users might perceive as
569 serious reliability issues.
5713.7.3. Trace Information
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
579 the Time-stamp-line may include an internationalized domain name that
580 uses the U-label form.
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.
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.
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.
5963.7.4. UTF-8 Strings in Replies
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.
6103.7.4.2. VRFY and EXPN Commands and the SMTPUTF8 Parameter
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
618Yao & Mao Standards Track [Page 11]
620RFC 6531 SMTP Extension for SMTPUTF8 February 2012
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.
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.
639 VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to:
642 [ SP "SMTPUTF8" ] CRLF
643 ; String may include Non-ASCII characters
646 [ SP "SMTPUTF8" ] CRLF
647 ; String may include Non-ASCII characters
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.
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:
666 ; Mailbox is defined in Section 3.3 of this document.
667 ; User Name can contain non-ASCII characters.
670 ; Mailbox is defined in Section 3.3 of this document.
674Yao & Mao Standards Track [Page 12]
676RFC 6531 SMTP Extension for SMTPUTF8 February 2012
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".
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.
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
6994. IANA Considerations
7014.1. SMTP Service Extensions Registry
703 IANA has added a new value "SMTPUTF8" to the "SMTP Service Extension"
704 registry of the "Mail Parameters" registry, according to the
707 +----------+---------------------------------+-----------+
708 | Keywords | Description | Reference |
709 +----------+---------------------------------+-----------+
710 | SMTPUTF8 | Internationalized email address | [RFC6531] |
711 +----------+---------------------------------+-----------+
7134.2. SMTP Enhanced Status Code Registry
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:
730Yao & Mao Standards Track [Page 13]
732RFC 6531 SMTP Extension for SMTPUTF8 February 2012
736 Sample Text: Non-ASCII addresses not permitted for that
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
747 Sample Text: UTF-8 string reply is required, but not permitted by
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
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
770 Description: This is a duplicate of X.6.8 and is thus deprecated.
786Yao & Mao Standards Track [Page 14]
788RFC 6531 SMTP Extension for SMTPUTF8 February 2012
794 IANA has modified or added the following entries in the "WITH
795 protocol types" sub-registry under the "Mail Transmission Types"
798 +--------------+------------------------------+---------------------+
799 | WITH | Description | Reference |
802 +--------------+------------------------------+---------------------+
803 | UTF8SMTP | ESMTP with SMTPUTF8 | [RFC6531] |
804 | UTF8SMTPA | ESMTP with SMTPUTF8 and AUTH | [RFC4954] [RFC6531] |
805 | UTF8SMTPS | ESMTP with SMTPUTF8 and | [RFC3207] [RFC6531] |
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] |
813 | UTF8LMTPSA | LMTP with SMTPUTF8 and both | [RFC3207] [RFC4954] |
814 | | STARTTLS and AUTH | [RFC6531] |
815 +--------------+------------------------------+---------------------+
8175. Security Considerations
819 The extended security considerations discussion in the framework
820 document [RFC6530] applies here.
822 More security considerations are discussed below:
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:
828 o the logging systems of SMTP transactions and other logs to monitor
831 o the trouble ticket systems used by security teams to manage
832 security incidents, when an email address is involved;
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
842Yao & Mao Standards Track [Page 15]
844RFC 6531 SMTP Extension for SMTPUTF8 February 2012
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.
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
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.
881 Thanks a lot to Dave Crocker for his comments and helping with ABNF
8867.1. Normative References
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.
892 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
893 Requirement Levels", BCP 14, RFC 2119, March 1997.
898Yao & Mao Standards Track [Page 16]
900RFC 6531 SMTP Extension for SMTPUTF8 February 2012
903 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
904 Extension for Delivery Status Notifications (DSNs)",
905 RFC 3461, January 2003.
907 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
908 RFC 3463, January 2003.
910 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
911 for Delivery Status Notifications", RFC 3464,
914 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
915 10646", RFC 3629, November 2003.
917 [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types
918 Registration", RFC 3848, July 2004.
920 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
921 Specifications: ABNF", STD 68, RFC 5234, January 2008.
923 [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced
924 Mail System Status Codes", RFC 5248, June 2008.
926 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
929 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
932 [RFC5890] Klensin, J., "Internationalizing Domain Names in
933 Applications (IDNA definitions)", RFC 5890, June 2010.
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.
939 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
940 STD 72, RFC 6409, November 2011.
942 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for
943 Internationalized Email", RFC 6530, February 2012.
945 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
946 Email Headers", RFC 6532, February 2012.
948 [RFC6533] Hansen, T., Ed., Newman, C., and A. Melnikov, Ed.,
949 "Internationalized Delivery Status and Disposition
950 Notifications", RFC RFC6533, February 2012.
954Yao & Mao Standards Track [Page 17]
956RFC 6531 SMTP Extension for SMTPUTF8 February 2012
9597.2. Informative References
961 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
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.
968 [RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission
969 of Large and Binary MIME Messages", RFC 3030,
972 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
973 Transport Layer Security", RFC 3207, February 2002.
975 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension
976 for Authentication", RFC 4954, July 2007.
978 [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized
979 Email Addresses", RFC 5336, September 2008.
981 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
988 No.4 South 4th Street, Zhongguancun
992 Phone: +86 10 58813007
993 EMail: yaojk@cnnic.cn
998 No.4 South 4th Street, Zhongguancun
1002 Phone: +86 10 58812230
1003 EMail: maowei_ietf@cnnic.cn
1010Yao & Mao Standards Track [Page 18]