Network Working Group Y. Abel, Ed.
Request for Comments: 5335 TWNIC
Updates: 2045, 2822 September 2008
Category: Experimental
Network Working Group Y. Abel, Ed.
Request for Comments: 5335 TWNIC
Updates: 2045, 2822 September 2008
Category: Experimental
Internationalized Email Headers
国际化电子邮件标题
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.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Abstract
摘要
Full internationalization of electronic mail requires not only the capabilities to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and the information based on them in mail header fields. This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. This specification Updates section 6.4 of RFC 2045 to conform with the requirements.
电子邮件的全面国际化不仅需要传输非ASCII内容、在特定的标题字段中对选定信息进行编码以及在信封地址中使用非ASCII字符的能力。它还需要能够在邮件头字段中表达这些地址以及基于这些地址的信息。本文档指定了Internet邮件的一个实验变体，它允许使用UTF-8编码的Unicode而不是ASCII作为Internet电子邮件头字段的基本形式。根据相关规范的规定，只有在得到SMTP扩展授权的情况下，才允许传输此表单。本规范更新了RFC 2045第6.4节，以符合要求。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Role of This Specification . . . . . . . . . . . . . . . . 3
1.2. Relation to Other Standards . . . . . . . . . . . . . . . 3
2. Background and History . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Changes on Message Header Fields . . . . . . . . . . . . . . . 5
4.1. UTF-8 Syntax and Normalization . . . . . . . . . . . . . . 5
4.2. Changes on MIME Headers . . . . . . . . . . . . . . . . . 6
4.3. Syntax Extensions to RFC 2822 . . . . . . . . . . . . . . 6
4.4. Change on addr-spec Syntax . . . . . . . . . . . . . . . . 8
4.5. Trace Field Syntax . . . . . . . . . . . . . . . . . . . . 9
4.6. message/global . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Role of This Specification . . . . . . . . . . . . . . . . 3
1.2. Relation to Other Standards . . . . . . . . . . . . . . . 3
2. Background and History . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Changes on Message Header Fields . . . . . . . . . . . . . . . 5
4.1. UTF-8 Syntax and Normalization . . . . . . . . . . . . . . 5
4.2. Changes on MIME Headers . . . . . . . . . . . . . . . . . 6
4.3. Syntax Extensions to RFC 2822 . . . . . . . . . . . . . . 6
4.4. Change on addr-spec Syntax . . . . . . . . . . . . . . . . 8
4.5. Trace Field Syntax . . . . . . . . . . . . . . . . . . . . 9
4.6. message/global . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Full internationalization of electronic mail requires several capabilities:
电子邮件的完全国际化需要几个功能：
o The capability to transmit non-ASCII content, provided for as part of the basic MIME specification [RFC2045], [RFC2046].
o 传输非ASCII内容的能力，作为基本MIME规范[RFC2045]、[RFC2046]的一部分提供。
o The capability to use international characters in envelope addresses, discussed in [RFC4952] and specified in [RFC5336].
o [RFC4952]中讨论并在[RFC5336]中规定的在信封地址中使用国际字符的能力。
o The capability to express those addresses, and information related to them and based on them, in mail header fields, defined in this document.
o 在本文档中定义的邮件头字段中表示这些地址及其相关信息的能力。
This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8 [RFC3629], rather than ASCII, as the base form for Internet email header fields. This form is permitted in transmission, if authorized by the SMTP extension specified in [RFC5336] or by other transport mechanisms capable of processing it.
本文档指定了一种试验性的Internet邮件变体，它允许使用UTF-8[RFC3629]中编码的Unicode而不是ASCII作为Internet电子邮件头字段的基本形式。如果[RFC5336]中指定的SMTP扩展或其他能够处理此表单的传输机制授权，则允许传输此表单。
This document updates Section 6.4 of RFC 2045. It removes the blanket ban on applying a content-transfer-encoding to all subtypes of message/, and instead specifies that a composite subtype MAY specify whether or not a content-transfer-encoding can be used for that subtype, with "cannot be used" as the default.
本文件更新了RFC 2045第6.4节。它取消了对message/的所有子类型应用内容传输编码的全面禁止，而是指定复合子类型可以指定是否可以对该子类型使用内容传输编码，默认为“不能使用”。
This document also updates [RFC2822] and MIME ([RFC2045]), and the fact that an Experimental specification updates a Standards-Track specification means that people who participate in the experiment have to consider those standards updated.
该文档还更新[RCFC2222]和MIME（[RCF204]），并且实验规范更新标准跟踪规范的事实意味着参与实验的人必须考虑更新这些标准。
Allowing use of a content-transfer-encoding on subtypes of messages is not limited to transmissions that are authorized by the SMTP extension specified in [RFC5336]. Message/global permits use of a content-transfer-encoding.
允许在邮件子类型上使用内容传输编码不限于[RFC5336]中指定的SMTP扩展授权的传输。消息/全局允许使用内容传输编码。
Mailbox names often represent the names of human users. Many of these users throughout the world have names that are not normally expressed with just the ASCII repertoire of characters, and would like to use more or less their real names in their mailbox names.
邮箱名称通常表示人类用户的名称。世界上许多这样的用户的姓名通常不使用ASCII字符表来表示，他们希望在邮箱名称中或多或少使用自己的真实姓名。
These users are also likely to use non-ASCII text in their common names and subjects of email messages, both received and sent. This protocol specifies UTF-8 as the encoding to represent email header field bodies.
这些用户在收到和发送的电子邮件中的常用名称和主题中也可能使用非ASCII文本。此协议指定UTF-8作为表示电子邮件头字段正文的编码。
The traditional format of email messages [RFC2822] allows only ASCII characters in the header fields of messages. This prevents users from having email addresses that contain non-ASCII characters. It further forces non-ASCII text in common names, comments, and in free text (such as in the Subject: field) to be encoded (as required by MIME format [RFC2047]). This specification describes a change to the email message format that is related to the SMTP message transport change described in the associated document [RFC4952] and [RFC5336], and that allows non-ASCII characters in most email header fields. These changes affect SMTP clients, SMTP servers, mail user agents (MUAs), list expanders, gateways to other media, and all other processes that parse or handle email messages.
传统的电子邮件格式[RFC2822]只允许在邮件的标题字段中使用ASCII字符。这将防止用户拥有包含非ASCII字符的电子邮件地址。它进一步强制对普通名称、注释和自由文本（如主题：字段）中的非ASCII文本进行编码（按照MIME格式[RFC2047]的要求）。本规范描述了与相关文档[RFC4952]和[RFC5336]中描述的SMTP邮件传输更改相关的电子邮件格式更改，该更改允许在大多数电子邮件标题字段中使用非ASCII字符。这些更改会影响SMTP客户端、SMTP服务器、邮件用户代理（MUA）、列表扩展器、到其他媒体的网关，以及解析或处理电子邮件的所有其他进程。
As specified in [RFC5336], an SMTP protocol extension "UTF8SMTP" is used to prevent the transmission of messages with UTF-8 header fields to systems that cannot handle such messages.
如[RFC5336]中所述，SMTP协议扩展“UTF8SMTP”用于防止将带有UTF-8头字段的邮件传输到无法处理此类邮件的系统。
Use of this SMTP extension helps prevent the introduction of such messages into message stores that might misinterpret, improperly display, or mangle such messages. It should be noted that using an ESMTP extension does not prevent transferring email messages with UTF-8 header fields to other systems that use the email format for messages and that may not be upgraded, such as unextended POP and IMAP servers. Changes to these protocols to handle UTF-8 header fields are addressed in [EAI-POP] and [IMAP-UTF8] .
使用此SMTP扩展有助于防止将此类邮件引入邮件存储中，从而可能误解、不正确显示或损坏此类邮件。应该注意的是，使用ESMTP扩展并不能阻止将带有UTF-8头字段的电子邮件传输到使用邮件格式且可能无法升级的其他系统，例如未扩展的POP和IMAP服务器。[EAI-POP]和[IMAP-UTF8]中对这些协议进行了更改，以处理UTF-8头字段。
The objective for this protocol is to allow UTF-8 in email header fields. Issues such as how to handle messages containing UTF-8 header fields that have to be delivered to systems that have not been upgraded to support this capability are discussed in [DOWNGRADE].
此协议的目标是在电子邮件头字段中允许UTF-8。[Degrade]中讨论了如何处理包含UTF-8头字段的消息等问题，这些消息必须发送到尚未升级以支持此功能的系统。
A plain ASCII string is also a valid UTF-8 string; see [RFC3629]. In this document, ordinary ASCII characters are UTF-8 characters if they are in headers which contain <utf8-xtra-char>s.
普通ASCII字符串也是有效的UTF-8字符串；参见[RFC3629]。在本文档中，如果普通ASCII字符位于包含<utf8 xtra char>s的标题中，则它们是UTF-8字符。
Unless otherwise noted, all terms used here are defined in [RFC2821], [RFC2822], [RFC4952], or [RFC5336].
除非另有说明，此处使用的所有术语均在[RFC2821]、[RFC2822]、[RFC4952]或[RFC5336]中定义。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
SMTP clients can send header fields in UTF-8 format, if the UTF8SMTP extension is advertised by the SMTP server or is permitted by other transport mechanisms.
如果SMTP服务器播发UTF8SMTP扩展或其他传输机制允许，SMTP客户端可以发送UTF-8格式的标头字段。
This protocol does NOT change the [RFC2822] rules for defining header field names. The bodies of header fields are allowed to contain UTF-8 characters, but the header field names themselves must contain only ASCII characters.
此协议不会更改定义标头字段名称的[RFC2822]规则。头字段的主体可以包含UTF-8字符，但头字段名称本身只能包含ASCII字符。
To permit UTF-8 characters in field values, the header definition in [RFC2822] must be extended to support the new format. The following ABNF is defined to substitute those definitions in [RFC2822].
为了允许字段值中包含UTF-8字符，必须扩展[RFC2822]中的标题定义以支持新格式。定义以下ABNF以替代[RFC2822]中的定义。
The syntax rules not covered in this section remain as defined in [RFC2822].
本节未涉及的语法规则仍如[RFC2822]中所定义。
UTF-8 characters can be defined in terms of octets using the following ABNF [RFC5234], taken from [RFC3629]:
UTF-8字符可以使用取自[RFC3629]的以下ABNF[RFC5234]以八位字节定义：
UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4
UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = %xC2-DF UTF8-tail
UTF8-2 = %xC2-DF UTF8-tail
UTF8-3 = %xE0 %xA0-BF UTF8-tail /
%xE1-EC 2(UTF8-tail) /
%xED %x80-9F UTF8-tail /
%xEE-EF 2(UTF8-tail)
UTF8-3 = %xE0 %xA0-BF UTF8-tail /
%xE1-EC 2(UTF8-tail) /
%xED %x80-9F UTF8-tail /
%xEE-EF 2(UTF8-tail)
UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) /
%xF1-F3 3( UTF8-tail ) /
%xF4 %x80-8F 2( UTF8-tail )
UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) /
%xF1-F3 3( UTF8-tail ) /
%xF4 %x80-8F 2( UTF8-tail )
UTF8-tail = %x80-BF
UTF8-tail = %x80-BF
These are normatively defined in [RFC3629], but kept in this document for reasons of convenience.
[RFC3629]中对其进行了规范性定义，但出于方便起见，将其保存在本文件中。
See [RFC5198] for a discussion of normalization; the use of normalization form NFC is RECOMMENDED.
有关规范化的讨论，请参见[RFC5198]；建议使用标准化形式的NFC。
This specification updates Section 6.4 of [RFC2045]. [RFC2045] prohibits applying a content-transfer-encoding to all subtypes of message/. This specification relaxes the rule -- it allows newly defined MIME types to permit content-transfer-encoding, and it allows content-transfer-encoding for message/global (see Section 4.6).
本规范更新了[RFC2045]第6.4节。[RFC2045]禁止对message/的所有子类型应用内容传输编码。该规范放宽了规则——它允许新定义的MIME类型允许内容传输编码，并且允许消息/全局的内容传输编码（参见第4.6节）。
Background: Normally, transfer of message/global will be done in 8-bit-clean channels, and body parts will have "identity" encodings, that is, no decoding is necessary. In the case where a message containing a message/global is downgraded from 8-bit to 7-bit as described in [RFC1652], an encoding may be applied to the message; if the message travels multiple times between a 7-bit environment and an environment implementing UTF8SMTP, multiple levels of encoding may occur. This is expected to be rarely seen in practice, and the potential complexity of other ways of dealing with the issue are thought to be larger than the complexity of allowing nested encodings where necessary.
背景：通常情况下，消息/全局的传输将在8位干净通道中完成，身体部位将有“身份”编码，即不需要解码。如[RFC1652]所述，在包含消息/全局的消息从8位降级到7位的情况下，可对该消息应用编码；如果消息在7位环境和实现UTF8SMTP的环境之间多次传输，则可能会出现多级编码。这在实践中是很少见的，其他处理该问题的方法的潜在复杂性被认为比在必要时允许嵌套编码的复杂性更大。
The following rules are intended to extend the corresponding rules in [RFC2822] in order to allow UTF-8 characters.
以下规则旨在扩展[RFC2822]中的相应规则，以允许使用UTF-8字符。
FWS = <see [RFC2822], folding white space>
FWS = <see [RFC2822], folding white space>
CFWS = <see [RFC2822], folding white space>
CFWS = <see [RFC2822], folding white space>
ctext =/ UTF8-xtra-char
ctext=/UTF8 xtra char
utext =/ UTF8-xtra-char
utext=/UTF8 xtra char
comment = "(" *([FWS] utf8-ccontent) [FWS] ")"
comment = "(" *([FWS] utf8-ccontent) [FWS] ")"
word = utf8-atom / utf8-quoted-string
word = utf8-atom / utf8-quoted-string
This means that all the [RFC2822] constructs that build upon these will permit UTF-8 characters, including comments and quoted strings. We do not change the syntax of <atext> in order to allow UTF8 characters in <addr-spec>. This would also allow UTF-8 characters in <message-id>, which is not allowed due to the limitation described in Section 4.5. Instead, <utf8-atext> is added to meet this requirement.
这意味着所有基于这些的[RFC2822]构造将允许UTF-8字符，包括注释和带引号的字符串。我们不会为了在<addr spec>中允许UTF8字符而更改<atext>的语法。这也将允许在<message id>中使用UTF-8字符，由于第4.5节所述的限制，这是不允许的。相反，添加了<utf8 atext>以满足此要求。
utf8-text = %d1-9 / ; all UTF-8 characters except
%d11-12 / ; US-ASCII NUL, CR, and LF
%d14-127 /
UTF8-xtra-char
utf8-text = %d1-9 / ; all UTF-8 characters except
%d11-12 / ; US-ASCII NUL, CR, and LF
%d14-127 /
UTF8-xtra-char
utf8-quoted-pair = ("\" utf8-text) / obs-qp
utf8-quoted-pair = ("\" utf8-text) / obs-qp
utf8-qcontent = utf8-qtext / utf8-quoted-pair
utf8-qcontent = utf8-qtext / utf8-quoted-pair
utf8-quoted-string = [CFWS]
DQUOTE *([FWS] utf8-qcontent) [FWS] DQUOTE
[CFWS]
utf8-quoted-string = [CFWS]
DQUOTE *([FWS] utf8-qcontent) [FWS] DQUOTE
[CFWS]
utf8-ccontent = ctext / utf8-quoted-pair / comment
utf8-ccontent = ctext / utf8-quoted-pair / comment
utf8-qtext = qtext / UTF8-xtra-char
utf8-qtext = qtext / UTF8-xtra-char
utf8-atext = ALPHA / DIGIT /
"!" / "#" / ; Any character except
"$" / "%" / ; controls, SP, and specials.
"&" / "'" / ; Used for atoms.
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~" /
UTF8-xtra-char
utf8-atext = ALPHA / DIGIT /
"!" / "#" / ; Any character except
"$" / "%" / ; controls, SP, and specials.
"&" / "'" / ; Used for atoms.
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~" /
UTF8-xtra-char
utf8-atom = [CFWS] 1*utf8-atext [CFWS]
utf8-atom = [CFWS] 1*utf8-atext [CFWS]
utf8-dot-atom = [CFWS] utf8-dot-atom-text [CFWS]
utf8-dot-atom = [CFWS] utf8-dot-atom-text [CFWS]
utf8-dot-atom-text = 1*utf8-atext *("." 1*utf8-atext)
utf8-dot-atom-text = 1*utf8-atext *("." 1*utf8-atext)
qcontent = utf8-qcontent
qcontent = utf8-qcontent
To allow the use of UTF-8 in a Content-Description header field [RFC2045], the following syntax is used:
要允许在内容描述标头字段[RFC2045]中使用UTF-8，请使用以下语法：
description = "Content-Description:" unstructured CRLF
description=“Content description:”非结构化CRLF
The <utext> syntax is extended above to allow UTF-8 in all <unstructured> header fields.
上面扩展了<utext>语法，允许在所有<unstructured>头字段中使用UTF-8。
Note, however, this does not remove any constraint on the character set of protocol elements; for instance, all the allowed values for timezone in the Date: headers are still expressed in ASCII. And also, none of this revised syntax changes what is allowed in a <msg-id>, which will still remain in pure ASCII.
然而，请注意，这并没有消除协议元素的字符集上的任何约束；例如，Date:头中时区的所有允许值仍然用ASCII表示。而且，这些修改后的语法都没有改变<msg id>中允许的内容，而<msg id>仍将保持纯ASCII格式。
Internationalized email addresses are represented in UTF-8. Thus, all header fields containing <mailbox>es are updated to permit UTF-8 as well as an additional, optional all-ASCII alternate address. Note that Message Submission Servers ("MSAs") and Message Transfer Agents (MTAs) may downgrade internationalized messages as needed. The procedure for doing so is described in [DOWNGRADE].
国际化电子邮件地址以UTF-8表示。因此，包含<mailbox>es的所有报头字段都会更新，以允许UTF-8以及一个额外的可选全ASCII备用地址。请注意，邮件提交服务器（“MSA”）和邮件传输代理（MTA）可能会根据需要降级国际化邮件。执行此操作的程序在[降级]中进行了说明。
mailbox = name-addr / addr-spec / utf8-addr-spec
mailbox = name-addr / addr-spec / utf8-addr-spec
angle-addr =/ [CFWS] "<" utf8-addr-spec [ alt-address ] ">"
[CFWS] / obs-angle-addr
angle-addr =/ [CFWS] "<" utf8-addr-spec [ alt-address ] ">"
[CFWS] / obs-angle-addr
utf8-addr-spec = utf8-local-part "@" utf8-domain
utf8地址规范=utf8本地部分“@”utf8域
utf8-local-part= utf8-dot-atom / utf8-quoted-string / obs-local-part
utf8-local-part= utf8-dot-atom / utf8-quoted-string / obs-local-part
utf8-domain = utf8-dot-atom / domain-literal / obs-domain
utf8-domain = utf8-dot-atom / domain-literal / obs-domain
alt-address = FWS "<" addr-spec ">"
alt-address = FWS "<" addr-spec ">"
Below are a few examples of possible <mailbox> representations.
下面是一些可能的<mailbox>表示的示例。
"DISPLAY_NAME" <ASCII@ASCII>
; traditional mailbox format
"DISPLAY_NAME" <ASCII@ASCII>
; traditional mailbox format
"DISPLAY_NAME" <non-ASCII@non-ASCII>
; UTF8SMTP but no ALT-ADDRESS parameter provided,
; message will bounce if UTF8SMTP extension is not supported
"DISPLAY_NAME" <non-ASCII@non-ASCII>
; UTF8SMTP but no ALT-ADDRESS parameter provided,
; message will bounce if UTF8SMTP extension is not supported
<non-ASCII@non-ASCII>
; without DISPLAY_NAME and quoted string
; UTF8SMTP but no ALT-ADDRESS parameter provided,
; message will bounce if UTF8SMTP extension is not supported
<non-ASCII@non-ASCII>
; without DISPLAY_NAME and quoted string
; UTF8SMTP but no ALT-ADDRESS parameter provided,
; message will bounce if UTF8SMTP extension is not supported
"DISPLAY_NAME" <non-ASCII@non-ASCII <ASCII@ASCII>>
; UTF8SMTP with ALT-ADDRESS parameter provided,
; ALT-ADDRESS can be used if downgrade is necessary
"DISPLAY_NAME" <non-ASCII@non-ASCII <ASCII@ASCII>>
; UTF8SMTP with ALT-ADDRESS parameter provided,
; ALT-ADDRESS can be used if downgrade is necessary
"For" fields containing internationalized addresses are allowed, by use of the new uFor syntax. UTF-8 information may be needed in Received fields. Such information is therefore allowed to preserve the integrity of those fields. The uFor syntax retains the original UTF-8 email address between email address internationalization (EAI)- aware MTAs. Note that, should downgrading be required, the uFor parameter is dropped per the procedure specified in [DOWNGRADE].
通过使用新的uFor语法，允许包含国际化地址的“For”字段。接收字段中可能需要UTF-8信息。因此，允许此类信息保持这些字段的完整性。uFor语法在支持电子邮件地址国际化（EAI）的MTA之间保留原始UTF-8电子邮件地址。请注意，如果需要降级，将按照[降级]中指定的程序删除uFor参数。
The "Return-Path" header provides the email return address in the mail delivery. Thus, the header is augmented to carry UTF-8 addresses (see the revised syntax of <angle-addr> in Section 4.4 of this document). This will not break the rule of trace field integrity, because the header is added at the last MTA and described in [RFC2821].
“返回路径”标题在邮件传递中提供电子邮件返回地址。因此，标头被扩充以承载UTF-8地址（参见本文件第4.4节中<angle addr>的修订语法）。这不会违反跟踪字段完整性规则，因为头是在最后一次MTA时添加的，并在[RFC2821]中进行了描述。
The <item-value> on "Received:" syntax is augmented to allow UTF-8 email address in the "For" field. <angle-addr> is augmented to include UTF-8 email address. In order to allow UTF-8 email addresses in an <addr-spec>, <utf8-addr-spec> is added to <item-value>.
“Received:”语法中的<item value>被扩充，以允许在“For”字段中使用UTF-8电子邮件地址<angle addr>被扩充为包含UTF-8电子邮件地址。为了允许在<addr spec>中使用UTF-8电子邮件地址，将<utf8 addr spec>添加到<item value>。
item-value =/ utf8-addr-spec
项目值=/utf8地址规格
Internationalized messages must only be transmitted as authorized by [RFC5336] or within a non-SMTP environment which supports these messages. A message is a "message/global message", if
只能在[RFC5336]授权的情况下或在支持这些邮件的非SMTP环境中传输国际化邮件。消息是“消息/全局消息”，如果
o it contains UTF-8 header values as specified in this document, or
o 它包含本文档中指定的UTF-8标头值，或
o it contains UTF-8 values in the headers fields of body parts.
o 它在身体部位的标题字段中包含UTF-8值。
The type message/global is similar to message/rfc822, except that it contains a message that can contain UTF-8 characters in the headers of the message or body parts. If this type is sent to a 7-bit-only system, it has to be encoded in MIME [RFC2045]. (Note that a system compliant with MIME that doesn't recognize message/global would treat it as "application/octet-stream" as described in Section 5.2.4 of [RFC2046].)
message/global类型与message/rfc822类似，只是它包含一条消息，消息头或正文部分中可以包含UTF-8字符。如果将此类型发送到仅7位的系统，则必须使用MIME[RFC2045]对其进行编码。（请注意，与MIME兼容但不识别消息/全局的系统会将其视为[RFC2046]第5.2.4节所述的“应用程序/八位字节流”。）
Alternatively, SMTP servers and other systems which transfer a message/global body part MAY choose to down-convert it to a message/ rfc822 body part using the rules described in [DOWNGRADE].
或者，传输邮件/全局正文部分的SMTP服务器和其他系统可以选择使用[降级]中描述的规则将其向下转换为邮件/rfc822正文部分。
Type name: message
类型名称：消息
Subtype name: global
子类型名称：全局
Required parameters: none
所需参数：无
Optional parameters: none
可选参数：无
Encoding considerations: Any content-transfer-encoding is permitted. The 8-bit or binary content-transfer-encodings are recommended where permitted.
编码注意事项：允许任何内容传输编码。如果允许，建议使用8位或二进制内容传输编码。
Security considerations: See Section 5.
安全注意事项：见第5节。
Interoperability considerations: The media type provides functionality similar to the message/rfc822 content type for email messages with international email headers. When there is a need to embed or return such content in another message, there is generally an option to use this media type and leave the content unchanged or down-convert the content to message/rfc822. Both of these choices will interoperate with the installed base, but with different properties. Systems unaware of international headers will typically treat a message/global body part as an unknown attachment, while they will understand the structure of a message/ rfc822. However, systems that understand message/global will provide functionality superior to the result of a down-conversion to message/rfc822. The most interoperable choice depends on the deployed software.
互操作性注意事项：对于具有国际电子邮件标题的电子邮件，媒体类型提供了类似于message/rfc822内容类型的功能。当需要在另一条消息中嵌入或返回此类内容时，通常可以选择使用此媒体类型，保持内容不变，或将内容向下转换为消息/rfc822。这两种选择都将与已安装的基础互操作，但具有不同的属性。不知道国际标头的系统通常会将消息/全局正文部分视为未知附件，同时它们会了解消息/rfc822的结构。但是，理解message/global的系统将提供优于message/rfc822下转换结果的功能。最具互操作性的选择取决于部署的软件。
Published specification: RFC 5335
已发布规范：RFC 5335
Applications that use this media type: SMTP servers and email clients that support multipart/report generation or parsing. Email clients which forward messages with international headers as attachments.
使用此媒体类型的应用程序：支持多部分/报告生成或分析的SMTP服务器和电子邮件客户端。电子邮件客户端转发带有国际邮件头作为附件的邮件。
Additional information:
其他信息：
Magic number(s): none
幻数：无
File extension(s): The extension ".u8msg" is suggested.
文件扩展名：建议使用扩展名“.u8msg”。
Macintosh file type code(s): A uniform type identifier (UTI) of "public.utf8-email-message" is suggested. This conforms to "public.message" and "public.composite-content", but does not necessarily conform to "public.utf8-plain-text".
Macintosh文件类型代码：建议使用“public.utf8电子邮件”的统一类型标识符（UTI）。这符合“public.message”和“public.composite content”，但不一定符合“public.utf8纯文本”。
Person & email address to contact for further information: See the Author's Address section of this document.
联系人和电子邮件地址以了解更多信息：请参阅本文档的作者地址部分。
Intended usage: COMMON
预期用途：普通
Restrictions on usage: This is a structured media type which embeds other MIME media types. The 8-bit or binary content-transfer-encoding MUST be used unless this media type is sent over a 7-bit-only transport.
使用限制：这是一种嵌入其他MIME媒体类型的结构化媒体类型。除非此媒体类型通过仅7位传输发送，否则必须使用8位或二进制内容传输编码。
Author: See the Author's Address section of this document.
作者：请参阅本文档的作者地址部分。
Change controller: IETF Standards Process
变更控制员：IETF标准流程
If a user has a non-ASCII mailbox address and an ASCII mailbox address, a digital certificate that identifies that user may have both addresses in the identity. Having multiple email addresses as identities in a single certificate is already supported in PKIX (Public Key Infrastructure for X.509 Certificates) and OpenPGP.
如果用户具有非ASCII邮箱地址和ASCII邮箱地址，则标识该用户的数字证书可能在标识中同时具有这两个地址。PKIX（用于X.509证书的公钥基础设施）和OpenPGP已经支持在单个证书中使用多个电子邮件地址作为身份。
Because UTF-8 often requires several octets to encode a single character, internationalized local parts may cause mail addresses to become longer. As specified in [RFC2822], each line of characters MUST be no more 998 octets, excluding the CRLF.
由于UTF-8通常需要几个八位字节来编码单个字符，国际化的本地部分可能会导致邮件地址变长。按照[RFC2822]中的规定，除CRLF外，每行字符不得超过998个八位字节。
Because internationalized local parts may cause email addresses to be longer, processes that parse, store, or handle email addresses or local parts must take extra care not to overflow buffers, truncate addresses, or exceed storage allotments. Also, they must take care, when comparing, to use the entire lengths of the addresses.
由于国际化的本地部分可能会导致电子邮件地址变长，因此解析、存储或处理电子邮件地址或本地部分的进程必须格外小心，以免缓冲区溢出、地址截断或超出存储分配。此外，在比较时，他们必须注意使用地址的整个长度。
In this specification, a user could provide an ASCII alternative address for a non-ASCII address. However, it is possible these two addresses go to different mailboxes, or even different people. This configuration may be based on a user's personal choice or on administration policy. We recognize that if ASCII and non-ASCII email is delivered to two different destinations, based on MTA capability, this may violate the principle of least astonishment, but this is not a "protocol problem".
在本规范中，用户可以为非ASCII地址提供ASCII替代地址。但是，这两个地址有可能指向不同的邮箱，甚至是不同的人。此配置可能基于用户的个人选择或管理策略。我们认识到，如果基于MTA功能，将ASCII和非ASCII电子邮件发送到两个不同的目的地，这可能会违反最小惊讶原则，但这不是“协议问题”。
The security impact of UTF-8 headers on email signature systems such as Domain Keys Identified Mail (DKIM), S/MIME, and OpenPGP is discussed in RFC 4952, Section 9. A subsequent document [DOWNGRADE] will cover the impact of downgrading on these systems.
RFC 4952第9节讨论了UTF-8头对电子邮件签名系统（如域密钥识别邮件（DKIM）、S/MIME和OpenPGP）的安全影响。随后的文件[降级]将涵盖降级对这些系统的影响。
IANA has registered the message/global MIME type using the registration form contained in Section 4.4.
IANA已使用第4.4节中包含的注册表格注册了消息/全局MIME类型。
This document incorporates many ideas first described in Internet-Draft form by Paul Hoffman, although many details have changed from that earlier work.
本文件包含了保罗·霍夫曼（Paul Hoffman）在互联网初稿中首次描述的许多想法，尽管许多细节与之前的工作有所不同。
The author especially thanks Jeff Yeh for his efforts and contributions on editing previous versions.
作者特别感谢Jeff Yeh在编辑之前版本方面所做的努力和贡献。
Most of the content of this document is provided by John C Klensin. Also, some significant comments and suggestions were received from Charles H. Lindsey, Kari Hurtta, Pete Resnick, Alexey Melnikov, Chris Newman, Yangwoo Ko, Yoshiro Yoneya, and other members of the JET team (Joint Engineering Team) and were incorporated into the document. The editor sincerely thanks them for their contributions.
本文件的大部分内容由John C Klensin提供。此外，查尔斯·H·林赛、卡里·赫塔、皮特·雷斯尼克、阿列克谢·梅尔尼科夫、克里斯·纽曼、杨宇高、Yoshiro Yoneya和喷气机团队（联合工程团队）的其他成员也提出了一些重要的意见和建议，并将其纳入本文件。编辑衷心感谢他们的贡献。
[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月。
[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月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[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月。
[RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 4952, July 2007.
[RFC4952]Klensin，J.和Y.Ko，“国际化电子邮件的概述和框架”，RFC 49522007年7月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198]Klensin，J.和M.Padlipsky，“网络交换的Unicode格式”，RFC 51982008年3月。
[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月。
[RFC5336] Yao, J., Ed. and W. Mao, Ed., "SMTP Extension for Internationalized Email Addresses", RFC 5336, September 2008.
[RFC5336]Yao，J.，Ed.和W.Mao，Ed.，“国际化电子邮件地址的SMTP扩展”，RFC 53362008年9月。
[DOWNGRADE] Fujiwara, K. and Y. Yoneya, "Downgrading mechanism for Email Address Internationalization", Work in Progress, July 2008.
[降级]Fujiwara，K.和Y.Yoneya，“电子邮件地址国际化的降级机制”，正在进行的工作，2008年7月。
[EAI-POP] Newman, C. and R. Gellens, "POP3 Support for UTF-8", Work in Progress, July 2008.
[EAI-POP]Newman，C.和R.Gellens，“对UTF-8的POP3支持”，正在进行的工作，2008年7月。
[IMAP-UTF8] Resnick, P. and C. Newman, "IMAP Support for UTF-8", Work in Progress, April 2008.
[IMAP-UTF8]Resnick，P.和C.Newman，“UTF-8的IMAP支持”，正在进行的工作，2008年4月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
Author's Address
作者地址
Abel Yang (editor) TWNIC 4F-2, No. 9, Sec 2, Roosvelt Rd. Taipei, 100 Taiwan
杨亚伯（编辑）台湾台北市罗斯福路2段9号TWNIC 4F-2
Phone: +886 2 23411313 ext 505
EMail: abelyang@twnic.net.tw
Phone: +886 2 23411313 ext 505
EMail: abelyang@twnic.net.tw
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.