Internet Engineering Task Force (IETF)                        R. Gellens
Request for Comments: 5983                                      Qualcomm
Category: Experimental                                      October 2010
ISSN: 2070-1721
Internet Engineering Task Force (IETF)                        R. Gellens
Request for Comments: 5983                                      Qualcomm
Category: Experimental                                      October 2010
ISSN: 2070-1721

Mailing Lists and Internationalized Email Addresses




This document describes considerations for mailing lists with the introduction of internationalized email addresses.


This document makes some specific recommendations on how mailing lists should act in various situations.


Status of This Memo


This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.


This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准;见RFC 5741第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice


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

版权所有(c)2010 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate 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 ....................................................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
1. 介绍

This document describes considerations for mailing lists with the introduction of internationalized email addresses [RFC5335].


Mailing lists are an important part of email usage and collaborative communications. The introduction of internationalized email addresses affects mailing lists in three main areas: (1) transport (receiving and sending messages), (2) message headers of received and retransmitted messages, and (3) mailing list operational policies.


A mailing list is a mechanism whereby a message may be distributed to multiple recipients by sending to one address. An agent (typically not a human being) at that single address receives the message and then causes the message to be redistributed to a list of recipients. This agent sets the envelope return address of the redistributed message to a different address from that of the original message. Using a different envelope return address (reverse-path) directs error (and other automatically generated) messages to an error


handling address associated with the mailing list. (This avoids having error and other automatic messages go to the original sender, who typically doesn't control the list and hence can't do anything about them.)


In most cases, the mailing list agent redistributes a received message to its subscribers as a new message, that is, conceptually it uses message submission [submission] (as did the sender of the original message). The exception, where the mailing list is not a separate agent that receives and redistributes messages in separate transactions, but is instead an expansion step within an SMTP transaction where one local address expands to multiple local or non-local addresses, is out of scope for this document.


Some mailing lists alter message header fields, while others do not. A number of standardized list-related header fields have been defined, and many lists add one or more of these header fields. Separate from these standardized list-specific header fields, and despite a history of interoperability problems from doing so, some lists alter or add header fields in an attempt to control where replies are sent. Such lists typically add or replace the "Reply-To" field and some add or replace the "Sender" field. Poorly behaved lists may alter or replace other fields, including "From".


Among these list-specific header fields are those specified 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]. For more information, see Section 5.

在这些特定于列表的头字段中,有RFC 2369(“使用URL作为核心邮件列表命令的元语法及其通过邮件头字段的传输”)[list-*]和RFC 2919(“列表Id:用于标识邮件列表的结构化字段和命名空间”)[list Id]中指定的头字段。有关更多信息,请参见第5节。

While the mail transport protocol does not differ between regular email recipients and mailing list recipients, lists have special considerations with internationalized email addresses because they retransmit messages composed by other agents to potentially many recipients.


There are considerations for internationalized email addresses in the envelope as well as in header fields of redistributed messages. In particular, an internationalized message cannot be downgraded unless all envelope addresses are available in ASCII (that is, each address either is ASCII or has an alt-address [UTF8SMTP]).


With mailing lists, there are two different types of considerations: first, the purely technical ones involving message handling, error cases, downgrades, and the like; and second, those that arise from the fact that humans use mailing lists to communicate. As an example of the first, mailing lists might choose to reject all messages from internationalized addresses that lack an alt-address, or even all


internationalized messages that cannot be downgraded. As an example of the second, a user who sends a message to a list often is unaware of the list membership. In particular, the user often doesn't know if the members are UTF-8 mail users or not, and often neither the original sender nor the recipients personally know each other. As a consequence of this, remedies that may be readily available for a missed email in one-to-one communications might not be appropriate when dealing with mailing lists. For example, if a user sends a message that is undeliverable, normally the telephone, instant messaging, or other forms of communication are available to obtain a working address. With mailing lists, the users may not have any recourse. Of course, with mailing lists, the original sender usually does not know if the message was successfully received by any list members or if it was undeliverable to some.


Conceptually, a mailing list's internationalization can be divided into three capabilities: First, does it have a UTF-8 submission or return-path address? Second, does it accept subscriptions to UTF-8 addresses? And third, does it accept [UTF8SMTP] messages? This is explored in Section 4.


A brief discussion on a few additional considerations for mailing list operation is in Section 6.


2. Conventions Used in This Document
2. 本文件中使用的公约

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
3. 涉及邮件列表的场景

