RFC 4952
Overview and Framework for Internationalized Email
RFC 4952: Overview and Framework for Internationalized Email ✨
okay bestie, so this is RFC 4952, "Overview and Framework for Internationalized Email" 💌 It's an Informational doc from July 2007, written by J. Klensin and Y. Ko (ICU) 🎀 It's a big-picture map for the whole internationalized email project, not a spec you implement directly. The title block doesn't list anything it obsoletes or updates, so it's standing on its own 🦋
Status of This Memo 📜
this doc is for the Internet community to read as info 🧚 it is not an Internet standard of any kind, and you can distribute it as much as you want 💅
Copyright Notice ©️
Copyright (C) The IETF Trust (2007). 🌈
Abstract 💖
so the big dream is that everyone on Earth can use their own name, spelled correctly in their own language and script, as the mailbox name in their email address 😭🫶 this document kicks off a whole series of specs that define the mechanisms and protocol extensions needed to fully support internationalized email addresses 🔥 the changes include an SMTP extension, plus stretching the email header syntax so it can handle UTF-8 data ✨ the doc set also talks through the key assumptions and issues you'll run into when you actually roll out fully internationalized email 🍓
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Role of This Specification . . . . . . . . . . . . . . . . 3
1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of the Approach . . . . . . . . . . . . . . . . . . . 6
3. Document Plan . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of Protocol Extensions and Changes . . . . . . . . . 7
4.1. SMTP Extension for Internationalized Email Address . . . . 7
4.2. Transmission of Email Header Fields in UTF-8 Encoding . . 8
4.3. Downgrading Mechanism for Backward Compatibility . . . . . 9
5. Downgrading before and after SMTP Transactions . . . . . . . . 10
5.1. Downgrading before or during Message Submission . . . . . 10
5.2. Downgrading or Other Processing After Final SMTP
Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Additional Issues . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Impact on URIs and IRIs . . . . . . . . . . . . . . . . . 11
6.2. Interaction with Delivery Notifications . . . . . . . . . 12
6.3. Use of Email Addresses as Identifiers . . . . . . . . . . 12
6.4. Encoded Words, Signed Messages, and Downgrading . . . . . 12
6.5. Other Uses of Local Parts . . . . . . . . . . . . . . . . 13
6.6. Non-Standard Encapsulation Formats . . . . . . . . . . . . 13
7. Experimental Targets . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 161. Introduction 🌸
okay so to use internationalized email addresses, we have to internationalize both the domain part and the local part 🫶 the domain part is already internationalized [RFC3490], but the local part is not 💀 without the extensions in this doc, the mailbox name is limited to a subset of 7-bit ASCII [RFC2821] 😭 MIME [RFC2045] lets non-ASCII data travel around, but it doesn't give us a way to do internationalized email addresses 🙈 RFC 2047 [RFC2047] gives MIME a way to encode non-ASCII data in some specific message header fields, but it still doesn't let you use email addresses that include non-ASCII characters 🥲 so unless we get these extensions (or something equivalent), the only way to fit non-ASCII characters anywhere in an email address is to tuck them into the "display name" of the relevant headers using RFC 2047 coding 🧩 that's the thing RFC 2822 [RFC2822] calls the "display name" (it goes by "name phrase" or other terms elsewhere) 💅 the catch is that info coded into the display name is invisible in the message envelope, and for lots of purposes it isn't part of the address at all 👀
1.1. Role of This Specification 🦋
this doc gives the overview and framework for the next stage of email internationalization 🚀 this stage needs more than just internationalized addresses and headers, it also needs the transport and delivery models to match 💖
this doc is the framework for a series of experimental specifications that together give you the details for implementing and supporting internationalized email ✨ it also explains how all the different pieces of email internationalization fit together, and how the various documents relate to each other 🧚
1.2. Problem Statement 💅
Internationalizing Domain Names in Applications (IDNA) [RFC3490] lets you use internationalized domain names, but most users still haven't gotten there 🥺 one big reason is that we don't have fully internationalized naming schemes yet 😤 domain names are just one of many names and identifiers that need to be internationalized, so until more of those get done, internationalized domain names on their own don't mean a whole lot 🍓
email addresses are the perfect example of why internationalizing just the domain name isn't enough 😭 most of us have learned the hard way that users really prefer email addresses that look like names or initials, not random strings of letters and numbers 💜 unless the whole address can use familiar characters and formats, users will feel like email is culturally unfriendly 🙈 if the names and initials can be written in people's own native languages and writing systems, the Internet will feel way more natural, especially to people whose native language isn't written in a Roman-derived script 🌈
changing the SMTP envelope isn't the whole story, and neither is changing the From, To, and Cc headers or letting upgraded Mail User Agents (MUAs) decode a special coding and show local characters 🙅♀️ for addresses to feel usable, they have to be internationalized and handled consistently everywhere they show up 🔥 that's a huge requirement with far-reaching implications, and patches and workarounds just aren't enough 😩 even if they were, a workaround-based approach would give you a pile of implementations, each with its own random set of patches, and users would be totally confused about what actually works and what's supported 🌀 so instead we need to build a fully internationalized email environment, one that focuses on letting people who share a language or community talk to each other efficiently 🫶 that means changing the mail header environment so it can handle the full range of Unicode characters where that makes sense, adding an SMTP Extension to permit UTF-8 [RFC3629] mail addressing and delivery of those extended headers, and (last but definitely not least) requiring support for the 8BITMIME SMTP extension [RFC1652] 👑 that way all of this can travel through the mail system without running into the limit that headers don't have content-transfer-encodings ✨
1.3. Terminology 📚
Okay so this bit is the glossary, bestie 🫶 It assumes you already get the core email stuff from [RFC2821] and [RFC2822]. If you don't, go read those first, no cap ✨
A lot of this depends on "Mail Transfer Agent" ("MTA") and "Mail User Agent" ("MUA"). Here's the tea though: those terms and their concepts showed up after the internet's email design was already locked in, and the "protocols on the wire" principle was applied to it. As email evolved and that "wire" principle held firm, nobody ever got strong, standardized lines between how MTAs and MUAs talk on a given origin or destination host. It's even fuzzy whether they're separate things at all 🌸
The term "final delivery MTA" here works the same way as "delivery system" or "final delivery system" in RFC 2821. It's the SMTP server that controls the format of the local parts of addresses and is allowed to look at and interpret them. It takes messages from the network for delivery to mailboxes or other local processing, including any forwarding or aliasing that changes envelope addresses, instead of relaying them. From the network's point of view, anything local like saving to a message store, handing off to specific delivery programs or agents, or the ways people fetch messages all live "behind" the final delivery MTA. So they aren't part of the SMTP transport or delivery process 🧚
An address is "all-ASCII", or just an "ASCII address", if every character in it is in the ASCII character repertoire [ASCII]. An address is "non-ASCII", or an "i18n-address", if any character isn't in that repertoire. Addresses can have other restrictions too, but those don't matter for this definition. The term "all-ASCII" also gets used for other protocol elements when the distinction matters, with "non-ASCII" or "internationalized" as the opposite 💖
The umbrella term for the email address internationalization in this document and its companion docs is "UTF8SMTP". So an address this spec allows is called a "UTF8SMTP (compliant) address" ✨
Heads up, bestie: by these definitions, the set of all "all-ASCII" addresses and the set of all "non-ASCII" addresses are mutually exclusive. The set of all UTF8SMTP addresses is the union of those two sets 🎀
An "ASCII user" (i) exclusively uses email addresses with only ASCII characters, and (ii) can't generate recipient addresses with non-ASCII characters 💅
An "i18mail user" has one or more non-ASCII email addresses. They might have ASCII addresses too. If the user has more than one email account and matching address, or more than one alias for the same address, they have some way to choose which address to use on outgoing email. Under this definition you can't tell from an ASCII address whether its owner is an i18mail user, or not 🙈 (A non-ASCII address implies a belief that its owner is an i18mail user.) There's no such thing as an "i18mail message" though. The term only applies to users and their agents and capabilities 🦋
A "message" gets sent from one user (the sender) using a particular email address to one or more other recipient email addresses. Those are often just called "users" or "recipient users" 🌈
A "mailing list" lets you send one message to multiple recipients by sending it to a single recipient address. An agent at that single address (usually not a human) then redistributes the message to the actual targets. This agent sets the envelope return address of the redistributed message to a different address than the original single recipient's. Using a different envelope return address (reverse-path) means error messages, and other automatically generated ones, go to an error handling address instead 💜
As RFC 2821 says, a message that can't be delivered for some reason is expected to notify the sender. That can happen in one of two ways. The first, usually called "Rejection", happens when an SMTP server returns a reply code showing a fatal error (a "5yz" code) or keeps returning a temporary failure error (a "4yz" code). The second is accepting the message during SMTP processing and then generating a message to the sender, usually called a "Non-delivery Notification" or "NDN". Current practice often prefers rejection over NDNs, because NDNs are less likely to get used as a spamming technique. The NDN case can't be avoided if an intermediate MTA accepts a message that the next-hop server then rejects 😭
The pronouns "he" and "she" are used interchangeably to mean a human of indeterminate gender 🫶
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [RFC2119] ✨
2. Overview of the Approach 🌸
This set of specs changes both SMTP and the format of email headers so non-ASCII characters can be represented directly. Each important piece of the work gets its own document. The document set (members are listed in the next section) also includes informational documents, whose purpose is to give implementation suggestions and guidance for the protocols 💖
3. Document Plan 🗺️
Besides this document, the following documents make up this specification and give advice and context for it.
- SMTP extensions. This document [EAI-SMTPext] provides an SMTP extension for internationalized addresses, as allowed for in RFC 2821.
- Email headers in UTF-8. This document [EAI-UTF8] basically updates RFC 2822 so some information in email headers can be written directly as Unicode characters encoded in UTF-8, when the SMTP extension above is in use. This document, maybe with one or more supplemental ones, will also need to deal with how this interacts with MIME, including the relationships between UTF8SMTP and internal MIME headers and content types 🦋
- In-transit downgrading from internationalized addressing (with the SMTP extension and UTF-8 headers) to traditional email formats and characters [EAI-downgrade]. Downgrading at the point of message origination, versus after the mail has been successfully received by a final delivery SMTP server, comes with different constraints and possibilities. See Section 4.3 and Section 5, below. Processing that happens after final delivery, especially processing involved with delivery to a mailbox or message store, is sometimes called "Message Delivery" processing 🌈
- Extensions to the IMAP protocol to support internationalized headers [EAI-imap] 💜
- Parallel extensions to the POP protocol [EAI-pop] ✨
- Description of internationalization changes for delivery notifications (DSNs) [EAI-DSN] 🎀
- Scenarios for using these protocols [EAI-scenarios] 🧚
4. Overview of Protocol Extensions and Changes 🦋
4.1. SMTP Extension for Internationalized Email Address 💅
An SMTP extension, "UTF8SMTP", is specified like this:
- It permits the use of UTF-8 strings in email addresses, in both local parts and domain names.
- It permits the selective use of UTF-8 strings in email headers (see Section 4.2).
- It requires that the server advertise the
8BITMIMEextension [RFC1652], and that the client support 8-bit transmission, so header information can be sent without using special content-transfer-encoding. - It provides information to support downgrading mechanisms.
Some general principles shape the development decisions behind this work 🔥
- Email addresses go through subsystems (like a user interface) that may do charset conversions or other encoding changes. When the left hand side of the address includes characters outside the US-ASCII character repertoire, using punycode on the right hand side is discouraged. This keeps characters processed consistently all the way through the address 💖
- An SMTP relay must:
- Either recognize the format explicitly, agreeing to do so via an ESMTP option,
- Or select and use an ASCII-only address, downgrading other information as needed (see Section 4.3),
- Or reject the message or, if necessary, return a non-delivery notification message, so the sender can make another plan.
If the message can't be forwarded because the next-hop system can't accept the extension, and there isn't enough information to reliably downgrade it, it MUST be rejected or a non-delivery message generated and sent. 😭
- For the sake of interoperability, charsets other than UTF-8 are prohibited in mail addresses and headers. There's no practical way to properly identify them with an extension like this one without adding great complexity 🙈
Conformance to this group of standards for email transport and delivery requires implementing the SMTP Extension specification, including recognizing the keywords associated with alternate addresses, and the UTF-8 Header specification. Support for downgrading is not required, but if it's implemented, it MUST be implemented as specified. Similarly, if the system implements IMAP or POP, it MUST conform to the i18n IMAP or POP specifications, respectively 👑
4.2. Transmission of Email Header Fields in UTF-8 Encoding ✨
okay so there are SO many places in MUAs and user presentation where email addresses or domain names pop up 💅 like the classic From, To, and Cc header fields, Message-ID and In-Reply-To (which usually have domain names, but they might be a special case 🙈), and even stuff in message bodies. Each one needs an internationalization check 🫶. The user is gonna expect to see mailbox and domain names in their local characters, and to see them consistently, no cap. If non-obvious encodings get used, like protocol-specific ASCII-Compatible Encoding (ACE) variants, the user will inevitably see them every now and then instead of "native" characters, and that's gonna feel discomfiting or astonishing 😭. Also, if different codings are used for mail transport and message bodies, the user is extra likely to be shook, even if it's just because of the long-established "things leak" principle 💀. The only practical way to dodge all this drama, now and later, is to make the transport encodings as similar as possible to the encodings used in message headers and message bodies 🎀.
When email local parts get internationalized, it seems clear that they should be accompanied by arrangements for the email headers to be in the fully internationalized form 🦋. That form should presumably use UTF-8 rather than ASCII as the base character set for the contents of header fields, though the protocol elements, like the header field names themselves, stay entirely in ASCII 🌸. For transition purposes and compatibility with legacy systems, this can be done by extending the encoding models of [RFC2045] and [RFC2231]. But our real target is fully internationalized headers, as discussed in [EAI-UTF8] 👑.
4.3. Downgrading Mechanism for Backward Compatibility
okay so as with any use of the SMTP extension mechanism, there's always the possibility of a client that needs the feature running into a server that doesn't support it 🙈. For email address and header internationalization, the risk should be minimized by a couple of things: the sender's client usually controls which submission servers get picked, and the administration of the final delivery server controls which intermediate relays get used 🧚.
For situations where a client that needs to use UTF8SMTP runs into a server that does not support the extension UTF8SMTP, there are two possibilities 💅:
- Reject the message or generate and send a non-delivery message, requiring the sender to resubmit it with traditional-format addresses and headers.
- Figure out a way to downgrade the envelope or message body in transit. Especially when internationalized addresses are involved, downgrading requires that all-ASCII addresses be obtained from some source. An optional extension parameter is provided as a way of transmitting an alternate address. Downgrade issues and a specification are discussed in [EAI-downgrade] ✨.
(The client can also try an alternate next-hop host or requeue the message and try later, on the assumption that the lack of UTF8SMTP is a transient failure. Since this ultimately resolves to success or failure, it doesn't change the discussion here 🌈.)
The first of these two options, rejecting or returning the message to the sender, MAY always be chosen 💖.
If a UTF8SMTP capable client is sending a message that doesn't require the extended capabilities, it SHOULD send the message whether or not the server announces support for the extension 🫶. In other words, both the addresses in the envelope and the entire set of headers of the message are entirely in ASCII (perhaps including encoded words in the headers). In that case, the client SHOULD send the message whether or not the server announces the capability specified here 🍓.
5. Downgrading before and after SMTP Transactions ✨
on top of the in-transit downgrades we just covered, downgrading can also happen before or during the initial message submission, or after the delivery to the final delivery MTA 🦋. These cases have a different set of available information from in-transit cases, so the constraints and opportunities might be somewhat different too. Both get their own subsections below 💅.
5.1. Downgrading before or during Message Submission
honestly, the most convenient time to find an ASCII address that matches an internationalized address is at the originating MUA 💖. That can happen either before the message is sent or after the internationalized form of the message gets rejected. It's also the most convenient time to convert a message from internationalized form into conventional ASCII form, or to generate a non-delivery message to the sender if either one is necessary 🎀. At that point the user has a full range of choices, including contacting the intended recipient out of band for an alternate address, consulting appropriate directories, arranging for translation of both addresses and message content into a different language, and so on 🌸. It's natural to think of message downgrading as ideally being fully automated, but we should not underestimate what a user of at least moderate intelligence can do when they want to talk to another such user 👑.
In this context, you can easily imagine modifications to message submission servers (as described in [RFC4409]) so that they'd perform downgrading, or maybe even upgrading, operations. They'd receive messages with one or more of the internationalization extensions discussed here and adapt the outgoing message as needed, to respond to the delivery or next-hop environment they run into 🧚✨.
5.2. Downgrading or Other Processing After Final SMTP Delivery
when an email message gets received by a final delivery SMTP server, it's usually stored in some form 📦. Then it gets retrieved either by software that reads the stored form directly, or by client software through email retrieval mechanisms such as POP or IMAP 💜.
The SMTP extension described in Section 4.1 provides protection only in transport 😭. It does not prevent MUAs and email retrieval mechanisms that haven't been upgraded to understand internationalized addresses and UTF-8 headers from accessing stored internationalized emails 💀.
Since the final delivery SMTP server (or, to be more specific, its corresponding mail storage agent) can't safely assume that agents accessing email storage will always be capable of handling the extensions proposed here, it MAY either downgrade internationalized emails or specially identify messages that use these extensions, or both 🙈. If this is done, the final delivery SMTP server SHOULD include a mechanism to preserve or recover the original internationalized forms without information loss, so UTF8SMTP-aware agents can still access them 🫶.
6. Additional Issues 🌈
this section covers issues that are NOT part of this set of specifications, but that will need consideration when email address and header internationalization gets deployed 👀.
6.1. Impact on URIs and IRIs
the mailto: scheme defined in [RFC2368] and discussed in the Internationalized Resource Identifier (IRI) specification [RFC3987] may need to be modified once this work is completed and standardized 🦋.
6.2. Interaction with Delivery Notifications
the arrival of UTF8SMTP makes it necessary to think about how it interacts with delivery notification mechanisms, including the SMTP extension for requesting delivery notifications [RFC3461] and the format of delivery notifications [RFC3464] 📬. These issues are discussed in a forthcoming document that will update those RFCs as needed [EAI-DSN] 🎀.
6.3. Use of Email Addresses as Identifiers
there are a bunch of places in current Internet usage where email addresses are used as identifiers for individuals, including as identifiers to Web servers supporting some electronic commerce sites 🛍️. These documents don't address those uses, but it's reasonable to expect some difficulties when internationalized addresses are first used in those contexts, many of which can't even handle the full range of addresses permitted today 😬.
6.4. Encoded Words, Signed Messages, and Downgrading
one super important thing about the email format is its persistency: MUAs are expected to handle messages that were originally sent decades ago, not just ones delivered seconds ago ⏳. So MUAs and mail filtering software, such as that specified in Sieve [RFC3028], will need to keep accepting and decoding header fields that use the "encoded word" mechanism [RFC2047] to accommodate non-ASCII characters in some header fields 💅. Extensions to both POP3 and IMAP have been proposed to enable automatic EAI-upgrade (including RFC 2047 decoding) of messages by the POP3 or IMAP server. But there are message structures and MIME content-types where that can't be done, or where the change would have unacceptable side effects 🙅♀️.
For example, message parts that are cryptographically signed, using e.g., S/MIME [RFC3851] or Pretty Good Privacy (PGP) [RFC3156], can't be upgraded from the RFC 2047 form to normal UTF-8 characters without breaking the signature 🔐. Similarly, message parts that are encrypted may contain header fields that use the RFC 2047 encoding once decrypted. Those messages can't be "fully" upgraded without access to cryptographic keys 🗝️.
Similar issues may come up if signed messages get downgraded in transit [EAI-downgrade], then an attempt is made to upgrade them back to the original form and verify the signatures. Even the very subtle changes that can result from algorithms that downgrade and then upgrade again may be enough to invalidate the signatures if they affect either the primary or MIME bodypart headers 😭. When signatures are present, downgrading must be performed with extreme care, if at all 🚨.
6.5. Other Uses of Local Parts
local parts sometimes get used to construct domain labels 🏡. For example, the local part "user" in the address user@domain.example could be converted into a vanity host user.domain.example, with its Web space at http://user.domain.example and the catchall addresses any.thing.goes@user.domain.example 💖.
Schemes like this are obviously limited by, among other things, the SMTP rules for domain names. They won't work without further restrictions for other local parts, such as the <utf8-local-part> specified in [EAI-UTF8] 🙃. Whether this issue is relevant to these specifications is an open question 🤔. It might just be another case of the considerable flexibility given to delivery MTAs in deciding which mailbox names they'll accept and how they're interpreted ✨.
6.6. Non-Standard Encapsulation Formats
some applications use formats similar to the application/mbox format defined in [RFC4155] instead of the message/digest form from RFC 2046, Section 5.1.5 [RFC2046] to transfer multiple messages as single units 📨. Insofar as those applications assume that all stored messages use the message/rfc822 form from RFC 2046, Section 5.2.1 [RFC2046] with US-ASCII headers, they're not ready for the extensions specified in this series of documents. Special measures may be needed to properly detect and process them 🧐.
7. Experimental Targets 🧪
okay so beyond the big question of whether this model can actually work well for upgraded systems and still protect the un-upgraded ones 👀, we also expect real-world testing to answer two more things. first, what limits should be put on the characters allowed in address local-parts, like character lists or normalization, if any at all? 🔤 second, how useful will downgrading actually be in practice, once you factor in all the restrictions and constraints it has to live with? 🤔 this is so important bestie 💅
8. IANA Considerations 📋
this overview and framework document doesn't ask for any IANA registrations or other actions, so it's giving no paperwork ✨ bestie. some of the other documents in the group do have their own IANA considerations sections and requirements though, so check those too 🫶
9. Security Considerations 🚨
okay this section is SERIOUS but also kinda iconic 😭 any expansion of permitted characters and encoding forms in email addresses brings some risks 💀. there have been discussions about so called "IDN-spoofing" or "IDN homograph attacks" 🙈. these let an attacker (aka a "phisher") spoof the domain or URLs of real businesses 🎣. the same kind of attack is also possible on the local part of internationalized email addresses 😬. also, the proposed fix of forcing all displayed elements into normalized lower-case works for domain names in URLs, but NOT for email local parts, since those are case sensitive 🙅♀️
email addresses often get copied down from business cards and notes on paper ✍️, so they're open to problems from confusable characters (see [RFC4690]) 👀. these problems are somewhat reduced if the domain is unambiguous and supports a relatively small number of mailboxes whose names follow local system conventions 🧠. they get worse with very large mail systems where users can freely pick their own addresses 📈.
the internationalization of email addresses and headers must not leave the Internet less secure than it is without the required extensions 🔐. the requirements and mechanisms in this set of specs don't, in general, raise any brand new security issues ✅. they DO require a review of issues tied to confusable characters, which is a topic being explored thoroughly elsewhere (see, e.g., [RFC4690]) 🔍, and potentially some issues with UTF-8 normalization, discussed in [RFC3629], plus other transformations 🌀. normalization and other issues with transformations and standard forms are also part of ongoing work discussed in [Net-Unicode], in [IDNAbis-BIDI], and elsewhere 📚. some issues specific to internationalized addresses and headers are covered in more detail in the other documents in this set 🧵. but caution is needed here: any "downgrading" mechanism, or any use of downgraded addresses, should not inappropriately assume authenticated bindings between the internationalized and ASCII addresses ⚠️
⚠️ bestie this is the big one: don't assume the UTF-8 address and its ASCII downgraded twin are cryptographically tied together, unless something actually proves it 🙅♀️💔
the new UTF-8 header and message formats might also raise, or make worse, another known issue 😤. if the model creates new forms of "invalid" or "malformed" messages, then a brand new email attack shows up 🧨: to be robust, some or most agents will accept such messages and interpret them as if they were well-formed 🫠. if a filter reads one of these messages differently than the final MUA does, it might be possible to craft a message that looks fine to the filter but should get rejected under the final MUA's reading 👻. attacks like this already exist for current messages and encoding layers, e.g., invalid MIME syntax, invalid HTML markup, and invalid coding of particular image types 🖼️.
models for "downgrading" messages or addresses from UTF-8 form into some ASCII form, including those described in [EAI-downgrade], are another special problem and risk 🎭. any system that transforms one address or set of mail header fields into another becomes a point where spoofing can happen 🕵️♀️, and people who want to spoof messages might manage it by imitating a message downgraded from one with a legit original address 😈.
on top of that, email addresses get used in lots of contexts other than sending mail, like as identifiers in various situations (see Section 6.3) 🪪. each of those contexts needs to be evaluated in turn to figure out whether non-ASCII forms are appropriate there and what particular issues they bring 🔎.
this work will clearly impact any systems or mechanisms that rely on digital signatures or similar integrity protection for mail headers (see also the discussion in Section 6.4) 🔏. lots of conventional PGP and S/MIME uses aren't affected, since they sign body parts but not headers 💌. on the flip side, the developing work on domain keys identified mail (DKIM [DKIM-Charter]) will eventually need to consider this work, and vice versa 🤝. this experiment doesn't try to address or solve the issues raised by DKIM and other signed-header mechanisms, but those issues will have to be coordinated and resolved eventually if the two sets of protocols are going to co-exist 🫶. also, to the degree that email addresses appear in PKI (Public Key Infrastructure) certificates, the standards for those certificates will need upgrades to handle these internationalized addresses 🪪✨. those upgrades will need to deal with spoofing by look-alikes of the addresses themselves 👯♀️.
10. Acknowledgements 🫶🎀
this document, and the related ones, were originally derived from documents by John Klensin and the JET group [Klensin-emailaddr], [JET-IMA] 👑. the work was also inspired by discussions on the "IMAA" mailing list, sponsored by the Internet Mail Consortium 💌, and especially by an early document from Paul Hoffman and Adam Costello [Hoffman-IMAA] that tried to define an MUA-only solution to the address internationalization problem 🙌.
more recent documents have benefited from lots of discussion within the IETF EAI Working Group 🌸, especially from suggestions and text from Martin Duerst, Frank Ellermann, Philip Guenther, Kari Hurtta, and Alexey Melnikov 💖, plus extended discussions among the editors and authors of the core documents cited in Section 3: Harald Alvestrand, Kazunori Fujiwara, Chris Newman, Pete Resnick, Jiankang Yao, Jeff Yeh, and Yoshiro Yoneya 🥰.
extra comments received during IETF Last Call, including those from Paul Hoffman and Robert Sparks, were super helpful in making the document clearer and more comprehensive 🧚.
11. References 📚
11.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.
ANSI X3.4-1968 has been replaced by newer
versions with slight modifications, but the 1968
version remains definitive for the Internet.
[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'", RFC 2119, BCP 14,
March 1997.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol",
RFC 2821, April 2001.
[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.11.2. Informative References ✨
okay bestie, these are the "for more context" links 📚🫶 they're not required reading to implement, but they're where all the internationalized email drama lives 💅
[DKIM-Charter] IETF, "Domain Keys Identified Mail (dkim)",
October 2006, <http://www.ietf.org/
html.charters/dkim-charter.html>.
[EAI-DSN] Newman, C., "UTF-8 Delivery and Disposition
Notification", Work in Progress, January 2007.
[EAI-SMTPext] Yao, J., Ed. and W. Mao, Ed., "SMTP extension
for internationalized email address", Work
in Progress, June 2007.
[EAI-UTF8] Yeh, J., "Internationalized Email Headers", Work
in Progress, April 2007.
[EAI-downgrade] Yoneya, Y., Ed. and K. Fujiwara, Ed.,
"Downgrading mechanism for Internationalized
eMail Address (IMA)", Work in Progress,
March 2007.
[EAI-imap] Resnick, P. and C. Newman, "IMAP Support for
UTF-8", Work in Progress, March 2007.
[EAI-pop] Newman, C., "POP3 Support for UTF-8", Work
in Progress, January 2007.
[EAI-scenarios] Alvestrand, H., "UTF-8 Mail: Scenarios", Work
in Progress, February 2007.
[Hoffman-IMAA] Hoffman, P. and A. Costello, "Internationalizing
Mail Addresses in Applications (IMAA)", Work
in Progress, October 2003.
[IDNAbis-BIDI] Alvestrand, H. and C. Karp, "An IDNA problem in
right-to-left scripts", Work in Progress,
October 2006.
[JET-IMA] Yao, J. and J. Yeh, "Internationalized eMail
Address (IMA)", Work in Progress, June 2005.
[Klensin-emailaddr] Klensin, J., "Internationalization of Email
Addresses", Work in Progress, July 2005.
[Net-Unicode] Klensin, J. and M. Padlipsky, "Unicode Format
for Network Interchange", Work in Progress,
March 2007.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose
Internet Mail Extensions (MIME) Part One: Format
of Internet Message Bodies", RFC 2045,
November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose
Internet Mail Extensions (MIME) Part Two: Media
Types", RFC 2046, November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header
Extensions for Non-ASCII Text", RFC 2047,
November 1996.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value
and Encoded Word Extensions:
Character Sets, Languages, and Continuations",
RFC 2231, November 1997.
[RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The
mailto URL scheme", RFC 2368, July 1998.
[RFC2822] Resnick, P., "Internet Message Format",
RFC 2822, April 2001.
[RFC3028] Showalter, T., "Sieve: A Mail Filtering
Language", RFC 3028, January 2001.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T.
Roessler, "MIME Security with OpenPGP",
RFC 3156, August 2001.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP)
Service Extension for Delivery Status
Notifications (DSNs)", RFC 3461, January 2003.
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible
Message Format for Delivery Status
Notifications", RFC 3464, January 2003.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message
Specification", RFC 3851, July 2004.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized
Resource Identifiers (IRIs)", RFC 3987,
January 2005.
[RFC4155] Hall, E., "The application/mbox Media Type",
RFC 4155, September 2005.
[RFC4409] Gellens, R. and J. Klensin, "Message Submission
for Mail", RFC 4409, April 2006.
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB,
"Review and Recommendations for
Internationalized Domain Names (IDNs)",
RFC 4690, September 2006.Authors' Addresses 🎀
the crew behind this doc, with their contact info 💌
John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
YangWoo Ko
ICU
119 Munjiro
Yuseong-gu, Daejeon 305-732
Republic of Korea
EMail: yw@mrko.pe.krFull Copyright Statement 🧾
the legal bit, kept word-for-word so nothing gets lost in translation 🔒
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and 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 🔐
more legal vibes, same deal: exact wording, no edits 💜
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.Acknowledgement 🌸
and that's a wrap, bestie! ✨
Funding for the RFC Editor function is currently provided by the
Internet Society.📦 where this page comes from
- ietf: rfc4952 2007-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms