SMTPUTF8 Email Addresses
draft-ietf-mailmaint-smtputf8-syntax-06

mailmaint                                                 A. Gulbrandsen
Internet-Draft                                                     ICANN
Updates: 6532 (if approved)                                       J. Yao
Intended status: Standards Track                                   CNNIC
Expires: 16 April 2027                                   13 October 2026

                        SMTPUTF8 Email Addresses
                draft-ietf-mailmaint-smtputf8-syntax-06

Abstract

   RFC 6532 extends the internet email format to allow UTF8 in many
   contexts.  This document updates RFC 6532 and restricts the set of
   allowed addresses in header fields slightly, and thereby simplifies
   use of these addresses.

   This is one of a pair of documents.  This one is simple to implement
   and contains only globally viable rules.  Its companion has more
   complex rules, takes regional usage into account, and describes
   addresses that can be read by some community and cut-and-pasted in
   some locale.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Mail Maintenance
   Working Group mailing list (mailmaint@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/mailmaint/.

   Source for this draft and an issue tracker can be found at
   https://github.com/arnt/mailmaint-smtputf8.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Gulbrandsen & Yao         Expires 16 April 2027                 [Page 1]
Internet-Draft          SMTPUTF8 Email Addresses            October 2026

   This Internet-Draft will expire on 16 April 2027.

Copyright Notice

   Copyright (c) 2026 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 (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .   7
   Appendix B.  Instructions to the RFC editor . . . . . . . . . . .   7
   Appendix C.  Testing  . . . . . . . . . . . . . . . . . . . . . .   7
   Appendix D.  Open issues  . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   [RFC6530]-[RFC6533] and [RFC6854]-[RFC6858] extend various aspects of
   the email system to support non-ASCII both in localparts and domain
   parts.  In addition, some email software supports unicode in domain
   parts by using encoded domain parts in the SMTP transaction ("RCPT
   TO:info@xn--dmi-0na.fo (mailto:info@xn--dmi-0na.fo)") and presenting
   the unicode version (dømi.fo in this case) in the user interface.

Gulbrandsen & Yao         Expires 16 April 2027                 [Page 2]
Internet-Draft          SMTPUTF8 Email Addresses            October 2026

   The email address syntax extension is in [RFC6532], and allows almost
   all UTF8 strings as localparts.  While this certainly allows
   everything users want to use, it is also flexible enough to allow
   many things that users and implementers find surprising and sometimes
   worrying.  For example, the domain extracted by code may not match
   that shown to users on-screen.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Terminology

   Script, in this document, refers to the unicode script property (see
   [UAX24]).  Each code point is assigned to one script ("a" is Latin),
   except that some are assigned to "Common" or a few other special
   values.  Fraktur and /etc/rc.local aren't scripts in this document,
   but Latin is.

   Latin refers to those code points that have the script property
   "Latin" in Unicode.  Orléans in France and Münster in Germany both
   have Latin names in this document.  It also refers to combinations of
   those code points and combining characters, and to strings that
   contain no code points from other scripts.

   Han, Cyrillic etc. refer to those code points that have the
   respective script property in Unicode, as well as to strings that
   contain no code points from other scripts.

   ASCII refers to the first 128 code points within unicode, which
   includes the letters A-Z but not É or Ü. It also refers to strings
   that contain only ASCII code points.

   Non-ASCII refers to unicode code points except the first 128, and
   also to strings that contain at least one such code point.

   By way of example, the address info@dømi.fo is latin and non-ASCII,
   its localpart is latin and ASCII, and its domain part is latin and
   non-ASCII. 中国 is a Han string in this document, but 阿Q正传 is neither a
   Latin string nor a Han string, because it contains a Latin Q and
   three Han code points.

   The term a-label is defined in [RFC5890] section 2.3.2.1.

Gulbrandsen & Yao         Expires 16 April 2027                 [Page 3]
Internet-Draft          SMTPUTF8 Email Addresses            October 2026

   PRECIS is described in [RFC8264], and the IdentifierClass in section
   4.2 of that document.

4.  Rules

   The following four rules apply to the [I-D.ietf-emailcore-rfc5322bis]
   mailbox production, as indirectly extended by [RFC6532].

   1.  An atom in an address MUST NOT be an a-label (e.g. xn--dmi-0na).

   2.  An address MUST contain only code points that the PRECIS
       IdentifierClass treats as valid, and " ".  Where the
       IdentifierClass requires a contextual rule, the address MUST
       satisfy that rule ([RFC5892] Appendix A).

   3.  An address MUST NOT contain more than one script, when ASCII is
       disregarded.  Han, Hiragana and Katakana count as one script
       here, since Japanese uses all three together; so do Han and
       Hangul, and Han and Bopomofo.  (For example: In the word Orléans,
       Orl and ans are ASCII and é is non-ASCII.  The single é is in a
       single script, so the word contains only one script. まり子 is
       Hiragana and Han, which count as one.)

   4.  An address MUST be in the unicode NFC form.

   This does not affect rules in other documents.  For example,
   [RFC952], [RFC5891] and others specify rules on domain names, which
   implicitly affect which email addresses are permitted on the public
   internet.  Domain registries often have policies regarding which
   names may be registered.

5.  Examples

   example@example.com is permitted, because 1) it does not contain any
   a-label, 2) it consists entirely of permissible code points and 3) it
   contains no non-ASCII code points at all.

   The address dømi@dømi.fo is permitted, because 1) it does not contain
   any a-label, 2) the IdentifierClass permits every code point in it
   and 3) it consists entirely of 'Latin' and 'Common' code points (and
   ./@).

   The address U+200E '@' U+200F '.'  U+200E is not permitted, because
   2) the IdentifierClass disallows U+200E and U+200F as ignorable code
   points.

