Internet Engineering Task Force (IETF) J. Klensin
Request for Comments: 6530 Y. Ko
Obsoletes: 4952, 5504, 5825 February 2012
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Klensin
Request for Comments: 6530 Y. Ko
Obsoletes: 4952, 5504, 5825 February 2012
Category: Standards Track
ISSN: 2070-1721
Overview and Framework for Internationalized Email
国际化电子邮件的概述和框架
Abstract
摘要
Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is a replacement for RFC 4952; it reflects additional issues identified since that document was published.
在全世界范围内充分使用电子邮件要求（受其他限制）人们能够在电子邮件地址中使用自己姓名的近变体（用自己的语言和脚本正确书写）作为邮箱名称。本文档介绍了一系列规范，这些规范定义了完全支持国际化电子邮件地址所需的机制和协议扩展。这些更改包括SMTP扩展和电子邮件头语法扩展，以适应UTF-8数据。该文档集还包括对部署完全国际化电子邮件的关键假设和问题的讨论。本文件代替RFC 4952；它反映了自该文件发表以来查明的其他问题。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc6530.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6530.
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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您在以下方面的权利和限制：
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.
请参阅本文件。从本文件中提取的代码组件必须包括信托法律条款第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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Role of This Specification . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Mail User and Mail Transfer Agents . . . . . . . . . . . . 6
4.2. Address Character Sets . . . . . . . . . . . . . . . . . . 7
4.3. User Types . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Conventional Message and Internationalized Message . . . . 8
4.7. Undeliverable Messages, Notification, and Delivery
Receipts . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Overview of the Approach and Document Plan . . . . . . . . . . 9
6. Review of Experimental Results . . . . . . . . . . . . . . . . 9
7. Overview of Protocol Extensions and Changes . . . . . . . . . 10
7.1. SMTP Extension for Internationalized Email Address . . . . 10
7.2. Transmission of Email Header Fields in UTF-8 Encoding . . 11
7.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 12
8. Downgrading before and after SMTP Transactions . . . . . . . . 12
8.1. Downgrading before or during Message Submission . . . . . 13
8.2. Downgrading or Other Processing after Final SMTP
Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Downgrading in Transit . . . . . . . . . . . . . . . . . . . . 15
10. User Interface and Configuration Issues . . . . . . . . . . . 15
10.1. Choices of Mailbox Names and Unicode Normalization . . . . 15
11. Additional Issues . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Impact on URIs and IRIs . . . . . . . . . . . . . . . . . 17
11.2. Use of Email Addresses as Identifiers . . . . . . . . . . 17
11.3. Encoded Words, Signed Messages, and Downgrading . . . . . 18
11.4. Other Uses of Local Parts . . . . . . . . . . . . . . . . 18
11.5. Non-Standard Encapsulation Formats . . . . . . . . . . . . 19
12. Key Changes from the Experimental Protocols and Framework . . 19
13. Security Considerations . . . . . . . . . . . . . . . . . . . 19
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
15.1. Normative References . . . . . . . . . . . . . . . . . . . 21
15.2. Informative References . . . . . . . . . . . . . . . . . . 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Role of This Specification . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Mail User and Mail Transfer Agents . . . . . . . . . . . . 6
4.2. Address Character Sets . . . . . . . . . . . . . . . . . . 7
4.3. User Types . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Conventional Message and Internationalized Message . . . . 8
4.7. Undeliverable Messages, Notification, and Delivery
Receipts . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Overview of the Approach and Document Plan . . . . . . . . . . 9
6. Review of Experimental Results . . . . . . . . . . . . . . . . 9
7. Overview of Protocol Extensions and Changes . . . . . . . . . 10
7.1. SMTP Extension for Internationalized Email Address . . . . 10
7.2. Transmission of Email Header Fields in UTF-8 Encoding . . 11
7.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 12
8. Downgrading before and after SMTP Transactions . . . . . . . . 12
8.1. Downgrading before or during Message Submission . . . . . 13
8.2. Downgrading or Other Processing after Final SMTP
Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Downgrading in Transit . . . . . . . . . . . . . . . . . . . . 15
10. User Interface and Configuration Issues . . . . . . . . . . . 15
10.1. Choices of Mailbox Names and Unicode Normalization . . . . 15
11. Additional Issues . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Impact on URIs and IRIs . . . . . . . . . . . . . . . . . 17
11.2. Use of Email Addresses as Identifiers . . . . . . . . . . 17
11.3. Encoded Words, Signed Messages, and Downgrading . . . . . 18
11.4. Other Uses of Local Parts . . . . . . . . . . . . . . . . 18
11.5. Non-Standard Encapsulation Formats . . . . . . . . . . . . 19
12. Key Changes from the Experimental Protocols and Framework . . 19
13. Security Considerations . . . . . . . . . . . . . . . . . . . 19
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
15.1. Normative References . . . . . . . . . . . . . . . . . . . 21
15.2. Informative References . . . . . . . . . . . . . . . . . . 22
In order to use internationalized email addresses, it is necessary to internationalize both the domain part and the local part of email addresses. The domain part of email addresses is already internationalized [RFC5890], while the local part is not. Without the extensions specified in this document, the mailbox name is restricted to a subset of 7-bit ASCII [RFC5321]. Though MIME [RFC2045] enables the transport of non-ASCII data, it does not provide a mechanism for internationalized email addresses. In RFC 2047 [RFC2047], MIME defines an encoding mechanism for some specific message header fields to accommodate non-ASCII data. However, it does not permit the use of email addresses that include non-ASCII characters. Without the extensions defined here, or some equivalent set, the only way to incorporate non-ASCII characters in any part of email addresses is to use RFC 2047 coding to embed them in what RFC 5322 [RFC5322] calls the "display name" (known as a "name phrase" or by other terms elsewhere) of the relevant header fields. Information coded into the display name is invisible in the message envelope and, for many purposes, is not part of the address at all.
为了使用国际化的电子邮件地址，有必要对电子邮件地址的域部分和本地部分进行国际化。电子邮件地址的域部分已国际化[RFC5890]，而本地部分未国际化。如果没有本文档中指定的扩展名，邮箱名称将被限制为7位ASCII[RFC5321]的子集。尽管MIME[RFC2045]支持非ASCII数据的传输，但它不提供国际化电子邮件地址的机制。在RFC 2047[RFC2047]中，MIME为一些特定的消息头字段定义了一种编码机制，以容纳非ASCII数据。但是，它不允许使用包含非ASCII字符的电子邮件地址。如果没有此处定义的扩展名或某些等效集，在电子邮件地址的任何部分中包含非ASCII字符的唯一方法是使用RFC 2047编码将它们嵌入到RFC 5322[RFC5322]所称的相关标题字段的“显示名称”（称为“名称短语”或其他术语）。编码到显示名称中的信息在消息信封中是不可见的，并且出于许多目的，根本不是地址的一部分。
This document is a replacement for RFC 4952 [RFC4952]; it reflects additional issues, shared terminology, and some architectural changes identified since that document was published. It obsoletes that document. The experimental descriptions of in-transit downgrading [RFC5504] [RFC5825] are now irrelevant and no longer needed due to the changes discussed in Section 12. The RFC Editor is requested to move all three of those documents to Historic.
本文件代替RFC 4952[RFC4952]；它反映了自该文档发布以来发现的其他问题、共享术语和一些架构更改。它废弃了那份文件。由于第12节中讨论的变化，在途降级[RFC5504][RFC5825]的实验说明现在不相关，不再需要。要求RFC编辑器将所有这三个文档移动到历史位置。
The pronouns "he" and "she" are used interchangeably to indicate a human of indeterminate gender.
代词“他”和“她”交替使用，表示性别不确定的人。
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 BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
This document presents the overview and framework for an approach to the next stage of email internationalization. This new stage requires not only internationalization of addresses and header fields, but also associated transport and delivery models. A prior version of this specification, RFC 4952 [RFC4952], also provided an introduction to a series of experimental protocols [RFC5335] [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825]. This revised form provides overview and conceptual information for the Standards Track successors of a subset of those protocols. Details
本文档介绍了电子邮件国际化下一阶段方法的概述和框架。这个新阶段不仅需要地址和头字段的国际化，还需要相关的传输和交付模型。本规范的先前版本RFC 4952[RFC4952]还介绍了一系列实验协议[RFC5335][RFC5336][RFC5337][RFC5504][RFC5721][RFC5738][RFC5825]。该修订表格提供了这些协议子集的标准跟踪后续版本的概述和概念信息。细节
of the documents and the relationships among them appear in Section 5 and a discussion of what was learned from the experimental protocols and their implementations appears in Section 6.
第5节介绍了这些文件及其相互之间的关系，第6节讨论了从实验协议及其实现中学到的知识。
Taken together, these specifications provide the details for a way to implement and support internationalized email. The document itself describes how the various elements of email internationalization fit together and the relationships among the primary specifications associated with message transport, header formats, and handling.
总之，这些规范提供了实现和支持国际化电子邮件的详细信息。文档本身描述了电子邮件国际化的各种元素如何结合在一起，以及与消息传输、头格式和处理相关的主要规范之间的关系。
This document, and others that comprise the collection described above, assume a reasonable familiarity with the basic Internet electronic mail specifications and terminology [RFC5321] [RFC5322] and the MIME [RFC2045] and 8BITMIME [RFC6152] ones as well. While not strictly required to implement this specification, a general familiarity with the terminology and functions of IDNA [RFC5890] [RFC5891] [RFC5892] [RFC5893] [RFC5894] are also assumed.
本文档以及构成上述集合的其他文档假定对基本的Internet电子邮件规范和术语[RFC5321][RFC5322]以及MIME[RFC2045]和8BITMIME[RFC6152]有一定的了解。虽然不严格要求实施本规范，但也假定对IDNA[RFC5890][RFC5891][RFC5892][RFC5893][RFC5894]的术语和功能有一般的了解。
Internationalizing Domain Names in Applications (IDNA) [RFC5890] permits internationalized domain names, but deployment has not yet reached most users. One of the reasons for this is that we do not yet have fully internationalized naming schemes. Domain names are just one of the various names and identifiers that are required to be internationalized. In many contexts, until more of those identifiers are internationalized, internationalized domain names alone have little value.
应用程序中的国际化域名（IDNA）[RFC5890]允许国际化域名，但大多数用户尚未使用。其中一个原因是我们还没有完全国际化的命名方案。域名只是需要国际化的各种名称和标识符之一。在许多情况下，在更多的标识符国际化之前，国际化域名本身没有什么价值。
Email addresses are prime examples of why it is not good enough to just internationalize the domain name. As most observers have learned from experience, users strongly prefer email addresses that resemble names or initials to those involving seemingly meaningless strings of letters or numbers. Unless the entire email address can use familiar characters and formats, users will perceive email as being culturally unfriendly. If the names and initials used in email addresses can be expressed in the native languages and writing systems of the users, the Internet will be perceived as more natural, especially by those whose native language is not written in a subset of a Roman-derived script.
电子邮件地址是为什么仅仅国际化域名还不够好的主要例子。正如大多数观察家从经验中了解到的那样，与那些看似毫无意义的字母或数字串相比，用户更喜欢类似姓名或首字母的电子邮件地址。除非整个电子邮件地址可以使用熟悉的字符和格式，否则用户会认为电子邮件在文化上不友好。如果电子邮件地址中使用的姓名和首字母可以用用户的母语和书写系统表达，互联网将被视为更加自然，尤其是那些母语不是用罗马衍生脚本子集书写的人。
Internationalization of email addresses is not merely a matter of changing the SMTP envelope; or of modifying the "From:", "To:", and "Cc:" header fields; or of permitting upgraded Mail User Agents (MUAs) to decode a special coding and respond by displaying local characters. To be perceived as usable, the addresses must be internationalized and handled consistently in all of the contexts in which they occur. This requirement has far-reaching implications:
电子邮件地址的国际化不仅仅是更改SMTP信封的问题；或者修改“From:”、“To:”、“Cc:”标题字段；或者允许升级的邮件用户代理（MUA）解码特殊编码并通过显示本地字符进行响应。要被认为是可用的，地址必须国际化，并在它们出现的所有上下文中一致地处理。这一要求具有深远的影响：
collections of patches and workarounds are not adequate. Even if they were adequate, a workaround-based approach may result in an assortment of implementations with different sets of patches and workarounds having been applied with consequent user confusion about what is actually usable and supported. Instead, we need to build a fully internationalized email environment, focusing on permitting efficient communication among those who share a language and writing system. That, in turn, implies changes to the mail header environment to permit those header fields that are appropriately internationalized to utilize the full range of Unicode characters, an SMTP extension to permit UTF-8 [RFC3629] [RFC5198] mail addressing and delivery of those extended header fields, support for internationalization of delivery and service notifications [RFC3461] [RFC3464], and (finally) a requirement for support of the 8BITMIME SMTP extension [RFC6152] so that all of these can be transported through the mail system without having to overcome the limitation that header fields do not have content-transfer-encodings.
修补程序和解决方法的集合不充分。即使它们是足够的，基于解决方案的方法可能会导致应用了不同补丁集和解决方案的各种实现，从而导致用户对什么是实际可用和支持的感到困惑。相反，我们需要建立一个完全国际化的电子邮件环境，重点是允许那些共享语言和书写系统的人之间进行有效沟通。这反过来又意味着对邮件头环境的更改，以允许对这些头字段进行适当的国际化，以利用全部Unicode字符，SMTP扩展允许对这些扩展头字段进行UTF-8[RFC3629][RFC5198]邮件寻址和传递，支持传递和服务通知国际化[RFC3461][RFC3464]，以及（最后）支持8BITMIME SMTP扩展[RFC6152]的要求，以便所有这些都可以通过邮件系统传输，而无需克服标头字段没有内容传输编码的限制。
This document assumes a reasonable understanding of the protocols and terminology of the core email standards as documented in RFC 5321 [RFC5321] and RFC 5322 [RFC5322].
本文件假设合理理解RFC 5321[RFC5321]和RFC 5322[RFC5322]中记录的核心电子邮件标准的协议和术语。
Much of the description in this document depends on the abstractions of "Mail Transfer Agent" ("MTA") and "Mail User Agent" ("MUA"). However, it is important to understand that those terms and the underlying concepts postdate the design of the Internet's email architecture and the application of the "protocols on the wire" principle to it. That email architecture, as it has evolved, and that "on the wire" principle have prevented any strong and standardized distinctions about how MTAs and MUAs interact on a given origin or destination host (or even whether they are separate).
本文档中的大部分描述依赖于“邮件传输代理”（“MTA”）和“邮件用户代理”（“MUA”）的抽象。然而，重要的是要理解，这些术语和基本概念追溯到互联网电子邮件体系结构的设计和“在线协议”原则的应用。随着电子邮件体系结构的发展，以及“在线”原则，使得MTA和MUA在给定的源主机或目标主机（甚至是它们是否分开）上的交互方式没有任何明显的标准化区别。
However, the term "final delivery MTA" is used in this document in a fashion equivalent to the term "delivery system" or "final delivery system" of RFC 5321. This is the SMTP server that controls the format of the local parts of addresses and is permitted to inspect and interpret them. It receives messages from the network for delivery to mailboxes or for other local processing, including any forwarding or aliasing that changes envelope addresses, rather than relaying. From the perspective of the network, any local delivery arrangements such as saving to a message store, handoff to specific message delivery programs or agents, and mechanisms for retrieving messages are all "behind" the final delivery MTA and hence are not part of the SMTP transport or delivery process.
但是，本文件中使用的术语“最终交付MTA”与RFC 5321中的术语“交付系统”或“最终交付系统”相同。这是SMTP服务器，控制地址的本地部分的格式，并允许检查和解释它们。它接收来自网络的消息，以便发送到邮箱或进行其他本地处理，包括更改信封地址的任何转发或别名，而不是中继。从网络的角度来看，任何本地传递安排（如保存到邮件存储、切换到特定邮件传递程序或代理以及检索邮件的机制）都是在最终传递MTA之后，因此不属于SMTP传输或传递过程的一部分。
In this document, an address is "all-ASCII", or just an "ASCII address", if every character in the address is in the ASCII character repertoire [ASCII]; an address is "non-ASCII", or an "i18n-address", if any character is not in the ASCII character repertoire. Such addresses MAY be restricted in other ways, but those restrictions are not relevant to this definition. The term "all-ASCII" is also applied to other protocol elements when the distinction is important, with "non-ASCII" or "internationalized" as its opposite.
在本文档中，如果地址中的每个字符都在ASCII字符表[ASCII]中，则地址为“全部ASCII”，或仅为“ASCII地址”；如果ASCII字符表中没有任何字符，则地址为“非ASCII”或“i18n地址”。此类地址可能会受到其他方式的限制，但这些限制与本定义无关。当区分很重要时，术语“所有ASCII”也适用于其他协议元素，与之相对的是“非ASCII”或“国际化”。
The umbrella term to describe the email address internationalization specified by this document and its companion documents is "SMTPUTF8". For example, an address permitted by this specification is referred to as a "SMTPUTF8 (compliant) address".
描述本文档及其配套文档指定的电子邮件地址国际化的总称为“SMTPUTF8”。例如，本规范允许的地址称为“SMTPUTF8（兼容）地址”。
Please note that, according to the definitions given here, the set of all "all-ASCII" addresses and the set of all "non-ASCII" addresses are mutually exclusive. The set of all addresses permitted when SMTPUTF8 appears is the union of these two sets.
请注意，根据此处给出的定义，所有“所有ASCII”地址集和所有“非ASCII”地址集是互斥的。SMTPUTF8出现时允许的所有地址集是这两个地址集的并集。
An "ASCII user" (i) exclusively uses email addresses that contain ASCII characters only, and (ii) cannot generate recipient addresses that contain non-ASCII characters.
“ASCII用户”（i）只使用仅包含ASCII字符的电子邮件地址，（ii）无法生成包含非ASCII字符的收件人地址。
An "internationalized email user" has one or more non-ASCII email addresses, or is able to generate recipient addresses that contain non-ASCII characters. Such a user may have ASCII addresses too; if the user has more than one email account and a corresponding address, or more than one alias for the same address, he or she has some method to choose which address to use on outgoing email. Note that under this definition, it is not possible to tell from an ASCII address if the owner of that address is an internationalized email user or not. (A non-ASCII address implies a belief that the owner of that address is an internationalized email user.) There is no such thing as an "internationalized email user message"; the term applies only to users and their agents and capabilities. In particular, the use of non-ASCII, and hence presumably internationalized, message content is an integral part of the MIME specifications [RFC2045] and does not require these extensions (although it is compatible with them).
“国际化电子邮件用户”具有一个或多个非ASCII电子邮件地址，或者能够生成包含非ASCII字符的收件人地址。这样的用户也可能有ASCII地址；如果用户有多个电子邮件帐户和相应的地址，或者同一地址有多个别名，则用户可以通过某种方法选择在发送电子邮件时使用的地址。请注意，根据此定义，无法从ASCII地址判断该地址的所有者是否为国际化电子邮件用户。（非ASCII地址意味着相信该地址的所有者是国际化电子邮件用户。）没有“国际化电子邮件用户消息”这样的东西；该术语仅适用于用户及其代理和功能。特别是，使用非ASCII（因此可能是国际化的）消息内容是MIME规范[RFC2045]不可分割的一部分，不需要这些扩展（尽管它与MIME规范兼容）。
A "message" is sent from one user (the sender) using a particular email address to one or more other recipient email addresses (often referred to just as "users" or "recipient users").
“消息”从一个用户（发送者）使用特定的电子邮件地址发送到一个或多个其他收件人电子邮件地址（通常称为“用户”或“收件人用户”）。
A "mailing list" is a mechanism whereby a message may be distributed to multiple recipients by sending it to one recipient address. An agent (typically not a human being) at that single address then causes the message to be redistributed to the target recipients. This agent sets the envelope return address of the redistributed message to a different address from that of the original single recipient message. Using a different envelope return address (reverse-path) causes error (and other automatically generated) messages to go to an error-handling address.
“邮件列表”是一种机制，通过将邮件发送到一个收件人地址，可以将邮件分发给多个收件人。然后，位于该地址的代理（通常不是人）会将邮件重新分发给目标收件人。此代理将重新分发邮件的信封返回地址设置为与原始单个收件人邮件不同的地址。使用不同的信封返回地址（反向路径）会导致错误（和其他自动生成的）消息转到错误处理地址。
Special provisions for managing mailing lists that might contain non-ASCII addresses are discussed in a document that is specific to that topic [RFC5983] and its expected successor [RFC5983bis-MailingList].
管理可能包含非ASCII地址的邮件列表的特殊规定在特定于该主题的文件[RFC5983]及其预期后续文件[RFC5983bis MailingList]中讨论。
o A conventional message is one that does not use any extension defined in the SMTP extension document [RFC6531] or in the UTF8header document [RFC6532] in this set of specifications, and is strictly conformant to RFC 5322 [RFC5322].
o 传统邮件不使用SMTP扩展文档[RFC6531]或本规范集合中UTF8header文档[RFC6532]中定义的任何扩展，并且严格符合RFC 5322[RFC5322]。
o An internationalized message is a message utilizing one or more of the extensions defined in this set of specifications, so that it is no longer conformant to the traditional specification of an email message or its transport.
o 国际化消息是使用本规范集中定义的一个或多个扩展的消息，因此它不再符合电子邮件消息或其传输的传统规范。
As specified in RFC 5321, a message that is undeliverable for some reason is expected to result in notification to the sender. This can occur in either of two ways. One, typically called "Rejection", occurs when an SMTP server returns a reply code indicating a fatal error (a "5yz" code) or persistently returns a temporary failure error (a "4yz" code). The other involves accepting the message during SMTP processing and then generating a message to the sender, typically known as a "Non-delivery Notification" or "NDN". Current practice often favors rejection over NDNs because of the reduced likelihood that the generation of NDNs will be used as a spamming technique. The latter, NDN, case is unavoidable if an intermediate MTA accepts a message that is then rejected by the next-hop server.
如RFC 5321中所述，由于某种原因无法传递的消息预计会导致通知发送方。这可以通过两种方式之一发生。当SMTP服务器返回指示致命错误的回复代码（“5yz”代码）或持续返回临时故障错误（“4yz”代码）时，会发生一种通常称为“拒绝”的情况。另一种是在SMTP处理过程中接受邮件，然后向发件人生成邮件，通常称为“未送达通知”或“NDN”。目前的做法通常倾向于拒绝NDN，因为生成NDN作为垃圾邮件技术的可能性降低。如果中间MTA接受消息，然后被下一跳服务器拒绝，则后一种情况（NDN）是不可避免的。
A sender MAY also explicitly request message receipts [RFC3461] that raise the same issues for these internationalization extensions as NDNs.
发送方还可以显式请求消息接收[RFC3461]，这些消息接收会对这些国际化扩展提出与NDN相同的问题。
This set of specifications changes both SMTP and the character encoding of email message headers to permit non-ASCII characters to be represented directly. Each important component of the work is described in a separate document. The document set, whose members are described below, also contains Informational documents whose purpose is to provide implementation suggestions and guidance for the protocols.
这组规范更改了SMTP和电子邮件消息头的字符编码，以允许直接表示非ASCII字符。工作的每个重要组成部分在单独的文件中描述。文件集（其成员如下所述）还包含信息性文件，其目的是为协议提供实施建议和指导。
In addition to this document, the following documents make up this specification and provide advice and context for it.
除本文件外，以下文件构成本规范，并为其提供建议和上下文。
o SMTP extension. The SMTP extension document [RFC6531] provides an SMTP extension (as provided for in RFC 5321) for internationalized addresses.
o SMTP分机。SMTP扩展文档[RFC6531]为国际化地址提供SMTP扩展（如RFC 5321中所述）。
o Email message headers in UTF-8. The email message header document [RFC6532] essentially updates RFC 5322 to permit some information in email message headers to be expressed directly by Unicode characters encoded in UTF-8 when the SMTP extension described above is used. This document, possibly with one or more supplemental ones, will also need to address the interactions with MIME, including relationships between SMTPUTF8 and internal MIME headers and content types.
o UTF-8中的电子邮件消息头。电子邮件头文档[RFC6532]实质上更新了RFC 5322，以允许在使用上述SMTP扩展时，电子邮件头中的某些信息直接由UTF-8编码的Unicode字符表示。本文档（可能有一个或多个补充文档）还需要解决与MIME的交互，包括SMTPUTF8与内部MIME头和内容类型之间的关系。
o Extensions to delivery status and notification handling to adapt to internationalized addresses [RFC6533].
o 对交付状态和通知处理的扩展，以适应国际化地址[RFC6533]。
o Forthcoming documents will specify extensions to the IMAP protocol [RFC3501] to support internationalized message headers [RFC5738bis-IMAP], parallel extensions to the POP protocol [RFC5721] [RFC5721bis-POP3], and some common properties of the two [POPIMAP-downgrade].
o 即将发布的文档将指定IMAP协议[RFC3501]的扩展，以支持国际化消息头[RFC5738bis IMAP]，POP协议[RFC5721][RFC5721bis-POP3]的并行扩展，以及两个[POPIMAP降级]的一些通用属性。
The key difference between this set of protocols and the experimental set that preceded them [RFC5335] [RFC5336] [RFC5337] [RFC5504] [RFC5721] [RFC5738] [RFC5825] is that the earlier group provided a mechanism for in-transit downgrading of messages (described in detail in RFC 5504). That mechanism permitted, and essentially required, that each non-ASCII address be accompanied by an all-ASCII equivalent. That, in turn, raised security concerns associated with
这组协议与之前的实验组[RFC5335][RFC5336][RFC5337][RFC5504][RFC5721][RFC5738][RFC5825]之间的关键区别在于，早期组提供了一种消息传输中降级机制（在RFC 5504中详细描述）。该机制允许，并且本质上要求每个非ASCII地址都附带一个全ASCII等效地址。这反过来又引起了与之相关的安全问题
pairing of addresses that could not be authenticated. It also introduced the first incompatible change to Internet mail addressing in many years, raising concerns about interoperability issues if the new address forms "leaked" into legacy email implementations. After examining experience with the earlier, experimental, predecessors of these specifications, the working group that produced them concluded that the advantages of in-transit downgrading, were it feasible operationally, would be significant enough to overcome those concerns.
无法进行身份验证的地址配对。它还引入了多年来第一个不兼容的Internet邮件寻址更改，如果新的地址形式“泄漏”到旧的电子邮件实现中，则会引发对互操作性问题的担忧。在研究了这些规范的早期、实验性前辈的经验后，制定这些规范的工作组得出结论，如果在操作上可行，在途降级的优势将足以克服这些问题。
That turned out not to be the case, with interoperability problems among initial implementations. Prior to starting on the work that led to this set of specifications, the WG concluded that the combination of requirements and long-term implications of that earlier model were too complex to be satisfactory and that work should move ahead without it.
事实证明情况并非如此，因为初始实现之间存在互操作性问题。在开始制定这套规范的工作之前，工作组得出结论认为，早期模型的要求和长期影响的组合过于复杂，无法令人满意，没有它，工作应该继续进行。
The other significant change to the protocols themselves is that the SMTPUTF8 keyword is now required as an SMTP client announcement if the extension is needed; in the experimental version, only the server announcement that an extended envelope and/or content were permitted was necessary.
协议本身的另一个重大变化是，如果需要扩展，现在需要SMTPUTF8关键字作为SMTP客户端公告；在实验版本中，只需要服务器声明允许扩展信封和/或内容。
An SMTP extension, "SMTPUTF8", is specified as follows:
SMTP扩展名“SMTPUTF8”指定如下：
o Permits the use of UTF-8 strings in email addresses, both local parts and domain names.
o 允许在电子邮件地址（本地部分和域名）中使用UTF-8字符串。
o Permits the selective use of UTF-8 strings in email message headers (see Section 7.2).
o 允许在电子邮件消息头中选择性使用UTF-8字符串（参见第7.2节）。
o Requires that the server advertise the 8BITMIME extension [RFC6152] and that the client support 8-bit transmission so that header information can be transmitted without using a special content-transfer-encoding.
o 要求服务器播发8BITMIME扩展[RFC6152]，并且客户端支持8位传输，以便在不使用特殊内容传输编码的情况下传输头信息。
Some general principles affect the development decisions underlying this work.
一些一般原则会影响这项工作背后的开发决策。
1. Email addresses enter subsystems (such as a user interface) that may perform charset conversions or other encoding changes. When the local part of the address includes characters outside the ASCII character repertoire, use of ASCII-compatible encoding (ACE) [RFC3492] [RFC5890] in the domain part is discouraged to
1. 电子邮件地址输入可能执行字符集转换或其他编码更改的子系统（如用户界面）。当地址的本地部分包含ASCII字符表之外的字符时，不鼓励在域部分中使用ASCII兼容编码（ACE）[RFC3492][RFC5890]来
promote consistent processing of characters throughout the address.
促进整个地址中字符的一致处理。
2. An SMTP relay MUST
2. 必须使用SMTP中继
* Either recognize the format explicitly, agreeing to do so via an ESMTP option, or
* 明确识别格式，同意通过ESMTP选项进行识别，或
* Reject the message or, if necessary, return a non-delivery notification message, so that the sender can make another plan.
* 拒绝邮件，或在必要时返回未送达通知邮件，以便发件人可以制定其他计划。
3. If the message cannot be forwarded because the next-hop system cannot accept the extension, it MUST be rejected or a non-delivery message MUST be generated and sent.
3. 如果由于下一跳系统无法接受扩展而无法转发消息，则必须拒绝该消息，或者必须生成并发送未送达消息。
4. In the interest of interoperability, charsets other than UTF-8 are prohibited in mail addresses and message headers being transmitted over the Internet. There is no practical way to identify multiple charsets properly with an extension similar to this without introducing great complexity.
4. 为了实现互操作性，在通过Internet传输的邮件地址和消息头中禁止使用UTF-8以外的字符集。使用类似于此的扩展来正确识别多个字符集，而不引入极大的复杂性，是没有实际方法的。
Conformance to the group of standards specified here for email transport and delivery requires implementation of the SMTP extension specification and the UTF-8 header specification. If the system implements IMAP or POP, it MUST conform to the internationalized IMAP [RFC5738bis-IMAP] or POP [RFC5721bis-POP3] specifications respectively.
要符合此处为电子邮件传输和传递指定的一组标准，需要实施SMTP扩展规范和UTF-8标头规范。如果系统实现IMAP或POP，则必须分别符合国际化IMAP[RFC5738bis IMAP]或POP[RFC5721bis-POP3]规范。
There are many places in MUAs or in a user presentation in which email addresses or domain names appear. Examples include the conventional "From:", "To:", or "Cc:" header fields; "Message-ID:" and "In-Reply-To:" header fields that normally contain domain names (but that may be a special case); and in message bodies. Each of these must be examined from an internationalization perspective. The user will expect to see mailbox and domain names in local characters, and to see them consistently. If non-obvious encodings, such as protocol-specific ACE variants, are used, the user will inevitably, if only occasionally, see them rather than "native" characters and will find that discomfiting or astonishing. Similarly, if different codings are used for mail transport and message bodies, the user is particularly likely to be surprised, if only as a consequence of the long-established "things leak" principle. The only practical way to avoid these sources of discomfort, in both the medium and the longer term, is to have the encodings used in transport be as similar to the encodings used in message headers and message bodies as possible.
MUAs或用户演示文稿中有许多地方显示电子邮件地址或域名。示例包括常规的“From:”、“To:”或“Cc:”标题字段；“消息ID:”和“回复：”标题字段通常包含域名（但这可能是一种特殊情况）；以及在消息体中。每一项都必须从国际化的角度来审视。用户将期望看到本地字符的邮箱和域名，并一致地看到它们。如果使用不明显的编码，例如特定于协议的ACE变体，用户将不可避免地（即使只是偶尔）看到它们而不是“本地”字符，并会发现这令人不安或惊讶。类似地，如果邮件传输和消息正文使用不同的编码，那么用户尤其可能会感到惊讶，如果这仅仅是长期存在的“东西泄漏”原则的结果。从中期和长期来看，避免这些不适源的唯一实用方法是使传输中使用的编码尽可能类似于消息头和消息体中使用的编码。
When email local parts are internationalized, they SHOULD be accompanied by arrangements for the message headers to be in the fully internationalized form. That form SHOULD use UTF-8 rather than ASCII as the base character set for the contents of header fields (protocol elements such as the header field names themselves are unchanged and remain entirely in ASCII). For transition purposes and compatibility with legacy systems, this can be done by extending the traditional MIME encoding models for non-ASCII characters in headers [RFC2045] [RFC2231], but even these should be based on UTF-8, rather than other encodings, if at all possible [RFC6055]. However, the target is fully internationalized message headers, as discussed in [RFC6532] and not an extended and painful transition.
当电子邮件本地部分被国际化时，它们应该伴随着消息头以完全国际化形式的安排。该表单应使用UTF-8而不是ASCII作为标题字段内容的基本字符集（协议元素（如标题字段名称）本身保持不变，并完全保持ASCII格式）。出于转换目的和与传统系统的兼容性，可以通过扩展头[RFC2045][RFC2231]中非ASCII字符的传统MIME编码模型来实现，但即使这些模型也应基于UTF-8，而不是其他编码（如果可能的话）[RFC6055]。然而，正如[RFC6532]中所讨论的，目标是完全国际化的消息头，而不是一个漫长而痛苦的转换。
The existing Delivery Status Notifications (DSNs) specification [RFC3461], which is a Draft Standard, is limited to ASCII text in the machine-readable portions of the protocol. "International Delivery and Disposition Notifications" [RFC6533] adds a new address type for international email addresses so an original recipient address with non-ASCII characters can be correctly preserved even after downgrading. If an SMTP server advertises both the SMTPUTF8 and the DSN extension, that server MUST implement internationalized DSNs including support for the ORCPT parameter specified in RFC 3461 [RFC3461].
现有的交付状态通知（DSNs）规范[RFC3461]是一个标准草案，仅限于协议机器可读部分中的ASCII文本。“国际传递和处置通知”[RFC6533]为国际电子邮件地址添加了新的地址类型，因此即使降级后，也可以正确保留具有非ASCII字符的原始收件人地址。如果SMTP服务器同时播发SMTPUTF8和DSN扩展，则该服务器必须实现国际化DSN，包括对RFC 3461[RFC3461]中指定的ORCPT参数的支持。
An important issue with these extensions is how to handle interactions between systems that support non-ASCII addresses and legacy systems that expect ASCII. There is, of course, no problem with ASCII-only systems sending to those that can handle internationalized forms because the ASCII forms are just a proper subset. But, when systems that support these extensions send mail, they MAY include non-ASCII addresses for senders, receivers, or both and might also provide non-ASCII header information other than addresses. If the extension is not supported by the first-hop system (i.e., the SMTP server accessed by the submission server acting as an SMTP client), message-originating systems SHOULD be prepared to either send conventional envelopes and message headers or to return the message to the originating user so the message may be manually downgraded to the traditional form, possibly using encoded words [RFC2047] in the message headers. Of course, such transformations imply that the originating user or system must have ASCII-only addresses available for all senders and recipients. Mechanisms by which such addresses may be found or identified are outside the scope
这些扩展的一个重要问题是如何处理支持非ASCII地址的系统与期望使用ASCII的遗留系统之间的交互。当然，只使用ASCII的系统发送给那些可以处理国际化表单的系统没有问题，因为ASCII表单只是一个适当的子集。但是，当支持这些扩展的系统发送邮件时，它们可能包括发送者、接收者或两者的非ASCII地址，还可能提供地址以外的非ASCII头信息。如果第一个跃点系统（即作为SMTP客户端的提交服务器访问的SMTP服务器）不支持扩展，消息发起系统应准备发送传统信封和消息头，或将消息返回给发起用户，以便可以手动将消息降级为传统形式，可能在消息头中使用编码字[RFC2047]。当然，这样的转换意味着原始用户或系统必须只有ASCII地址可用于所有发送者和接收者。可以找到或识别此类地址的机制不在范围之内
of these specifications as are decisions about the design of originating systems such as whether any required transformations are made by the user, the originating MUA, or the submission server.
这些规范包括关于原始系统设计的决策，例如是否由用户、原始MUA或提交服务器进行任何必需的转换。
A somewhat more complex situation arises when the first-hop system supports these extensions but some subsequent server in the SMTP transmission chain does not. It is important to note that most cases of that situation with forward-pointing addresses will be the result of configuration errors: especially if it hosts non-ASCII addresses, a final delivery MTA that accepts these extensions SHOULD NOT be configured with lower-preference MX hosts that do not. When the only non-ASCII address being transmitted is backward-pointing (e.g., in an SMTP MAIL command), recipient configuration cannot help in general. On the other hand, alternate, all-ASCII addresses for senders are those most likely to be authoritatively known by the submission environment or the sender herself. Consequently, if an intermediate SMTP relay that requires these extensions then discovers that the next system in the chain does not support them, it will have little choice other than to reject or return the message.
当第一跳系统支持这些扩展，但SMTP传输链中的某些后续服务器不支持这些扩展时，会出现更复杂的情况。需要注意的是，在这种情况下，使用前向地址的大多数情况都是由于配置错误造成的：特别是如果它承载非ASCII地址，则接受这些扩展的最终交付MTA不应配置为不接受这些扩展的低首选项MX主机。当传输的唯一非ASCII地址是反向指向（例如，在SMTP邮件命令中）时，收件人配置通常无法提供帮助。另一方面，发件人的所有ASCII地址都是提交环境或发件人自己最可能知道的授权地址。因此，如果需要这些扩展的中间SMTP中继随后发现链中的下一个系统不支持这些扩展，那么除了拒绝或返回消息之外，它将别无选择。
As discussed above, downgrading to an ASCII-only form may occur before or during the initial message submission. It might also occur after the delivery to the final delivery MTA in order to accommodate message stores, IMAP or POP servers, or clients that have different capabilities than the delivery MTA. These cases are discussed in the subsections below.
如上所述，降级为仅ASCII格式可能发生在初始消息提交之前或期间。它也可能发生在传递到最终传递MTA之后，以便容纳邮件存储、IMAP或POP服务器，或具有与传递MTA不同功能的客户端。下面的小节将讨论这些情况。
The IETF has traditionally avoided specifying the precise behavior of MUAs to provide maximum flexibility in the associated user interfaces. The SMTP standard [RFC5321], Section 6.4, gives wide latitude to MUAs and submission servers as to what might be supplied by the user as long as the result conforms with "on the wire" standards once it is injected into the public Internet. In that tradition, the discussion in the remainder of Section 8 is provided as general guidance rather than normative requirements.
IETF传统上避免指定MUA的精确行为，以在相关用户界面中提供最大的灵活性。SMTP标准[RFC5321]第6.4节为MUA和提交服务器提供了很大的自由度，只要结果符合“在线”标准（一旦注入公共互联网）。按照这种传统，第8节其余部分的讨论是作为一般性指导而不是规范性要求提供的。
Messages that require these extensions will sometimes be transferred to a system that does not support these extensions; it is likely that the most common cases will involve the combination of ASCII-only forward-pointing addresses with a non-ASCII backward-pointing one. Until the extensions described here have been universally implemented in the Internet email environment, senders who prefer to use non-ASCII addresses (or raw UTF-8 characters in header fields), even when their intended recipients use and expect all-ASCII ones, will need to be especially careful about the error conditions that can arise. The
需要这些扩展的消息有时会传输到不支持这些扩展的系统；最常见的情况可能包括仅ASCII前向地址与非ASCII后向地址的组合。在这里描述的扩展在Internet电子邮件环境中普遍实现之前，喜欢使用非ASCII地址（或标题字段中的原始UTF-8字符）的发件人，即使其预期收件人使用并期望使用所有ASCII地址，也需要特别小心可能出现的错误情况。这个
risks are especially great in environments in which non-delivery messages (or other indications from submission servers) are routinely dropped or ignored.
在经常删除或忽略未送达邮件（或来自提交服务器的其他指示）的环境中，风险尤其大。
Perhaps obviously, the most convenient time to find an ASCII address corresponding to an internationalized address is at the originating MUA or closely associated systems. This can occur either before the message is sent or after the internationalized form of the message is rejected. It is also the most convenient time to convert a message from the internationalized form into conventional ASCII form or to generate a non-delivery message to the sender if either is necessary. At that point, the user has a full range of choices available, including changing backward-pointing addresses, contacting the intended recipient out of band for an alternate address, consulting appropriate directories, arranging for translation of both addresses and message content into a different language, and so on. While it is natural to think of message downgrading as optimally being a fully automated process, we should not underestimate the capabilities of a user of at least moderate intelligence who wishes to communicate with another such user.
很明显，查找与国际化地址相对应的ASCII地址的最方便时间是在原始MUA或密切相关的系统。这可能发生在消息发送之前或消息的国际化形式被拒绝之后。这也是将消息从国际化格式转换为常规ASCII格式或在必要时生成未送达消息给发送方的最方便的时间。在这一点上，用户有一整套可用的选择，包括更改反向地址、联系带外的预期收件人以获得备用地址、查阅适当的目录、安排将地址和消息内容翻译成不同的语言，等等。虽然将消息降级视为最佳的全自动过程是很自然的，但我们不应低估希望与另一个此类用户通信的至少具有中等智能的用户的能力。
In this context, one can easily imagine modifications to message submission servers (as described in RFC 6409 [RFC6409]) so that they would perform downgrading operations or perhaps even upgrading ones. Such operations would permit receiving messages with one or more of the internationalization extensions discussed here and adapting the outgoing message, as needed, to respond to the delivery or next-hop environment the submission server encounters.
在这种情况下，可以很容易地想象对消息提交服务器的修改（如RFC6409[RFC6409]中所述），以便它们执行降级操作，甚至升级操作。此类操作将允许接收带有此处讨论的一个或多个国际化扩展的消息，并根据需要调整传出消息，以响应提交服务器遇到的传递或下一跳环境。
When an email message is received by a final delivery MTA, it is usually stored in some form. Then it is retrieved either by software that reads the stored form directly or by client software via some email retrieval mechanisms such as POP or IMAP.
当最终传递MTA收到电子邮件时，它通常以某种形式存储。然后通过直接读取存储表单的软件或通过一些电子邮件检索机制（如POP或IMAP）由客户端软件检索。
The SMTP extension described in Section 7.1 provides protection only in transport. It does not prevent MUAs and email retrieval mechanisms that have not been upgraded to understand internationalized addresses and UTF-8 message headers from accessing stored internationalized emails.
第7.1节中描述的SMTP扩展仅在传输中提供保护。它不会阻止尚未升级以理解国际化地址和UTF-8消息头的MUA和电子邮件检索机制访问存储的国际化电子邮件。
Since the final delivery MTA (or, to be more specific, its corresponding mail storage agent) cannot safely assume that agents accessing email storage will always be capable of handling the extensions proposed here, it MAY downgrade internationalized emails, specially identify messages that utilize these extensions, or both. If either or both of these actions were to be taken, the final
由于最终交付MTA（或更具体地说，其相应的邮件存储代理）无法安全地假定访问电子邮件存储的代理始终能够处理此处建议的扩展，因此它可能会降级国际化电子邮件，特别是识别使用这些扩展的邮件，或两者兼而有之。如果采取其中一项或两项行动，则最终
delivery MTA SHOULD include a mechanism to preserve or recover the original internationalized forms without information loss. Preservation of that information is necessary to support access by SMTPUTF8-aware agents.
交付MTA应包括一种机制，以在不丢失信息的情况下保留或恢复原始国际化表单。保存该信息对于支持SMTPUTF8感知代理的访问是必要的。
The base SMTP specification (Section 2.3.11 of RFC 5321 [RFC5321]) states that "due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address". This is not a new requirement; equivalent statements appeared in specifications in 2001 [RFC2821] and even in 1989 [RFC1123].
基本SMTP规范（RFC 5321[RFC5321]第2.3.11节）规定，“由于中间主机试图通过修改来优化传输时存在的问题由来已久，因此必须仅由地址的域部分中指定的主机解释和分配本地部分的语义”。这不是新的要求；2001年[RFC2821]甚至1989年[RFC1123]的规范中都出现了类似的声明。
Adherence to this rule means that a downgrade mechanism that transforms the local part of an email address cannot be utilized in transit. It can only be applied at the endpoints, specifically by the MUA or submission server or by the final delivery MTA.
遵守此规则意味着转换电子邮件地址本地部分的降级机制不能在传输过程中使用。它只能应用于端点，特别是MUA或提交服务器或最终交付MTA。
One of the reasons for this rule has to do with legacy email systems that embed mail routing information in the local part of the address field. Transforming the email address destroys such routing information. There is no way a server other than the final delivery server can know, for example, whether the local part of user%foo@example.com is a route ("user" is reached via "foo") or simply a local address.
此规则的原因之一与在地址字段的本地部分嵌入邮件路由信息的传统电子邮件系统有关。转换电子邮件地址会破坏此类路由信息。除了最终交付服务器之外，服务器无法知道，例如，用户%foo@example.com是一个路由（“用户”通过“foo”到达），或者仅仅是一个本地地址。
Internationalization of addresses and message headers, especially in combination with variations on character coding that are inherent to Unicode, may make careful choices of addresses and careful configuration of servers and DNS records even more important than they are for traditional Internet email. It is likely that, as experience develops with the use of these protocols, it will be desirable to produce one or more additional documents that offer guidance for configuration and interfaces. A document that discusses issues with MUAs, especially with regard to downgrading, is expected to be developed. The subsections below address some other issues.
地址和消息头的国际化，特别是结合Unicode固有的字符编码变化，可能会使地址的仔细选择、服务器和DNS记录的仔细配置比传统Internet电子邮件更为重要。随着使用这些协议的经验的发展，很可能需要生成一个或多个为配置和接口提供指导的附加文档。预计将编制一份与MUA讨论问题的文件，特别是关于降级的文件。下面的小节讨论了一些其他问题。
It has long been the case that the email syntax permits choices about mailbox names that are unwise in practice, if one actually intends the mailboxes to be accessible to a broad range of senders. The most often cited examples involve the use of case-sensitivity and tricky quoting of embedded characters in mailbox local parts. These
长期以来，电子邮件语法允许对邮箱名称进行选择，这在实践中是不明智的，如果一个人真的打算让大量发件人访问邮箱的话。最常引用的例子包括使用区分大小写和在邮箱本地部分中巧妙地引用嵌入字符。这些
deliberately unusual constructions are permitted by the protocols, and servers are expected to support them. Although they can provide value in special cases, taking advantage of them is almost always bad practice unless the intent is to create some form of security by obscurity.
协议允许故意不寻常的构造，并且服务器应支持这些构造。尽管它们在特殊情况下可以提供价值，但利用它们几乎总是不好的做法，除非其目的是通过模糊创造某种形式的安全。
In the absence of these extensions, SMTP clients and servers are constrained to using only those addresses permitted by RFC 5321. The local parts of those addresses MAY be made up of any ASCII characters except the control characters that RFC 5321 prohibits, although some of them MUST be quoted as specified there. It is notable in an internationalization context that there is a long history on some systems of using overstruck ASCII characters (a character, a backspace, and another character) within a quoted string to approximate non-ASCII characters. This form of internationalization was permitted by RFC 821 [RFC0821] but is prohibited by RFC 5321 because it requires a backspace character (a prohibited C0 control). Because RFC 5321 (and its predecessor, RFC 2821) prohibit the use of this character in ASCII mailbox names and it is even more problematic (for canonicalization and normalization reasons) in non-ASCII strings, backspace MUST NOT appear in SMTPUTF8 mailbox names.
在没有这些扩展的情况下，SMTP客户端和服务器只能使用RFC 5321允许的地址。这些地址的本地部分可以由除RFC 5321禁止的控制字符以外的任何ASCII字符组成，尽管其中一些字符必须按照此处的规定引用。值得注意的是，在国际化背景下，在一些系统上使用带引号的字符串中的超粗ASCII字符（一个字符、一个退格和另一个字符）来近似非ASCII字符已有很长的历史。RFC 821[RFC0821]允许这种形式的国际化，但RFC 5321禁止这种国际化，因为它需要退格字符（禁止的C0控件）。由于RFC 5321（及其前身RFC 2821）禁止在ASCII邮箱名称中使用此字符，而且在非ASCII字符串中使用此字符的问题更大（出于规范化和规范化原因），因此SMTPUTF8邮箱名称中不得出现退格。
For the particular case of mailbox names that contain non-ASCII characters in the local part, domain part, or both, special attention MUST be paid to Unicode normalization [Unicode-UAX15], in part because Unicode strings may be normalized by other processes independent of what a mail protocol specifies (this is exactly analogous to what may happen with quoting and dequoting in traditional addresses). Consequently, the following principles are offered as advice to those who are selecting names for mailboxes:
对于在本地部分、域部分或两者中包含非ASCII字符的邮箱名称的特殊情况，必须特别注意Unicode规范化[Unicode-UAX15]，部分原因是Unicode字符串可以由其他进程进行规范化，而不受邮件协议的规定（这与传统地址中的引用和取消引用完全类似）。因此，以下原则可作为为邮箱选择名称的建议：
o In general, it is wise to support addresses in Normalized form, using at least Normalization Form NFC. Except in circumstances in which NFKC would map characters together that the parties responsible for the destination mail server would prefer to be kept distinguishable, supporting the NFKC-conformant form would yield even more predictable behavior for the typical user.
o 通常，明智的做法是支持标准化形式的地址，至少使用标准化形式的NFC。除了在NFKC将字符映射到一起的情况下（负责目标邮件服务器的各方希望保持可区分），支持符合NFKC的表单将为典型用户产生更可预测的行为。
o It will usually be wise to support other forms of the same local-part string, either as aliases or by normalization of strings reaching the delivery server: the sender should not be depended upon to send the strings in normalized form.
o 通常明智的做法是支持相同本地部分字符串的其他形式，或者作为别名，或者通过将字符串标准化到传递服务器：不应依赖发送方以标准化形式发送字符串。
o Stated differently and in more specific terms, the rules of the protocol for local-part strings essentially provide that:
o 以不同的方式和更具体的术语表述，协议中关于局部字符串的规则基本上规定：
* Unnormalized strings are valid, but sufficiently bad practice that they may not work reliably on a global basis. Servers should not depend on clients to send normalized forms but should be aware that procedures on client machines outside the control of the MUA may cause normalized strings to be sent regardless of user intent.
* 未规范化的字符串是有效的，但这是非常糟糕的做法，它们可能无法在全局基础上可靠地工作。服务器不应依赖客户端发送规范化表单，但应注意，MUA控制范围之外的客户端计算机上的过程可能会导致发送规范化字符串，而不管用户意图如何。
* C0 (and presumably C1) controls (see The Unicode Standard [Unicode]) are prohibited, the first in RFC 5321 and the second by an obvious extension from it [RFC5198].
* C0（可能还有C1）控件（参见Unicode标准[Unicode]）是被禁止的，第一个在RFC 5321中，第二个在它的明显扩展[RFC5198]中。
* Other kinds of punctuation, spaces, etc., are risky practice. Perhaps they will work, and SMTP receiver code is required to handle them without severe errors (even if such strings are not accepted in addresses to be delivered on that server), but creating dependencies on them in mailbox names that are chosen is usually a bad practice and may lead to interoperability problems.
* 其他类型的标点符号、空格等都是危险的做法。也许它们可以工作，并且需要SMTP接收方代码来处理它们而不会出现严重错误（即使该服务器上要传递的地址中不接受此类字符串），但在所选邮箱名称中创建依赖项通常是一种不好的做法，可能会导致互操作性问题。
This section identifies issues that are not covered, or not covered comprehensively, as part of this set of specifications, but that will require ongoing review as part of deployment of email address and header internationalization.
本节确定了本规范未涵盖或未全面涵盖的问题，但作为电子邮件地址和标头国际化部署的一部分，需要持续审查。
The mailto: schema [RFC6068], and the discussion of it in the Internationalized Resource Identifier (IRI) specification [RFC3987], may need to be modified when this work is completed and standardized.
mailto:schema[RFC6068]以及国际化资源标识符（IRI）规范[RFC3987]中对它的讨论可能需要在这项工作完成并标准化后进行修改。
There are a number of places in contemporary Internet usage in which email addresses are used as identifiers for individuals, including as identifiers to Web servers supporting some electronic commerce sites and in some X.509 certificates [RFC5280]. These documents do not address those uses, but it is reasonable to expect that some difficulties will be encountered when internationalized addresses are first used in those contexts, many of which cannot even handle the full range of addresses permitted today.
在当代互联网使用的许多地方，电子邮件地址被用作个人的标识符，包括作为支持某些电子商务网站的Web服务器的标识符，以及一些X.509证书[RFC5280]。这些文件并未涉及这些用途，但可以合理预期，当国际化地址首次在这些环境中使用时，会遇到一些困难，其中许多甚至无法处理今天允许的全部地址范围。
One particular characteristic of the email format is its persistency: MUAs are expected to handle messages that were originally sent decades ago and not just those delivered seconds ago. As such, MUAs and mail filtering software, such as that specified in Sieve [RFC5228], will need to continue to accept and decode header fields that use the "encoded word" mechanism [RFC2047] to accommodate non-ASCII characters in some header fields. While extensions to both POP3 [RFC1939] and IMAP [RFC3501] have been defined that include automatic upgrading of messages that carry non-ASCII information in encoded form -- including RFC 2047 decoding -- of messages by the POP3 [RFC5721bis-POP3] or IMAP [RFC5738bis-IMAP] server, there are message structures and MIME content-types for which that cannot be done or where the change would have unacceptable side effects.
电子邮件格式的一个特殊特征是它的持久性：MUA被期望处理几十年前最初发送的消息，而不仅仅是几秒钟前发送的消息。因此，MUA和邮件过滤软件（如SIVE[RFC5228]中指定的）将需要继续接受和解码使用“编码字”机制[RFC2047]的头字段，以在某些头字段中容纳非ASCII字符。虽然已经定义了对POP3[RFC1939]和IMAP[RFC3501]的扩展，包括通过POP3[RFC5721bis-POP3]或IMAP[RFC5738bis IMAP]服务器自动升级携带编码形式的非ASCII信息的消息（包括RFC 2047解码），有些消息结构和MIME内容类型无法完成，或者更改会产生不可接受的副作用。
For example, message parts that are cryptographically signed, using e.g., S/MIME [RFC5751] or Pretty Good Privacy (PGP) [RFC3156], cannot be upgraded from the RFC 2047 form to normal UTF-8 characters without breaking the signature. Similarly, message parts that are encrypted may contain, when decrypted, header fields that use the RFC 2047 encoding; such messages cannot be 'fully' upgraded without access to cryptographic keys.
例如，使用S/MIME[RFC5751]或Pretty Good Privacy（PGP）[RFC3156]等加密签名的消息部分无法在不破坏签名的情况下从RFC 2047表单升级为正常UTF-8字符。类似地，加密的消息部分在解密时可包含使用RFC 2047编码的报头字段；如果不访问加密密钥，则无法“完全”升级此类消息。
Similar issues may arise if messages are signed and then subsequently downgraded, e.g., as discussed in Section 8.1, and then an attempt is made to upgrade them to the original form and then verify the signatures. Even the very subtle changes that may result from algorithms to downgrade and then upgrade again may be sufficient to invalidate the signatures if they impact either the primary or MIME body part headers. When signatures are present, downgrading must be performed with extreme care if at all.
如果消息经过签名并随后降级（如第8.1节所述），然后尝试将其升级为原始格式，然后验证签名，则可能会出现类似问题。即使是由于算法降级然后再次升级而导致的非常细微的更改也足以使签名失效，如果它们影响了主或MIME主体部分头。如果存在签名，则必须非常小心地进行降级。
Local parts are sometimes used to construct domain labels, e.g., the local part "user" in the address user@domain.example could be converted into a host name user.domain.example with its Web space at <http://user.domain.example> and the catch-all addresses any.thing.goes@user.domain.example.
本地部分有时用于构造域标签，例如地址中的本地部分“用户”user@domain.example可以转换为主机名user.domain.example，其Web空间位于<http://user.domain.example>“一网打尽”可以解决任何问题。goes@user.domain.example.
Such schemes are obviously limited by, among other things, the SMTP rules for domain names, and will not work without further restrictions for other local parts. Whether those limitations are relevant to these specifications is an open question. It may be simply another case of the considerable flexibility accorded to delivery MTAs in determining the mailbox names they will accept and how they are interpreted.
除其他外，此类方案显然受到域名SMTP规则的限制，如果没有其他本地部分的进一步限制，将无法工作。这些限制是否与这些规范相关是一个悬而未决的问题。这可能只是传递MTA在确定他们将接受的邮箱名称以及如何解释这些名称时具有相当大的灵活性的另一个例子。
Some applications use formats similar to the application/mbox format [RFC4155] instead of the message/digest form defined in RFC 2046, Section 5.1.5 [RFC2046] to transfer multiple messages as single units. Insofar as such applications assume that all stored messages use the message/rfc822 format described in RFC 2046, Section 5.2.1 [RFC2046] with ASCII message headers, they are not ready for the extensions specified in this series of documents, and special measures may be needed to properly detect and process them.
一些应用程序使用类似于应用程序/mbox格式[RFC4155]的格式，而不是RFC 2046第5.1.5节[RFC2046]中定义的消息/摘要格式，将多条消息作为单个单元传输。如果此类应用程序假定所有存储的消息都使用RFC 2046第5.2.1节[RFC2046]中描述的带有ASCII消息头的消息/rfc822格式，则它们尚未准备好进行本系列文档中指定的扩展，可能需要采取特殊措施来正确检测和处理它们。
The original framework for internationalized email addresses and headers was described in RFC 4952 and a subsequent set of experimental protocol documents. Those relationships are described in Section 3. The key architectural difference between the experimental specifications and this newer set is that the earlier specifications supported in-transit downgrading. Those mechanisms included the definition of syntax and functions to support passing alternate, all-ASCII addresses with the non-ASCII ones as well as special headers to indicate the downgraded status of messages. Those features were eliminated after experimentation indicated that they were more complex and less necessary than had been assumed earlier. Those issues are described in more detail in Sections 6 and 9.
RFC 4952和随后的一组实验协议文档中描述了国际化电子邮件地址和邮件头的原始框架。第3节描述了这些关系。实验性规范和新规范之间的关键架构差异在于，早期规范支持运输降级。这些机制包括定义语法和函数，以支持用非ASCII地址传递备用的所有ASCII地址，以及指示消息降级状态的特殊头。在实验表明这些特征比先前假设的更复杂、更不必要后，这些特征被消除。第6节和第9节将更详细地描述这些问题。
Any expansion of permitted characters and encoding forms in email addresses raises some risks. There have been discussions on so called "IDN-spoofing" or "IDN homograph attacks". These attacks allow an attacker (or "phisher") to spoof the domain or URLs of businesses or other entities. The same kind of attack is also possible on the local part of internationalized email addresses. It should be noted that the proposed fix involving forcing all displayed elements into normalized lowercase works for domain names in URLs, but not for email local parts since those are case sensitive.
电子邮件地址中允许的字符和编码形式的任何扩展都会带来一些风险。关于所谓的“IDN欺骗”或“IDN同音词攻击”已经有过讨论。这些攻击允许攻击者（或“网络钓鱼者”）欺骗企业或其他实体的域或URL。在国际化电子邮件地址的本地部分也可能发生同样的攻击。应该注意的是，建议的修复方案涉及强制所有显示元素使用标准化的小写字母，这适用于URL中的域名，但不适用于电子邮件本地部分，因为它们区分大小写。
Since email addresses are often transcribed from business cards and notes on paper, they are subject to problems arising from confusable characters (see [RFC4690]). These problems are somewhat reduced if the domain associated with the mailbox is unambiguous and supports a relatively small number of mailboxes whose names follow local system conventions. They are increased with very large mail systems in which users can freely select their own addresses.
由于电子邮件地址通常是从纸面名片和便笺中转录而来的，因此容易因易混淆字符而出现问题（请参见[RFC4690]）。如果与邮箱关联的域是明确的，并且支持名称遵循本地系统约定的邮箱数量相对较少，则这些问题会有所减少。他们增加了非常大的邮件系统，用户可以自由选择自己的地址。
The internationalization of email addresses and message headers must not leave the Internet less secure than it is without the required extensions. The requirements and mechanisms documented in this set of specifications do not, in general, raise any new security issues.
电子邮件地址和消息头的国际化不能使Internet的安全性低于没有所需扩展的情况。这组规范中记录的需求和机制通常不会引起任何新的安全问题。
They do require a review of issues associated with confusable characters -- a topic that is being explored thoroughly elsewhere (see, e.g., RFC 4690 [RFC4690]) -- and, potentially, some issues with UTF-8 normalization, discussed in RFC 3629 [RFC3629], and other transformations. Normalization and other issues associated with transformations and standard forms are also part of the subject of work described elsewhere [RFC5198] [RFC5893] [RFC6055].
它们确实需要审查与可混淆字符相关的问题——这是一个在其他地方正在深入探讨的主题（参见，例如，RFC 4690[RFC4690]）——以及可能与UTF-8规范化有关的一些问题（在RFC 3629[RFC3629]中讨论）和其他转换。规范化和其他与转换和标准表单相关的问题也是其他地方描述的工作主题的一部分[RFC5198][RFC5893][RFC6055]。
Some issues specifically related to internationalized addresses and message headers are discussed in more detail in the other documents in this set. However, in particular, caution should be taken that any "downgrading" mechanism, or use of downgraded addresses, does not inappropriately assume authenticated bindings between the internationalized and ASCII addresses. This potential problem can be mitigated somewhat by enforcing the expectation that most or all such transformations will be performed prior to final delivery by systems that are presumed to be under the administrative control of the sending user (as opposed to being performed in transit by entities that are not under the administrative control of the sending user).
本集中的其他文档将更详细地讨论与国际化地址和消息头相关的一些问题。但是，特别要注意的是，任何“降级”机制或使用降级地址都不会不适当地假定国际化地址和ASCII地址之间存在经过身份验证的绑定。通过强制执行这样的期望，可以在一定程度上缓解这个潜在问题，即大多数或所有这样的转换将在假定由发送用户管理控制的系统最终交付之前执行（而不是由不受发送用户管理控制的实体在传输过程中执行）。
The new UTF-8 header and message formats might also raise, or aggravate, another known issue. If the model creates new forms of an 'invalid' or 'malformed' message, then a new email attack is created: in an effort to be robust, some or most agents will accept such messages and interpret them as if they were well-formed. If a filter interprets such a message differently than the MUA used by the recipient, then it may be possible to create a message that appears acceptable under the filter's interpretation but that should be rejected under the interpretation given to it by that MUA. Such attacks already have occurred for existing messages and encoding layers, e.g., invalid MIME syntax, invalid HTML markup, and invalid coding of particular image types.
新的UTF-8报头和消息格式也可能引发或加剧另一个已知问题。如果该模型创建了新形式的“无效”或“格式错误”消息，则会创建新的电子邮件攻击：为了保持健壮性，一些或大多数代理会接受此类消息，并将其解释为格式正确。如果筛选器对此类消息的解释与收件人使用的MUA不同，则可能会创建一条消息，该消息在筛选器的解释下看起来是可接受的，但在该MUA给出的解释下应该被拒绝。现有消息和编码层已经发生了此类攻击，例如无效的MIME语法、无效的HTML标记和特定图像类型的无效编码。
In addition, email addresses are used in many contexts other than sending mail, such as for identifiers under various circumstances (see Section 11.2). Each of those contexts will need to be evaluated, in turn, to determine whether the use of non-ASCII forms is appropriate and what particular issues they raise.
此外，电子邮件地址用于除发送邮件以外的许多上下文，例如用于各种情况下的标识符（见第11.2节）。这些上下文中的每一个都需要依次进行评估，以确定使用非ASCII格式是否合适，以及它们会引起哪些特殊问题。
This work will clearly affect any systems or mechanisms that are dependent on digital signatures or similar integrity protection for email message headers (see also the discussion in Section 11.3). Many conventional uses of PGP and S/MIME are not affected since they
这项工作将明显影响任何依赖于数字签名或电子邮件消息头类似完整性保护的系统或机制（另请参见第11.3节中的讨论）。PGP和S/MIME的许多传统用法不受影响，因为它们
are used to sign body parts but not message headers. On the other hand, the developing work on DomainKeys Identified Mail (DKIM) [RFC5863] will eventually need to consider this work, and vice versa: while this specification does not address or solve the issues raised by DKIM and other signed header mechanisms, the issues will have to be coordinated and resolved eventually if the two sets of protocols are to coexist. In addition, to the degree to which email addresses appear in PKI (Public Key Infrastructure) certificates [RFC5280], standards addressing such certificates will need to be upgraded to address these internationalized addresses. Those upgrades will need to address questions of spoofing by look-alikes of the addresses themselves.
用于签名正文部分，但不用于签名消息头。另一方面，DOMIN KEY识别邮件（DKIM）[RCF5863]的开发工作最终将需要考虑这项工作，反之亦然：虽然本规范没有解决或解决由DKIM和其他签名头机制提出的问题，如果这两套议定书要共存，这些问题最终必须得到协调和解决。此外，对于PKI（公钥基础设施）证书[RFC5280]中出现的电子邮件地址的程度，需要升级处理此类证书的标准，以处理这些国际化地址。这些升级需要解决通过地址本身的相似性进行欺骗的问题。
This document is an update to, and derived from, RFC 4952. This document would have been impossible without the work and contributions acknowledged in it. The present document benefited significantly from discussions in the IETF EAI working group and elsewhere after RFC 4952 was published, especially discussions about the experimental versions of other documents in the internationalized email collection, and from RFC errata on RFC 4952 itself.
本文件是对RFC 4952的更新，源于RFC 4952。如果没有其中所承认的工作和贡献，这份文件是不可能的。本文件从IETF EAI工作组和RFC 4952发布后的其他地方的讨论中获益匪浅，特别是关于国际化电子邮件收集中其他文件的实验版本的讨论，以及RFC 4952本身的RFC勘误表。
Special thanks are due to Ernie Dainow for careful reviews and suggested text in this version and to several IESG members for a careful review and specific suggestions.
特别感谢Ernie Dainow对本版本的仔细审查和建议文本，以及几位IESG成员对本版本的仔细审查和具体建议。
[ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange", ANSI X3.4-1968, 1968.
[ASCII]美国国家标准协会（前美国标准协会），“美国信息交换代码”，ANSI X3.4-1968，1968年。
ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet.
ANSI X3.4-1968已被稍作修改的较新版本所取代，但1968年版本仍然是互联网的最终版本。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月。
[RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP Service Extension for 8-bit MIME Transport", STD 71, RFC 6152, March 2011.
[RFC6152]Klensin，J.，Freed，N.，Rose，M.，和D.Crocker，“8位MIME传输的SMTP服务扩展”，STD 71，RFC 6152，2011年3月。
[RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Address", RFC 6531, February 2012.
[RFC6531]Yao，J.和W.Mao，“国际化电子邮件地址的SMTP扩展”，RFC 65312012年2月。
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, February 2012.
[RFC6532]Yang，A.，Steele，S.，和N.Freed，“国际化电子邮件标题”，RFC 6532，2012年2月。
[RFC6533] Hansen, T., Newman, C., and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 6533, February 2012.
[RFC6533]Hansen，T.，Newman，C.，和A.Melnikov，“国际化交付状态和处置通知”，RFC 65332012年2月。
[POPIMAP-downgrade] Fujiwara, K., "Post-delivery Message Downgrading for Internationalized Email Messages", Work in Progress, October 2011.
[POPIMAP降级]藤原，K.，“国际化电子邮件的投递后邮件降级”，正在进行的工作，2011年10月。
[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC0821]Postel，J.，“简单邮件传输协议”，STD 10，RFC 821，1982年8月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC1939]迈尔斯，J.和M.罗斯，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[RFC2231]Freed，N.和K.Moore，“MIME参数值和编码字扩展：字符集、语言和连续体”，RFC 22311997年11月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[RFC3156]Elkins，M.，Del Torto，D.，Levien，R.，和T.Roessler，“OpenPGP的MIME安全性”，RFC 3156，2001年8月。
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[RFC3461]Moore，K.，“用于传递状态通知（DSN）的简单邮件传输协议（SMTP）服务扩展”，RFC 3461，2003年1月。
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[RFC3464]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，2003年1月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]Costello，A.，“Punycode：应用程序中国际化域名的Unicode引导字符串编码（IDNA）”，RFC 3492，2003年3月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987]Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，2005年1月。
[RFC4155] Hall, E., "The application/mbox Media Type", RFC 4155, September 2005.
[RFC4155]Hall，E.“应用程序/mbox媒体类型”，RFC 4155，2005年9月。
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006.
[RFC4690]Klensin，J.，Faltstrom，P.，Karp，C.，和IAB，“国际化域名（IDN）的审查和建议”，RFC 46902006年9月。
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.
[RFC4952]Klensin，J.和Y.Ko，“国际化电子邮件的概述和框架”，RFC 49522007年7月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198]Klensin，J.和M.Padlipsky，“网络交换的Unicode格式”，RFC 51982008年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月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5335] Yang, A., "Internationalized Email Headers", RFC 5335, September 2008.
[RFC5335]Yang，A.“国际化电子邮件标题”，RFC 53352008年9月。
[RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008.
[RFC5336]Yao，J.和W.Mao，“国际化电子邮件地址的SMTP扩展”，RFC 53362008年9月。
[RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", RFC 5337, September 2008.
[RFC5337]Newman，C.和A.Melnikov，“国际化交付状态和处置通知”，RFC 5337，2008年9月。
[RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for Email Address Internationalization", RFC 5504, March 2009.
[RFC5504]Fujiwara，K.和Y.Yoneya，“电子邮件地址国际化的降级机制”，RFC 55042009年3月。
[RFC5721] Gellens, R. and C. Newman, "POP3 Support for UTF-8", RFC 5721, February 2010.
[RFC5721]Gellens，R.和C.Newman，“UTF-8的POP3支持”，RFC 57212010年2月。
[RFC5721bis-POP3] Gellens, R., Newman, C., Yao, J., and K. Fujiwara, "POP3 Support for UTF-8", Work in Progress, November 2011.
[RFC5721bis-POP3]Gellens，R.，Newman，C.，Yao，J.，和K.Fujiwara，“对UTF-8的POP3支持”，正在进行的工作，2011年11月。
[RFC5738] Resnick, P. and C. Newman, "IMAP Support for UTF-8", RFC 5738, March 2010.
[RFC5738]Resnick，P.和C.Newman，“UTF-8的IMAP支持”，RFC 5738，2010年3月。
[RFC5738bis-IMAP] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP Support for UTF-8", Work in Progress, December 2011.
[RFC5738bis IMAP]Resnick，P.，Ed.，Newman，C.，Ed.，和S.Shen，Ed.，“UTF-8的IMAP支持”，正在进行的工作，2011年12月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[RFC5825] Fujiwara, K. and B. Leiba, "Displaying Downgraded Messages for Email Address Internationalization", RFC 5825, April 2010.
[RFC5825]Fujiwara，K.和B.Leiba，“为电子邮件地址国际化显示降级邮件”，RFC 58252010年4月。
[RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, "DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations", RFC 5863, May 2010.
[RFC5863]Hansen，T.，Siegel，E.，Hallam Baker，P.，和D.Crocker，“域密钥识别邮件（DKIM）开发、部署和操作”，RFC 58632010年5月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 58912010年8月。
[RFC5892] Faltstrom, P., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, August 2010.
[RFC5892]Faltstrom，P.，“Unicode代码点和应用程序的国际化域名（IDNA）”，RFC 58922010年8月。
[RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, August 2010.
[RFC5893]Alvestrand，H.和C.Karp，“应用程序国际化域名（IDNA）的从右到左脚本”，RFC 58932010年8月。
[RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, August 2010.
[RFC5894]Klensin，J.“应用程序的国际化域名（IDNA）：背景、解释和基本原理”，RFC 58942010年8月。
[RFC5983] Gellens, R., "Mailing Lists and Internationalized Email Addresses", RFC 5983, October 2010.
[RFC5983]Gellens，R.，“邮件列表和国际化电子邮件地址”，RFC 59832010年10月。
[RFC5983bis-MailingList] Levine, J. and R. Gellens, "Mailing Lists and UTF-8 Addresses", Work in Progress, December 2011.
[RFC5983bis邮件列表]Levine，J.和R.Gellens，“邮件列表和UTF-8地址”，正在进行的工作，2011年12月。
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, February 2011.
[RFC6055]Thaler，D.，Klensin，J.，和S.Cheshire，“IAB对国际化域名编码的思考”，RFC 60552011年2月。
[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月。
[Unicode] The Unicode Consortium. The Unicode Standard, Version 6.0.0, defined by:, "The Unicode Standard, Version 6.0.0", (Mountain View, CA: The Unicode Consortium, 2011. ISBN 978-1-936213-01-6)., <http://www.unicode.org/versions/Unicode6.0.0/>.
[Unicode]Unicode联盟。Unicode标准，版本6.0.0，定义如下：，“Unicode标准，版本6.0.0”（加利福尼亚州山景城：Unicode联盟，2011年，ISBN 978-1-936213-01-6）<http://www.unicode.org/versions/Unicode6.0.0/>.
[Unicode-UAX15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", September 2010, <http://www.unicode.org/reports/tr15/>.
[Unicode-UAX15]Unicode联盟，“Unicode标准附件#15：Unicode规范化表单”，2010年9月<http://www.unicode.org/reports/tr15/>.
Authors' Addresses
作者地址
John C KLENSIN 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
美国马萨诸塞州剑桥市322号马萨诸塞大道1770号约翰·C·克伦辛，邮编：02140
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
YangWoo KO 112-202 Malgeunachim APT. Nae-dong Seo-gu, Daejeon 302-981 Republic of Korea
韩国大田阳湖KO 112-202 Malgeunachim Nae dong Seo gu公寓302-981
EMail: yangwooko@gmail.com
EMail: yangwooko@gmail.com