Internet Engineering Task Force (IETF) K. Fujiwara
Request for Comments: 6857 JPRS
Category: Standards Track March 2013
ISSN: 2070-1721
Internet Engineering Task Force (IETF) K. Fujiwara
Request for Comments: 6857 JPRS
Category: Standards Track March 2013
ISSN: 2070-1721
Post-Delivery Message Downgrading for Internationalized Email Messages
国际化电子邮件的投递后邮件降级
Abstract
摘要
The Email Address Internationalization (SMTPUTF8) extension to SMTP allows Unicode characters encoded in UTF-8 and outside the ASCII repertoire in mail header fields. Upgraded POP and IMAP servers support internationalized messages. If a POP or IMAP client does not support Email Address Internationalization, a POP or IMAP server cannot deliver internationalized messages to the client and cannot remove the message. To avoid that situation, this document describes a mechanism for converting internationalized messages into the traditional message format. As part of the conversion process, message elements that require internationalized treatment are recoded or removed, and receivers are able to recognize that they received messages containing such elements, even if they cannot process the internationalized elements.
SMTP的电子邮件地址国际化（SMTPUTF8）扩展允许使用UTF-8编码的Unicode字符，并在邮件头字段中的ASCII指令表之外。升级的POP和IMAP服务器支持国际化消息。如果POP或IMAP客户端不支持电子邮件地址国际化，则POP或IMAP服务器无法向客户端传递国际化邮件，也无法删除该邮件。为了避免这种情况，本文档描述了将国际化消息转换为传统消息格式的机制。作为转换过程的一部分，需要国际化处理的消息元素将被重新编码或删除，并且接收者能够识别出他们接收到了包含此类元素的消息，即使他们无法处理国际化元素。
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/rfc6857.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6857.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
1.2. Possible Solutions . . . . . . . . . . . . . . . . . . . . 4
1.3. Approach Taken in This Specification . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Email Message Header Field Downgrading . . . . . . . . . . . . 7
3.1. Downgrading Method for Each ABNF Element . . . . . . . . . 7
3.1.1. Unstructured Downgrading . . . . . . . . . . . . . . . 7
3.1.2. Word Downgrading . . . . . . . . . . . . . . . . . . . 7
3.1.3. Comment Downgrading . . . . . . . . . . . . . . . . . 7
3.1.4. MIME-Value Downgrading . . . . . . . . . . . . . . . . 7
3.1.5. Display-Name Downgrading . . . . . . . . . . . . . . . 7
3.1.6. Domain Downgrading . . . . . . . . . . . . . . . . . . 8
3.1.7. Group Downgrading . . . . . . . . . . . . . . . . . . 8
3.1.8. Mailbox Downgrading . . . . . . . . . . . . . . . . . 8
3.1.9. Type-Addr Downgrading . . . . . . . . . . . . . . . . 9
3.1.10. Encapsulation: A Last Resort . . . . . . . . . . . . . 9
3.2. Downgrading Method for Each Header Field . . . . . . . . . 10
3.2.1. Address Header Fields That Contain <address>
Elements . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2. Non-ASCII Strings in <comment> Elements . . . . . . . 11
3.2.3. Message-ID Header Fields . . . . . . . . . . . . . . . 11
3.2.4. Received Header Field . . . . . . . . . . . . . . . . 11
3.2.5. MIME Content Header Fields . . . . . . . . . . . . . . 12
3.2.6. Non-ASCII Characters in <unstructured> Elements . . . 12
3.2.7. Non-ASCII Characters in <phrase> Elements . . . . . . 12
3.2.8. Other Header Fields . . . . . . . . . . . . . . . . . 12
4. MIME Body Parts and Delivery Status Notifications . . . . . . 12
4.1. MIME Body Part Header Field Downgrading . . . . . . . . . 13
4.2. Delivery Status Notification Downgrading . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Implementation Note: Encoded-Word Encoding . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1. Obsolescence of Existing Downgraded-* Header Fields . . . 15
7.2. Registration of New Downgraded-* Header Fields . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Downgrading Example . . . . . . . . . . . . . . . . . 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
1.2. Possible Solutions . . . . . . . . . . . . . . . . . . . . 4
1.3. Approach Taken in This Specification . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Email Message Header Field Downgrading . . . . . . . . . . . . 7
3.1. Downgrading Method for Each ABNF Element . . . . . . . . . 7
3.1.1. Unstructured Downgrading . . . . . . . . . . . . . . . 7
3.1.2. Word Downgrading . . . . . . . . . . . . . . . . . . . 7
3.1.3. Comment Downgrading . . . . . . . . . . . . . . . . . 7
3.1.4. MIME-Value Downgrading . . . . . . . . . . . . . . . . 7
3.1.5. Display-Name Downgrading . . . . . . . . . . . . . . . 7
3.1.6. Domain Downgrading . . . . . . . . . . . . . . . . . . 8
3.1.7. Group Downgrading . . . . . . . . . . . . . . . . . . 8
3.1.8. Mailbox Downgrading . . . . . . . . . . . . . . . . . 8
3.1.9. Type-Addr Downgrading . . . . . . . . . . . . . . . . 9
3.1.10. Encapsulation: A Last Resort . . . . . . . . . . . . . 9
3.2. Downgrading Method for Each Header Field . . . . . . . . . 10
3.2.1. Address Header Fields That Contain <address>
Elements . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2. Non-ASCII Strings in <comment> Elements . . . . . . . 11
3.2.3. Message-ID Header Fields . . . . . . . . . . . . . . . 11
3.2.4. Received Header Field . . . . . . . . . . . . . . . . 11
3.2.5. MIME Content Header Fields . . . . . . . . . . . . . . 12
3.2.6. Non-ASCII Characters in <unstructured> Elements . . . 12
3.2.7. Non-ASCII Characters in <phrase> Elements . . . . . . 12
3.2.8. Other Header Fields . . . . . . . . . . . . . . . . . 12
4. MIME Body Parts and Delivery Status Notifications . . . . . . 12
4.1. MIME Body Part Header Field Downgrading . . . . . . . . . 13
4.2. Delivery Status Notification Downgrading . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Implementation Note: Encoded-Word Encoding . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1. Obsolescence of Existing Downgraded-* Header Fields . . . 15
7.2. Registration of New Downgraded-* Header Fields . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Downgrading Example . . . . . . . . . . . . . . . . . 19
Traditional (legacy) mail systems, which are defined by the Internet Message Format [RFC5322] and other specifications, allow only ASCII characters in mail header field values. The SMTPUTF8 extension [RFC6530] [RFC6531] [RFC6532] allows Unicode characters encoded in UTF-8 [RFC3629] in these mail header fields. "Raw non-ASCII strings" refers to strings of those characters in which at least one of them is not part of the ASCII repertoire.
由Internet消息格式[RFC5322]和其他规范定义的传统（传统）邮件系统只允许在邮件头字段值中使用ASCII字符。SMTPUTF8扩展名[RFC6530][RFC6531][RFC6532]允许在这些邮件头字段中使用UTF-8[RFC3629]编码的Unicode字符。“原始非ASCII字符串”是指其中至少一个字符不属于ASCII指令集的字符串。
If a header field contains non-ASCII strings, a POP or IMAP server cannot deliver internationalized messages to legacy clients that do not send UTF8 commands or have UTF8 capability. Also, because they have no obvious or standardized way to explain what is going on to clients, a POP or IMAP server cannot even safely discard the message.
如果标头字段包含非ASCII字符串，则POP或IMAP服务器无法将国际化消息传递给不发送UTF8命令或具有UTF8功能的旧客户端。此外，由于它们没有明显或标准化的方式来解释客户端发生了什么，POP或IMAP服务器甚至无法安全地丢弃消息。
There are four plausible approaches to the problem. The preferred approach depends on the particular circumstances and relationship among the delivery SMTP server, the mail store, the POP or IMAP server, and the users and their Mail User Agent (MUA) clients. The four approaches are as follows:
解决这个问题有四种可行的方法。首选方法取决于传送SMTP服务器、邮件存储、POP或IMAP服务器以及用户及其邮件用户代理（MUA）客户端之间的特定情况和关系。这四种方法如下：
1. If the delivery Mail Transport Agent (MTA) has sufficient knowledge about the POP or IMAP server and the clients being used, the message may be rejected as undeliverable.
1. 如果传递邮件传输代理（MTA）对POP或IMAP服务器以及正在使用的客户端有足够的了解，则邮件可能会因无法传递而被拒绝。
2. A new, surrogate, message may be created by downgrading the original one in the POP or IMAP server in a way that preserves maximum information at the expense of some complexity and that does not create security or operational problems in the mail system. These surrogate messages are referred to as "downgraded" in this specification and as "surrogate messages" elsewhere.
2. 可以通过降低POP或IMAP服务器中原始邮件的级别来创建新的代理邮件，这种方式可以以牺牲某些复杂性的方式保留最大的信息，并且不会在邮件系统中造成安全或操作问题。这些代理消息在本规范中称为“降级”，在其他地方称为“代理消息”。
3. Some intermediate downgrading may be applied that balances additional information loss against lower complexity and greater ease of implementation.
3. 可以应用一些中间降级，以平衡额外的信息丢失与较低的复杂性和更易于实现之间的关系。
4. The POP or IMAP server may fabricate a message that is intended to notify the client that an internationalized message is waiting but cannot be delivered until an upgraded client is available.
4. POP或IMAP服务器可能会制造一条消息，用于通知客户机国际化消息正在等待，但在升级的客户机可用之前无法传递。
This specification describes the second of these options. It is worth noting that, at least in the general case, none of these options preserves sufficient information to guarantee that it is possible to reply to an incoming message without loss of information, so the choice may be considered one of the available "least bad" options. While this document specifies a well-designed mechanism, it is only an interim solution while clients are being upgraded [RFC6855] [RFC6856].
本规范描述了这些选项中的第二个。值得注意的是，至少在一般情况下，这些选项都不会保留足够的信息，以保证能够在不丢失信息的情况下回复传入消息，因此该选项可能被视为可用的“最不坏”选项之一。虽然本文档指定了一种设计良好的机制，但它只是客户机升级时的临时解决方案[RFC6855][RFC6856]。
This message downgrading mechanism converts mail header fields to an all-ASCII representation. The POP or IMAP server can use the downgrading mechanism and then deliver the internationalized message in a traditional form, which allows receivers to know whether a message is internationalized or unknown or broken.
此邮件降级机制将邮件标题字段转换为全ASCII表示形式。POP或IMAP服务器可以使用降级机制，然后以传统形式传递国际化消息，这允许接收者知道消息是国际化的、未知的还是中断的。
The Internationalized Mail Header specification [RFC6532] allows UTF-8 characters (see Section 2) to be used in mail header fields and MIME header fields. The Internationalized Mail Transport specification [RFC6531] allows UTF-8 characters to be used in some trace header fields. The message downgrading mechanism specified here describes the method by which internationalized messages [RFC6530] [RFC6532] are converted to traditional email messages [RFC5322].
国际化邮件头规范[RFC6532]允许在邮件头字段和MIME头字段中使用UTF-8字符（参见第2节）。国际化邮件传输规范[RFC6531]允许在某些跟踪头字段中使用UTF-8字符。此处指定的消息降级机制描述了将国际化消息[RFC6530][RFC6532]转换为传统电子邮件消息[RFC5322]的方法。
This document provides a precise definition of the minimum-information-loss message downgrading process.
本文件提供了最小信息丢失消息降级过程的精确定义。
Downgrading consists of the following two parts:
降级由以下两部分组成：
o Email header field downgrading
o 电子邮件标题字段降级
o MIME header field downgrading
o MIME头字段降级
Email header field downgrading is described in Section 3. It generates ASCII-only header fields.
第3节介绍了电子邮件标题字段降级。它只生成ASCII头字段。
Header fields starting with Downgraded- are introduced in Section 3.1.10. They preserve the information that appeared in the original header fields.
第3.1.10节介绍了以降级-开头的标题字段。它们保留出现在原始标题字段中的信息。
The definition of MIME header fields in internationalized messages is described in RFC 6532. A delivery status notification may contain non-ASCII addresses. MIME header field downgrading is described in Section 4.1. Delivery status notification downgrading is described in Section 4.2. It generates ASCII-only MIME header fields.
RFC 6532中描述了国际化消息中MIME头字段的定义。传递状态通知可能包含非ASCII地址。MIME头字段降级在第4.1节中有描述。第4.2节描述了交付状态通知降级。它只生成ASCII MIME头字段。
Displaying downgraded messages that originally contained internationalized header fields is out of scope of this document. A POP or IMAP client that does not support UTF8 extensions as defined for POP3 "UTF8 command" and IMAP "ENABLE UTF8=ACCEPT command" does not recognize the internationalized message format [RFC6532].
显示最初包含国际化标题字段的降级邮件超出了本文档的范围。不支持为POP3“UTF8命令”和IMAP“ENABLE UTF8=ACCEPT命令”定义的UTF8扩展的POP或IMAP客户端无法识别国际化消息格式[RFC6532]。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Many of the specialized terms used in this specification are defined in other documents. They include "Overview and Framework for Internationalized Email" [RFC6530], the Internet Message Format specification [RFC5322], and some of the basic MIME documents [RFC2045] [RFC2183]. This specification makes extensive use of the MIME Message Header Extensions [RFC2047] and extended MIME parameter encodings [RFC2231]. For convenience, both are described as "encoded-words" or "encoded-word encoding". All of the encoded-words generated according to this specification use UTF-8 as their charset.
本规范中使用的许多专用术语在其他文件中有定义。其中包括“国际化电子邮件概述和框架”[RFC6530]、互联网消息格式规范[RFC5322]和一些基本MIME文档[RFC2045][RFC2183]。本规范广泛使用MIME消息头扩展[RFC2047]和扩展MIME参数编码[RFC2231]。为了方便起见，两者都被描述为“编码字”或“编码字编码”。根据本规范生成的所有编码字都使用UTF-8作为其字符集。
The terms "U-label", "A-label", and "IDNA" are used as defined in the IDNA Definitions document [RFC5890]. The terms "ASCII address", "non-ASCII address", "SMTPUTF8", "message", and "internationalized message" are used as defined RFC 6530. The term "non-ASCII string" is used with the definition provided in the Internationalized Email Headers document [RFC6532]. The term "UTF-8 character" is used informally in this document to denote a Unicode character, encoded in UTF-8, outside the ASCII repertoire. Such characters are more formally described using the ABNF element <UTF8-non-ascii>, defined in RFC 6532.
术语“U标签”、“A标签”和“IDNA”的使用与IDNA定义文件[RFC5890]中的定义相同。术语“ASCII地址”、“非ASCII地址”、“SMTPUTF8”、“消息”和“国际化消息”按照RFC 6530的定义使用。术语“非ASCII字符串”与国际化电子邮件标题文档[RFC6532]中提供的定义一起使用。术语“UTF-8字符”在本文档中非正式地用于表示ASCII指令表之外的以UTF-8编码的Unicode字符。使用RFC 6532中定义的ABNF元素<UTF8 non ascii>，对此类字符进行更正式的描述。
This document refers to the Augmented Backus-Naur Form (ABNF) [RFC5234] elements that appear in RFC 5322 and RFC 2045. RFC 5322 describes the ABNF elements <CFWS>, <comment>, <display-name>, <group>, <id-left>, <id-right>, <mailbox>, <quoted-string>, <unstructured>, and <word>. RFC 2045 describes the ABNF element <value>. Section 3.3 of the Internationalized Mail Transport specification [RFC6531] and Section 3.2 of the Internationalized Email Headers document [RFC6532] updated <domain> to allow non-ASCII characters.
本文档引用了RFC 5322和RFC 2045中出现的扩充巴科斯诺尔表（ABNF）[RFC5234]元素。RFC 5322描述了ABNF元素<CFWS>、<comment>、<display name>、<group>、<id left>、<id right>、<mailbox>、<quoted string>、<unstructured>和<word>。RFC 2045描述了ABNF元素<value>。国际邮件传输规范[RFC6531]第3.3节和国际邮件标题文档[RFC6532]第3.2节更新了<domain>，允许使用非ASCII字符。
Some additional terms are defined locally in-line below.
一些附加术语在下面的行中本地定义。
This section defines the method for converting each header field that may contain non-ASCII strings into ASCII. Section 3.1 describes the methods for rewriting each ABNF element. Section 3.2 describes the methods for rewriting each header field.
本节定义了将可能包含非ASCII字符串的每个标题字段转换为ASCII的方法。第3.1节描述了重写每个ABNF元素的方法。第3.2节描述了重写每个标题字段的方法。
Header field downgrading is defined below for each ABNF element. Conversion of the header field terminates when no characters other than those in the ASCII repertoire remain in the header field.
下面为每个ABNF元素定义了标题字段降级。当标头字段中除ASCII指令表中的字符外没有其他字符保留时，标头字段的转换终止。
If the header field has an <unstructured> field that contains non-ASCII strings, apply encoded-word encoding.
如果标题字段具有包含非ASCII字符串的<unstructured>字段，请应用编码字编码。
If the header field has any <word> fields that contain non-ASCII strings, apply encoded-word encoding.
如果标题字段有任何包含非ASCII字符串的<word>字段，请应用编码字编码。
If the header field has any <comment> fields that contain non-ASCII strings, apply encoded-word encoding.
如果标题字段有任何包含非ASCII字符串的<comment>字段，请应用编码字编码。
If the header field has any <value> elements [RFC2045] that contain non-ASCII strings, remove any <CFWS> that appear outside DQUOTE [RFC5234] that appear in those elements, then encode the <value> elements as extended MIME parameter encodings [RFC2231] and leave the language information empty.
如果标题字段有任何包含非ASCII字符串的<value>元素[RFC2045]，请删除出现在这些元素中的DQUOTE[RFC5234]之外的任何<CFWS>，然后将<value>元素编码为扩展MIME参数编码[RFC2231]，并将语言信息保留为空。
If the header field has any <address> (<mailbox> or <group>) elements, and they have <display-name> elements that contain non-ASCII strings, encode the <display-name> elements as encoded-words. Display-Name downgrading uses the same algorithm as Word downgrading.
如果标题字段有任何<address>（<mailbox>或<group>）元素，并且它们有包含非ASCII字符串的<display name>元素，请将<display name>元素编码为编码字。显示名称降级使用与单词降级相同的算法。
If the header field has any <domain> elements that contain U-labels, rewrite the non-ASCII domain name into an ASCII domain name using A-labels [RFC5891].
如果标题字段有任何包含U标签的<domain>元素，请使用A标签[RFC5891]将非ASCII域名重写为ASCII域名。
<group> is defined in Section 3.4 of the Internet Message Format specification [RFC5322]. The <group> element may contain <mailbox> elements that contain non-ASCII addresses.
互联网消息格式规范[RFC5322]第3.4节定义了<group>。<group>元素可能包含包含非ASCII地址的<mailbox>元素。
If a <group> element contains <mailbox> elements and one of those
<mailbox> elements contains a non-ASCII <local-part>, rewrite the
<group> element as
If a <group> element contains <mailbox> elements and one of those
<mailbox> elements contains a non-ASCII <local-part>, rewrite the
<group> element as
display-name " " ENCODED_WORD " :;"
显示名称“编码的单词”：
where the <ENCODED_WORD> is the original <group-list> encoded as encoded-words.
其中<ENCODED_WORD>是编码为编码字的原始<group list>。
Otherwise, the <group> element contains an ASCII-only <local-part>. If the <group> element contains non-ASCII <mailbox> elements, they contain non-ASCII domain names. Rewrite the non-ASCII domain names into ASCII domain names using A-labels [RFC5891]. Generated <mailbox> elements contain ASCII addresses only.
否则，<group>元素只包含ASCII<localpart>。如果<group>元素包含非ASCII<mailbox>元素，则它们包含非ASCII域名。使用A标签[RFC5891]将非ASCII域名重写为ASCII域名。生成的<mailbox>元素仅包含ASCII地址。
If the <local-part> of the <mailbox> element contains no characters other than those in the ASCII repertoire, the <domain> element may contain non-ASCII characters. Rewrite the non-ASCII domain names into ASCII domain names using A-labels [RFC5891].
如果<mailbox>元素的<local part>不包含ASCII指令集以外的字符，则<domain>元素可能包含非ASCII字符。使用A标签[RFC5891]将非ASCII域名重写为ASCII域名。
Otherwise, the <local-part> may contain non-ASCII characters. The <local-part> that contains characters outside the ASCII repertoire has no equivalent format for ASCII addresses. The <addr-spec> element that contains non-ASCII strings may appear in two forms as:
否则，<local part>可能包含非ASCII字符。包含ASCII指令表以外字符的<local part>没有ASCII地址的等效格式。包含非ASCII字符串的<addr spec>元素可能以两种形式出现：
"<" addr-spec ">"
“<“地址规范”>”
or
或
addr-spec
地址规格
Rewrite both as:
将两者重写为：
ENCODED-WORD " :;"
编码字“；”
where the <ENCODED-WORD> is the original <addr-spec> encoded as encoded-words.
其中<ENCODED-WORD>是作为编码字编码的原始<addr spec>。
If the header field contains <utf-8-type-addr> and the <utf-8-type-addr> contains raw non-ASCII strings (<UTF8-non-ascii>), it is in utf-8-address form [RFC6533]. Convert it to utf-8-addr-xtext form [RFC6533]. Comment downgrading is also performed in this case. If the address type is unrecognized and the header field contains non-ASCII strings, then fall back to using Encapsulation on the entire header field as specified in Section 3.1.10.
如果标头字段包含<utf-8-type-addr>，并且<utf-8-type-addr>包含原始非ASCII字符串（<UTF8非ASCII>），则它是utf-8-address格式[RFC6533]。将其转换为utf-8-addr-xtext格式[RFC6533]。在这种情况下，还将执行注释降级。如果地址类型无法识别，且标头字段包含非ASCII字符串，则应按照第3.1.10节的规定，对整个标头字段使用封装。
As a last resort, when header fields cannot be converted as discussed in the previous subsection, the fields are deleted and replaced by specialized new header fields. Those fields are defined to preserve, in encoded form, as much information as possible from the header field values of the incoming message. This mechanism is known as Encapsulation downgrading in this specification because it preserves the original information in a different form. The syntax of these new header fields is:
最后一种方法是，如果无法如前一小节所述转换标题字段，则会删除这些字段，并将其替换为专门的新标题字段。这些字段定义为以编码形式保留传入消息的报头字段值中尽可能多的信息。这种机制在本规范中称为封装降级，因为它以不同的形式保留原始信息。这些新标题字段的语法如下：
fields =/ downgraded
字段=/降级
downgraded = "Downgraded-Message-Id:" unstructured CRLF /
"Downgraded-Resent-Message-Id:" unstructured CRLF /
"Downgraded-In-Reply-To:" unstructured CRLF /
"Downgraded-References:" unstructured CRLF /
"Downgraded-Original-Recipient:" unstructured CRLF /
"Downgraded-Final-Recipient:" unstructured CRLF
downgraded = "Downgraded-Message-Id:" unstructured CRLF /
"Downgraded-Resent-Message-Id:" unstructured CRLF /
"Downgraded-In-Reply-To:" unstructured CRLF /
"Downgraded-References:" unstructured CRLF /
"Downgraded-Original-Recipient:" unstructured CRLF /
"Downgraded-Final-Recipient:" unstructured CRLF
Applying this procedure to the "Received:" header field is prohibited. Encapsulation downgrading is allowed for "Message-ID:", "In-Reply-To:", "References:", "Original-Recipient:", and "Final-Recipient:" header fields.
禁止将此过程应用于“已接收：”标题字段。允许对“邮件ID:”、“回复：”中的“引用：”、“原始收件人：”和“最终收件人：”标题字段进行封装降级。
To preserve a header field in a Downgraded- header field:
要在降级标题字段中保留标题字段，请执行以下操作：
1. Generate a new header field.
1. 生成一个新的标题字段。
* The field name is a concatenation of Downgraded- and the original field name.
* 字段名是降级字段名和原始字段名的串联。
* The initial new field value is the original header field value.
* 初始新字段值是原始标题字段值。
2. Treat the initial new header field value as if it were unstructured, and then apply the encoded-word encoding as necessary so that the resulting new header field value is completely in ASCII.
2. 将初始新标题字段值视为非结构化，然后根据需要应用编码字编码，以便生成的新标题字段值完全以ASCII格式显示。
3. Remove the original header field.
3. 删除原始标题字段。
The Mail and MIME Header Fields document [RFC4021] establishes a registry of header fields. This section describes the downgrading method for each header field listed in that registry as of the date of publication of this specification.
邮件和MIME头字段文档[RFC4021]建立了头字段的注册表。本节描述了自本规范发布之日起该注册表中列出的每个标题字段的降级方法。
If the entire mail header field contains no characters other than those in the ASCII repertoire, email header field downgrading is not required. Each header field's downgrading method is described below.
如果整个邮件标题字段不包含ASCII指令表中以外的字符，则不需要对邮件标题字段进行降级。每个标题字段的降级方法如下所述。
From: Sender: To: Cc: Bcc: Reply-To: Resent-From: Resent-Sender: Resent-To: Resent-Cc: Resent-Bcc: Resent-Reply-To: Return-Path: Disposition-Notification-To:
发件人：收件人：抄送：密件抄送：答复：重新发送发件人：重新发送至：重新发送抄送：重新发送密件抄送：重新发送答复：返回路径：处置通知收件人：
If the header field contains non-ASCII characters, first perform Comment downgrading and Display-Name downgrading as described in the corresponding subsections of Section 3.1. If the header field still contains non-ASCII characters, complete the following two steps:
如果标题字段包含非ASCII字符，首先执行注释降级和显示名称降级，如第3.1节相应小节所述。如果标题字段仍然包含非ASCII字符，请完成以下两个步骤：
1. If the header field contains <group> elements that contain non-ASCII addresses, perform Group downgrading on those elements.
1. 如果标题字段包含包含非ASCII地址的<group>元素，请对这些元素执行组降级。
2. If the header field contains <mailbox> elements that contain non-ASCII addresses, perform Mailbox downgrading on those elements.
2. 如果标头字段包含包含非ASCII地址的<mailbox>元素，请对这些元素执行邮箱降级。
This procedure may generate empty <group> elements in the "From:" and "Sender:" header fields. The Group Syntax document [RFC6854] updates the Internet Message Format specification [RFC5322] to allow (empty) <group> elements in the "From:" and "Sender:" header fields.
此过程可能会在“发件人：”和“发件人：”标题字段中生成空的<group>元素。组语法文档[RFC6854]更新了Internet消息格式规范[RFC5322]，以允许在“发件人：”和“发件人：”标题字段中使用（空）<Group>元素。
Date: Resent-Date: MIME-Version: Content-ID: Content-Transfer-Encoding: Content-Language: Accept-Language: Auto-Submitted:
日期：重新发送日期：MIME版本：内容ID:内容传输编码：内容语言：接受语言：自动提交：
Except in comments, these header fields do not contain characters other than those in the ASCII repertoire. If the header field contains UTF-8 characters in comments, perform Comment downgrading.
除注释外，这些标题字段不包含ASCII指令表中以外的字符。如果标题字段在注释中包含UTF-8字符，请执行注释降级。
Message-ID: Resent-Message-ID: In-Reply-To: References:
邮件ID：重新发送邮件ID:回复：引用：
If there are non-ASCII strings in <id-left> or <id-right> elements, perform Encapsulation. Otherwise, the header field contains UTF-8 characters in comments and Comment downgrading should be performed.
如果<id left>或<id right>元素中存在非ASCII字符串，则执行封装。否则，标题字段在注释中包含UTF-8字符，应执行注释降级。
Received:
收到：
If <domain> elements or <mailbox> elements contain U-labels, perform Domain downgrading as specified in Section 3.1.6. Comments may contain non-ASCII strings; if so, perform Comment downgrading.
如果<domain>元素或<mailbox>元素包含U型标签，则按照第3.1.6节的规定执行域降级。注释可能包含非ASCII字符串；如果是，请执行注释降级。
After the Domain downgrading and the Comment downgrading, if the "FOR" clause contains a non-ASCII <local-part>, remove the FOR clause. If the "ID" clause contains a non-ASCII value, remove the ID clause.
域降级和注释降级后，如果“FOR”子句包含非ASCII<local part>，请删除FOR子句。如果“ID”子句包含非ASCII值，请删除ID子句。
Content-Type: Content-Disposition:
内容类型：内容配置：
If there are non-ASCII strings in <value> or <CFWS> elements, perform MIME-Value and Comment downgrading.
如果<value>或<CFWS>元素中存在非ASCII字符串，请执行MIME值和注释降级。
Subject: Comments: Content-Description:
主题：评论：内容描述：
If non-ASCII strings are present in <unstructured> elements, perform Unstructured downgrading.
如果<unstructured>元素中存在非ASCII字符串，请执行非结构化降级。
Keywords:
关键词：
If non-ASCII strings are present in <phrase> elements, perform Word downgrading.
如果<phrase>元素中存在非ASCII字符串，请执行单词降级。
Other header fields that are not covered in this document (such as implementation-specific or user-defined fields) might also contain non-ASCII strings. Any header field that does not have a conversion method defined above will be in this category and treated as follows.
本文档中未涉及的其他标题字段（如特定于实现或用户定义的字段）也可能包含非ASCII字符串。任何没有上面定义的转换方法的标题字段都将属于此类，并按如下方式处理。
If there are non-ASCII strings present in the header fields, perform Unstructured downgrading.
如果标头字段中存在非ASCII字符串，请执行非结构化降级。
If the software understands the header field's structure and a downgrading algorithm other than Unstructured is applicable, that software SHOULD use that algorithm; Unstructured downgrading is used when there is no other option.
如果软件了解标题字段的结构，并且适用非结构化的降级算法，则该软件应使用该算法；如果没有其他选项，则使用非结构化降级。
Mailing list header fields (those that start in "List-") are part of this category.
邮件列表标题字段（以“列表-”开头的字段）属于此类别。
Both the MIME body part header fields [RFC2045] [RFC6532] and the contents of a delivery status notification [RFC6533] may contain non-ASCII characters.
MIME正文部分标题字段[RFC2045][RFC6532]和传递状态通知[RFC6533]的内容都可能包含非ASCII字符。
RFC 6532 specifies an extension that permits MIME header fields, including body part header fields, to contain non-ASCII strings. This section defines the conversion method to ASCII-only header fields for each MIME header field that contains non-ASCII strings. Parse the message body's MIME structure at all levels and check each MIME header field to see whether it contains non-ASCII strings. If the header field contains non-ASCII strings in the header field value, the header field is a target of the MIME body part header field's downgrading. The downgrading methods used for the MIME body part header fields Content-ID, Content-Type, Content-Disposition, and Content-Description are the same as those used for the header fields of the same name described in Section 3.2
RFC6532指定一个扩展，该扩展允许MIME头字段（包括正文部分头字段）包含非ASCII字符串。本节为每个包含非ASCII字符串的MIME头字段定义将其转换为仅ASCII头字段的方法。在所有级别分析消息体的MIME结构，并检查每个MIME头字段，以查看它是否包含非ASCII字符串。如果标头字段值中包含非ASCII字符串，则标头字段是MIME正文部分标头字段降级的目标。MIME正文部分标题字段Content ID、Content Type、Content Disposition和Content Description使用的降级方法与第3.2节中描述的同名标题字段使用的降级方法相同
If the message contains a delivery status notification (see Section 6 of the SMTP DSN Extension [RFC3461]), perform the following tests and conversions.
如果邮件包含传递状态通知（请参阅SMTP DSN扩展[RFC3461]的第6节），请执行以下测试和转换。
If there are "Original-Recipient:" and "Final-Recipient:" header fields, and the header fields contain non-ASCII strings, perform Type-Addr downgrading.
如果存在“原始收件人：”和“最终收件人：”标题字段，并且标题字段包含非ASCII字符串，请执行类型Addr降级。
The purpose of post-delivery message downgrading is to allow POP and IMAP servers to deliver internationalized messages to traditional POP and IMAP clients and to permit the clients to display those messages. Users that receive such messages can know that they were internationalized. It does not permit receivers to read the messages in their original form and, in general, will not permit generating replies, at least without significant user intervention.
传递后邮件降级的目的是允许POP和IMAP服务器向传统POP和IMAP客户端传递国际化邮件，并允许客户端显示这些邮件。接收此类消息的用户可以知道这些消息已国际化。它不允许接收者阅读其原始形式的消息，并且通常不允许生成回复，至少在没有重大用户干预的情况下。
After downgrading as specified in this document, the header fields of a message will contain ASCII characters only, some of them in encoded-word form. Nothing in this document or other SMTPUTF8 specifications [RFC6530] [RFC6531] alters the basic properties of MIME that allow characters outside the ASCII repertoire in encodings as specified for them. Thus, this document inherits the security considerations associated with MIME-encoded header fields as specified in RFC 2047 [RFC2047] and with UTF-8 itself as specified in RFC 3629 [RFC3629].
按照本文档中的规定降级后，消息的标题字段将仅包含ASCII字符，其中一些字符采用编码字形式。本文档或其他SMTPUTF8规范[RFC6530][RFC6531]中的任何内容都不会改变MIME的基本属性，即允许ASCII指令表之外的字符按指定编码。因此，本文档继承了与RFC 2047[RFC2047]中指定的MIME编码头字段以及与RFC 3629[RFC3629]中指定的UTF-8本身相关的安全注意事项。
Rewriting header fields increases the opportunities for undetected spoofing by malicious senders. However, the rewritten header field values are preserved in equivalent MIME form or in newly defined
重写标头字段会增加恶意发件人未检测到欺骗的机会。但是，重写的头字段值以等效的MIME格式或新定义的格式保留
header fields for which traditional MUAs have no special processing procedures.
传统MUA没有特殊处理过程的标头字段。
The techniques described here may invalidate methods that depend on digital signatures over any part of the message, which includes the top-level header fields and body part header fields. Depending on the specific message being downgraded, at least the following techniques are likely to break: DomainKeys Identified Mail (DKIM) and possibly S/MIME and Pretty Good Privacy (PGP). The downgrade mechanism SHOULD NOT remove signatures even if the signatures will fail validation after downgrading. As much of the information as possible from the original message SHOULD be preserved. In addition, MUAs may be able to use the presence of an Authentication-Results header field [RFC5451] to assess whether the digital signatures were valid before the header fields were downgraded.
这里描述的技术可能使依赖于消息任何部分上的数字签名的方法无效，其中包括顶级头字段和正文部分头字段。根据被降级的特定消息，至少以下技术可能会被破坏：域密钥识别邮件（DKIM）和可能的S/MIME和相当好的隐私（PGP）。降级机制不应删除签名，即使签名在降级后验证失败。应尽可能多地保留原始消息中的信息。此外，MUA可以使用认证结果报头字段[RFC5451]的存在来评估在报头字段降级之前数字签名是否有效。
While information in any email header field should usually be treated with some suspicion, current email systems commonly employ various mechanisms and protocols to make the information more trustworthy. Information in the new Downgraded-* header fields is not inspected by traditional MUAs and may be even less trustworthy than the traditional header fields. Note that the Downgraded-* header fields could have been inserted with malicious intent (and with content unrelated to the traditional header fields); however, traditional MUAs do not evaluate Downgraded-* header fields.
尽管任何电子邮件标题字段中的信息通常都应该受到怀疑，但当前的电子邮件系统通常采用各种机制和协议来提高信息的可信度。新的降级-*头字段中的信息不受传统MUA检查，可能比传统头字段更不可信。请注意，降级的-*标题字段可能是恶意插入的（并且内容与传统标题字段无关）；但是，传统的MUA不评估降级的-*头字段。
See the Security Considerations sections in the Group Syntax document [RFC6854] and the Internationalized Email Framework [RFC6530] for more discussion.
有关更多讨论，请参阅组语法文档[RFC6854]和国际化电子邮件框架[RFC6530]中的安全注意事项部分。
While the specification of encoded-words includes specific rules for dealing with whitespace in adjacent encoded words [RFC2047], there are a number of deployed implementations that fail to implement the algorithm correctly. As a result, whitespace behavior is somewhat unpredictable, in practice, when multiple encoded words are used.
虽然编码字的规范包括处理相邻编码字中空白的特定规则[RFC2047]，但仍有许多部署的实现无法正确实现算法。因此，在实践中，当使用多个编码字时，空白行为在某种程度上是不可预测的。
While RFC 5322 states that implementations SHOULD limit lines to 78 characters or less, implementations MAY choose to allow overly long encoded words to work around faulty implementations of encoded-words. Implementations that choose to do so SHOULD have an optional mechanism to limit line length to 78 characters.
虽然RFC5322声明实现应将行限制为78个字符或更少，但实现可能会选择允许过长的编码字来解决编码字的错误实现。选择这样做的实现应该有一个可选机制，将行长度限制为78个字符。
The experimental specification from which this document was partially derived [RFC5504] specifies that no new header fields beginning with Downgraded- are to be registered. That restriction is now lifted, and this document makes a new set of registrations, replacing the experimental fields with standard ones.
本文档部分源自的实验规范[RFC5504]规定，不注册以降级-开头的新标题字段。现在，这一限制被取消，这份文件建立了一套新的注册，用标准的注册取代了实验场。
The Downgraded-* header fields that were registered as experimental fields in RFC 5504 are no longer in use. IANA has changed the status from "experimental" to "obsoleted" for every name in the "Permanent Message Header Field Names" registry that began with Downgraded-.
在RFC 5504中注册为实验字段的降级-*标题字段不再使用。IANA已将“永久消息头字段名”注册表中以降级-开头的每个名称的状态从“实验性”更改为“已过时”。
The following header fields have been registered in the "Permanent Message Header Field Names" registry, in accordance with the procedures set out in the Header Field Registration document [RFC3864].
根据标题字段注册文件[RFC3864]中规定的程序，以下标题字段已在“永久性邮件标题字段名称”注册表中注册。
Header field name: Downgraded-Message-Id
Applicable protocol: mail
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.10)
Header field name: Downgraded-Message-Id
Applicable protocol: mail
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.10)
Header field name: Downgraded-In-Reply-To
Applicable protocol: mail
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.10)
Header field name: Downgraded-In-Reply-To
Applicable protocol: mail
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.10)
Header field name: Downgraded-References
Applicable protocol: mail
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.10)
Header field name: Downgraded-References
Applicable protocol: mail
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.10)
Header field name: Downgraded-Original-Recipient
Applicable protocol: mail
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.10)
Header field name: Downgraded-Original-Recipient
Applicable protocol: mail
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.10)
Header field name: Downgraded-Final-Recipient
Applicable protocol: mail
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.10)
Header field name: Downgraded-Final-Recipient
Applicable protocol: mail
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.10)
This document draws heavily from the experimental in-transit message downgrading procedure described RFC 5504. The contributions of the coauthor of that earlier document, Y. Yoneya, are gratefully acknowledged. Significant comments and suggestions were received from John Klensin, Barry Leiba, Randall Gellens, Pete Resnick, Martin J. Durst, and other WG participants.
本文件大量借鉴了RFC 5504所述的实验性在途消息降级程序。感谢该早期文件的合著者Y.Yoneya的贡献。John Klensin、Barry Leiba、Randall Gellens、Pete Resnick、Martin J.Durst和其他工作组参与者提出了重要的意见和建议。
[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月。
[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月。
[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月。
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2183]Troost，R.，Dorner，S.，和K.Moore，“在Internet消息中传递表示信息：内容处置头字段”，RFC 2183，1997年8月。
[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月。
[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月。
[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月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME Header Fields", RFC 4021, March 2005.
[RFC4021]Klyne，G.和J.Palme，“邮件和MIME头字段的注册”，RFC4021，2005年3月。
[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月。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC5891]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 58912010年8月。
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012.
[RFC6530]Klensin，J.和Y.Ko，“国际化电子邮件的概述和框架”，RFC6530，2012年2月。
[RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email", 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月。
[RFC6854] Leiba, B., "Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields", RFC 6854, March 2013.
[RFC6854]Leiba，B.，“更新互联网消息格式以允许在“发件人：”和“发件人：”标题字段中使用组语法”，RFC 68542013年3月。
[RFC6855] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP Support for UTF-8", RFC 6855, March 2013.
[RFC6855]Resnick，P.，Ed.，Newman，C.，Ed.，和S.Shen，Ed.，“UTF-8的IMAP支持”，RFC 68552013年3月。
[RFC6856] Gellens, R., Newman, C., Yao, J., and K. Fujiwara, "Post Office Protocol Version 3 (POP3) Support for UTF-8", RFC 6856, March 2013.
[RFC6856]Gellens，R.，Newman，C.，Yao，J.，和K.Fujiwara，“邮局协议版本3（POP3）对UTF-8的支持”，RFC 68562013年3月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5451] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.
[RFC5451]Kucherawy，M.，“用于指示消息身份验证状态的消息头字段”，RFC 5451，2009年4月。
[RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for Email Address Internationalization", RFC 5504, March 2009.
[RFC5504]Fujiwara，K.和Y.Yoneya，“电子邮件地址国际化的降级机制”，RFC 55042009年3月。
This appendix shows a message downgrading example. Consider a received mail message where:
本附录显示了一个消息降级示例。考虑收到的邮件消息：
o The sender address is a non-ASCII address, "NON-ASCII-LOCAL@example.com". Its display-name is "DISPLAY-LOCAL".
o 发送方地址是非ASCII地址，“非ASCII”-LOCAL@example.com". 其显示名称为“display-LOCAL”。
o The "To:" header field contains two non-ASCII addresses, "NON-ASCII-REMOTE1@example.net" and "NON-ASCII-REMOTE2@example.com". Their display-names are "DISPLAY-REMOTE1" and "DISPLAY-REMOTE2".
o “收件人：”标题字段包含两个非ASCII地址，“非ASCII”-REMOTE1@example.net“和”非ASCII-REMOTE2@example.com". 它们的显示名称是“display-REMOTE1”和“display-REMOTE2”。
o The "Cc:" header field contains a non-ASCII address, "NON-ASCII-REMOTE3@example.org". Its display-name is "DISPLAY-REMOTE3".
o “Cc:”标头字段包含一个非ASCII地址，“非ASCII”-REMOTE3@example.org". 其显示名称为“display-REMOTE3”。
o Four display-names contain non-ASCII characters.
o 四个显示名称包含非ASCII字符。
o The "Subject:" header field is "NON-ASCII-SUBJECT", which contains non-ASCII strings.
o “主题：”标题字段是“非ASCII主题”，其中包含非ASCII字符串。
o The "Message-Id:" header field contains "NON-ASCII-MESSAGE_ID", which contains non-ASCII strings.
o “Message Id:”标头字段包含“NON-ASCII-Message_Id”，其中包含非ASCII字符串。
o There is an unknown header field "X-Unknown-Header:", which contains non-ASCII strings.
o 存在未知标题字段“X-unknown-header:”，其中包含非ASCII字符串。
Return-Path: <NON-ASCII-LOCAL@example.com>
Received: from ... by ... for <NON-ASCII-REMOTE1@example.net>
Received: from ... by ... for <NON-ASCII-REMOTE1@example.net>
From: DISPLAY-LOCAL <NON-ASCII-LOCAL@example.com>
To: DISPLAY-REMOTE1 <NON-ASCII-REMOTE1@example.net>,
DISPLAY-REMOTE2 <NON-ASCII-REMOTE2@example.com>
Cc: DISPLAY-REMOTE3 <NON-ASCII-REMOTE3@example.org>
Subject: NON-ASCII-SUBJECT
Date: Mon, 30 Jul 2012 01:23:45 -0000
Message-Id: NON-ASCII-MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Unknown-Header: NON-ASCII-CHARACTERS
Return-Path: <NON-ASCII-LOCAL@example.com>
Received: from ... by ... for <NON-ASCII-REMOTE1@example.net>
Received: from ... by ... for <NON-ASCII-REMOTE1@example.net>
From: DISPLAY-LOCAL <NON-ASCII-LOCAL@example.com>
To: DISPLAY-REMOTE1 <NON-ASCII-REMOTE1@example.net>,
DISPLAY-REMOTE2 <NON-ASCII-REMOTE2@example.com>
Cc: DISPLAY-REMOTE3 <NON-ASCII-REMOTE3@example.org>
Subject: NON-ASCII-SUBJECT
Date: Mon, 30 Jul 2012 01:23:45 -0000
Message-Id: NON-ASCII-MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Unknown-Header: NON-ASCII-CHARACTERS
MAIL_BODY
邮件正文
Figure 1: Received Message in a Maildrop
图1：邮件投递中收到的消息
The downgraded message is shown in Figure 2. "Return-Path:", "From:", "To:", and "Cc:" header fields are rewritten. "Subject:" and "X-Unknown-Header:" header fields are encoded as encoded-words. The "Message-Id:" header field is encapsulated as a "Downgraded-Message-Id:" header field.
降级消息如图2所示。“返回路径：”、“发件人：”、“收件人：”、“抄送：”标头字段将被重写。“Subject:”和“X-Unknown-Header:”标题字段被编码为编码字。“消息Id:”标头字段封装为“降级消息Id:”标头字段。
Return-Path: =?UTF-8?Q?NON-ASCII-LOCAL@example.com?= :;
Received: from ... by ...
Received: from ... by ...
From: =?UTF-8?Q?DISPLAY-LOCAL?=
=?UTF-8?Q?NON-ASCII-LOCAL@example.com?= :;
To: =?UTF-8?Q?DISPLAY-REMOTE1?=
=?UTF-8?Q?NON-ASCII-REMOTE1@example.net?= :;,
=?UTF-8?Q?DISPLAY-REMOTE2?=
=?UTF-8?Q?NON-ASCII-REMOTE2@example.com?= :;,
Cc: =?UTF-8?Q?DISPLAY-REMOTE3?=
=?UTF-8?Q?NON-ASCII-REMOTE3@example.org?= :;
Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
Date: Mon, 30 Jul 2012 01:23:45 -0000
Downgraded-Message-Id: =?UTF-8?Q?MESSAGE_ID?=
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Unknown-Header: =?UTF-8?Q?NON-ASCII-CHARACTERS?=
Return-Path: =?UTF-8?Q?NON-ASCII-LOCAL@example.com?= :;
Received: from ... by ...
Received: from ... by ...
From: =?UTF-8?Q?DISPLAY-LOCAL?=
=?UTF-8?Q?NON-ASCII-LOCAL@example.com?= :;
To: =?UTF-8?Q?DISPLAY-REMOTE1?=
=?UTF-8?Q?NON-ASCII-REMOTE1@example.net?= :;,
=?UTF-8?Q?DISPLAY-REMOTE2?=
=?UTF-8?Q?NON-ASCII-REMOTE2@example.com?= :;,
Cc: =?UTF-8?Q?DISPLAY-REMOTE3?=
=?UTF-8?Q?NON-ASCII-REMOTE3@example.org?= :;
Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
Date: Mon, 30 Jul 2012 01:23:45 -0000
Downgraded-Message-Id: =?UTF-8?Q?MESSAGE_ID?=
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Unknown-Header: =?UTF-8?Q?NON-ASCII-CHARACTERS?=
MAIL_BODY
邮件正文
Figure 2: Downgraded Message
图2：降级消息
Author's Address
作者地址
Kazunori Fujiwara Japan Registry Services Co., Ltd. Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan
日本东京101-0065西神田千代田区3-8-1号千代田第一大厦东13楼藤原和仁日本注册服务有限公司
Phone: +81 3 5215 8451
EMail: fujiwara@jprs.co.jp
Phone: +81 3 5215 8451
EMail: fujiwara@jprs.co.jp