Gulbrandsen & Yao         Expires 16 April 2027                 [Page 4]
Internet-Draft          SMTPUTF8 Email Addresses            October 2026

   The address 'admin' U+3164 '@example.com' is not permitted for the
   same reason.  U+3164 HANGUL FILLER renders as nothing at all, so the
   address looks exactly like admin@example.com.  U+0640 ARABIC TATWEEL
   is disallowed too, although it is a letter by category: it only
   elongates the preceding letter, and would let one address be spelled
   in any number of ways.

   The address まり子@まり子.日本 is permitted, because 1) it contains no
   a-label, 2) the IdentifierClass permits every code point in it and 3)
   Hiragana and Han count as one script.

   阿Q正传@阿Q正传.example is permitted because it contains ASCII and Han,
   dømi@dømi.fo is legal because it contains ASCII and Latin, but
   阿Q正传@dømi.fo is not, because it contains both Han (阿) and Latin non-
   ASCII (ø).

   example@-example-.example.com is permitted by the rules above.
   However, since [RFC952] and its successors prohibit both of the
   hyphens, that email address is effectively not permitted on the
   internet.

6.  IANA Considerations

   This document does not require any actions from the IANA.

7.  Security Considerations

   When a program renders a non-ASCII email address string on-screen or
   stores it as a string (e.g. in a system log file), the address shown
   to the eventual human may not be as intended.  One possible way to
   diminish the risk is to replace impermissible code points with
   U+FFFD, REPLACEMENT CHARACTER.  There are also other options.

   The rules in this document permit a number of code points that can
   make an address difficult to cut and paste.

   This document does not change the longstanding rule that addresses
   may be either case-sensitive or case-insensitive.  However, UTF8 adds
   an extra wrinkle: case conversion depends on the locale.  When
   processing addresses in remote domains, one cannot be sure which
   conversion rules apply.  Implementers may want to consider unusual
   cases such as the Turkish dotless ı.

8.  References

8.1.  Normative References

Gulbrandsen & Yao         Expires 16 April 2027                 [Page 5]
Internet-Draft          SMTPUTF8 Email Addresses            October 2026

   [I-D.ietf-emailcore-rfc5322bis]
              Resnick, P., "Internet Message Format", Work in Progress,
              Internet-Draft, draft-ietf-emailcore-rfc5322bis-12, 13
              June 2024, <https://datatracker.ietf.org/doc/html/draft-
              ietf-emailcore-rfc5322bis-12>.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <https://www.rfc-editor.org/rfc/rfc5890>.

   [RFC5892]  Faltstrom, P., Ed., "The Unicode Code Points and
              Internationalized Domain Names for Applications (IDNA)",
              RFC 5892, DOI 10.17487/RFC5892, August 2010,
              <https://www.rfc-editor.org/rfc/rfc5892>.

   [RFC6530]  Klensin, J. and Y. Ko, "Overview and Framework for
              Internationalized Email", RFC 6530, DOI 10.17487/RFC6530,
              February 2012, <https://www.rfc-editor.org/rfc/rfc6530>.

   [RFC6532]  Yang, A., Steele, S., and N. Freed, "Internationalized
              Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
              2012, <https://www.rfc-editor.org/rfc/rfc6532>.

   [RFC8264]  Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
              Preparation, Enforcement, and Comparison of
              Internationalized Strings in Application Protocols",
              RFC 8264, DOI 10.17487/RFC8264, October 2017,
              <https://www.rfc-editor.org/rfc/rfc8264>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

