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




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


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 ( 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文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您在以下方面的权利和限制:

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.


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


Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  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
1. Introduction
1. 介绍

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]中的说明进行解释。

2. Role of This Specification
2. 本规范的作用

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.


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.


3. Problem Statement
3. 问题陈述

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.


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:


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]的要求,以便所有这些都可以通过邮件系统传输,而无需克服标头字段没有内容传输编码的限制。

4. Terminology
4. 术语

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]中记录的核心电子邮件标准的协议和术语。

4.1. Mail User and Mail Transfer Agents
4.1. 邮件用户和邮件传输代理

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


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传输或传递过程的一部分。

4.2. Address Character Sets
4.2. 地址字符集

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.


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


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.


4.3. User Types
4.3. 用户类型

An "ASCII user" (i) exclusively uses email addresses that contain ASCII characters only, and (ii) cannot generate recipient addresses that contain non-ASCII characters.


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


4.4. Messages
4.4. 信息

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


4.5. Mailing Lists
4.5. 邮件列表

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]中讨论。

4.6. Conventional Message and Internationalized Message
4.6. 传统报文与国际化报文

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 国际化消息是使用本规范集中定义的一个或多个扩展的消息,因此它不再符合电子邮件消息或其传输的传统规范。

4.7. Undeliverable Messages, Notification, and Delivery Receipts
4.7. 无法送达的邮件、通知和送达回执

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.


5. Overview of the Approach and Document Plan
5. 方法和文件计划概述

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.


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降级]的一些通用属性。

6. Review of Experimental Results
6. 实验结果回顾

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.


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.


7. Overview of Protocol Extensions and Changes
7. 协议扩展和更改概述
7.1. SMTP Extension for Internationalized Email Address
7.1. 国际化电子邮件地址的SMTP扩展

An SMTP extension, "SMTPUTF8", is specified as follows:


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]规范。

7.2. Transmission of Email Header Fields in UTF-8 Encoding
7.2. UTF-8编码中电子邮件头字段的传输

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.


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.


7.3. SMTP Service Extension for DSNs
7.3. DSN的SMTP服务扩展

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参数的支持。

8. Downgrading before and after SMTP Transactions
8. SMTP事务前后降级

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


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.


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.


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.


8.1. Downgrading before or during Message Submission
8.1. 在邮件提交之前或提交期间降级

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.


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


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.


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.


8.2. Downgrading or Other Processing after Final SMTP Delivery
8.2. 最终SMTP传递后降级或其他处理

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.


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.


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


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.


9. Downgrading in Transit
9. 运输中的降级

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.


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 is a route ("user" is reached via "foo") or simply a local address.


10. User Interface and Configuration Issues
10. 用户界面和配置问题

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.


10.1. Choices of Mailbox Names and Unicode Normalization
10.1. 邮箱名称和Unicode规范化的选择

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:


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接收方代码来处理它们而不会出现严重错误(即使该服务器上要传递的地址中不接受此类字符串),但在所选邮箱名称中创建依赖项通常是一种不好的做法,可能会导致互操作性问题。

11. Additional Issues
11. 其他问题

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.


11.1. Impact on URIs and IRIs
11.1. 对URI和IRIs的影响

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.


11.2. Use of Email Addresses as Identifiers
11.2. 使用电子邮件地址作为标识符

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.


11.3. Encoded Words, Signed Messages, and Downgrading
11.3. 编码字、签名消息和降级

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.


11.4. Other Uses of Local Parts
11.4. 本地零件的其他用途

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.


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.


11.5. Non-Standard Encapsulation Formats
11.5. 非标准封装格式

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格式,则它们尚未准备好进行本系列文档中指定的扩展,可能需要采取特殊措施来正确检测和处理它们。

12. Key Changes from the Experimental Protocols and Framework
12. 实验协议和框架的关键变化

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节将更详细地描述这些问题。

13. Security Considerations
13. 安全考虑

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.


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.


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.


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


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.


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.


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


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]中出现的电子邮件地址的程度,需要升级处理此类证书的标准,以处理这些国际化地址。这些升级需要解决通过地址本身的相似性进行欺骗的问题。

14. Acknowledgments
14. 致谢

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成员对本版本的仔细审查和具体建议。

15. References
15. 工具书类
15.1. Normative References
15.1. 规范性引用文件

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


[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月。

15.2. Informative References
15.2. 资料性引用

[POPIMAP-downgrade] Fujiwara, K., "Post-delivery Message Downgrading for Internationalized Email Messages", Work in Progress, October 2011.


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


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


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

[Unicode]Unicode联盟。Unicode标准,版本6.0.0,定义如下:,“Unicode标准,版本6.0.0”(加利福尼亚州山景城:Unicode联盟,2011年,ISBN 978-1-936213-01-6)<>.

[Unicode-UAX15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", September 2010, <>.


Authors' Addresses


John C KLENSIN 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA


   Phone: +1 617 491 5735
   Phone: +1 617 491 5735

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