RFC 5983

Mailing Lists and Internationalized Email Addresses

📅 published October 2010, from ietf

RFC 5983: Mailing Lists and Internationalized Email Addresses ✨

Okay bestie, this is RFC 5983, called Mailing Lists and Internationalized Email Addresses 💌 It's an IETF document written by R. Gellens at Qualcomm 🫶 Its category is Experimental, it's dated October 2010, and its ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so there's nothing to flag there 🌸

Abstract 🦋

This doc is all about the things mailing lists need to think about once internationalized email addresses show up. It also gives some specific recommendations on how lists should behave in different situations 💅

Status of This Memo 📜

Heads up: this is not an Internet Standards Track spec 🙅‍♀️ It's published so people can examine it, try it out experimentally, and evaluate it.

That said, it does define an Experimental Protocol for the Internet community 🧪 It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, and it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is up for any level of Internet Standard, though, so check Section 2 of RFC 5741 if you're curious 🤓

For the latest status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc5983 🔗

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

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

This doc may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. Some of the people who hold copyright in that older material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from those copyright holders, this document can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈

Table of Contents 🗂️

1. Introduction ....................................................2
2. Conventions Used in This Document ...............................4
3. Scenarios Involving Mailing Lists ...............................4
4. Capabilities and Requirements ...................................5
5. List Header Fields ..............................................6
6. Further Discussion ..............................................8
7. Security Considerations .........................................8
8. Acknowledgments .................................................9
9. References ......................................................9
   9.1. Normative References .......................................9
   9.2. Informative References ....................................10

1. Introduction 💖

This doc covers the considerations mailing lists have when internationalized email addresses come along [RFC5335] 📬

Mailing lists are a huge part of email and group communication 🍓 Internationalized addresses hit lists in three main areas: (1) transport (receiving and sending messages), (2) message headers on received and retransmitted messages, and (3) mailing list operational policies 🧚

So what even is a mailing list? It's a setup where one message goes out to lots of people by sending it to a single address. An agent sits at that address (usually not a human 🤖), receives the message, and then redistributes it to a list of recipients. That agent sets the envelope return address of the redistributed message to something different from the original's. This matters because a different envelope return address (reverse-path) sends error messages, and other automatic messages, to an error handling address tied to the list. That way the errors don't land on the original sender, who usually doesn't control the list and can't do anything about them anyway 😭

Most of the time, the list agent sends the message out as a brand-new message. Conceptually, it uses message submission [submission], the same way the original sender did 💅 The exception is when the list isn't a separate agent that receives and redistributes in its own transactions, and is instead just an expansion step inside an SMTP transaction, where one local address expands to multiple local or non-local addresses. That case is out of scope for this doc 🙅‍♀️

Some lists change message header fields and some don't. There are a bunch of standardized list-related header fields, and lots of lists add one or more of them ✨ Separately, and even though it's caused interoperability problems before, some lists change or add header fields to control where replies go 🙃 Usually that means adding or replacing the Reply-To field, and sometimes the Sender field too. Poorly behaved lists might also change or replace other fields, including From 💀

Some of these list-specific header fields are defined in RFC 2369 ("The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields") [List-*] and RFC 2919 ("List-Id: A Structured Field and Namespace for the Identification of Mailing Lists") [List-ID]. Section 5 has more on those 🎀

The mail transport protocol doesn't treat regular recipients and list recipients differently. But lists still have special considerations with internationalized addresses, because they retransmit messages written by other agents to potentially a lot of recipients 🦋

Considerations show up in the envelope and in the header fields of redistributed messages. The big one: an internationalized message can't be downgraded unless every envelope address is available in ASCII. Each address either has to be ASCII or have an alt-address [UTF8SMTP] 🔥

There are two kinds of list considerations. The first is purely technical stuff: message handling, error cases, downgrades, and so on. The second comes from the fact that humans use mailing lists to talk to each other 🫶 For the technical side, lists might choose to reject every message from an internationalized address that lacks an alt-address, or even every internationalized message that can't be downgraded 🚫