8.2.  Informative References

   [RFC952]   Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
              host table specification", RFC 952, DOI 10.17487/RFC952,
              October 1985, <https://www.rfc-editor.org/rfc/rfc952>.

Gulbrandsen & Yao         Expires 16 April 2027                 [Page 6]
Internet-Draft          SMTPUTF8 Email Addresses            October 2026

   [RFC5891]  Klensin, J., "Internationalized Domain Names in
              Applications (IDNA): Protocol", RFC 5891,
              DOI 10.17487/RFC5891, August 2010,
              <https://www.rfc-editor.org/rfc/rfc5891>.

   [RFC6533]  Hansen, T., Ed., Newman, C., and A. Melnikov,
              "Internationalized Delivery Status and Disposition
              Notifications", RFC 6533, DOI 10.17487/RFC6533, February
              2012, <https://www.rfc-editor.org/rfc/rfc6533>.

   [RFC6854]  Leiba, B., "Update to Internet Message Format to Allow
              Group Syntax in the "From:" and "Sender:" Header Fields",
              RFC 6854, DOI 10.17487/RFC6854, March 2013,
              <https://www.rfc-editor.org/rfc/rfc6854>.

   [RFC6858]  Gulbrandsen, A., "Simplified POP and IMAP Downgrading for
              Internationalized Email", RFC 6858, DOI 10.17487/RFC6858,
              March 2013, <https://www.rfc-editor.org/rfc/rfc6858>.

   [UAX24]    Whistler, K., "Unicode Script Property", 31 July 2025,
              <https://unicode.org/reports/tr24>.

Appendix A.  Acknowledgments

   The authors wish to thank John C.  Klensin, Daniel Eggert, Andrew
   Gallagher, Jeffrey Stedfast, Pete Resnick, (your name here, please)

   (Wow, the ack section is already outdated)

   Dømi.fo and 例子.中国 are reserved by nic.fo and CNNIC for use in
   examples and documentation.

   阿Q正传 is a famous Chinese novella, 阿Q is the main character.

Appendix B.  Instructions to the RFC editor

   Please remove all mentions of the Protocol Police before publication
   (including this sentence).

   Please remove the Open Issues section.

Appendix C.  Testing

   This is a set of test addresses in JSON format.

   Below is a verbatim copy of https://github.com/arnt/mailmaint-
   smtputf8/tests.json as it was on (date here).  It contains a number
   of strange and unusual code points, so cutting and pasting this may

Gulbrandsen & Yao         Expires 16 April 2027                 [Page 7]
Internet-Draft          SMTPUTF8 Email Addresses            October 2026

   not work.  Rather, it is recommended to either use the rfcstrip tool
   or download the tests using a command such as curl
   https://github.com/arnt/mailmaint-smtputf8/tests.json > tests.json.

   Note to IETF reviewers: The tests will be included here shortly
   before publication (and after IETF Last Call).

Appendix D.  Open issues

   1.  More words on the relationship between this and the companion.
       There are several parallel differences, maybe this warrants a
       section of its own.

   2.  SHOULD or MUST not contain a-labels?

Authors' Addresses

   Arnt Gulbrandsen
   ICANN
   6 Rond Point Schumann, Bd. 1
   1040 Brussels
   Belgium
   Email: arnt@gulbrandsen.priv.no

   Jiankang Yao
   CNNIC
   No.4 South 4th Zhongguancun Street
   Beijing
   100190
   China
   Email: yaojk@cnnic.cn

Gulbrandsen & Yao         Expires 16 April 2027                 [Page 8]