Network Working Group J. Lyon
Request for Comments: 4407 Microsoft Corp.
Category: Experimental April 2006
Network Working Group J. Lyon
Request for Comments: 4407 Microsoft Corp.
Category: Experimental April 2006
Purported Responsible Address in E-Mail Messages
电子邮件中声称的责任地址
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) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
IESG Note
IESG注释
The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) are published simultaneously as Experimental RFCs, although there is no general technical consensus and efforts to reconcile the two approaches have failed. As such, these documents have not received full IETF review and are published "AS-IS" to document the different approaches as they were considered in the MARID working group.
以下文件（RFC 4405、RFC 4406、RFC 4407和RFC 4408）作为实验性RFC同时发布，尽管没有普遍的技术共识，协调这两种方法的努力也失败了。因此，这些文件没有得到IETF的全面审查，而是按“原样”发布，以记录MARID工作组中考虑的不同方法。
The IESG takes no position about which approach is to be preferred and cautions the reader that there are serious open issues for each approach and concerns about using them in tandem. The IESG believes that documenting the different approaches does less harm than not documenting them.
IESG对首选哪种方法不持任何立场，并提醒读者，每种方法都存在严重的开放性问题，并关注如何同时使用它们。IESG认为，记录不同的方法比不记录它们危害更小。
Note that the Sender ID experiment may use DNS records that may have been created for the current SPF experiment or earlier versions in this set of experiments. Depending on the content of the record, this may mean that Sender-ID heuristics would be applied incorrectly to a message. Depending on the actions associated by the recipient with those heuristics, the message may not be delivered or may be discarded on receipt.
请注意，发送方ID实验可能使用为当前SPF实验或这组实验中的早期版本创建的DNS记录。根据记录的内容，这可能意味着发件人ID试探法将错误地应用于消息。根据接收者与这些试探法相关联的操作，消息可能不会被传递，也可能在接收时被丢弃。
Participants relying on Sender ID experiment DNS records are warned that they may lose valid messages in this set of circumstances. Participants publishing SPF experiment DNS records should consider the advice given in section 3.4 of RFC 4406 and may wish to publish both v=spf1 and spf2.0 records to avoid the conflict.
依赖发送方ID实验DNS记录的参与者将收到警告，在这种情况下，他们可能会丢失有效消息。参加者发布SPF实验DNS记录应考虑RFC 4406第3.4节中给出的建议，并希望同时发布V= SPF1和SPF2.0记录以避免冲突。
Participants in the Sender-ID experiment need to be aware that the way Resent-* header fields are used will result in failure to receive legitimate email when interacting with standards-compliant systems (specifically automatic forwarders which comply with the standards by not adding Resent-* headers, and systems which comply with RFC 822 but have not yet implemented RFC 2822 Resent-* semantics). It would be inappropriate to advance Sender-ID on the standards track without resolving this interoperability problem.
发送者ID实验的参与者需要意识到，当与符合标准的系统交互时，使用Resent-*头字段的方式将导致无法接收合法电子邮件（特别是通过不添加RENT-*头来符合标准的自动转发器，以及符合RFC 822但尚未实现RFC 2822 RENT-*语义的系统）。在不解决此互操作性问题的情况下，在标准轨道上提前发送ID是不合适的。
The community is invited to observe the success or failure of the two approaches during the two years following publication, in order that a community consensus can be reached in the future.
请社区在出版后的两年内观察这两种方法的成功或失败，以便将来能够达成社区共识。
Abstract
摘要
This document defines an algorithm by which, given an e-mail message, one can extract the identity of the party that appears to have most proximately caused that message to be delivered. This identity is called the Purported Responsible Address (PRA).
本文档定义了一种算法，通过该算法，在给定电子邮件消息的情况下，可以提取似乎最接近导致该消息传递的一方的身份。这种身份称为所谓的责任地址（PRA）。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Determining the Purported Responsible Address ...................3
3. Security Considerations .........................................5
4. Acknowledgements ................................................5
5. References ......................................................5
5.1. Normative References .......................................5
5.2. Informative References .....................................5
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Determining the Purported Responsible Address ...................3
3. Security Considerations .........................................5
4. Acknowledgements ................................................5
5. References ......................................................5
5.1. Normative References .......................................5
5.2. Informative References .....................................5
Most e-mail flows relatively directly from a sender to a recipient, with a small number of Mail Transfer Agents (MTAs) in between. Some messages, however, are resent by forwarding agents, mailing list servers, and other such software. These messages effectively result in two or more mail transactions: one from the sender to the forwarding agent, and another from the agent to the destination.
大多数电子邮件相对直接地从发件人发送到收件人，其间有少量邮件传输代理（MTA）。但是，有些邮件会被转发代理、邮件列表服务器和其他此类软件重新发送。这些消息有效地导致两个或多个邮件事务：一个从发件人到转发代理，另一个从代理到目的地。
In some cases, messages travel through more than one of these agents. This can occur, for example, when one mailing list is subscribed to another, or when the address subscribed to a mailing list is a forwarding service.
在某些情况下，消息通过这些代理中的一个以上进行传播。例如，当一个邮件列表订阅另一个邮件列表时，或者当订阅邮件列表的地址是转发服务时，可能会发生这种情况。
Further complicating the situation, in some cases the party that introduces a message is not the author of the message. For example, many news web sites have a "Mail this article" function that the
使情况进一步复杂化的是，在某些情况下，介绍电文的一方不是电文的作者。例如，许多新闻网站都具有“发送本文”功能
public can use to e-mail a copy of the article to a friend. In this case, the mail is "from" the person who pressed the button, but is physically sent by the operator of the web site.
公众可以使用电子邮件将文章副本发送给朋友。在这种情况下，邮件“来自”按下按钮的人，但由网站操作员实际发送。
This document defines a new identity associated with an e-mail message, called the Purported Responsible Address (PRA), which is determined by inspecting the header of the message. The PRA is designed to be the entity that (according to the header) most recently caused the message to be delivered.
本文档定义了一个与电子邮件相关联的新标识，称为所谓的责任地址（PRA），它是通过检查邮件的标题来确定的。PRA被设计为（根据标头）最近导致消息传递的实体。
Note that the results of this algorithm are only as truthful as the headers contained in the message; if a message contains fraudulent or incorrect headers, this algorithm will yield an incorrect result. For this reason, the result of the algorithm is called the "Purported Responsible Address" -- "purported" because it tells you what a message claims about where it came from, but not necessarily where it actually came from.
请注意，此算法的结果仅与消息中包含的标题一样真实；如果消息包含欺诈或不正确的头，此算法将产生不正确的结果。由于这个原因，算法的结果被称为“声称的负责地址”--“声称的”，因为它告诉你一条消息声称它来自哪里，但不一定是它实际来自哪里。
This document does not prescribe any particular uses for the Purported Responsible Address. However, [RFC4406] describes a method of determining whether a particular MTA is authorized to send mail on behalf of the domain contained in the PRA.
本文件未规定声称的责任地址的任何特定用途。但是，[RFC4406]描述了一种确定特定MTA是否有权代表PRA中包含的域发送邮件的方法。
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]中所述进行解释。
The PRA of a message is determined by the following algorithm:
消息的PRA由以下算法确定：
1. Select the first non-empty Resent-Sender header in the message. If no such header is found, continue with step 2. If it is preceded by a non-empty Resent-From header and one or more Received or Return-Path headers occur after said Resent-From header and before the Resent-Sender header, continue with step 2. Otherwise, proceed to step 5.
1. 选择邮件中第一个非空的重新发送发件人标头。如果未找到此类标头，请继续执行步骤2。如果前面有一个非空的“重新发送自”标头，并且在所述“重新发送自”标头之后和“重新发送发件人”标头之前出现一个或多个“接收或返回路径”标头，请继续执行步骤2。否则，转至步骤5。
2. Select the first non-empty Resent-From header in the message. If a Resent-From header is found, proceed to step 5. Otherwise, continue with step 3.
2. 选择消息中的第一个非空“重新发送自”标题。如果找到“重新发送自”标题，请转至步骤5。否则，继续执行步骤3。
3. Select all the non-empty Sender headers in the message. If there are no such headers, continue with step 4. If there is exactly one such header, proceed to step 5. If there is more than one such header, proceed to step 6.
3. 选择邮件中的所有非空发件人标题。如果没有此类标头，请继续执行步骤4。如果只有一个这样的标题，则转至步骤5。如果存在多个这样的标题，则转至步骤6。
4. Select all the non-empty From headers in the message. If there is exactly one such header, continue with step 5. Otherwise, proceed to step 6.
4. 选择邮件中的所有非空发件人标题。如果只有一个这样的标题，请继续执行步骤5。否则，继续执行步骤6。
5. A previous step has selected a single header from the message. If that header is malformed (e.g., it appears to contain multiple mailboxes, or the single mailbox is hopelessly malformed, or the single mailbox does not contain a domain name), continue with step 6. Otherwise, return that single mailbox as the Purported Responsible Address.
5. 上一步从消息中选择了一个标题。如果该标头的格式不正确（例如，它似乎包含多个邮箱，或者单个邮箱的格式严重错误，或者单个邮箱不包含域名），请继续执行步骤6。否则，将该邮箱作为声称的负责地址返回。
6. The message is ill-formed, and it is impossible to determine a Purported Responsible Address.
6. 消息格式不正确，无法确定声称的负责地址。
For the purposes of this algorithm, a header field is "non-empty" if and only if it contains any non-whitespace characters. Header fields that are otherwise relevant but contain only whitespace are ignored and treated as if they were not present.
在该算法中，当且仅当标题字段包含任何非空白字符时，标题字段才为“非空”。其他相关但仅包含空白的标题字段将被忽略，并被视为不存在。
Note that steps 1 and 2 above extract the Resent-Sender or Resent-From header from the first resent block (as defined by section 3.6.6 of [RFC2822]) if any. Steps 3 and 4 above extract the Sender or From header if there are no resent blocks.
请注意，上述步骤1和2从第一个RENT块（如[RFC2822]第3.6.6节所定义）中提取RENT发送方或RENT From报头（如有）。上面的步骤3和4提取发送方或从标头（如果没有重新发送的块）。
Note that what constitutes a hopelessly malformed header or a hopelessly malformed mailbox in step 5 above is a matter for local policy. Such local policy will never cause two implementations to return different PRAs. However, it may cause one implementation to return a PRA where another implementation does not. This will occur only when dealing with a message containing headers of questionable legality.
请注意，在上面的步骤5中，构成格式错误的标题或格式错误的邮箱的内容由本地策略决定。这种本地策略永远不会导致两个实现返回不同的PRA。但是，它可能会导致一个实现返回PRA，而另一个实现不返回PRA。只有在处理包含合法性有问题的头的消息时，才会发生这种情况。
Although the algorithm specifies how messages that are not in strict conformance with the provisions of RFC 2822 should be treated for the purposes of determining the PRA, this should not be taken as requiring or recommending that any systems accept such messages when they otherwise would not have done so. However, if a liberal implementation accepts such messages and desires to know their PRAs, it MUST use the algorithm specified here.
虽然算法规定了如何处理不严格符合RFC 2822规定的消息，以确定PRA，但这不应视为要求或建议任何系统接受此类消息，否则它们不会接受此类消息。然而，如果一个自由的实现接受这样的消息并希望知道它们的PRA，它必须使用这里指定的算法。
Where messages conform to RFC 822 rather than RFC 2822, it is possible for the algorithm to give unexpected results. An RFC822 message should not normally contain more than one set of resent headers; however, the placement of those headers is not specified, nor are they required to be contiguous. It is therefore possible that the Resent-From header will be selected even though a Resent-Sender header is present. Such cases are expected to be rare or non-existent in practice.
如果消息符合RFC 822而不是RFC 2822，则算法可能会给出意外的结果。RFC822消息通常不应包含一组以上的重新发送头；但是，没有指定这些头的位置，也不要求它们是连续的。因此，即使存在“重新发送发件人”标头，也可能会选择“重新发送发件人”标头。预计这种情况在实践中很少或根本不存在。
The PRA, as described by this document, is extracted from message headers that have historically not been verified. Thus, anyone using the PRA for any purpose MUST be aware that the headers from which it is derived might be fraudulent, malicious, malformed, and/or incorrect. [RFC4406] describes one mechanism for validating the PRA.
如本文档所述，PRA是从历史上未经验证的消息头中提取的。因此，任何出于任何目的使用PRA的人都必须知道，从中派生PRA的头可能是欺诈性的、恶意的、格式错误的和/或不正确的。[RFC4406]描述了一种验证PRA的机制。
A message's PRA will often be extracted from a header field that is not normally displayed by existing mail user agent software. If the PRA is used as part of a mechanism to authenticate the message's origin, the message SHOULD NOT be displayed with an indication of its authenticity (positive or negative) without the PRA header field also being displayed.
邮件的PRA通常从现有邮件用户代理软件通常不显示的标题字段中提取。如果PRA用作验证消息来源的机制的一部分，则在未显示PRA标题字段的情况下，消息不应显示其真实性（正或负）。
The PRA concept was first published in [CallerID]. It has been refined using valuable suggestions from members of the MARID working group.
审慎监管局的概念首次发表于[CallerID]。利用MARID工作组成员的宝贵建议对其进行了改进。
[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月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[CallerID] Microsoft Corporation, Caller ID for E-Mail Technical
Specification,
http://www.microsoft.com/mscorp/safety/technologies/
senderid/resources.mspx
[CallerID] Microsoft Corporation, Caller ID for E-Mail Technical
Specification,
http://www.microsoft.com/mscorp/safety/technologies/
senderid/resources.mspx
[RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, April 2006.
[RFC4406]Lyon，J.和M.Wong，“发件人ID：验证电子邮件”，RFC 4406，2006年4月。
Author's Address
作者地址
Jim Lyon Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
Jim Lyon微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: jimlyon@microsoft.com
EMail: jimlyon@microsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。