Generally (and exclusively within the scope of this document), an original message is sent to a mailing list as a completely separate and independent transaction from the mailing 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 multiple recipients. That is, the original message might be sent to additional recipients as well as the mailing list agent, and the mailing list might choose to send the retransmitted message to each list recipient in a separate message submission [submission] transaction, or it might choose to include multiple recipients per transaction. (Often, mailing lists are constructed to work in cooperation with, rather than include the functionality of, a message submission server [submission], and hence the list transmits to a single submission server one copy of the retransmitted message, with


all list recipients specified in the SMTP envelope. The submission server then decides which recipients to include in which transaction.)


The retransmitted message sent by the mailing list to its subscribers might need to be downgraded [EAI-Downgrade]. In order for a downgrade to be possible, the return path set by the mailing list agent must be an ASCII address or have an alt-address [UTF8SMTP] specified. In addition, the recipient addresses need to have ASCII addresses available. It may be advisable for mailing list operators to pre-obtain an alt-address for all its internationalized member addresses.


In the case where a member or non-member with an internationalized email address is sending to a mailing list, no alt-address [UTF8SMTP] is specified, and a downgrade is required, the message cannot be delivered. To protect against this, a UTF8SMTP-aware [UTF8SMTP] mailing list might prefer to reject submissions from internationalized email addresses that lack an alt-address.


(Note that this situation is not unique to mailing lists. Mail relays that are UTF8SMTP-aware will potentially encounter the same situation.) Further discussions are included in Section 6 of this document.


4. Capabilities and Requirements
4. 能力和要求

There are three primary internationalization capabilities of mailing lists: 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 support any combination of these. In practice, only some offer any benefit. For example, neither allowing UTF-8 addresses to subscribe, nor accepting UTF8SMTP messages, makes much sense without the other (an all-ASCII address might or might not be capable of receiving UTF8SMTP messages, but a UTF-8 address of necessity needs to accept UTF8SMTP messages). Likewise, there is no real benefit to a list in using a UTF-8 submission address unless it also accepts UTF8SMTP messages and permits UTF-8 addresses to subscribe.


However, requirements for lists can be discussed separately for each of the three capabilities.


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

1. 如果列表使用UTF-8提交或返回路径地址,则应为其指定alt地址[UTF8SMTP]。显然,它需要位于启用UTF8SMTP的最终传递SMTP服务器后面

[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).


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

2. 如果允许UTF-8地址订阅,则可能需要为每个UTF-8订阅服务器指定一个alt地址[UTF8SMTP]。

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].

当然,如果它允许UTF-8地址订阅,那么它需要一种机制来接受来自这些地址的订阅请求(最好在表单中指定)<utf8@utf8 <ascii@ascii>>). 为了向拥有UTF-8地址的订阅者发送电子邮件,其MSA需要支持[UTF8SMTP]。

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

3. 如果它接受UTF8SMTP邮件,则其入站路径中的邮件传输代理(MTA)和邮件传递代理(MDA)需要支持UTF8SMTP。

5. List Header Fields
5. 列表标题字段

A number of header fields, specifically for mailing lists, have been introduced in RFCs 2369 and 2919. For example, these include:

RFCs 2369和2919中引入了一些标题字段,专门用于邮件列表。例如,这些措施包括:

   List-Id: List Header Mailing List <>
   List-Help: <>
   List-Unsubscribe: <>
   List-Subscribe: <>
   List-Post: <>
   List-Owner: <> (Contact Person for Help)
   List-Archive: <>
   List-Id: List Header Mailing List <>
   List-Help: <>
   List-Unsubscribe: <>
   List-Subscribe: <>
   List-Post: <>
   List-Owner: <> (Contact Person for Help)
   List-Archive: <>

As described in RFC 2369, "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].

如RFC 2369所述,“列表标题字段的内容主要由尖括号(“<”、“>”)括起的URL组成,内部空白被忽略”[list-*]。对于列表ID,RFC 2919指定,“在大多数情况下,列表标识符将显示为列表所有者域中的主机名”[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].

除列表ID标题字段外,这些邮件列表标题字段包含URL[RFC3986]。最常见的方案通常是HTTP、HTTPS、mailto和FTP。同时允许URI和国际化资源标识符(IRI)[IRI]形式的方案应使用[IRI]中描述的URI编码形式。未来的工作可能会扩展这些标题字段或定义替换,以直接支持IRIs中的非编码UTF-8(例如,[mailto bis]),但在没有此类扩展或替换的情况下,非ASCII字符只能在编码为ASCII时出现在中。请注意,关于国际化域名应采用百分比编码还是少量编码的讨论正在进行中;见[IRI之二]。

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.

