Internet Engineering Task Force (IETF) J. Levine
Request for Comments: 6783 Taughannock Networks
Obsoletes: 5983 R. Gellens
Category: Informational Qualcomm Incorporated
ISSN: 2070-1721 November 2012
Internet Engineering Task Force (IETF) J. Levine
Request for Comments: 6783 Taughannock Networks
Obsoletes: 5983 R. Gellens
Category: Informational Qualcomm Incorporated
ISSN: 2070-1721 November 2012
Mailing Lists and Non-ASCII Addresses
邮件列表和非ASCII地址
Abstract
摘要
This document describes considerations for mailing lists with the introduction of non-ASCII UTF-8 email addresses. It outlines some possible scenarios for handling lists with mixtures of non-ASCII and traditional addresses but does not specify protocol changes or offer implementation or deployment advice.
本文档介绍了引入非ASCII UTF-8电子邮件地址的邮件列表注意事项。它概述了处理非ASCII地址和传统地址混合的列表的一些可能场景，但没有指定协议更改或提供实现或部署建议。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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/rfc6783.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6783.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Mailing List Header Additions and Modifications . . . . . . 3
1.2. Non-ASCII Email Addresses . . . . . . . . . . . . . . . . . 3
2. Scenarios Involving Mailing Lists . . . . . . . . . . . . . . . 4
2.1. Fully SMTPUTF8 Lists . . . . . . . . . . . . . . . . . . . 4
2.2. Mixed SMTPUTF8 and ASCII Lists . . . . . . . . . . . . . . 5
2.3. SMTP Issues . . . . . . . . . . . . . . . . . . . . . . . . 5
3. List Headers . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. SMTPUTF8 List Headers . . . . . . . . . . . . . . . . . . . 6
3.2. Downgrading List Headers . . . . . . . . . . . . . . . . . 7
3.3. Subscribers' Addresses in Downgraded Headers . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Normative References . . . . . . . . . . . . . . . . . . . 8
5.2. Informative References . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Mailing List Header Additions and Modifications . . . . . . 3
1.2. Non-ASCII Email Addresses . . . . . . . . . . . . . . . . . 3
2. Scenarios Involving Mailing Lists . . . . . . . . . . . . . . . 4
2.1. Fully SMTPUTF8 Lists . . . . . . . . . . . . . . . . . . . 4
2.2. Mixed SMTPUTF8 and ASCII Lists . . . . . . . . . . . . . . 5
2.3. SMTP Issues . . . . . . . . . . . . . . . . . . . . . . . . 5
3. List Headers . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. SMTPUTF8 List Headers . . . . . . . . . . . . . . . . . . . 6
3.2. Downgrading List Headers . . . . . . . . . . . . . . . . . 7
3.3. Subscribers' Addresses in Downgraded Headers . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Normative References . . . . . . . . . . . . . . . . . . . 8
5.2. Informative References . . . . . . . . . . . . . . . . . . 9
This document describes considerations for mailing lists with the introduction of non-ASCII UTF-8 email addresses. The usage of such addresses is described in [RFC6530].
本文档介绍了引入非ASCII UTF-8电子邮件地址的邮件列表注意事项。[RFC6530]中描述了此类地址的用法。
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 that distributes a message to multiple recipients when the originator sends it to a single address. An agent, usually software rather than a person, at that single address receives the message and then causes the message to be redistributed to a list of recipients. This agent usually sets the envelope return address (henceforth called the "bounce address") of the redistributed message to a different address from that of the original message. Using a different bounce address directs error and other automatically generated messages to an error-handling address associated with the mailing list. This sends error and other automatic messages to the list agent, which can often do something useful with them, rather than 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 [RFC6409] (as did the sender of the original message). The exception, where the mailing list is not managed by a
在大多数情况下，邮件列表代理将收到的消息作为新消息重新分发给其订阅者，也就是说，从概念上讲，它使用消息提交[RFC6409]（与原始消息的发送者一样）。例外情况，邮件列表不是由
separate agent that receives and redistributes messages in separate transactions but is implemented by an expansion step within an SMTP transaction where one local address expands to multiple local or non-local addresses, is not addressed by this document.
单独代理在单独的事务中接收和重新分发邮件，但通过SMTP事务中的扩展步骤实现，其中一个本地地址扩展为多个本地或非本地地址，本文档不处理该代理。
Some list agents 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 headers. 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. Some lists alter or replace other fields, including "From".
一些列表代理更改消息头字段，而另一些则不更改。已经定义了许多与列表相关的标准化标题字段，许多列表添加了一个或多个此类标题。与这些标准化的特定于列表的标题字段不同，尽管这样做有互操作性问题的历史记录，但有些列表会更改或添加标题字段，试图控制回复的发送位置。这些列表通常添加或替换“回复”字段，有些添加或替换“发件人”字段。一些列表更改或替换其他字段，包括“From”。
Among these list-specific header fields are those specified in RFCs 2369 [RFC2369] and 2919 [RFC2919]. For more information, see Section 3.
在这些列表特定的头字段中，有RFCs 2369[RFC2369]和2919[RFC2919]中指定的头字段。有关更多信息，请参见第3节。
While the mail transport protocol is the same for regular email recipients and mailing list recipients, list agents have special considerations with non-ASCII email addresses because they retransmit messages composed by other agents to potentially many recipients.
虽然普通电子邮件收件人和邮件列表收件人的邮件传输协议相同，但列表代理对非ASCII电子邮件地址有特殊的考虑，因为它们将由其他代理组成的邮件重新传输给可能的多个收件人。
There are considerations for non-ASCII email addresses in the envelope as well as in header fields of redistributed messages. In particular, a message with non-ASCII addresses in the headers or envelope cannot be sent to non-SMTPUTF8 recipients.
对于信封中的非ASCII电子邮件地址以及重新分发的邮件的标题字段，都有一些注意事项。特别是，标题或信封中包含非ASCII地址的邮件不能发送给非SMTPUTF8收件人。
With mailing lists, there are two different types of considerations: first, the purely technical ones involving message handling, error cases, and the like, and second, those that arise from the fact that humans use mailing lists to communicate. As an example of the first, list agents might choose to reject all messages from non-ASCII addresses if they are unprepared to handle SMTPUTF8 mail. 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 SMTPUTF8 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 one-to-one communication 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
对于邮件列表，有两种不同类型的考虑因素：第一种是涉及消息处理、错误案例等的纯技术考虑因素，第二种是由于人类使用邮件列表进行通信而产生的考虑因素。作为第一个示例，如果列表代理不准备处理SMTPUTF8邮件，则可能会选择拒绝来自非ASCII地址的所有邮件。作为第二个示例，向列表发送消息的用户通常不知道列表成员身份。特别是，用户通常不知道成员是否是SMTPUTF8邮件用户，并且通常原始发件人和收件人都不认识对方。因此，在处理邮件列表时，一对一通信可能随时可用的补救措施可能并不合适。例如，如果用户发送了无法发送的消息，通常可以使用电话、即时消息或其他形式的通信来获取工作消息
address. With mailing lists, the users may not have any recourse. Of course, with mailing lists, the original sender usually does not know which list members successfully received a message or if it was undeliverable to some.
住址对于邮件列表，用户可能没有任何追索权。当然，对于邮件列表，原始发件人通常不知道哪些列表成员成功接收了邮件，或者邮件是否无法发送给某些人。
Conceptually, a mailing list's internationalization can be divided into three capabilities. First, does the list have a non-ASCII submission address? Second, does the list agent accept subscriptions for addresses containing non-ASCII characters? And third, does the list agent accept messages that require SMTPUTF8 capabilities?
从概念上讲，邮件列表的国际化可以分为三种功能。首先，列表是否有非ASCII提交地址？其次，列表代理是否接受包含非ASCII字符的地址的订阅？第三，列表代理是否接受需要SMTPUTF8功能的消息？
If a list has subscribers with ASCII addresses, those subscribers might or might not be able to accept SMTPUTF8 messages.
如果列表中的订阅服务器具有ASCII地址，则这些订阅服务器可能无法接受SMTPUTF8消息。
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 list agent sending the retransmitted message to one or more list recipients. In both cases, the message might be addressed only to the list address or might have recipients in addition to the list. Furthermore, the list agent might choose to send the retransmitted message to each list recipient in a separate message submission transaction or might choose to include multiple recipients per transaction. Often, list agents are constructed to work in cooperation with, rather than include the functionality of, a message submission server; hence, the list transmits to a single submission server one copy of the retransmitted message. The submission server then decides which recipients to include in which transaction.
通常（且仅在本文档范围内），原始邮件作为完全独立的事务发送到邮件列表，列表代理将重新传输的邮件发送给一个或多个列表收件人。在这两种情况下，邮件可能只发送到列表地址，或者除了列表之外还可能有收件人。此外，列表代理可以选择在单独的消息提交事务中向每个列表收件人发送重新传输的消息，或者可以选择在每个事务中包括多个收件人。通常，列表代理被构造为与消息提交服务器协作工作，而不是包含消息提交服务器的功能；因此，列表将重新传输的消息的一个副本传输到单个提交服务器。然后，提交服务器决定将哪些收件人包括在哪个事务中。
Some lists may wish to be fully SMTPUTF8. That is, all subscribers are expected to be able to receive SMTPUTF8 mail. For list hygiene reasons, such a list would probably want to prevent subscriptions from addresses that are unable to receive SMTPUTF8 mail. If a putative subscriber has a non-ASCII address, it must be able to receive SMTPUTF8 mail, but there is no way to tell whether a subscriber with an ASCII address can receive SMTPUTF8 mail short of sending an SMTPUTF8 probe or confirmation message and somehow finding out whether it was delivered, e.g., if the user clicked a link in the confirmation message.
有些列表可能希望完全是SMTPUTF8。也就是说，所有订户都希望能够接收SMTPUTF8邮件。出于列表卫生的原因，这样的列表可能会阻止来自无法接收SMTPUTF8邮件的地址的订阅。如果假定订阅者具有非ASCII地址，则必须能够接收SMTPUTF8邮件，但除了发送SMTPUTF8探测或确认消息并以某种方式查明邮件是否已送达之外，无法判断具有ASCII地址的订阅者是否能够接收SMTPUTF8邮件，例如。，如果用户单击了确认消息中的链接。
Other lists may wish to handle a mixture of SMTPUTF8 and ASCII subscribers, either as a transitional measure as subscribers upgrade to SMTPUTF8-capable mail software or as an ongoing feature. While it is not possible in general to downgrade SMTPUTF8 mail to ASCII mail, list software might divide the recipients into two sets, SMTPUTF8 and ASCII recipients, and create a downgraded version of SMTPUTF8 list messages to send to ASCII recipients. See Sections 3.2 and 3.3.
其他列表可能希望处理SMTPUTF8和ASCII订阅者的混合，作为订阅者升级到支持SMTPUTF8的邮件软件的过渡措施，或作为一项持续功能。虽然通常无法将SMTPUTF8邮件降级为ASCII邮件，但列表软件可能会将收件人分为两组，即SMTPUTF8和ASCII收件人，并创建SMTPUTF8列表邮件的降级版本以发送给ASCII收件人。见第3.2节和第3.3节。
To determine which set an address belongs in, list software might make the conservative assumption that ASCII addresses get ASCII messages, it might try to probe the address with an SMTPUTF8 test message, or it might let the subscriber set the message format manually, similar to the way that some lists now let subscribers choose between plain text and HTML mail, or individual messages and a daily digest.
为了确定地址属于哪一组，列表软件可能会保守地假设ASCII地址获得ASCII消息，它可能会尝试使用SMTPUTF8测试消息探测地址，或者它可能会让订阅者手动设置消息格式，类似于一些列表现在让订阅者在纯文本邮件和HTML邮件，或个人邮件和每日摘要之间进行选择的方式。
To determine whether a message needs to be downgraded for ASCII recipients, list software might assume that any message received via an SMTPUTF8 SMTP session is an SMTPUTF8 message or might examine the headers and body of the message to see whether it needs SMTPUTF8 treatment. Depending on the interface between the list software and the Mail Transfer Agent (MTA) and Mail Delivery Agent (MDA) that handle incoming messages, it may not be able to tell the type of session for incoming messages.
要确定ASCII收件人是否需要降级邮件，列表软件可能会假定通过SMTPUTF8 SMTP会话接收的任何邮件都是SMTPUTF8邮件，或者可能会检查邮件的标题和正文，以查看是否需要SMTPUTF8处理。根据列表软件与处理传入邮件的邮件传输代理（MTA）和邮件传递代理（MDA）之间的接口，它可能无法确定传入邮件的会话类型。
Mailing list software usually changes the envelope addresses on each message. The bounce address is set to an address that will return bounces to the list agent, and the recipient addresses are set to the subscribers of the list. For some lists, all messages to a list get the same bounce address. For others, list software may create a bounce address per recipient or a unique bounce address per message per recipient, bounce management techniques known as Variable Envelope Return Paths or VERP [VERP].
邮件列表软件通常会更改每封邮件的信封地址。反弹地址设置为将反弹返回列表代理的地址，收件人地址设置为列表的订阅者。对于某些列表，列表中的所有消息都会获得相同的跳出地址。对于其他人，列表软件可能会为每个收件人创建一个跳出地址，或为每个收件人的每条邮件创建一个唯一的跳出地址，跳出管理技术称为可变信封返回路径或VERP[VERP]。
The bounce address for a list typically includes the name of the list, so a list with a non-ASCII name will have a non-ASCII bounce address. Given the unknown paths that bounce messages might take, list software might instead use an ASCII bounce address to make it more likely that bounces can be delivered back to the list agent. Similarly, a VERP address for each subscriber typically embeds a version of the subscriber's address so the VERP bounce address for a non-ASCII subscriber address will be a non-ASCII address. For the same reason, the list software might use ASCII bounce addresses that encode the recipient's identity in some other way.
列表的跳出地址通常包括列表的名称，因此具有非ASCII名称的列表将具有非ASCII跳出地址。考虑到反弹消息可能采用的未知路径，列表软件可能会改为使用ASCII反弹地址，使反弹更有可能传递回列表代理。类似地，每个订户的VERP地址通常嵌入订户地址的一个版本，因此非ASCII订户地址的VERP跳转地址将是非ASCII地址。出于同样的原因，列表软件可能使用ASCII跳转地址，以其他方式对收件人的身份进行编码。
List agents typically add list-specific headers to each message before resending the message to list recipients.
列表代理通常在将邮件重新发送给列表收件人之前，向每条邮件添加特定于列表的标题。
The list headers in RFCs 2369 [RFC2369] and 2919 [RFC2919] were all specified before SMTPUTF8 mail existed, and their definitions do not address where non-ASCII characters might appear. These include, for example:
RFCs 2369[RFC2369]和2919[RFC2919]中的列表头都是在SMTPUTF8邮件存在之前指定的，它们的定义没有说明非ASCII字符可能出现的位置。这些措施包括，例如：
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 [RFC2369], "[t]he contents of the list header fields mostly consist of angle-bracket ('<', '>') enclosed URLs, with internal whitespace being ignored". [RFC2919] specifies that "[t]he list identifier will, in most cases, appear like a host name in a domain of the list owner". Since these headers were defined in the context of ASCII mail, these headers permit only ASCII text, including in the URLs.
如[RFC2369]所述，“列表标题字段的内容主要由尖括号（“<”、“>”）括起的URL组成，内部空白被忽略”。[RFC2919]指定“[t]在大多数情况下，列表标识符将在列表所有者的域中显示为主机名”。由于这些标题是在ASCII邮件的上下文中定义的，因此这些标题只允许ASCII文本，包括URL中的文本。
The most commonly used URI schemes in List-* headers tend to be http and mailto [RFC6068], although they sometimes include https and ftp and, in principle, can contain any valid URI.
List-*头中最常用的URI方案往往是http和mailto[RFC6068]，尽管它们有时包括https和ftp，原则上可以包含任何有效的URI。
Even if a scheme permits an internationalized form, it should use a pure ASCII form of the URI described in [RFC3986]. Future work may extend these header fields or define replacements to directly support unencoded non-ASCII outside the ASCII repertoire in these and other header fields, but in the absence of such extension or replacement, non-ASCII characters can only be included by encoding them as ASCII.
即使方案允许国际化形式，也应该使用[RFC3986]中描述的URI的纯ASCII形式。未来的工作可能会扩展这些标题字段或定义替换项，以直接支持这些和其他标题字段中ASCII指令表之外的未编码非ASCII字符，但在没有此类扩展或替换项的情况下，只能通过将非ASCII字符编码为ASCII字符来包含这些字符。
The encoding technique specified in [RFC3986] is to use a pair of hex digits preceded by a percent sign, but percent signs have been used informally in mail addresses to do source routing. Although few mail systems still permit source routing, a lot of mail software still forbids or escapes characters formerly used for source routing, which can lead to unfortunate interactions with percent-encoded URIs or any URI that includes one of those characters. If a program interpreting a mailto: URI knew that the Mail User Agent (MUA) in use were able to handle non-ASCII data, the program could pass the URI in unencoded non-ASCII, avoiding problems with misinterpreted percent signs, but at this point, there is no standard or even informal way for MUAs to signal SMTPUTF8 capabilities. Also, note that whether internationalized domain names should be percent-encoded or appear in A-label form [RFC5890] depends on the context in which they occur.
[RFC3986]中规定的编码技术是使用一对十六进制数字，前面有百分号，但在邮件地址中非正式地使用了百分号来进行源路由。虽然很少有邮件系统仍然允许源路由，但许多邮件软件仍然禁止或转义以前用于源路由的字符，这可能导致与百分比编码URI或任何包含其中一个字符的URI进行不幸的交互。如果解释mailto:URI的程序知道正在使用的邮件用户代理（MUA）能够处理非ASCII数据，则该程序可以以未编码的非ASCII方式传递URI，从而避免出现错误解释百分号的问题，但在这一点上，MUA没有标准甚至非正式的方式来表示SMTPUTF8功能。另外，请注意，国际化域名是否应进行百分比编码或以A标签形式出现[RFC5890]，取决于它们出现的上下文。
The List-ID header field uniquely identifies a list. The intent is that the value of this header 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 [RFC5228], and so forth. If the definition of a List-ID header field were to be extended to allow non-ASCII text, filters and tests might not properly compare encoded and unencoded versions of a non-ASCII value. 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标题字段唯一标识列表。其目的是，即使用于操作或承载列表的机器或系统发生变化，该标题的值也保持不变。此标题字段通常用于各种过滤器和测试，如客户端过滤器、筛选过滤器[RFC5228]等。如果要扩展列表ID标题字段的定义以允许非ASCII文本，则筛选器和测试可能无法正确比较非ASCII值的编码版本和未编码版本。除了这些比较注意事项外，通常希望此标题字段包含用户可以键入的有意义的内容。但是，非ASCII字符的ASCII编码不太可能对用户有意义，也不太容易让用户准确键入。
If list software prepares a downgraded version of an SMTPUTF8 message, all the List-* headers must be downgraded. In particular, if a List-* header contains a non-ASCII mailto (even encoded in ASCII), it may be advisable to edit the header to remove the non-ASCII address or replace it with an equivalent ASCII address if one is known to the list software. Otherwise, a client might run into trouble if the decoded mailto results in a non-ASCII address. If a header that contains a mailto URL is downgraded by percent encoding, some mail software may misinterpret the percent signs as attempted source routing.
如果列表软件准备SMTPUTF8消息的降级版本，则必须降级所有列表-*标题。特别是，如果列表-*头包含非ASCII mailto（甚至是用ASCII编码的），建议编辑该头以删除非ASCII地址，或者在列表软件已知的情况下用等效ASCII地址替换它。否则，如果解码的mailto导致非ASCII地址，则客户端可能会遇到问题。如果包含mailto URL的标头被百分比编码降级，则某些邮件软件可能会将百分比符号误解为尝试的源路由。
When downgrading list headers, it may not be possible to produce a downgraded version that is satisfactorily equivalent to the original header. In particular, if a non-ASCII List-ID is downgraded to an ASCII version, software and humans at recipient systems will typically not be able to tell that both refer to the same list.
降级列表标题时，可能无法生成令人满意地等同于原始标题的降级版本。特别是，如果非ASCII列表ID降级为ASCII版本，则接收方系统的软件和人员通常无法判断两者是否引用同一列表。
If lists permit mail with multiple MIME parts, some MIME headers in SMTPUTF8 messages may include non-ASCII characters in file names and other descriptive text strings. Downgrading these strings may lose the sense of the names, break references from other MIME parts (such as HTML IMG references to embedded images), and otherwise damage the mail.
如果列表允许邮件包含多个MIME部分，则SMTPUTF8消息中的某些MIME头可能在文件名和其他描述性文本字符串中包含非ASCII字符。降级这些字符串可能会失去名称的意义，中断来自其他MIME部分的引用（例如对嵌入图像的HTML IMG引用），或者损坏邮件。
List software typically leaves the original submitter's address in the From: line, both so that recipients can tell who wrote the message and so that they have a choice of responding to the list or directly to the submitter. If a submitter has a non-ASCII address, there is no way to downgrade the From: header and preserve the address so that ASCII recipients can respond to it, since non-SMTPUTF8 mail systems can't send mail to non-ASCII addresses.
列表软件通常将原始提交人的地址保留在From:行中，这样收件人就可以知道是谁写的邮件，并且他们可以选择回复列表还是直接回复提交人。如果提交者具有非ASCII地址，则无法降级From:标头并保留该地址，以便ASCII收件人可以响应该地址，因为非SMTPUTF8邮件系统无法将邮件发送到非ASCII地址。
Possible work-arounds (none implemented that we know of) might include allowing subscribers with non-ASCII addresses to register an alternate ASCII address with the list software, having the list software itself create ASCII forwarding addresses, or just putting the list's address in the From: line and losing the ability to respond directly to the submitter.
可能的解决办法（据我们所知，尚未实施）可能包括允许具有非ASCII地址的订阅者向列表软件注册备用ASCII地址，让列表软件本身创建ASCII转发地址，或者只是把列表的地址放在From:行，失去了直接回复提交者的能力。
None beyond what mailing list agents do now.
没有比邮件列表代理现在所做的更多的了。
[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月。
[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, October 2010.
[RFC6068]Duerst，M.，Masinter，L.，和J.Zawinski，“mailto”URI方案”，RFC 6068，2010年10月。
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011.
[RFC6409]Gellens，R.和J.Klensin，“邮件信息提交”，STD 72，RFC 6409，2011年11月。
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012.
[RFC6530]Klensin，J.和Y.Ko，“国际化电子邮件的概述和框架”，RFC6530，2012年2月。
[RFC2369] 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.
[RFC2369]Neufeld，G.和J.Baer，“使用URL作为核心邮件列表命令的元语法及其通过消息头字段的传输”，RFC 2369，1998年7月。
[RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001.
[RFC2919]Chandhok，R.和G.Wenger，“列表Id：用于识别邮件列表的结构化字段和名称空间”，RFC 2919，2001年3月。
[RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[RFC5228]Guenther，P.和T.Showalter，“筛选：电子邮件过滤语言”，RFC 5228，2008年1月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月。
[VERP] Bernstein, D., "Variable Envelope Return Paths", February 1997, <http://cr.yp.to/proto/verp.txt>.
[VERP]Bernstein，D.，“可变包络返回路径”，1997年2月<http://cr.yp.to/proto/verp.txt>.
Authors' Addresses
作者地址
John Levine Taughannock Networks PO Box 727 Trumansburg, NY 14886 US
美国纽约州杜鲁曼斯堡市约翰·莱文·塔甘诺克网络公司邮政信箱727号，邮编14886
Phone: +1 831 480 2300
EMail: standards@taugh.com
URI: http://jl.ly
Phone: +1 831 480 2300
EMail: standards@taugh.com
URI: http://jl.ly
Randall Gellens Qualcomm Incorporated 5775 Morehouse Drive San Diego, CA 92121 US
美国加利福尼亚州圣地亚哥Morehouse大道5775号Randall Gellens高通公司，邮编92121
EMail: rg+ietf@qti.qualcomm.com
EMail: rg+ietf@qti.qualcomm.com