For the human side, the sender of a message to a list is often unaware of who's on it. They often don't know whether the members are UTF-8 mail users, and often neither the original sender nor the recipients personally know each other 👀 Because of that, fixes that work for a missed email in one-to-one talk might not fit lists at all. Say a message is undeliverable in one-to-one email. Usually you can grab the phone, send an instant message, or use some other channel to get a working address. With a list, users may have no recourse whatsoever 😭 And of course, the original sender usually has no idea whether any list members got the message, or whether it failed to reach some of them 💔

Conceptually, a list's internationalization can be split into three capabilities. First, does it have a UTF-8 submission or return-path address? Second, does it accept subscriptions to UTF-8 addresses? Third, does it accept [UTF8SMTP] messages? Section 4 digs into this 🌸

Section 6 has a short discussion of some extra considerations for running a list 🧚

2. Conventions Used in This Document 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS] 🔑

3. Scenarios Involving Mailing Lists 🎬

Generally, and exclusively within the scope of this document, an original message gets sent to a mailing list as a completely separate and independent transaction from the list agent sending the retransmitted message to one or more list recipients 💌 In both cases, the message might have only one recipient or might have several. So the original message might also go to extra recipients besides the list agent 👯‍♀️ The list might send the retransmitted message to each list recipient in its own message submission [submission] transaction, or it might put multiple recipients in one transaction. (Lists are often built to work alongside a message submission server [submission] instead of doing that job themselves. So the list hands one copy of the retransmitted message to a single submission server, with all the list recipients in the SMTP envelope, and the submission server decides which recipients go in which transaction 🧠)

The retransmitted message the list sends to its subscribers might need to be downgraded [EAI-Downgrade] 📉 For a downgrade to work, the return path set by the list agent has to be an ASCII address or have an alt-address [UTF8SMTP] specified. The recipient addresses also need ASCII versions available. It may be a good idea for list operators to pre-obtain an alt-address for all their internationalized member addresses 🎀

Now the tricky case: a member or non-member with an internationalized email address sends to a list, no alt-address [UTF8SMTP] is specified, and a downgrade is required. Then the message can't be delivered 😭 To protect against that, a UTF8SMTP-aware [UTF8SMTP] list might prefer to reject submissions from internationalized addresses that don't have an alt-address 🛡️

Quick aside: this situation isn't unique to mailing lists. Mail relays that are UTF8SMTP-aware can run into the exact same problem 👀

More discussion is in Section 6 of this document 🦋

4. Capabilities and Requirements ✨

okay so mailing lists have three main internationalization capabilities 💅 First, does it have a UTF-8 submission or return-path address? Second, does it allow subscriptions from UTF-8 addresses? And third, does it accept [UTF8SMTP] messages? 🦋

In theory, any list can mix and match these. In practice, only some combos actually give you a benefit 🤔 Like, allowing UTF-8 addresses to subscribe and accepting UTF8SMTP messages make zero sense without each other. (An all-ASCII address might or might not be able to receive UTF8SMTP messages, but a UTF-8 address of necessity needs to accept UTF8SMTP messages 💀) And a list doesn't really gain anything from a UTF-8 submission address unless it also accepts UTF8SMTP messages AND lets UTF-8 addresses subscribe 🫶

That said, requirements can be discussed separately for each of the three capabilities, so let's get into it 👑

  1. If the list uses a UTF-8 submission or return-path address, it SHOULD specify an alt-address [UTF8SMTP] for it. Clearly, it needs to sit behind a UTF8SMTP-enabled final-delivery SMTP server [UTF8SMTP] and delivery agent. Likewise, if a list uses a UTF-8 return-path address, then its Message Submission Agent (MSA) [submission] needs to support UTF8SMTP.

The list's return-path address is usually separate from its submission address (so that delivery reports and other automatically generated messages are not sent to the submission address) 📬 For reliability in receiving delivery status notifications, a list MAY choose to use an all-ASCII return path even if it uses a UTF-8 submission address. If the list does use a UTF-8 return path, it MUST specify an alt-address [UTF8SMTP] (or else there is a high risk of being unable to receive non-delivery reports 😱).