即使没有扩展这些标题字段以支持UTF-8,在降级时,一些特殊的规定可能会有所帮助。特别是,如果列表-*头字段包含一个UTF-8 mailto(甚至用ASCII编码),后跟一个ASCII mailto,建议不仅照常复制和保留原始头字段(封装方法[EAI降级]),而且编辑头字段以删除UTF-8地址。否则,如果解码的mailto导致非ASCII地址,则客户端可能会遇到问题。

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; caution is called for when considering how to form and use these header fields 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-*头字段中最常用的URI模式往往是HTTP和mailto。mailto的当前规范不允许使用未编码的UTF-8字符,尽管已建议扩展或更可能替换mailto以允许使用未编码的UTF-8字符。对于mailto URI,另一个需要考虑的问题是如何为UTF-8地址包含备用ASCII地址(alt地址)[UTF8SMTP]。请注意,在每个列表-*标题字段中指定多个URL的现有功能提供了一种解决方案。

[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 the value of this header field remain 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. Such filters and tests may not properly compare a non-ASCII value that has been encoded into ASCII. In addition to these comparison considerations, it is 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
6. 进一步讨论

While mailing lists do not create a significant additional burden to the deployment of internationalized email address functionalities, there are some specific areas that need to be considered when the operator of a mailing list or of a final delivery MTA that serves a mailing list upgrades to internationalized mail.


Mailing lists face additional complexity since they redistribute messages composed by other agents. Hence, 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, which is UTF8SMTP-aware, 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 supports UTF8SMTP). In order to mitigate this situation, the mailing list might perhaps 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.

1. 获取降级信息——对于邮件列表或邮件中继服务器(支持UTF8SMTP),接收来自国际化电子邮件地址的邮件时,发送MTA不需要alt地址[UTF8SMTP]即可完成传输。当邮件列表将邮件重新传输给其订户时,可能会遇到需要降级的路径(如果中继或最终MSA不支持UTF8SMTP)。为了缓解这种情况,邮件列表可能会决定拒绝来自缺少alt地址的国际化电子邮件地址的所有传入邮件。然而,请注意,一般情况下,降级预计不会是正常情况。

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].

2. mailto URL的降级注意事项——如果列表-*标题字段中的mailto链接中的UTF-8地址包含alt地址[UTF8SMTP],则更容易降级。

7. Security Considerations
7. 安全考虑

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.

仔细处理有关订阅、发件人筛选器和其他常见列表管理功能的授权决策。例如,攻击者可以使用UTF-8地址和ASCII alt地址之间的绑定来拒绝他人进入电子邮件地址国际化(EAI)邮件列表。

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

框架文档[EAI Framework]中讨论了其他相关的安全注意事项。

8. Acknowledgments
8. 致谢

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.

阿菲利亚的埃德蒙·钟(Edmon Chung)编写了这份文件的原始版本。感谢Harald Alvestrand的广泛评论。特德·哈迪提供了有关IRIs的有用文本。S.Moonesamy和Amanda Baber的最后一次通话评论,加上Pete Resnick的shepherd评论,改进了文档。

9. References
9. 工具书类
9.1. Normative References
9.1. 规范性引用文件

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

[EAI框架]Klensin,J.和Y.Ko,“国际化电子邮件的概述和框架”,RFC 49522007年7月。

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

[关键词]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[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-*]Neufeld,G.和J.Baer,“将URL用作核心邮件列表命令的元语法及其通过消息头字段的传输”,RFC 2369,1998年7月。

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

[列表ID]Chandhok,R.和G.Wenger,“列表ID:用于识别邮件列表的结构化字段和名称空间”,RFC 2919,2001年3月。

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

[RFC3986]Berners Lee,T.,Fielding,R.,和L.Masinter,“统一资源标识符(URI):通用语法”,STD 66,RFC 3986,2005年1月。

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

[RFC5335]Abel,Y.,编辑,“国际化电子邮件标题”,RFC 53352008年9月。

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

[提交资料]Gellens,R.和J.Klensin,“邮件信息提交”,RFC 4409,2006年4月。

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

[UTF8SMTP]Yao,J.,Ed.,和W.Mao,Ed.,“国际化电子邮件地址的SMTP扩展”,RFC 53362008年9月。

9.2. Informative References
9.2. 资料性引用

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

[EAI降级]Fujiwara,K.,Ed.,和Y.Yoneya,Ed.,“电子邮件地址国际化的降级机制”,RFC 55042009年3月。

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

[IRI]Duerst,M.和M.Suignard,“国际化资源标识符(IRIs)”,RFC 3987,2005年1月。

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

[IRI bis]Duerst,M.,Suignard,M.,和L.Masinter,“国际化资源标识符(IRI)”,正在进行的工作,2010年7月。

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

[mailto bis]Duerst,M.,Masinter,L.,和J.Zawinski,“mailto”URI方案”,正在进行的工作,2010年5月。

Author's Address


Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121

Randall Gellens高通公司5775 Morehouse Drive San Diego,CA 92121