Network Working Group K. Fujiwara, Ed.
Request for Comments: 5504 Y. Yoneya, Ed.
Category: Experimental JPRS
March 2009
Network Working Group K. Fujiwara, Ed.
Request for Comments: 5504 Y. Yoneya, Ed.
Category: Experimental JPRS
March 2009
Downgrading Mechanism for Email Address Internationalization
电子邮件地址国际化的降级机制
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 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 (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields. The Email Address Internationalization (UTF8SMTP) extension allows UTF-8 characters in SMTP envelope and mail header fields. To avoid rejecting internationalized email messages when a server in the delivery path does not support the UTF8SMTP extension, some sort of converting mechanism is required. This document describes a downgrading mechanism for Email Address Internationalization. Note that this is a way to downgrade, not tunnel. There is no associated up-conversion mechanism, although internationalized email clients might use original internationalized addresses or other data when displaying or replying to downgraded messages.
传统的邮件系统只处理SMTP信封和邮件标题字段中的ASCII字符。电子邮件地址国际化（UTF8SMTP）扩展允许在SMTP信封和邮件标题字段中使用UTF-8字符。为了避免在传递路径中的服务器不支持UTF8SMTP扩展时拒绝国际化电子邮件，需要某种转换机制。本文档描述了电子邮件地址国际化的降级机制。请注意，这是一种降级方式，而不是隧道。虽然国际化电子邮件客户端在显示或回复降级邮件时可能使用原始国际化地址或其他数据，但没有相关的上转换机制。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. New Header Fields Definition ....................................5
3.1. Envelope Information Preservation Header Fields ............5
3.2. Address Header Fields' Preservation Header Fields ..........6
3.3. Unknown Header Fields' Preservation Header Fields ..........6
4. SMTP Downgrading ................................................7
4.1. Path Element Downgrading ...................................7
4.2. ORCPT downgrading ..........................................8
5. Email Header Fields Downgrading .................................8
5.1. Downgrading Method for Each ABNF Element ...................8
5.1.1. RECEIVED Downgrading ................................9
5.1.2. UNSTRUCTURED Downgrading ............................9
5.1.3. WORD Downgrading ....................................9
5.1.4. COMMENT Downgrading .................................9
5.1.5. MIME-VALUE Downgrading ..............................9
5.1.6. DISPLAY-NAME Downgrading ............................9
5.1.7. MAILBOX Downgrading .................................9
5.1.8. ENCAPSULATION Downgrading ..........................10
5.1.9. TYPED-ADDRESS Downgrading ..........................10
5.2. Downgrading Method for Each Header Field ..................10
5.2.1. Address Header Fields That Contain <address>s ......10
5.2.2. Address Header Fields with Typed Addresses .........11
5.2.3. Downgrading Non-ASCII in Comments ..................11
5.2.4. Received Header Field ..............................11
5.2.5. MIME Content Header Fields .........................12
5.2.6. Non-ASCII in <unstructured> ........................12
5.2.7. Non-ASCII in <phrase> ..............................12
5.2.8. Other Header Fields ................................12
6. MIME Body-Part Header Field Downgrading ........................12
7. Security Considerations ........................................13
8. Implementation Notes ...........................................14
8.1. RFC 2047 Encoding .........................................14
8.2. Trivial Downgrading .......................................15
8.3. 7bit Transport Consideration ..............................15
9. IANA Considerations ............................................16
10. Acknowledgements ..............................................18
11. References ....................................................18
11.1. Normative References .....................................18
11.2. Informative References ...................................19
Appendix A. Examples .............................................20
A.1. Downgrading Example 1 .....................................20
A.2. Downgrading Example 2 .....................................22
1. Introduction ....................................................3
2. Terminology .....................................................4
3. New Header Fields Definition ....................................5
3.1. Envelope Information Preservation Header Fields ............5
3.2. Address Header Fields' Preservation Header Fields ..........6
3.3. Unknown Header Fields' Preservation Header Fields ..........6
4. SMTP Downgrading ................................................7
4.1. Path Element Downgrading ...................................7
4.2. ORCPT downgrading ..........................................8
5. Email Header Fields Downgrading .................................8
5.1. Downgrading Method for Each ABNF Element ...................8
5.1.1. RECEIVED Downgrading ................................9
5.1.2. UNSTRUCTURED Downgrading ............................9
5.1.3. WORD Downgrading ....................................9
5.1.4. COMMENT Downgrading .................................9
5.1.5. MIME-VALUE Downgrading ..............................9
5.1.6. DISPLAY-NAME Downgrading ............................9
5.1.7. MAILBOX Downgrading .................................9
5.1.8. ENCAPSULATION Downgrading ..........................10
5.1.9. TYPED-ADDRESS Downgrading ..........................10
5.2. Downgrading Method for Each Header Field ..................10
5.2.1. Address Header Fields That Contain <address>s ......10
5.2.2. Address Header Fields with Typed Addresses .........11
5.2.3. Downgrading Non-ASCII in Comments ..................11
5.2.4. Received Header Field ..............................11
5.2.5. MIME Content Header Fields .........................12
5.2.6. Non-ASCII in <unstructured> ........................12
5.2.7. Non-ASCII in <phrase> ..............................12
5.2.8. Other Header Fields ................................12
6. MIME Body-Part Header Field Downgrading ........................12
7. Security Considerations ........................................13
8. Implementation Notes ...........................................14
8.1. RFC 2047 Encoding .........................................14
8.2. Trivial Downgrading .......................................15
8.3. 7bit Transport Consideration ..............................15
9. IANA Considerations ............................................16
10. Acknowledgements ..............................................18
11. References ....................................................18
11.1. Normative References .....................................18
11.2. Informative References ...................................19
Appendix A. Examples .............................................20
A.1. Downgrading Example 1 .....................................20
A.2. Downgrading Example 2 .....................................22
Traditional mail systems, which are defined by [RFC5321] and [RFC5322], allow ASCII characters in SMTP envelope and mail header field values. The UTF8SMTP extension ([RFC4952], [RFC5335], and [RFC5336]) allows UTF-8 characters in SMTP envelope and mail header field values.
由[RFC5321]和[RFC5322]定义的传统邮件系统允许在SMTP信封和邮件头字段值中使用ASCII字符。UTF8SMTP扩展名（[RFC4952]、[RFC5335]和[RFC5336]）允许在SMTP信封和邮件头字段值中使用UTF-8字符。
If an envelope address or header field contains non-ASCII characters, the message cannot be delivered unless every system in the delivery path supports UTF8SMTP. This document describes a downgrading mechanism to avoid rejection of such messages when a server that does not support the UTF8SMTP extension is encountered. This downgrading mechanism converts envelope and mail header fields to an all-ASCII representation.
如果信封地址或标题字段包含非ASCII字符，则除非传递路径中的每个系统都支持UTF8SMTP，否则无法传递邮件。本文档描述了一种降级机制，以避免在遇到不支持UTF8SMTP扩展的服务器时拒绝此类邮件。此降级机制将信封和邮件标题字段转换为全ASCII表示形式。
[RFC5335] allows UTF-8 characters to be used in mail header fields and MIME header fields. The downgrading mechanism specified here converts mail header fields and MIME header fields to ASCII.
[RFC5335]允许在邮件头字段和MIME头字段中使用UTF-8字符。此处指定的降级机制将邮件头字段和MIME头字段转换为ASCII。
This document does not change any protocols except by defining new header fields. It describes the conversion method from the internationalized email envelopes/messages that are defined in [RFC4952], [RFC5335], and [RFC5336] to the traditional email envelopes/messages defined in [RFC5321] and [RFC5322].
本文档不会更改任何协议，除非定义新的标题字段。它描述了从[RFC4952]、[RFC5335]和[RFC5336]中定义的国际化电子邮件信封/消息到[RFC5321]和[RFC5322]中定义的传统电子邮件信封/消息的转换方法。
Section 3.2 of [RFC5336] defines when downgrading occurs. If the SMTP client has a UTF8SMTP envelope or an internationalized message and the SMTP server doesn't support the UTF8SMTP extension, then the SMTP client MUST NOT send a UTF8SMTP envelope or an internationalized message to the SMTP server. The section lists 4 choices in this case. The fourth choice is downgrading, as described here.
[RFC5336]第3.2节定义了降级发生的时间。如果SMTP客户端具有UTF8SMTP信封或国际化邮件，并且SMTP服务器不支持UTF8SMTP扩展，则SMTP客户端不得向SMTP服务器发送UTF8SMTP信封或国际化邮件。本节列出了本例中的4个选项。第四种选择是降级，如下所述。
Downgrading may be implemented in Mail User Agents (MUAs), Mail Submission Agents (MSAs), and Mail Transport Agents (MTAs) that act as SMTP clients. It may also be implemented in Message Delivery Agents (MDAs), Post Office Protocol (POP) servers, and IMAP servers that store or offer UTF8SMTP envelopes or internationalized messages to non-UTF8SMTP-compliant systems, which include message stores.
降级可以在充当SMTP客户端的邮件用户代理（MUA）、邮件提交代理（MSA）和邮件传输代理（MTA）中实现。它还可以在邮件传递代理（MDA）、邮局协议（POP）服务器和IMAP服务器中实现，这些服务器存储或向不符合UTF8SMTP的系统（包括邮件存储）提供UTF8SMTP信封或国际化邮件。
This document tries to define the downgrading process clearly and it preserves the original internationalized email information as much as possible.
本文档试图明确定义降级过程，并尽可能保留原始的国际化电子邮件信息。
Downgrading in UTF8SMTP consists of the following four parts:
UTF8SMTP中的降级由以下四部分组成：
o New header field definitions o SMTP downgrading o Email header field downgrading o MIME header field downgrading
o 新标题字段定义o SMTP降级o电子邮件标题字段降级o MIME标题字段降级
In Section 3 of this document, many header fields starting with "Downgraded-" are introduced. They preserve the original envelope information and the original header fields.
在本文档的第3节中，介绍了许多以“降级”开头的标题字段。它们保留原始信封信息和原始标题字段。
SMTP downgrading is described in Section 4. It generates ASCII-only envelope information from a UTF8SMTP envelope.
SMTP降级在第4节中介绍。它从UTF8SMTP信封生成仅ASCII的信封信息。
Email header field downgrading is described in Section 5. It generates ASCII-only header fields.
第5节介绍了电子邮件标题字段降级。它只生成ASCII头字段。
MIME header fields are expanded in [RFC5335]. MIME header field downgrading is described in Section 6. It generates ASCII-only MIME header fields.
MIME头字段在[RFC5335]中展开。MIME头字段降级在第6节中描述。它只生成ASCII MIME头字段。
Displaying downgraded messages that originally contained internationalized email addresses or internationalized header fields is described in an another document ([DISPLAY]).
显示最初包含国际化电子邮件地址或国际化标题字段的降级邮件在另一个文档（[DISPLAY]）中进行了描述。
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]中所述进行解释。
All specialized terms used in this specification are defined in the Email Address Internationalization (EAI) overview [RFC4952], in the mail specifications [RFC5321] [RFC5322], or in the MIME documents [RFC2045] [RFC2047] [RFC2183] [RFC2231]. The terms "ASCII address", "internationalized email address", "non-ASCII address", "i18mail address", "UTF8SMTP", "message", and "mailing list" are used with the definitions from [RFC4952].
本规范中使用的所有专用术语均在电子邮件地址国际化（EAI）概述[RFC4952]、邮件规范[RFC5321][RFC5322]或MIME文档[RFC2045][RFC2047][RFC2183][RFC2231]中定义。术语“ASCII地址”、“国际化电子邮件地址”、“非ASCII地址”、“I18邮件地址”、“UTF8SMTP”、“邮件”和“邮件列表”与[RFC4952]中的定义一起使用。
This document depends on [RFC5335], [RFC5336], and [RFC5337]. Key words used in those documents are used in this document, too.
本文件依赖于[RFC5335]、[RFC5336]和[RFC5337]。这些文件中使用的关键词也在本文件中使用。
The term "non-ASCII" refers to a UTF-8 string that contains at least one non-ASCII character.
术语“非ASCII”指至少包含一个非ASCII字符的UTF-8字符串。
A "UTF8SMTP envelope" has email originator/recipient addresses expanded by [RFC5336] and [RFC5337].
“UTF8SMTP信封”的电子邮件发起者/收件人地址扩展为[RFC5336]和[RFC5337]。
A "UTF8SMTP message" is an email message expanded by [RFC5335].
“UTF8SMTP消息”是由[RFC5335]扩展的电子邮件消息。
New header fields starting with "Downgraded-" are defined here to preserve those original envelope and mail header field values that contain UTF-8 characters. During downgrading, one new "Downgraded-" header field is added for each original envelope or mail header field that cannot be passed as-is to a server that does not support UTF8SMTP. The original envelope or mail header field is removed or rewritten. Only those envelope and mail header fields that contain non-ASCII characters are affected. The result of this process is a message that is compliant with existing email specifications [RFC5321] and [RFC5322]. The original internationalized information can be retrieved by examining the "Downgraded-" header fields that were added.
此处定义了以“降级-”开头的新标题字段，以保留包含UTF-8字符的原始信封和邮件标题字段值。降级期间，对于无法按原样传递到不支持UTF8SMTP的服务器的每个原始信封或邮件标题字段，将添加一个新的“降级-”标题字段。原始信封或邮件标题字段将被删除或重写。只有那些包含非ASCII字符的信封和邮件标题字段才会受到影响。此过程的结果是生成符合现有电子邮件规范[RFC5321]和[RFC5322]的消息。可以通过检查添加的“降级”标题字段来检索原始国际化信息。
SMTP envelope downgraded information <downgraded-envelope-addr> consists of the original non-ASCII address and the downgraded all-ASCII address. The ABNF [RFC5234] syntax is as follows:
SMTP信封降级信息<降级信封地址>由原始非ASCII地址和降级的所有ASCII地址组成。ABNF[RFC5234]语法如下：
downgraded-envelope-addr = [FWS] "<" [ A-d-l ":" ] uMailbox
FWS "<" Mailbox ">" ">" [CFWS]
downgraded-envelope-addr = [FWS] "<" [ A-d-l ":" ] uMailbox
FWS "<" Mailbox ">" ">" [CFWS]
<uMailbox> is defined in [RFC5336]; <Mailbox> and <A-d-l> are defined in Section 4.1.2 of [RFC5321].
[RFC5336]中定义了<uMailbox><[RFC5321]第4.1.2节定义了邮箱>和<A-d-l>。
Two header fields, "Downgraded-Mail-From:" and "Downgraded-Rcpt-To:", are defined to preserve SMTP envelope downgraded information. The header field syntax is specified as follows:
定义了两个标题字段“降级邮件发件人：”和“降级Rcpt至：”以保留SMTP信封降级信息。标题字段语法指定如下：
fields =/ downgradedmailfrom / downgradedrcptto
fields =/ downgradedmailfrom / downgradedrcptto
downgradedmailfrom = "Downgraded-Mail-From:" unstructured CRLF
降级邮件发件人：“非结构化CRLF”
downgradedrcptto = "Downgraded-Rcpt-To:" unstructured CRLF
降级DRCPTTO=“将Rcpt降级为：”非结构化CRLF
The unstructured content is downgraded-envelope-addr and treated as if it were unstructured, with [RFC2047] encoding (and charset UTF-8) as needed.
非结构化内容被降级为envelope addr，并被视为非结构化内容，根据需要使用[RFC2047]编码（和字符集UTF-8）。
The address header fields' preservation header fields are defined to preserve the original header field. Their value field holds the original header field value. The header field syntax is specified as follows:
地址头字段的保留头字段定义为保留原始头字段。其值字段保存原始标题字段值。标题字段语法指定如下：
fields =/ known-downgraded-headers ":" unstructured CRLF
fields=/known降级标题“：“非结构化CRLF”
known-downgraded-headers = "Downgraded-" original-headers
已知降级标题=“降级-”原始标题
original-headers = "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"
original-headers = "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"
To preserve a header field in a "Downgraded-" header field:
要在“降级”标题字段中保留标题字段，请执行以下操作：
1. Generate a new "Downgraded-" header field whose value is the original header field value.
1. 生成一个新的“降级”标题字段，其值为原始标题字段值。
2. Treat the generated header field content as if it were unstructured, and then apply [RFC2047] encoding with charset UTF-8 as necessary so that the result is ASCII.
2. 将生成的标题字段内容视为非结构化，然后根据需要使用字符集UTF-8应用[RFC2047]编码，以使结果为ASCII。
The unknown header fields' preservation header fields are defined to encapsulate those original header fields that contain non-ASCII characters and are not otherwise provided for in this specification. The encapsulation header field name is the concatenation of "Downgraded-" and the original name. The value field holds the original header field value.
未知标头字段的保留标头字段定义为封装包含非ASCII字符且本规范中未另行提供的原始标头字段。封装头字段名是“降级”和原始名称的串联。值字段保存原始标题字段值。
The header field syntax is specified as follows:
标题字段语法指定如下：
fields =/ unknown-downgraded-headers ":" unstructured CRLF
fields =/ unknown-downgraded-headers ":" unstructured CRLF
unknown-downgraded-headers = "Downgraded-" original-header-field-name
未知降级标题=“降级-”原始标题字段名称
original-header-field-name = field-name
original-header-field-name = field-name
field-name = 1*ftext
field-name = 1*ftext
ftext = %d33-57 / ; Any character except
%d59-126 ; controls, SP, and ":".
ftext = %d33-57 / ; Any character except
%d59-126 ; controls, SP, and ":".
To encapsulate a header field in a "Downgraded-" header field:
要将标题字段封装在“降级”标题字段中，请执行以下操作：
1. Generate a new "Downgraded-" header field whose value is the original header field value.
1. 生成一个新的“降级”标题字段，其值为原始标题字段值。
2. Treat the generated header field content as if it were unstructured, and then apply [RFC2047] encoding with charset UTF-8 as necessary so the result is ASCII.
2. 将生成的标题字段内容视为非结构化，然后根据需要使用字符集UTF-8应用[RFC2047]编码，以使结果为ASCII。
3. Remove the original header field.
3. 删除原始标题字段。
The targets of downgrading elements in an SMTP envelope are below:
SMTP信封中降级元素的目标如下：
o <reverse-path> of MAIL FROM command o <forward-path> of RCPT TO command o ORCPT parameter of RCPT TO command
o 邮件的<反向路径>从命令o<转发路径>的RCPT到命令o或RCPT到命令的参数
<reverse-path> and <forward-path> are described in [RFC5321] and [RFC5336]. The ORCPT parameter is described in [RFC3461] and [RFC5337].
<反向路径>和<正向路径>在[RFC5321]和[RFC5336]中描述。[RFC3461]和[RFC5337]中描述了ORCPT参数。
Downgrading the <path> of MAIL FROM and RCPT TO commands uses the ALT-ADDRESS parameter defined in [RFC5336]. An SMTP command is downgradable if the <path> contains a non-ASCII address and the command has an ALT-ADDRESS parameter that specifies an ASCII address. Since only non-ASCII addresses are downgradable, specifying an ALT-ADDRESS value for an all-ASCII address is invalid for use with this specification, and no interpretation is assigned to it. This restriction allows for future extension of the specification even though no such extensions are currently anticipated.
使用[RFC5336]中定义的ALT-ADDRESS参数降级MAIL FROM和RCPT TO命令的<path>。如果<path>包含非ASCII地址且该命令具有指定ASCII地址的ALT-address参数，则SMTP命令可降级。由于只有非ASCII地址是可降级的，因此为所有ASCII地址指定ALT-ADDRESS值对于本规范的使用是无效的，并且不会为其分配任何解释。这一限制允许规范的未来扩展，即使目前没有预期此类扩展。
Note that even if no downgrading is performed on the envelope, message header fields and message body MIME header fields that contain non-ASCII characters MUST be downgraded. This is described in Sections 5 and 6.
请注意，即使未对信封执行降级，包含非ASCII字符的消息头字段和消息正文MIME头字段也必须降级。第5节和第6节对此进行了描述。
When downgrading, replace each <path> that contains a non-ASCII mail address with its specified alternative ASCII address, and preserve the original information using "Downgraded-Mail-From" and
降级时，将包含非ASCII邮件地址的每个<path>替换为其指定的备选ASCII地址，并使用“降级邮件来源”和保留原始信息
"Downgraded-Rcpt-To" header fields as defined in Section 3. Before replacing, decode the ALT-ADDRESS parameter value because it is encoded as xtext [RFC3461].
第3节定义的“降级Rcpt至”标题字段。替换之前，请解码ALT-ADDRESS参数值，因为它编码为xtext[RFC3461]。
To avoid disclosing recipient addresses, the downgrading process MUST NOT add the "Downgraded-Rcpt-To:" header field if the SMTP downgrading targets multiple recipients. See Section 7 for more details.
为避免披露收件人地址，如果SMTP降级针对多个收件人，则降级过程不得添加“降级的Rcpt To:”标头字段。详见第7节。
As a result of the recipient address downgrading, the domain part of the recipient address prior to downgrading might be different from the domain part of the new recipient address. If the result of address resolution for the domain part of the new recipient address contains the server at the connection destination of the SMTP session for the recipient address prior to downgrading, the SMTP connection is valid for the new recipient address. Otherwise, the downgrading process MUST NOT send the downgraded message to the new recipient address via the connection and MUST try to send the downgraded message to the new recipient address.
由于收件人地址降级，降级前收件人地址的域部分可能与新收件人地址的域部分不同。如果新收件人地址的域部分的地址解析结果包含降级前收件人地址的SMTP会话连接目标处的服务器，则SMTP连接对新收件人地址有效。否则，降级过程不能通过连接将降级邮件发送到新的收件人地址，必须尝试将降级邮件发送到新的收件人地址。
The "RCPT TO" command can have an ORCPT parameter if the Delivery Status Notification (DSN) extension [RFC3461] is supported. If the ORCPT parameter contains a "utf-8" type address and the address contains raw non-ASCII characters, the address MUST be converted to utf-8-addr-xtext form. Those forms are described in [RFC5337] and clarified by successor documents such as [DSNBIS].
如果支持传递状态通知（DSN）扩展[RFC3461]，则“RCPT TO”命令可以具有ORCPT参数。如果ORCPT参数包含“utf-8”类型的地址，并且该地址包含原始非ASCII字符，则该地址必须转换为utf-8-addr-xtext格式。这些表格在[RFC5337]中进行了描述，并由后续文件（如[DSNBIS]）进行了澄清。
Before converting to utf-8-addr-xtext form, remove xtext encoding.
在转换为utf-8-addr-xtext格式之前，请删除xtext编码。
This section defines the conversion method to ASCII for each header field that may contain non-ASCII characters.
本节为每个可能包含非ASCII字符的标题字段定义转换为ASCII的方法。
[RFC5335] expands "Received:" header fields; [RFC5322] describes ABNF elements <mailbox>, <word>, <comment>, <unstructured>; [RFC2045] describes ABNF element <value>.
[RFC5335]展开“已接收：”标题字段；[RFC5322]描述ABNF元素<mailbox>，<word>，<comment>，<unstructured>；[RFC2045]描述ABNF元素<value>。
Header field downgrading is defined below for each ABNF element. Downgrading an unknown header field is also defined as ENCAPSULATION downgrading. Converting the header field terminates when no non-ASCII characters remain in the header field.
下面为每个ABNF元素定义了标题字段降级。降级未知标头字段也定义为封装降级。当标头字段中没有非ASCII字符时，转换标头字段终止。
If the header field name is "Received:" and the FOR clause contains a non-ASCII address, remove the FOR clause from the header field. Other parts (not counting <comment>s) should not contain non-ASCII values.
如果标题字段名为“Received:”，并且FOR子句包含非ASCII地址，请从标题字段中删除FOR子句。其他部分（不包括<comment>s）不应包含非ASCII值。
If the header field has an <unstructured> field that contains non-ASCII characters, apply [RFC2047] encoding with charset UTF-8.
如果标题字段具有包含非ASCII字符的<unstructured>字段，请使用字符集UTF-8应用[RFC2047]编码。
If the header field has any <word> fields that contain non-ASCII characters, apply [RFC2047] encoding with charset UTF-8.
如果标题字段有任何<word>字段包含非ASCII字符，请使用字符集UTF-8应用[RFC2047]编码。
If the header field has any <comment> fields that contain non-ASCII characters, apply [RFC2047] encoding with charset UTF-8.
如果标题字段有任何包含非ASCII字符的<comment>字段，请使用字符集UTF-8应用[RFC2047]编码。
If the header field has any <value> elements defined by [RFC2045] and the elements contain non-ASCII characters, encode the <value> elements according to [RFC2231] with charset UTF-8 and leave the language information empty. If the <value> element is <quoted-string> and it contains <CFWS> outside the DQUOTE, remove the <CFWS> before this conversion.
如果标题字段有[RFC2045]定义的任何<value>元素，并且这些元素包含非ASCII字符，则使用字符集UTF-8根据[RFC2231]对<value>元素进行编码，并将语言信息保留为空。如果<value>元素是<quoted string>，并且在DQUOTE之外包含<CFWS>，请在转换之前删除<CFWS>。
If the header field has any <address> (<mailbox> or <group>) elements and they have <display-name> elements that contain non-ASCII characters, encode the <display-name> elements according to [RFC2047] with charset UTF-8. DISPLAY-NAME downgrading is the same algorithm as WORD downgrading.
如果标题字段有任何<address>（<mailbox>或<group>）元素，并且它们有<display name>元素包含非ASCII字符，则根据[RFC2047]使用字符集UTF-8对<display name>元素进行编码。显示名称降级与单词降级的算法相同。
The <mailbox> elements have no equivalent format for non-ASCII addresses. If the header field has any <mailbox> elements that contain non-ASCII characters, preserve the header field in the corresponding "Downgraded-" header field, which is defined in Section 3.2, and rewrite each <mailbox> element to ASCII-only format. The <mailbox> element that contains non-ASCII characters is one of three formats.
<mailbox>元素对于非ASCII地址没有等效的格式。如果标题字段有任何包含非ASCII字符的<mailbox>元素，请将标题字段保留在第3.2节中定义的相应“降级-”标题字段中，并将每个<mailbox>元素重写为仅ASCII格式。包含非ASCII字符的<mailbox>元素是三种格式之一。
o [ Display-name ] "<" Utf8-addr-spec 1*FCS "<" Addr-spec ">>"
o [ Display-name ] "<" Utf8-addr-spec 1*FCS "<" Addr-spec ">>"
Rewrite it as: [ Display-name ] "<" Addr-spec ">"
将其重写为：[显示名称]“<“地址规范”>”
o [ Display-name ] "<" Utf8-addr-spec ">" o Utf8-addr-spec
o [显示名称]“<”Utf8地址规范“>”o Utf8地址规范
Rewrite both as: [ Display-name ] "Internationalized Address " Encoded-word " Removed:;" where the <Encoded-word> is the original <Utf8-addr-spec> encoded according to [RFC2047].
将两者重写为：[Display name]“Internationalized Address”Encoded word“Removed:；”，其中<Encoded word>是根据[RFC2047]编码的原始<Utf8 addr spec>。
If the header field contains non-ASCII characters and is such that no rule is given above, encapsulate it in a "Downgraded-" header field as described in Section 3.3 as a last resort.
如果标题字段包含非ASCII字符，并且上面没有给出任何规则，则将其封装在“降级”标题字段中，如第3.3节所述，作为最后手段。
Applying this procedure to "Received:" header field is prohibited.
禁止将此过程应用于“已接收：”标题字段。
If the header field contains <utf-8-type-addr> and the <utf-8-type-addr> contains raw non-ASCII characters, it is in utf-8-address form. Convert it to utf-8-addr-xtext form as described in Section 4.2. COMMENT downgrading is also performed in this case. If the address type is unrecognized and the header field contains non-ASCII characters, then fall back to using ENCAPSULATION downgrading on the entire header field.
如果标题字段包含<utf-8-type-addr>，并且<utf-8-type-addr>包含原始非ASCII字符，则其为utf-8-address格式。将其转换为utf-8-addr-xtext格式，如第4.2节所述。在这种情况下，还将执行注释降级。如果地址类型无法识别，并且标头字段包含非ASCII字符，则可以对整个标头字段使用封装降级。
Header fields are listed in [RFC4021]. This section describes the downgrading method for each header field.
标题字段列在[RFC4021]中。本节介绍每个标题字段的降级方法。
If the whole mail header field does not contain non-ASCII characters, 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 <mailbox> elements that contain non-ASCII addresses, preserve the header field in a "Downgraded-" header field before the conversion. Then perform COMMENT downgrading, DISPLAY-NAME downgrading, and MAILBOX downgrading.
如果标头字段包含包含非ASCII地址的<mailbox>元素，则在转换之前将标头字段保留在“降级-”标头字段中。然后执行注释降级、显示名称降级和邮箱降级。
Original-Recipient: Final-Recipient:
原始收件人：最终收件人：
If the header field contains non-ASCII characters, perform TYPED-ADDRESS downgrading.
如果标题字段包含非ASCII字符，请执行键入地址降级。
Date: Message-ID: Resent-Message-ID: In-Reply-To: References: Resent-Date: Resent-Message-ID: MIME-Version: Content-ID: Content-Transfer-Encoding: Content-Language: Accept-Language: Auto-Submitted:
日期：邮件ID:重新发送邮件ID:回复：引用：重新发送日期：重新发送邮件ID:MIME版本：内容ID:内容传输编码：内容语言：接受语言：自动提交：
These header fields do not contain non-ASCII characters except in comments. If the header field contains UTF-8 characters in comments, perform COMMENT downgrading.
除注释外，这些标题字段不包含非ASCII字符。如果标题字段在注释中包含UTF-8字符，请执行注释降级。
Received:
收到：
Perform COMMENT downgrading and RECEIVED downgrading.
执行评论降级和收到的降级。
Content-Type: Content-Disposition:
内容类型：内容配置：
Perform MIME-VALUE downgrading and COMMENT downgrading.
执行MIME值降级和注释降级。
Subject: Comments: Content-Description:
主题：评论：内容描述：
Perform UNSTRUCTURED downgrading.
执行非结构化降级。
Keywords:
关键词：
Perform WORD downgrading.
执行单词降级。
For all other header fields that contain non-ASCII characters, are user-defined, and are missing from this document or future defined header fields, perform ENCAPSULATION downgrading.
对于包含非ASCII字符、用户定义且在此文档或将来定义的标题字段中缺失的所有其他标题字段，请执行封装降级。
If the software understands the header field's structure and a downgrading algorithm other than ENCAPSULATION is applicable, that software SHOULD use that algorithm; ENCAPSULATION downgrading is used as a last resort.
如果软件了解标题字段的结构，并且适用除封装以外的降级算法，则该软件应使用该算法；封装降级是最后的手段。
Mailing list header fields (those that start in "List-") are part of this category.
邮件列表标题字段（以“列表-”开头的字段）属于此类别。
MIME body-part header fields may contain non-ASCII characters [RFC5335]. This section defines the conversion method to ASCII-only header fields for each MIME header field that contains non-ASCII characters. Parse the message body's MIME structure at all levels and check each MIME header field to see whether it contains non-ASCII characters. If the header field contains non-ASCII characters in the header field value, the header field is a target of the MIME body-part header field's downgrading. Each MIME header field's downgrading method is described below. COMMENT downgrading, MIME-VALUE downgrading, and UNSTRUCTURED downgrading are described in Section 5.
MIME正文部分标题字段可能包含非ASCII字符[RFC5335]。本节为每个包含非ASCII字符的MIME头字段定义将其转换为仅ASCII头字段的方法。在所有级别解析消息体的MIME结构，并检查每个MIME头字段，以查看它是否包含非ASCII字符。如果标头字段值中包含非ASCII字符，则标头字段是MIME正文部分标头字段降级的目标。每个MIME头字段的降级方法如下所述。注释降级、MIME值降级和非结构化降级在第5节中进行了描述。
Content-ID: The "Content-ID:" header field does not contain non-ASCII characters except in comments. If the header field contains UTF-8 characters in comments, perform COMMENT downgrading.
内容ID:“内容ID:”标题字段不包含非ASCII字符，注释中除外。如果标题字段在注释中包含UTF-8字符，请执行注释降级。
Content-Type:
内容类型：
Content-Disposition: Perform MIME-VALUE downgrading and COMMENT downgrading.
内容配置：执行MIME值降级和注释降级。
Content-Description: Perform UNSTRUCTURED downgrading.
内容描述：执行非结构化降级。
A downgraded message's header fields contain ASCII characters only. But they still contain MIME-encapsulated header fields that contain non-ASCII UTF-8 characters. Furthermore, the body part may contain UTF-8 characters. Implementations parsing Internet messages need to accept UTF-8 body parts and UTF-8 header fields that are MIME-encoded. Thus, this document inherits the security considerations of MIME-encoded header fields ([RFC2047] and [RFC3629]).
降级邮件的标题字段仅包含ASCII字符。但它们仍然包含包含非ASCII UTF-8字符的MIME封装头字段。此外，主体部分可能包含UTF-8字符。解析Internet消息的实现需要接受MIME编码的UTF-8正文部分和UTF-8头字段。因此，本文档继承了MIME编码头字段（[RFC2047]和[RFC3629]）的安全注意事项。
Rewriting header fields increases the opportunities for undetected spoofing by malicious senders. However, rewritten header fields are preserved into Downgraded-* header fields, and parsing Downgraded-* header fields enables the detection of spoofing caused by downgrading.
重写标头字段会增加恶意发件人未检测到欺骗的机会。但是，重写的头字段保留在降级的-*头字段中，解析降级的-*头字段可以检测降级导致的欺骗。
Addresses that do not appear in the message header fields may appear in the RCPT commands to an SMTP server for a number of reasons. Copying information from the envelope into the header fields risks inadvertent information disclosure (see [RFC5321] and Section 4 of this document). Mitigating inadvertent information disclosure is also discussed in these locations.
由于多种原因，邮件标题字段中未显示的地址可能会显示在发送给SMTP服务器的RCPT命令中。将信息从信封复制到标题字段可能会导致意外信息泄露（参见[RFC5321]和本文件第4节）。在这些地点还讨论了减轻无意信息披露的问题。
The techniques described here invalidate methods that depend on digital signatures over the envelope or any part of the message, which includes the top-level header fields and body-part header fields. Depending on the specific message being downgraded, the following techniques are likely to break: DomainKeys Identified Mail (DKIM), and possibly S/MIME and Pretty Good Privacy (PGP). The two obvious mitigations are to stick to 7-bit transport when using these techniques (as most/all of them presently require) or to make sure to have UTF8SMTP end-to-end when needed.
这里描述的技术使依赖于信封或消息任何部分上的数字签名的方法无效，其中包括顶级头字段和正文部分头字段。根据被降级的特定消息，以下技术可能会被破坏：DomainKeys Identified Mail（DKIM），以及S/MIME和Pretty Good Privacy（PGP）。两个明显的缓解措施是在使用这些技术时坚持使用7位传输（目前大多数/所有技术都需要），或者在需要时确保使用UTF8SMTP端到端。
Many gateways and servers on the Internet will discard header fields with which they are not familiar. To the extent to which the downgrade procedures depend on new header fields (e.g.,
Internet上的许多网关和服务器将丢弃他们不熟悉的头字段。降级程序取决于新标题字段的程度（例如。，
"Downgraded-") to avoid information loss, the risk of having those header fields dropped and subsequent implications must be identified. In particular, if the "Downgraded-" header fields are dropped, there is no possibility of reconstructing the original information at any point (before, during, or after delivery). Such gateways violate [RFC2979] and can be upgraded to correct the problem.
“降级-”）为避免信息丢失，必须确定删除这些标题字段的风险以及后续影响。特别是，如果删除“降级-”标题字段，则不可能在任何点（交付之前、期间或之后）重建原始信息。此类网关违反[RFC2979]，可以升级以纠正问题。
Even though the information is not lost, the original message cannot be perfectly reconstructed because some downgrading methods remove information (see Sections 5.1.1 and 5.1.5). Hence, downgrading is a one-way process.
即使信息没有丢失，原始信息也无法完全重建，因为某些降级方法会删除信息（见第5.1.1节和第5.1.5节）。因此，降级是一个单向过程。
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. Currently, information in the new Downgraded-* header fields is usually not inspected by these mechanisms, 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).
尽管任何电子邮件标题字段中的信息通常都应该受到怀疑，但当前的电子邮件系统通常采用各种机制和协议来提高信息的可信度。目前，这些机制通常不会检查新的降级-*头字段中的信息，并且可能比传统头字段更不可信。请注意，降级的-*标题字段可能是出于恶意插入的（以及与传统标题字段无关的内容）。
If an internationalized MUA would simply try to "upgrade" the message for display purposes (that is, display the information in the Downgraded-* header fields instead of the traditional header fields), the effectiveness of the deployed mechanisms and protocols is likely to be reduced, and the user may be exposed to additional risks. More guidance on how to display downgraded messages is given in [DISPLAY].
如果国际化的MUA只是为了显示目的而尝试“升级”消息（即，在降级的-*报头字段而不是传统的报头字段中显示信息），则部署的机制和协议的有效性可能会降低，用户可能会面临额外的风险。有关如何显示降级消息的更多指导，请参见[显示]。
Concerns about the trustworthiness of the Downgraded-* header fields are not limited to displaying and replying in MUAs, and should be carefully considered before using such header fields for other purposes as well.
对降级的-*标题字段的可信度的关注不仅限于在MUAs中显示和回复，在将此类标题字段用于其他用途之前，应仔细考虑。
See the "Security Considerations" section in [RFC4952] for more discussion.
有关更多讨论，请参阅[RFC4952]中的“安全注意事项”部分。
While [RFC2047] has a specific algorithm to deal with whitespace in adjacent encoded words, 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. While RFC 5322 states that implementations SHOULD limit lines to not more than 78 characters, implementations MAY choose to allow overly long encoded words in
虽然[RFC2047]有一个特定的算法来处理相邻编码字中的空白，但有许多部署的实现无法正确实现该算法。因此，在实际使用多个编码字时，空白行为在某种程度上是不可预测的。虽然RFC5322指出，实现应将行限制在不超过78个字符的范围内，但实现可能会选择允许输入过长的编码字
order to work around faulty [RFC2047] implementations. Implementations that choose to do so SHOULD have an optional mechanism to limit line length to 78 characters.
以解决[RFC2047]错误实现。选择这样做的实现应该有一个可选机制，将行长度限制为78个字符。
Downgrading is an alternative to avoid the rejection of messages that require UTF8SMTP support by a server that does not provide such support. Implementing the full specification of this document is desirable, but a partial implementation is also possible.
降级是一种替代方法，可以避免不提供UTF8SMTP支持的服务器拒绝需要UTF8SMTP支持的邮件。实现本文档的完整规范是可取的，但也可以部分实现。
If a partial downgrading implementation confronts an unsupported downgrading target, the implementation MUST NOT send the message to a server that does not support UTF8SMTP. Instead, it MUST either reject the message or generate a notification of non-deliverability.
如果部分降级实现遇到不受支持的降级目标，则该实现不得将消息发送到不支持UTF8SMTP的服务器。相反，它必须拒绝消息或生成不可交付性通知。
A partial downgrading, trivial downgrading, is discussed. It does not support non-ASCII addresses in SMTP envelope and address header fields, unknown header field downgrading, or the MIME body-part header field downgrading. It supports:
讨论了一种局部降阶，即琐碎降阶。它不支持SMTP信封和地址标头字段中的非ASCII地址、未知标头字段降级或MIME正文部分标头字段降级。它支持：
o some simple header field downgrading: Subject o comments and display name downgrading: From, To, Cc o trace header field downgrading: Received
o 一些简单的标题字段降级：主题o注释和显示名称降级：From、To、Cc o跟踪标题字段降级：Received
Otherwise, the downgrading fails.
否则，降级将失败。
Trivial downgrading targets mail messages that are generated by UTF8SMTP-aware MUAs and contain non-ASCII characters in comments, display names, and unstructured parts without using non-ASCII email addresses. These mail messages usually do not contain non-ASCII email addresses in the SMTP envelope and its header fields. But it is not deliverable via a UTF8SMTP-unaware SMTP server. Implementing full specification downgrading may be hard, but trivial downgrading saves mail messages without using non-ASCII addresses.
Trivial downgrading targets mail messages that are generated by UTF8SMTP-aware MUAs and contain non-ASCII characters in comments, display names, and unstructured parts without using non-ASCII email addresses. These mail messages usually do not contain non-ASCII email addresses in the SMTP envelope and its header fields. But it is not deliverable via a UTF8SMTP-unaware SMTP server. Implementing full specification downgrading may be hard, but trivial downgrading saves mail messages without using non-ASCII addresses.translate error, please retry
The SMTP client may encounter a SMTP server that does not support the 8BITMIME SMTP extension [RFC1652]. The server does not support "8bit" or "binary" data. Implementers need to consider converting "8bit" data to "base64" or "quoted-printable" encoded form and adjust the "Content-Transfer-Encoding" header field accordingly. If the body contains multiple MIME parts, this conversion MUST be performed for each MIME part.
SMTP客户端可能遇到不支持8BITMIME SMTP扩展[RFC1652]的SMTP服务器。服务器不支持“8位”或“二进制”数据。实现者需要考虑将“8位”数据转换为“Base64”或“引用的可打印”编码形式，并相应地调整“内容传输编码”标题字段。如果正文包含多个MIME部分，则必须对每个MIME部分执行此转换。
IANA has registered the following header fields in the Permanent Message Header Field registry, in accordance with the procedures set out in [RFC3864].
IANA已按照[RFC3864]中规定的程序，在永久消息标题字段注册表中注册了以下标题字段。
Header field name: Downgraded-Mail-From
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Mail-From
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Rcpt-To
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Rcpt-To
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-From
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-From
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Sender
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Sender
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-To
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-To
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Cc
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Cc
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Bcc
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Bcc
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Reply-To
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Reply-To
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Resent-From
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Resent-From
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Resent-Sender
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Resent-Sender
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Resent-To
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Resent-To
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Resent-Cc
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Resent-Cc
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Resent-Bcc
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Resent-Bcc
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Resent-Reply-To
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Resent-Reply-To
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Return-Path
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Return-Path
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Disposition-Notification-To
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Header field name: Downgraded-Disposition-Notification-To
Applicable protocol: mail
Status: experimental
Author/change controller: IETF
Specification document(s): This document (Section 3)
Furthermore, IANA is requested to refuse registration of all field names that start with "Downgraded-". For unknown header fields, use the downgrading method described in Section 3.3 to avoid conflicts with existing IETF activity (Email Address Internationalization).
此外，IANA被要求拒绝注册所有以“降级-”开头的字段名。对于未知的标题字段，请使用第3.3节中描述的降级方法，以避免与现有IETF活动（电子邮件地址国际化）发生冲突。
Significant comments and suggestions were received from John Klensin, Harald Alvestrand, Chris Newman, Randall Gellens, Charles Lindsey, Marcos Sanz, Alexey Melnikov, Frank Ellermann, Edward Lewis, S. Moonesamy, and JET members.
来自约翰·克莱辛、哈拉尔·阿尔韦斯特朗、克里斯·纽曼、兰德尔·盖伦斯、查尔斯·林赛、马科斯·桑兹、阿列克谢·梅尔尼科夫、弗兰克·埃勒曼、爱德华·刘易斯、S.穆内萨米和喷气机成员的重要评论和建议。
[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[RFC1652]Klensin，J.，Freed，N.，Rose，M.，Stefferud，E.，和D.Crocker，“8bit MIMEtransport的SMTP服务扩展”，RFC 16521994年7月。
[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月。
[RFC2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[RFC2979]弗里德，N.，“互联网防火墙的行为和要求”，RFC 2979，2000年10月。
[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月。
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.
[RFC4952]Klensin，J.和Y.Ko，“国际化电子邮件的概述和框架”，RFC 49522007年7月。
[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月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, September 2008.
[RFC5335]Abel，Y.，“国际化电子邮件标题”，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月。
[DISPLAY] Fujiwara, K., "Displaying Downgraded Messages for Email Address Internationalization", Work in Progress, March 2009.
[显示]Fujiwara，K.，“为电子邮件地址国际化显示降级邮件”，正在进行的工作，2009年3月。
[DSNBIS] Newman, C. and A. Melnikov, "Internationalized Delivery Status and Disposition Notifications", Work in Progress, December 2008.
[DSNBIS]Newman，C.和A.Melnikov，“国际化交付状态和处置通知”，正在进行的工作，2008年12月。
This appendix shows an SMTP downgrading example. Consider a mail message where:
本附录显示了SMTP降级示例。考虑邮件消息：
o The sender address is "NON-ASCII-local@example.com", which is a non-ASCII address. Its ASCII alternative is "ASCII-local@example.com" and its display-name is "DISPLAY-local".
o 发件人地址为“非ASCII”-local@example.com，这是一个非ASCII地址。它的ASCII替代品是“ASCII”-local@example.com其显示名称为“显示本地”。
o The "To:" address is "NON-ASCII-remote1@example.net", which is a non-ASCII address. Its ASCII alternative is "ASCII-remote1@example.net" and its display-name is "DISPLAY-remote1".
o “收件人：”地址是“非ASCII”-remote1@example.net，这是一个非ASCII地址。它的ASCII替代品是“ASCII”-remote1@example.net其显示名称为“display-remote1”。
o The "Cc:" address is a non-ASCII address, "NON-ASCII-remote2@example.org", without an alternative ASCII address. Its display-name is "DISPLAY-remote2".
o “Cc:”地址是非ASCII地址，“非ASCII”-remote2@example.org“，没有可选的ASCII地址。其显示名称为“display-remote2”。
o Three display names contain non-ASCII characters.
o 三个显示名称包含非ASCII字符。
o The Subject header field is "NON-ASCII-SUBJECT", which contains non-ASCII characters.
o 主题标题字段为“非ASCII主题”，包含非ASCII字符。
o Assume the "To:" recipient's MTA (example.net) does not support UTF8SMTP.
o 假设“收件人：”收件人的MTA（例如.net）不支持UTF8SMTP。
o Assume the "Cc:" recipient's MTA (example.org) supports UTF8SMTP.
o 假设“Cc:”收件人的MTA（example.org）支持UTF8SMTP。
The first example SMTP envelope/message is shown in Figure 1. In this example, the "To:" recipient's session is the focus.
第一个SMTP信封/邮件示例如图1所示。在本例中，“收件人：”的会话是焦点。
MAIL FROM: <NON-ASCII-local@example.com>
ALT-ADDRESS=ASCII-local@example.com
RCPT TO: <NON-ASCII-remote1@example.net>
ALT-ADDRESS=ASCII-remote1@example.net
RCPT TO: <NON-ASCII-remote2@example.org>
-------------------------------------------------------------
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>>
To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>>
Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Date: DATE
MAIL FROM: <NON-ASCII-local@example.com>
ALT-ADDRESS=ASCII-local@example.com
RCPT TO: <NON-ASCII-remote1@example.net>
ALT-ADDRESS=ASCII-remote1@example.net
RCPT TO: <NON-ASCII-remote2@example.org>
-------------------------------------------------------------
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>>
To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>>
Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Date: DATE
MAIL_BODY
邮件正文
Figure 1: Original envelope/message (example 1)
图1：原始信封/邮件（示例1）
In this example, there are two SMTP recipients; one is "To:", the other is "Cc:". The SMTP downgrading uses To: session downgrading. Figure 2 shows an SMTP downgraded example.
在本例中，有两个SMTP收件人；一个是“To:”，另一个是“Cc:”。SMTP降级用于：会话降级。图2显示了一个SMTP降级的示例。
MAIL FROM: <ASCII-local@example.com>
RCPT TO: <ASCII-remote1@example.net>
-------------------------------------------------------------
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net_?=
=?UTF-8?Q?<ASCII-remote1@example.net>>?=
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>>
To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>>
Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Date: DATE
MAIL FROM: <ASCII-local@example.com>
RCPT TO: <ASCII-remote1@example.net>
-------------------------------------------------------------
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net_?=
=?UTF-8?Q?<ASCII-remote1@example.net>>?=
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>>
To: DISPLAY-remote1 <NON-ASCII-remote1@example.net
<ASCII-remote1@example.net>>
Cc: DISPLAY-remote2 <NON-ASCII-remote2@example.org>
Date: DATE
MAIL_BODY
邮件正文
Figure 2: SMTP downgraded envelope/message (example 1)
图2:SMTP降级信封/邮件（示例1）
After SMTP downgrading, header field downgrading is performed. The final downgraded message is shown in Figure 3. A Return-Path header field will be added by the final destination MTA.
SMTP降级后，将执行标头字段降级。最终的降级消息如图3所示。最终目标MTA将添加返回路径标头字段。
Return-Path: <ASCII-local@example.com>
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net_?=
=?UTF-8?Q?<ASCII-remote1@example.net>>?=
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
From: =?UTF-8?Q?DISPLAY-local?= <ASCII-local@example.com>
Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?=
To: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net>
Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Cc: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address
=?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:;
Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?=
=?UTF-8?Q?<NON-ASCII-remote2@example.org>?=
Date: DATE
Return-Path: <ASCII-local@example.com>
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?=
Downgraded-Rcpt-To: =?UTF-8?Q?<NON-ASCII-remote1@example.net_?=
=?UTF-8?Q?<ASCII-remote1@example.net>>?=
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
From: =?UTF-8?Q?DISPLAY-local?= <ASCII-local@example.com>
Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?=
To: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net>
Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?=
=?UTF-8?Q?<NON-ASCII-remote1@example.net_<ASCII-remote1@example.net>>?=
Cc: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address
=?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:;
Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?=
=?UTF-8?Q?<NON-ASCII-remote2@example.org>?=
Date: DATE
MAIL_BODY
邮件正文
Figure 3: Downgraded message (example 1)
图3：降级消息（示例1）
In many cases, the sender wants to use a non-ASCII address and the recipient is a traditional mail user. The SMTP server handing mail for the recipient and/or the recipient's MUA does not support UTF8SMTP extension. Consider a mail message where:
在许多情况下，发件人希望使用非ASCII地址，而收件人是传统的邮件用户。为收件人和/或收件人的MUA处理邮件的SMTP服务器不支持UTF8SMTP扩展名。考虑邮件消息：
o The sender address is "NON-ASCII-local@example.com", which is a non-ASCII address. Its ASCII alternative is "ASCII-local@example.com". It has a display-name "DISPLAY-local", which contains non-ASCII characters.
o 发件人地址为“非ASCII”-local@example.com，这是一个非ASCII地址。它的ASCII替代品是“ASCII”-local@example.com". 它有一个显示名称“display local”，其中包含非ASCII字符。
o The "To:" address is "ASCII-remote1@example.net", which is ASCII-only. It has a display-name, "DISPLAY-remote1", which contains non-ASCII characters.
o “收件人：”地址是“ASCII”-remote1@example.net“，仅为ASCII码。它有一个显示名“display-remote1”，其中包含非ASCII字符。
o The "Subject:" header field is "NON-ASCII-SUBJECT", which contains non-ASCII characters.
o “主题：”标题字段为“非ASCII主题”，包含非ASCII字符。
The second example envelope/message is shown in Figure 4.
第二个示例信封/消息如图4所示。
MAIL From: <NON-ASCII-local@example.com>
ALT-ADDRESS=ASCII-local@example.com
RCPT TO: <ASCII-remote1@example.net>
-------------------------------------------------------------
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>>
To: DISPLAY-remote1 <ASCII-remote1@example.net>
Date: DATE
MAIL From: <NON-ASCII-local@example.com>
ALT-ADDRESS=ASCII-local@example.com
RCPT TO: <ASCII-remote1@example.net>
-------------------------------------------------------------
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>>
To: DISPLAY-remote1 <ASCII-remote1@example.net>
Date: DATE
MAIL_BODY
邮件正文
Figure 4: Original message (example 2)
图4：原始消息（示例2）
In this example, SMTP session is downgradable. Figure 5 shows an SMTP downgraded envelope/message.
在本例中，SMTP会话是可降级的。图5显示了SMTP降级的信封/邮件。
MAIL From: <ASCII-local@example.com>
RCPT TO: <ASCII-remote1@example.net>
-------------------------------------------------------------
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?=
?=UTF8?Q?<ASCII-local@example.com>>?=
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>>
To: DISPLAY-remote1 <ASCII-remote1@example.net>
Date: DATE
MAIL From: <ASCII-local@example.com>
RCPT TO: <ASCII-remote1@example.net>
-------------------------------------------------------------
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?=
?=UTF8?Q?<ASCII-local@example.com>>?=
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: NON-ASCII-SUBJECT
From: DISPLAY-local <NON-ASCII-local@example.com
<ASCII-local@example.com>>
To: DISPLAY-remote1 <ASCII-remote1@example.net>
Date: DATE
MAIL_BODY
邮件正文
Figure 5: SMTP downgraded envelope/message (example 2)
图5:SMTP降级信封/邮件（示例2）
After SMTP downgrading, header field downgrading is performed. The downgraded example is shown in Figure 6.
SMTP降级后，将执行标头字段降级。降级示例如图6所示。
Return-Path: <ASCII-local@example.com>
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?=
=?UTF8?Q?<ASCII-local@example.com>>?=
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?=
From: =?UTF-8?Q?DISPLAY-local?= <ASCII-local@example.com>
To: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net>
Date: DATE
Return-Path: <ASCII-local@example.com>
Downgraded-Mail-From: =?UTF-8?Q?<NON-ASCII-local@example.com_?=
=?UTF8?Q?<ASCII-local@example.com>>?=
Message-Id: MESSAGE_ID
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?=
Downgraded-From: =?UTF-8?Q?DISPLAY-local_<NON-ASCII-local@example.com_?=
=?UTF-8?Q?<ASCII-local@example.com>>?=
From: =?UTF-8?Q?DISPLAY-local?= <ASCII-local@example.com>
To: =?UTF-8?Q?DISPLAY-remote1?= <ASCII-remote1@example.net>
Date: DATE
MAIL_BODY
邮件正文
Figure 6: Downgraded message (example 2)
图6：降级消息（示例2）
Authors' Addresses
作者地址
Kazunori Fujiwara (editor) 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
Yoshiro Yoneya (editor) Japan Registry Services Co., Ltd. Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan
Yoneya Yoshiro（编辑）日本注册服务有限公司千代田第一大厦东13楼，日本东京西神田千代田区3-8-1号101-0065
Phone: +81 3 5215 8451
EMail: yone@jprs.co.jp
Phone: +81 3 5215 8451
EMail: yone@jprs.co.jp