There are also implications for the List-* header fields (see below) 🎀

  1. If it allows UTF-8 addresses to subscribe, it MAY require an alt-address [UTF8SMTP] to be specified for each UTF-8 subscriber.

Naturally, if it permits UTF-8 addresses to subscribe, it needs a mechanism to accept subscription requests from such addresses (preferably specified in the form <utf8@utf8 <ascii@ascii>>) 🧚 In order to send email to its subscribers who have UTF-8 addresses, its MSA needs to support [UTF8SMTP].

  1. If it accepts UTF8SMTP messages, the Message Transfer Agents (MTAs) and Mail Delivery Agent (MDA) in its inbound path need to support UTF8SMTP.

5. List Header Fields 💌

A bunch of header fields for mailing lists were introduced in RFCs 2369 and 2919 🌸 For example, these include:

List-Id: List Header Mailing List <list-header.example.com>
List-Help: <mailto:list@example.com?subject=help>
List-Unsubscribe: <mailto:list@example.com?subject=unsubscribe>
List-Subscribe: <mailto:list@example.com?subject=subscribe>
List-Post: <mailto:list@example.com>
List-Owner: <mailto:listmom@example.com> (Contact Person for Help)
List-Archive: <mailto:archive@example.com?subject=index%20list>

As RFC 2369 puts it, "The contents of the list header fields mostly consist of angle-bracket ('<', '>') enclosed URLs, with internal whitespace being ignored" [List-*]. For List-ID, RFC 2919 specifies that, "The list identifier will, in most cases, appear like a host name in a domain of the list owner" [List-ID] 🔥

Except for the List-ID header field, these mailing list header fields contain URLs [RFC3986]. The most common schemes are generally HTTP, HTTPS, mailto, and FTP. Schemes that permit both URI and Internationalized Resource Identifier (IRI) [IRI] forms should use the URI-encoded form described in [IRI]. Future work may extend these header fields or define replacements to directly support non-encoded UTF-8 in IRIs (for example, [mailto-bis]), but in the absence of such extension or replacement, non-ASCII characters can only appear within when encoded as ASCII. Note that discussion on whether internationalized domain names should be percent encoded or puny coded is ongoing; see [IRI-bis] 🫠

Even without these header fields being extended to support UTF-8, some special provisions may be helpful when downgrading 🦋 In particular, if a List-* header field contains a UTF-8 mailto (even encoded in ASCII) followed by an ASCII mailto, it may be advisable not only to copy and preserve the original header field as usual (ENCAPSULATION method of [EAI-Downgrade]), but also to edit the header field to remove the UTF-8 address. Otherwise, a client might run into trouble if the decoded mailto results in a non-ASCII address 😬

When mailing lists use a UTF-8 form of a List-* header field, an ASCII form SHOULD also be used. These header fields are vital to good operations and use of mailing lists, so caution is called for when considering how to form and use them in a non-ASCII environment 🚨

The most commonly used URI schemes in List-* header fields tend to be HTTP and mailto. The current specification for mailto does not permit unencoded UTF-8 characters, although work has been proposed to extend or more likely replace mailto in order to permit this 🌈 For mailto URIs, a separate consideration is how to include an alternate ASCII address (alt-address) [UTF8SMTP] for a UTF-8 address. Note that the existing ability to specify multiple URLs within each List-* header field provides one solution.

[List-*] says:

A list of multiple, alternate, URLs MAY be specified by a comma-separated list of angle-bracket enclosed URLs. The URLs have order of preference from left to right. The client application should use the left most protocol that it supports, or knows how to access by a separate application.

When a UTF-8 mailto is used in a List-* header field, an alt-address [UTF8SMTP], if available, SHOULD be supplied 💖

The List-ID header field provides an opaque value that uniquely identifies a list ✨ The intent is that this value stays constant, even if the machine or system used to operate or host the list changes. This header field is often used in various filters and tests, such as client-side filters, Sieve filters, and so forth. Those filters and tests may not properly compare a non-ASCII value that has been encoded into ASCII 🙈 On top of that, it's generally desirable that this header field contain something meaningful that users can type in. However, ASCII encodings of non-ASCII characters are unlikely to be meaningful to users or easy for them to accurately type 😭

