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
邮件列表和国际化电子邮件地址
Abstract
摘要
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 http://www.rfc-editor.org/info/rfc5983.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5983.
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 (http://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 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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
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
This document describes considerations for mailing lists with the introduction of internationalized email addresses [RFC5335].
本文档介绍了引入国际化电子邮件地址的邮件列表注意事项[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.
邮件列表是电子邮件使用和协作通信的重要组成部分。国际化电子邮件地址的引入在三个主要方面影响邮件列表：（1）传输（接收和发送邮件），（2）接收和重新传输邮件的邮件头，以及（3）邮件列表操作策略。
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.
在大多数情况下，邮件列表代理将收到的消息作为新消息重新分发给订阅者，也就是说，从概念上讲，它使用消息提交[提交]（与原始消息的发送者一样）。例外情况是，邮件列表不是在单独事务中接收和重新分发邮件的单独代理，而是SMTP事务中的一个扩展步骤，其中一个本地地址扩展为多个本地或非本地地址，不在本文档的范围内。
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".
有些邮件列表会改变邮件标题字段，而其他邮件列表则不会。定义了许多与列表相关的标准化标题字段，许多列表添加了一个或多个此类标题字段。与这些标准化的特定于列表的标题字段不同，尽管这样做有互操作性问题的历史记录，但有些列表会更改或添加标题字段，试图控制回复的发送位置。此类列表通常添加或替换“回复”字段，有些添加或替换“发件人”字段。表现不佳的列表可能会更改或替换其他字段，包括“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]).
在信封中以及在重新分发的邮件的标题字段中，需要考虑国际化电子邮件地址。特别是，除非所有信封地址都是ASCII格式（即每个地址都是ASCII或具有alt地址[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
对于邮件列表，有两种不同类型的考虑因素：第一，涉及消息处理、错误案例、降级等的纯技术考虑因素；第二，这些是由于人类使用邮件列表进行交流而产生的。作为第一个示例，邮件列表可能会选择拒绝来自缺少alt地址的国际化地址的所有邮件，甚至拒绝所有邮件
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.
无法降级的国际化邮件。作为第二个示例，向列表发送消息的用户通常不知道列表成员身份。特别是，用户通常不知道成员是否是UTF-8邮件用户，并且通常原始发件人和收件人都不认识对方。因此，在处理邮件列表时，对于一对一通信中丢失的电子邮件可能随时可用的补救措施可能并不合适。例如，如果用户发送了无法送达的消息，通常可以通过电话、即时消息或其他形式的通信来获取工作地址。对于邮件列表，用户可能没有任何追索权。当然，对于邮件列表，原始发件人通常不知道消息是否已被任何列表成员成功接收，或者消息是否无法传递给某些成员。
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.
从概念上讲，邮件列表的国际化可以分为三种功能：第一，它是否具有UTF-8提交或返回路径地址？第二，它是否接受对UTF-8地址的订阅？第三，它是否接受[UTF8SMTP]消息？第4节对此进行了探讨。
A brief discussion on a few additional considerations for mailing list operation is in Section 6.
第6节简要讨论了邮件列表操作的一些附加注意事项。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
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.)
SMTP信封中指定的所有列表收件人。然后，提交服务器决定将哪些收件人包括在哪个事务中。）
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.
邮件列表发送给其订户的重传消息可能需要降级[EAI降级]。为了使降级成为可能，邮件列表代理设置的返回路径必须是ASCII地址或指定了alt地址[UTF8SMTP]。此外，收件人地址需要有可用的ASCII地址。邮件列表操作员最好预先获取其所有国际化成员地址的alt地址。
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.
如果具有国际化电子邮件地址的成员或非成员正在向邮件列表发送邮件，但未指定alt地址[UTF8SMTP]，并且需要降级，则无法传递邮件。为了防止出现这种情况，支持UTF8SMTP的[UTF8SMTP]邮件列表可能更愿意拒绝来自缺少alt地址的国际化电子邮件地址的提交。
(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.
（请注意，这种情况并非邮件列表所独有。UTF8SMTP感知的邮件中继可能会遇到相同的情况。）本文档第6节将进一步讨论。
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?
邮件列表有三个主要的国际化功能：第一，它是否有UTF-8提交或返回路径地址？第二，它是否允许从UTF-8地址订阅？第三，它是否接受[UTF8SMTP]消息？
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.
从理论上讲，任何列表都可以支持这些选项的任意组合。在实践中，只有一些能提供任何好处。例如，如果没有其他地址，则既不允许UTF-8地址订阅，也不接受UTF8SMTP消息都是有意义的（全ASCII地址可能能够接收UTF8SMTP消息，也可能无法接收UTF8SMTP消息，但必要时UTF-8地址需要接受UTF8SMTP消息）。同样，列表使用UTF-8提交地址也没有真正的好处，除非它还接受UTF8SMTP消息并允许UTF-8地址订阅。
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.
[UTF8SMTP]和传递代理。同样，如果列表使用UTF-8返回路径地址，则其消息提交代理（MSA）[提交]需要支持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).
列表的返回路径地址通常与其提交地址分开（因此传递报告和其他自动生成的消息不会发送到提交地址）。为确保接收传递状态通知的可靠性，列表可以选择使用全ASCII返回路径，即使它使用UTF-8提交地址。如果列表使用UTF-8返回路径，则必须指定alt地址[UTF8SMTP]（否则存在无法接收未送达报告的高风险）。
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。
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-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>
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 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.
当邮件列表使用列表-*标题字段的UTF-8格式时，还应使用ASCII格式。这些标题字段对于邮件列表的良好操作和使用至关重要；在考虑如何在非ASCII环境中形成和使用这些标题字段时，需要谨慎。
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.
多个备选URL的列表可以由逗号分隔的尖括号内URL列表指定。URL具有从左到右的优先顺序。客户端应用程序应该使用它支持的最左边的协议，或者知道如何通过单独的应用程序进行访问。
When a UTF-8 mailto is used in a List-* header field, an alt-address [UTF8SMTP], if available, SHOULD be supplied.
在列表-*标题字段中使用UTF-8邮件时，应提供alt地址[UTF8SMTP]，如果可用。
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.
列表ID标题字段提供唯一标识列表的不透明值。其目的是，即使用于操作或承载列表的机器或系统发生变化，此标题字段的值也保持不变。此标题字段通常用于各种过滤器和测试，例如客户端过滤器、筛选过滤器等。此类过滤器和测试可能无法正确比较已编码为ASCII的非ASCII值。除了这些比较注意事项外，通常希望此标题字段包含用户可以键入的有意义的内容。但是，非ASCII字符的ASCII编码不太可能对用户有意义，也不太容易让用户准确键入。
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.
虽然邮件列表不会给国际化电子邮件地址功能的部署带来额外的负担，但当邮件列表或为邮件列表提供服务的最终交付MTA的运营商升级到国际化邮件时，需要考虑一些特定的方面。
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.
邮件列表面临额外的复杂性，因为它们重新分发由其他代理组成的邮件。因此，可能会要求他们接受由UTF8SMTP感知用户代理[UTF8SMTP]组成的非ASCII头字段的邮件，并通过不感知UTF8SMTP的系统将其重新分发给UTF-8邮件和所有ASCII邮件用户。
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]，则更容易降级。
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
由于对同一实体同时使用UTF-8地址和alt地址会导致列表订阅者和消息发送者身份的潜在模糊性，建议实施者
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]中讨论了其他相关的安全注意事项。
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评论，改进了文档。
[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月。
[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 rg+ietf@qualcomm.com
Randall Gellens高通公司5775 Morehouse Drive San Diego，CA 92121 rg+ietf@qualcomm.com