Internet Engineering Task Force (IETF) B. Leiba
Request for Comments: 6854 Huawei Technologies
Updates: 5322 March 2013
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) B. Leiba
Request for Comments: 6854 Huawei Technologies
Updates: 5322 March 2013
Category: Standards Track
ISSN: 2070-1721
Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields
更新到Internet邮件格式，以允许在“发件人：”和“发件人：”标题字段中使用组语法
Abstract
摘要
The Internet Message Format (RFC 5322) allows "group" syntax in some email header fields, such as "To:" and "CC:", but not in "From:" or "Sender:". This document updates RFC 5322 to relax that restriction, allowing group syntax in those latter fields, as well as in "Resent-From:" and "Resent-Sender:", in certain situations.
Internet消息格式（RFC 5322）允许在某些电子邮件标题字段中使用“组”语法，例如“收件人：”和“抄送：”字段，但不允许在“发件人：”或“发件人：”字段中使用。本文档更新了RFC 5322以放宽该限制，在某些情况下，允许后面的字段以及“重新发送发件人：”和“重新发送发件人：”中使用组语法。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6854.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6854.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3
1.1.1. Requirements Notation . . . . . . . . . . . . . . . . . 3
1.1.2. Syntactic Notation . . . . . . . . . . . . . . . . . . 3
2. Allowing Group Syntax in "From:" and "Sender:" . . . . . . . . 3
2.1. Replacement of RFC 5322, Section 3.6.2. Originator Fields . 4
2.2. Update to RFC 5322, Section 3.6.6. Resent Fields . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . . 6
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3
1.1.1. Requirements Notation . . . . . . . . . . . . . . . . . 3
1.1.2. Syntactic Notation . . . . . . . . . . . . . . . . . . 3
2. Allowing Group Syntax in "From:" and "Sender:" . . . . . . . . 3
2.1. Replacement of RFC 5322, Section 3.6.2. Originator Fields . 4
2.2. Update to RFC 5322, Section 3.6.6. Resent Fields . . . . . 5
3. Applicability Statement . . . . . . . . . . . . . . . . . . . . 6
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
The Internet Message Format, as far back as RFC 822 [RFC0822], has always required a usable address to appear in the "From:" header field of messages in order to allow replies to be sent. To this end, the syntax of messages, up to and including the current specification [RFC5322], has required the use of the mailbox address form in the originator ("From:" and "Sender:") fields of messages and has specifically forbidden the use of the group address form, which permits an empty list of addresses (that is, an address list with no address included that might be used for a reply).
早在RFC 822[RFC0822]之前，互联网消息格式就一直要求在消息的“发件人：”标题字段中显示一个可用地址，以便发送回复。为此，在当前规范[RFC5322]之前，邮件的语法要求在邮件的发件人（“发件人：”和“发件人：”）字段中使用邮箱地址表单，并明确禁止使用允许空地址列表的组地址表单（也就是说，可能用于回复的地址列表中没有包含地址）。
However, the use cases for the "From:" field have evolved. There are numerous instances of automated systems that wish to send email but cannot handle replies, and a "From:" field with no usable addresses would be extremely useful for that purpose. More recently, work with internationalized email addresses [RFC6530] creates a real need to take a message with an internationalized email address and hand it to an older client that would have no ability to reply to such an address but might still wish to display the contents of the message. The group construct provides an existing syntax for unusable addresses (using the empty list of addresses) and also allows for a text label that describes the originator. For example:
然而，“From:”字段的用例已经演变。有许多自动化系统希望发送电子邮件，但无法处理回复，而没有可用地址的“发件人：”字段将非常有用。最近，使用国际化电子邮件地址[RFC6530]产生了一种真正的需要，即使用国际化电子邮件地址接收邮件并将其交给旧客户机，该客户机将无法回复此类地址，但可能仍希望显示邮件的内容。组构造为不可用的地址提供了现有语法（使用空地址列表），还允许使用描述发起者的文本标签。例如：
From: Automated System:;
From: Automated System:;
A review of many current email programs finds that all reviewed clients will properly display a message with group syntax in the "From:" field. At worst, such programs generate an error message when an attempt is made to reply to such a message. No other interoperability problems have been discovered.
对当前许多电子邮件程序的审查发现，所有审查过的客户端都会在“发件人：”字段中正确显示带有组语法的消息。在最坏的情况下，当试图回复此类消息时，此类程序会生成错误消息。没有发现其他互操作性问题。
This document therefore updates the Internet Message Format specification [RFC5322] to relax that restriction, allowing group syntax to be used in the originator ("From:" and "Sender:") fields, as well as in their corresponding resent ("Resent-From:" and "Resent-Sender:") fields. This change permits empty groups, as described above, and also permits named groups of mailboxes (groups with non-empty lists of addresses; see Section 4). Nevertheless, this document recommends against the general use of group syntax in these fields at this time (see Section 3).
因此，本文档更新了Internet消息格式规范[RFC5322]以放宽该限制，允许在发起人（“发件人：”和“发件人：”字段中以及在其相应的重新发送（“重新发送发件人：”和“重新发送发件人：”字段中使用组语法。如上所述，此更改允许空组，也允许指定邮箱组（具有非空地址列表的组；请参阅第4节）。然而，本文件建议此时不要在这些字段中普遍使用组语法（见第3节）。
The notational conventions here are the same as those in RFC 5322, and the following two subsections are copied directly from that document.
此处的符号约定与RFC 5322中的符号约定相同，以下两小节直接从该文件中复制。
This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of these terms appears in the Key Words document [RFC2119].
本文档偶尔使用大写字母表示的术语。当术语“必须”、“应该”、“建议”、“不得”、“不应该”和“可能”出现大写时，它们用于表示本规范的特殊要求。关于这些术语含义的讨论见关键词文件[RFC2119]。
This specification uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation for the formal definitions of the syntax of messages. Characters will be specified either by a decimal value (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by a case-insensitive literal value enclosed in quotation marks (e.g., "A" for either uppercase or lowercase A).
本规范使用增广巴科斯-诺尔形式（ABNF）[RFC5234]符号对消息语法进行正式定义。字符将由十进制值（例如，大写a的值为%d65，小写a的值为%d97）或引号中包含的不区分大小写的文字值（例如，大写或小写a的值为“a”）指定。
Section 3.6.2 of RFC 5322 defines the "From:" header field as containing a <mailbox-list> syntax element. This specification changes that definition to use the <address-list> syntax element, as is used in other fields, such as "To:", "CC:", and "Reply-To:". This specification also changes the definition of the "Sender:" header field from the <mailbox> syntax element to the <address> syntax element. While the <address> element includes the <mailbox> element already, we have chosen to specify both in the updated syntax as a way of highlighting the limited use intended for the change (see Section 3).
RFC 5322第3.6.2节将“发件人：”标题字段定义为包含<mailbox list>语法元素。本规范将该定义更改为使用<address list>语法元素，就像在其他字段中使用的一样，如“to:”、“CC:”和“Reply to:”。本规范还将“发件人：”标题字段的定义从<mailbox>语法元素更改为<address>语法元素。虽然<address>元素已经包含<mailbox>元素，但我们选择在更新的语法中指定这两个元素，作为突出显示用于更改的有限用途的一种方式（参见第3节）。
Section 2.1 below is a full replacement for Section 3.6.2 of RFC 5322, containing the new syntax as well as a new description of the semantics for the "From:" and "Sender:" fields. Section 2.2 below is a replacement of only the ABNF syntax for the "Resent-From:" and "Resent-Sender:" fields in Section 3.6.6 of RFC 5322; the rest of the syntax as well as the descriptive text of Section 3.6.6 of RFC 5322 remains unchanged.
下面的第2.1节完全取代了RFC 5322第3.6.2节，其中包含新语法以及“发件人：”和“发件人：”字段语义的新描述。以下第2.2节仅替换RFC 5322第3.6.6节中“重新发送发件人：”和“重新发送发件人：”字段的ABNF语法；RFC 5322第3.6.6节的其余语法和描述性文本保持不变。
[The text in the following section is not consistent within itself nor with the rest of this document in how it refers to message header fields, sometimes putting the field name in quotation marks and sometimes not, sometimes capitalizing the field name and sometimes not, and sometimes including the final colon and sometimes not. Because minimizing changes to the original text is more important, in this case, than attaining consistency, the text in Section 2.1, as well as that in Sections 1.1.1 and 1.1.2 above, is left as it was in RFC 5322.]
[下一节中的文本在引用消息头字段的方式上既不一致，也与本文档的其他部分不一致，有时将字段名用引号括起来，有时不用引号括起来，有时将字段名大写，有时不大写，有时包括最后一个冒号，有时不包括。因为g在这种情况下，对原始文本的更改比实现一致性更为重要，第2.1节以及上文第1.1.1节和第1.1.2节中的文本与RFC 5322中的文本保持一致。]
The originator fields of a message consist of the from field, the sender field (when applicable), and optionally the reply-to field. The from field consists of the field name "From" and a comma-separated list of one or more addresses (either mailbox or group syntax). If the from field contains more than one mailbox specification (including all mailboxes included in any groups), then the sender field, containing the field name "Sender" and a single address, MUST appear in the message. The from field and the sender field SHOULD NOT use group syntax; rather, the from field SHOULD use only the mailbox-list syntax and the sender field SHOULD use only mailbox syntax (see RFC 6854, Section 3). If the sender field uses group syntax, the group MUST NOT contain more than one mailbox. In either case, an optional reply-to field MAY also be included, which contains the field name "Reply-To" and a comma-separated list of one or more addresses.
邮件的“发件人”字段包括“发件人”字段、“发件人”字段（如果适用）和“回复”字段（可选）。“发件人”字段由字段名“发件人”和一个或多个地址（邮箱或组语法）的逗号分隔列表组成。如果发件人字段包含多个邮箱规范（包括任何组中包含的所有邮箱），则包含字段名“发件人”和单个地址的发件人字段必须出现在邮件中。发件人字段和发件人字段不应使用组语法；相反，发件人字段应仅使用邮箱列表语法，发件人字段应仅使用邮箱语法（请参阅RFC 6854，第3节）。如果发件人字段使用组语法，则组中不能包含多个邮箱。在任何一种情况下，都可能包含一个可选的回复字段，其中包含字段名“回复”和一个或多个地址的逗号分隔列表。
from = "From:" (mailbox-list / address-list) CRLF
from = "From:" (mailbox-list / address-list) CRLF
sender = "Sender:" (mailbox / address) CRLF
sender = "Sender:" (mailbox / address) CRLF
reply-to = "Reply-To:" address-list CRLF
回复至=“回复至：”地址列表CRLF
The originator fields indicate the mailbox(es) of the source of the message. The "From:" field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message. For example, if a secretary were to send a message for
“原始发件人”字段表示邮件源的邮箱。“发件人：”字段指定邮件的作者，即负责撰写邮件的人员或系统的邮箱。“发件人：”字段指定负责实际传输邮件的代理的邮箱。例如，如果一位秘书要给他发一条信息
another person, the mailbox of the secretary would appear in the "Sender:" field and the mailbox of the actual author would appear in the "From:" field. If the originator of the message can be indicated by a single mailbox and the author and transmitter are identical, the "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD appear.
另一个人，秘书的邮箱将出现在“发件人：”字段中，实际作者的邮箱将出现在“发件人：”字段中。如果消息的发起者可以由单个邮箱表示，并且作者和发送者相同，则不应使用“发件人：”字段。否则，两个字段都应显示。
Note: The transmitter information is always present. The absence of the "Sender:" field is sometimes mistakenly taken to mean that the agent responsible for transmission of the message has not been specified. This absence merely means that the transmitter is identical to the author and is therefore not redundantly placed into the "Sender:" field.
注：变送器信息始终存在。缺少“Sender:”字段有时会被误认为意味着没有指定负责传输消息的代理。这种缺失仅仅意味着发送者与作者相同，因此不会冗余地放入“发送者：”字段。
The originator fields also provide the information required when replying to a message. When the "Reply-To:" field is present, it indicates the address(es) to which the author of the message suggests that replies be sent. In the absence of the "Reply-To:" field, replies SHOULD by default be sent to the mailbox(es) specified in the "From:" field unless otherwise specified by the person composing the reply.
“发件人”字段还提供回复邮件时所需的信息。当“回复：”字段存在时，它表示邮件作者建议向其发送回复的地址。如果没有“回复至：”字段，则默认情况下，回复应发送至“发件人：”字段中指定的邮箱，除非撰写回复的人员另有指定。
In all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message. See also Section 3.6.3 of RFC 5322 [RFC5322] for more information on forming the destination addresses for a reply.
在所有情况下，“发件人：”字段不应包含任何不属于邮件作者的邮箱。另请参见RFC 5322[RFC5322]第3.6.3节，了解有关形成回复目的地地址的更多信息。
This section updates RFC 5322, Section 3.6.6, to allow groups (via the address-list ABNF production) in the "Resent-From:" and "Resent-Sender:" fields, to parallel the change to "From:" and "Sender:" above. The ABNF for these fields is changed as follows:
本节更新RFC 5322第3.6.6节，以允许“重新发送发件人：”和“重新发送发件人：”字段中的组（通过地址列表ABNF production）同时更改为上面的“发件人：”和“发件人”。这些字段的ABNF更改如下：
resent-from = "Resent-From:" (mailbox-list / address-list) CRLF
resent-from = "Resent-From:" (mailbox-list / address-list) CRLF
resent-sender = "Resent-Sender:" (mailbox / address) CRLF
resent-sender = "Resent-Sender:" (mailbox / address) CRLF
Mailbox syntax is the normal syntax to use in the "From:" and "Sender:" header fields; the address syntax defined in Section 2.1, which allows the specification of a group, is only for Limited Use (see RFC 2026 [RFC2026], Section 3.3, item (d)) for the reasons described below.
邮箱语法是在“发件人：”和“发件人：”标题字段中使用的常规语法；第2.1节中定义的地址语法（允许对组进行规范）仅用于有限用途（见RFC 2026[RFC2026]，第3.3节，第（d）项），原因如下所述。
Many Internet email procedures and much software assumes that the addresses in the "From:" and "Sender:" fields can be replied to and are suitable for use in organizing and filtering mail. The use of groups instead of mailboxes can disrupt these uses. Consequently, while this specification legitimizes the use of groups, it does so only to enable circumstances when that use is necessary. Because the use of this mechanism is new, it is important that its use be limited to these circumstances and that it be used with caution. In particular, user agents SHOULD NOT permit the use of groups in those fields in outgoing messages.
许多Internet电子邮件程序和许多软件都假设“发件人：”和“发件人：”字段中的地址可以回复，并且适合用于组织和过滤邮件。使用组而不是邮箱可能会中断这些使用。因此，虽然本规范使组的使用合法化，但它这样做只是为了在需要使用组的情况下启用组。由于这一机制的使用是新的，重要的是，它的使用应限于这些情况，并应谨慎使用。特别是，用户代理不应允许在传出消息中使用这些字段中的组。
First, consider an email message that is sent by an automated nightly monitor program, to which replies should not be sent. Such messages commonly include a valid, replyable address that will discard any replies that are sent to it, but recipients who do reply might be unaware that their replies will be discarded. If the message is instead presented as follows, the recipients' email clients will not allow them to reply in the first place:
首先，考虑一个自动夜间监听程序发送的电子邮件，不应发送回复。这类邮件通常包含一个有效的、可回复的地址，该地址将丢弃发送给它的任何回复，但进行回复的收件人可能不知道他们的回复将被丢弃。如果改为按以下方式显示邮件，收件人的电子邮件客户端首先将不允许他们回复：
From: Nightly Monitor Robot:;
From: Nightly Monitor Robot:;
Second, consider an email message that is meant to be "from" the two managing partners of a business, Ben and Carol, and that is sent by their assistant, Dave. This message could always have been presented this way:
第二，考虑一个电子邮件消息，这意味着“来自”两个管理伙伴的业务，本和卡罗尔，这是由他们的助手，戴夫发送。这条信息可以始终以这种方式呈现：
From: ben@example.com,carol@example.com
Sender: dave@example.com
From: ben@example.com,carol@example.com
Sender: dave@example.com
This change allows it to be represented this way:
此更改允许以以下方式表示：
From: Managing Partners:ben@example.com,carol@example.com;
Sender: dave@example.com
From: Managing Partners:ben@example.com,carol@example.com;
Sender: dave@example.com
See the Internet Message Format specification [RFC5322] for general discussion of security considerations related to the formatting of email messages.
有关电子邮件格式相关安全注意事项的一般性讨论，请参阅Internet消息格式规范[RFC5322]。
The "From:" address is special, in that most user agents display this address, or the "friendly" text associated with it, to the end user, and label it so as to identify it as the origin of the message (as implied in Section 3.6.2 of RFC 5322). Group syntax in the "From:" header field can be used to hide the identity of the message originator. It is just as easy to use a fabricated "From:" address to accomplish the same thing, so allowing groups in this field does not exacerbate the security problem.
“发件人：”地址是特殊的，因为大多数用户代理向最终用户显示此地址或与其相关的“友好”文本，并对其进行标记，以便将其标识为消息的来源（如RFC 5322第3.6.2节所示）。“发件人：”标题字段中的组语法可用于隐藏消息发起人的身份。使用伪造的“发件人：”地址来完成同样的事情也同样容易，因此允许该领域的组不会加剧安全问题。
Some protocols attempt to validate the originator address by matching the "From:" address to a particular verified domain (for one such protocol, see the Author Domain Signing Practices (ADSP) document [RFC5617]). Such protocols will not be applicable to messages that lack an actual email address (whether real or fake) in the "From:" field. Local policy will determine how such messages are handled, and senders, therefore, need to be aware that using groups in the "From:" might adversely affect deliverability of the message.
一些协议试图通过将“发件人：”地址与特定验证域相匹配来验证发起者地址（对于其中一个协议，请参阅作者域签名实践（ADSP）文档[RFC5617]）。此类协议不适用于在“发件人：”字段中缺少实际电子邮件地址（无论是真是假）的邮件。本地策略将决定如何处理此类邮件，因此，发件人需要注意，在“发件人：”中使用组可能会对邮件的可交付性产生不利影响。
Because groups have previously not been allowed in the "From:" and "Sender:" header fields, it is possible that some implementations that conform to RFC 5322 might not be prepared to handle the group syntax, and, indeed, might not even recognize that group syntax is being used. Of those implementations, some subset might, when presented with group syntax in those header fields, behave in a way that is exploitable by an attacker. It is deemed unlikely that this will be a serious problem in practice: address field parsing is generally an integral component of implementations, and address field parsers are required to understand group syntax. In addition, if any implementations should be exploitable through this mechanism, it is already possible for attackers to do it by violating RFC 5322. Other violations of RFC 5322 are commonly used by malefactors.
由于以前在“发件人：”和“发件人：”标题字段中不允许使用组，因此一些符合RFC 5322的实现可能不准备处理组语法，甚至可能无法识别正在使用的组语法。在这些实现中，当在这些头字段中显示组语法时，某些子集的行为可能会被攻击者利用。在实践中，这不太可能是一个严重的问题：地址字段解析通常是实现的一个组成部分，需要地址字段解析器来理解组语法。此外，如果任何实现都可以通过此机制加以利用，那么攻击者就有可能通过违反RFC 5322进行攻击。其他违反RFC 5322的行为通常由犯罪分子使用。
IANA has updated the "Permanent Message Header Field Names" registry to include this document as a reference as follows:
IANA已更新“永久邮件标题字段名称”注册表，将本文件作为参考，如下所示：
OLD
+----------------+--------+------------+--------------------------+
| From | mail | standard | [RFC5322] |
+----------------+--------+------------+--------------------------+
OLD
+----------------+--------+------------+--------------------------+
| From | mail | standard | [RFC5322] |
+----------------+--------+------------+--------------------------+
+----------------+--------+------------+--------------------------+
| Sender | mail | standard | [RFC5322] |
+----------------+--------+------------+--------------------------+
+----------------+--------+------------+--------------------------+
| Sender | mail | standard | [RFC5322] |
+----------------+--------+------------+--------------------------+
+----------------+--------+------------+--------------------------+
| Resent-From | mail | standard | [RFC5322] |
+----------------+--------+------------+--------------------------+
+----------------+--------+------------+--------------------------+
| Resent-From | mail | standard | [RFC5322] |
+----------------+--------+------------+--------------------------+
+----------------+--------+------------+--------------------------+
| Resent-Sender | mail | standard | [RFC5322] |
+----------------+--------+------------+--------------------------+
+----------------+--------+------------+--------------------------+
| Resent-Sender | mail | standard | [RFC5322] |
+----------------+--------+------------+--------------------------+
NEW
+----------------+--------+------------+--------------------------+
| From | mail | standard | [RFC5322] [RFC6854] |
+----------------+--------+------------+--------------------------+
NEW
+----------------+--------+------------+--------------------------+
| From | mail | standard | [RFC5322] [RFC6854] |
+----------------+--------+------------+--------------------------+
+----------------+--------+------------+--------------------------+
| Sender | mail | standard | [RFC5322] [RFC6854] |
+----------------+--------+------------+--------------------------+
+----------------+--------+------------+--------------------------+
| Sender | mail | standard | [RFC5322] [RFC6854] |
+----------------+--------+------------+--------------------------+
+----------------+--------+------------+--------------------------+
| Resent-From | mail | standard | [RFC5322] [RFC6854] |
+----------------+--------+------------+--------------------------+
+----------------+--------+------------+--------------------------+
| Resent-From | mail | standard | [RFC5322] [RFC6854] |
+----------------+--------+------------+--------------------------+
+----------------+--------+------------+--------------------------+
| Resent-Sender | mail | standard | [RFC5322] [RFC6854] |
+----------------+--------+------------+--------------------------+
+----------------+--------+------------+--------------------------+
| Resent-Sender | mail | standard | [RFC5322] [RFC6854] |
+----------------+--------+------------+--------------------------+
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[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月。
[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月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[RFC0822]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009.
[RFC5617]Allman，E.，Fenton，J.，Delany，M.，和J.Levine，“域密钥识别邮件（DKIM）作者域签名实践（ADSP）”，RFC 56172009年8月。
[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012.
[RFC6530]Klensin，J.和Y.Ko，“国际化电子邮件的概述和框架”，RFC6530，2012年2月。
Author's Address
作者地址
Barry Leiba Huawei Technologies
巴里·雷巴华为技术有限公司
Phone: +1 646 827 0648
EMail: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/
Phone: +1 646 827 0648
EMail: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/