6. Further Discussion 🧠

While mailing lists don't create a significant extra burden for deploying internationalized email address functionality, there are some specific areas to think about when the operator of a mailing list (or of a final delivery MTA that serves a mailing list) upgrades to internationalized mail 🎀

Mailing lists have extra complexity because they redistribute messages composed by other agents. So they may be asked to accept a message with non-ASCII header fields composed by a UTF8SMTP-aware user agent [UTF8SMTP] and redistribute it to UTF-8 mail and all-ASCII mail users via systems that are not UTF8SMTP-aware 🫣

  1. Obtaining Downgrade Information -- For a mailing list (or mail relay server, for that matter) that is UTF8SMTP-aware and receiving mail from an internationalized email address, the alt-address [UTF8SMTP] is not required from the sending MTA for the transport to be complete. When the mailing list then retransmits the message to its subscribers, it may encounter paths where a downgrade is needed (if a relay or final MSA does not support UTF8SMTP). To mitigate this, the mailing list might decide to reject all incoming mail from an internationalized email address that lacks an alt-address. However, note that in general, downgrades are not expected to be the normal case 🌸
  2. Downgrading Considerations for mailto URLs -- UTF-8 addresses in mailto links in List-* header fields will be easier to downgrade if they contain an alt-address [UTF8SMTP] 🍓

7. Security Considerations 🚨

Because use of both a UTF-8 address and an alt-address for the same entity introduces a potential ambiguity regarding the identity of list subscribers and message senders, implementers are advised to carefully handle authorization decisions regarding subscriptions, sender filters, and other common list administration features. For example, a binding between a UTF-8 address and an ASCII alt-address can be used by an attacker to deny another person admission to an Email Address Internationalization (EAI) mailing list. 💀

Other relevant security considerations are discussed in the Framework document [EAI-Framework] 🔐

8. Acknowledgments 🫶

Edmon Chung of Afilias wrote the original version of this document 👑 Thanks to Harald Alvestrand for his extensive comments. Ted Hardie contributed helpful text on IRIs. Last-Call comments from S. Moonesamy and Amanda Baber, plus shepherd review by Pete Resnick, improved the document 💜

9. References 📚

9.1. Normative References

[EAI-Framework]
           Klensin, J. and Y. Ko, "Overview and Framework for
           Internationalized Email", RFC 4952, July 2007.

[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[List-*]   Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax
           for Core Mail List Commands and their Transport through
           Message Header Fields", RFC 2369, July 1998.

[List-ID]  Chandhok, R. and G. Wenger, "List-Id: A Structured Field
           and Namespace for the Identification of Mailing Lists",
           RFC 2919, March 2001.

[RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
           Resource Identifier (URI): Generic Syntax", STD 66, RFC
           3986, January 2005.

[RFC5335]  Abel, Y., Ed., "Internationalized Email Headers", RFC
           5335, September 2008.

[submission]
           Gellens, R. and J. Klensin, "Message Submission for Mail",
           RFC 4409, April 2006.

[UTF8SMTP] Yao, J., Ed., and W. Mao, Ed., "SMTP Extension for
           Internationalized Email Addresses", RFC 5336, September
           2008.

9.2. Informative References

[EAI-Downgrade]
           Fujiwara, K., Ed., and Y. Yoneya, Ed., "Downgrading
           Mechanism for Email Address Internationalization", RFC
           5504, March 2009.

[IRI]      Duerst, M. and M. Suignard, "Internationalized Resource
           Identifiers (IRIs)", RFC 3987, January 2005.

[IRI-bis]  Duerst, M., Suignard, M., and L. Masinter,
           "Internationalized Resource Identifiers (IRIs)", Work in
           Progress, July 2010.

[mailto-bis]
           Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
           URI Scheme", Work in Progress, May 2010.

Author's Address 🎀

Randall Gellens
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA  92121
rg+ietf@qualcomm.com
📦 where this page comes from