Network Working Group M. Kucherawy
Request for Comments: 5451 Sendmail, Inc.
Category: Standards Track April 2009
Network Working Group M. Kucherawy
Request for Comments: 5451 Sendmail, Inc.
Category: Standards Track April 2009
Message Header Field for Indicating Message Authentication Status
用于指示消息身份验证状态的消息头字段
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
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
摘要
This memo defines a new header field for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), may use this message header field to relay that information in a convenient way to users or to make sorting and filtering decisions.
此备忘录定义了用于电子邮件的新标题字段，以指示邮件身份验证工作的结果。任何接收方软件，如邮件过滤器或邮件用户代理（MUA），都可以使用此消息头字段以方便的方式将该信息转发给用户，或作出排序和过滤决定。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Trust Boundary . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Processing Scope . . . . . . . . . . . . . . . . . . . . . 5
1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.2. Security . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.3. Email Architecture . . . . . . . . . . . . . . . . . . 6
1.6. Trust Environment . . . . . . . . . . . . . . . . . . . . 7
2. Definition and Format of the Header Field . . . . . . . . . . 8
2.1. General Description . . . . . . . . . . . . . . . . . . . 8
2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 8
2.3. Authentication Identifier Field . . . . . . . . . . . . . 10
2.4. Result Values . . . . . . . . . . . . . . . . . . . . . . 12
2.4.1. DKIM and DomainKeys Results . . . . . . . . . . . . . 12
2.4.2. SPF and Sender-ID Results . . . . . . . . . . . . . . 13
2.4.3. "iprev" Results . . . . . . . . . . . . . . . . . . . 14
2.4.4. SMTP AUTH Results . . . . . . . . . . . . . . . . . . 14
2.4.5. Extension Result Codes . . . . . . . . . . . . . . . . 15
2.5. Authentication Methods . . . . . . . . . . . . . . . . . . 15
2.5.1. Definition of Initial Methods . . . . . . . . . . . . 16
2.5.2. Extension Methods . . . . . . . . . . . . . . . . . . 16
3. The "iprev" Authentication Method . . . . . . . . . . . . . . 17
4. Adding the Header Field to A Message . . . . . . . . . . . . . 18
4.1. Header Field Position and Interpretation . . . . . . . . . 19
4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 20
5. Removing the Header Field . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6.1. The Authentication-Results Header Field . . . . . . . . . 22
6.2. Email Authentication Method Name Registry . . . . . . . . 22
6.3. Email Authentication Result Name Registry . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 26
7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 27
7.3. Header Field Position . . . . . . . . . . . . . . . . . . 28
7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 28
7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 28
7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 28
7.7. Attacks against Authentication Methods . . . . . . . . . . 28
7.8. Intentionally Malformed Header Fields . . . . . . . . . . 29
7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 29
7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 29
7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Trust Boundary . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Processing Scope . . . . . . . . . . . . . . . . . . . . . 5
1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.2. Security . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.3. Email Architecture . . . . . . . . . . . . . . . . . . 6
1.6. Trust Environment . . . . . . . . . . . . . . . . . . . . 7
2. Definition and Format of the Header Field . . . . . . . . . . 8
2.1. General Description . . . . . . . . . . . . . . . . . . . 8
2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 8
2.3. Authentication Identifier Field . . . . . . . . . . . . . 10
2.4. Result Values . . . . . . . . . . . . . . . . . . . . . . 12
2.4.1. DKIM and DomainKeys Results . . . . . . . . . . . . . 12
2.4.2. SPF and Sender-ID Results . . . . . . . . . . . . . . 13
2.4.3. "iprev" Results . . . . . . . . . . . . . . . . . . . 14
2.4.4. SMTP AUTH Results . . . . . . . . . . . . . . . . . . 14
2.4.5. Extension Result Codes . . . . . . . . . . . . . . . . 15
2.5. Authentication Methods . . . . . . . . . . . . . . . . . . 15
2.5.1. Definition of Initial Methods . . . . . . . . . . . . 16
2.5.2. Extension Methods . . . . . . . . . . . . . . . . . . 16
3. The "iprev" Authentication Method . . . . . . . . . . . . . . 17
4. Adding the Header Field to A Message . . . . . . . . . . . . . 18
4.1. Header Field Position and Interpretation . . . . . . . . . 19
4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 20
5. Removing the Header Field . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6.1. The Authentication-Results Header Field . . . . . . . . . 22
6.2. Email Authentication Method Name Registry . . . . . . . . 22
6.3. Email Authentication Result Name Registry . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 26
7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 27
7.3. Header Field Position . . . . . . . . . . . . . . . . . . 28
7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 28
7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 28
7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 28
7.7. Attacks against Authentication Methods . . . . . . . . . . 28
7.8. Intentionally Malformed Header Fields . . . . . . . . . . 29
7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 29
7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 29
7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.1. Normative References . . . . . . . . . . . . . . . . . . . 30
8.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 32
Appendix B. Authentication-Results Examples . . . . . . . . . . . 33
B.1. Trivial Case; Header Field Not Present . . . . . . . . . . 33
B.2. Nearly Trivial Case; Service Provided, But No
Authentication Done . . . . . . . . . . . . . . . . . . . 34
B.3. Service Provided, Authentication Done . . . . . . . . . . 35
B.4. Service Provided, Several Authentications Done, Single
MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
B.5. Service Provided, Several Authentications Done,
Different MTAs . . . . . . . . . . . . . . . . . . . . . . 37
B.6. Service Provided, Multi-Tiered Authentication Done . . . . 39
Appendix C. Operational Considerations about Message
Authentication . . . . . . . . . . . . . . . . . . . 41
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 43
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.1. Normative References . . . . . . . . . . . . . . . . . . . 30
8.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 32
Appendix B. Authentication-Results Examples . . . . . . . . . . . 33
B.1. Trivial Case; Header Field Not Present . . . . . . . . . . 33
B.2. Nearly Trivial Case; Service Provided, But No
Authentication Done . . . . . . . . . . . . . . . . . . . 34
B.3. Service Provided, Authentication Done . . . . . . . . . . 35
B.4. Service Provided, Several Authentications Done, Single
MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
B.5. Service Provided, Several Authentications Done,
Different MTAs . . . . . . . . . . . . . . . . . . . . . . 37
B.6. Service Provided, Multi-Tiered Authentication Done . . . . 39
Appendix C. Operational Considerations about Message
Authentication . . . . . . . . . . . . . . . . . . . 41
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 43
This memo defines a new header field for electronic mail messages that presents the results of a message authentication effort in a machine-readable format. The intent is to create a place to collect such data when message authentication mechanisms are in use so that a Mail User Agent (MUA) and downstream filters can make filtering decisions and/or provide a recommendation to the user as to the validity of the message's origin and possibly the integrity of its content.
此备忘录为电子邮件定义了一个新的标题字段，该字段以机器可读的格式显示邮件身份验证工作的结果。目的是在使用消息认证机制时创建一个收集此类数据的场所，以便邮件用户代理（MUA）和下游过滤器能够做出过滤决策和/或向用户提供关于消息来源的有效性及其内容的完整性的建议。
End users are not expected to be direct consumers of this header field. This header field is intended for consumption by programs that will then use or render such data in a human-usable form.
最终用户不应是此标题字段的直接使用者。此标头字段供程序使用，这些程序随后将以人类可用的形式使用或呈现此类数据。
This memo defines both the format of this new header field and discusses the implications of its presence or absence. However, it does not discuss how the data contained in the header field should be used (i.e. what filtering decisions are appropriate, or how an MUA might render these results) as these are local policy and/or user interface design questions that are not appropriate for this memo.
此备忘录定义了此新标题字段的格式，并讨论了其存在或不存在的含义。但是，它没有讨论应如何使用标题字段中包含的数据（即，哪些过滤决策是适当的，或者MUA如何呈现这些结果），因为这些是本地政策和/或用户界面设计问题，不适用于本备忘录。
At the time of publication of this memo, [AUTH], [DKIM], [DOMAINKEYS], [SENDERID], and [SPF] are published DNS domain-level email authentication methods in common use. This proposal is not intended to be restricted to domain-based authentication, but this has proven to be a good starting point for implementations. As various methods emerge, it is necessary to prepare for their appearance and encourage convergence in the area of interfacing verifiers to filters and MUAs.
在本备忘录发布时，[AUTH]、[DKIM]、[DOMAINKEYS]、[SENDERID]和[SPF]是已发布的常用DNS域级电子邮件身份验证方法。这项建议并不打算局限于基于域的身份验证，但这已被证明是实现的良好起点。随着各种方法的出现，有必要为它们的出现做好准备，并鼓励在将验证器与过滤器和MUA连接的领域中进行收敛。
Although [SPF] defined a header field called Received-SPF and [DOMAINKEYS] defined one called DomainKey-Status for this purpose, those header fields are specific to the conveyance of their respective results only and thus are insufficient to satisfy the requirements enumerated below.
尽管[SPF]为此定义了一个称为Received SPF的头字段，[DOMAINKEYS]定义了一个称为DomainKey Status的头字段，但这些头字段仅用于传输各自的结果，因此不足以满足下面列举的要求。
The header field defined in this memo is expected to serve several purposes:
本备忘录中定义的标题字段预期有多种用途：
1. Convey the results of various message authentication checks being applied by upstream filters and Mail Transfer Agents (MTAs) to MUAs and downstream filters within the same "trust domain", as such agents may wish to render those results to end users or use that data to apply more or less stringent content checks based on authentication results;
1. 将上游筛选器和邮件传输代理（MTA）应用的各种邮件身份验证检查的结果传达给同一“信任域”内的MUA和下游筛选器，因为这些代理可能希望将这些结果呈现给最终用户，或使用该数据根据身份验证结果应用更严格或更不严格的内容检查；
2. Provide a common location within a message for this data;
2. 在消息中为此数据提供公共位置；
3. Create an extensible framework for reporting new authentication methods as they emerge.
3. 创建一个可扩展的框架，以便在新的身份验证方法出现时报告它们。
In particular, the mere presence of this header field should not be construed as meaning that its data is valid, but rather that it is asserting validity based on one or more authentication schemes somewhere upstream. For an MUA or downstream filter to treat the assertions as actually valid, there must be an assessment of the trust relationship between such agents and the validating MTA.
特别是，仅此报头字段的存在不应解释为意味着其数据有效，而应解释为它基于上游某处的一个或多个认证方案断言有效性。要使MUA或下游筛选器将断言视为实际有效，必须评估此类代理和验证MTA之间的信任关系。
This document makes several references to the "trust boundary" of an administrative management domain (ADMD). Given the diversity among existing mail environments, a precise definition of this term isn't possible.
本文档多次提及管理管理域（ADMD）的“信任边界”。考虑到现有邮件环境的多样性，不可能精确定义此术语。
Simply put, a transfer from the creator of the header field to the consumer must occur within a context of trust that the creator's information is correct. How this trust is obtained is outside the scope of this document. It is entirely a local matter.
简单地说，从标题字段的创建者到使用者的传输必须在信任创建者信息正确的上下文中进行。如何获得该信托不在本文件范围内。这完全是当地的事情。
Thus, this document defines a "trust boundary" as the delineation between "external" and "internal" entities; "external" here includes all hosts that do not deliberately provide some kind of messaging service for the receiving ADMD's users, and "internal" includes those hosts that do. By this definition, the hosts within a "trust boundary" may lie entirely within a receiving ADMD's direct control,
因此，本文件将“信托边界”定义为“外部”和“内部”实体之间的划分；此处的“外部”包括所有未特意为接收ADMD的用户提供某种消息服务的主机，“内部”包括提供此类服务的主机。根据此定义，“信任边界”内的主机可能完全位于接收ADMD的直接控制范围内，
or they can include hosts managed by another ADMD (such as an ISP or commercial filtering service) but that also provide services for the former.
或者，它们可以包括由另一个ADMD（如ISP或商业过滤服务）管理但也为前者提供服务的主机。
This proposal is intended to address the needs of authenticating messages or properties of messages during their actual transport. It is not meant to address the security of messages that might be encapsulated within other messages, such as a message/rfc822 [MIME] part within a message.
本建议旨在解决在实际传输过程中验证消息或消息属性的需要。它不是为了解决可能封装在其他消息中的消息的安全性，例如消息中的message/rfc822[MIME]部分。
This memo establishes no new requirements on existing protocols or servers.
本备忘录未对现有协议或服务器提出新要求。
In particular, this memo establishes no requirement on MTAs to reject or filter arriving messages that do not pass authentication checks. The data conveyed by the defined header field's contents are for the information of MUAs and filters and should be used at their discretion.
特别是，本备忘录不要求MTA拒绝或过滤未通过身份验证检查的到达邮件。定义的标题字段内容所传递的数据用于MUA和过滤器的信息，应自行决定使用。
This section defines various terms used throughout this document.
本节定义了本文件中使用的各种术语。
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 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
[SECURITY] discusses authentication and authorization and the conflation of the two concepts. The use of those terms within the context of recent message-security work has given rise to slightly different definitions, and this document reflects those current usages, as follows:
[SECURITY]讨论身份验证和授权以及这两个概念的融合。这些术语在最近的消息安全工作中的使用产生了略微不同的定义，本文档反映了这些当前用法，如下所示：
o "Authorization" is the establishment of permission to use a resource or represent an identity. In this context, authorization indicates that a message from a particular ADMD arrived via a route the ADMD has explicitly approved.
o “授权”是指建立使用资源或表示身份的权限。在此上下文中，授权表示来自特定ADMD的消息通过ADMD明确批准的路由到达。
o "Authentication" is the assertion of validity of a piece of data about a message (such as the sender's identity) or the message in its entirety.
o “身份验证”是关于消息（如发送者的身份）或整个消息的一段数据的有效性的断言。
As examples: [SPF] and [SENDERID] are authorization mechanisms in that they express a result that shows whether or not the ADMD that apparently sent the message has explicitly authorized the connecting [SMTP] client to relay messages on its behalf but do not actually validate any property of the message itself. By contrast, [DKIM] is agnostic as to the routing of a message but uses cryptographic signatures to authenticate agents claiming responsibility for the message (which implies authorization) and ensure it was not modified in transit. Since the signatures are not tied to SMTP connections, they can be added by either the ADMD of origin, intermediate ADMDs (such as a mailing list server), or both.
例如：[SPF]和[SENDERID]是授权机制，因为它们表示的结果表明，显然发送邮件的ADMD是否已明确授权连接[SMTP]客户端代表其中继邮件，但实际上并不验证邮件本身的任何属性。相比之下，[DKIM]对于消息的路由是不可知的，但使用加密签名来验证声称对消息负责的代理（这意味着授权），并确保消息在传输过程中未被修改。由于签名未绑定到SMTP连接，因此可以由源ADMD、中间ADMD（如邮件列表服务器）或两者都添加签名。
Rather than create a separate header field for each class of solution, this proposal groups them both into a single header field.
与为每类解决方案创建单独的标题字段不同，本提案将它们都分组到一个标题字段中。
o A "border MTA" is an MTA that acts as a gateway between the general Internet and the users within an organizational boundary. (See also Section 1.2.)
o “边界MTA”是一种MTA，用作普通Internet和组织边界内用户之间的网关。（另见第1.2节。）
o A "delivery MTA" (or Mail Delivery Agent or MDA) is an MTA that actually enacts delivery of a message to a user's inbox or other final delivery.
o “delivery MTA”（或Mail delivery Agent或MDA）是一种MTA，它实际执行邮件到用户收件箱的传递或其他最终传递。
o An "intermediate MTA" is an MTA that handles messages after a border MTA and before a delivery MTA.
o “中间MTA”是在边界MTA之后和传递MTA之前处理邮件的MTA。
The following diagram illustrates the flow of mail among these defined components:
下图说明了这些已定义组件之间的邮件流：
+-----+ +-----+ +------------+
| MUA |-->| MSA |-->| Border MTA |
+-----+ +-----+ +------------+
|
|
V
+----------+
| Internet |
+----------+
|
|
V
+-----+ +-----+ +------------------+ +------------+
| MUA |<--| MDA |<--| Intermediate MTA |<--| Border MTA |
+-----+ +-----+ +------------------+ +------------+
+-----+ +-----+ +------------+
| MUA |-->| MSA |-->| Border MTA |
+-----+ +-----+ +------------+
|
|
V
+----------+
| Internet |
+----------+
|
|
V
+-----+ +-----+ +------------------+ +------------+
| MUA |<--| MDA |<--| Intermediate MTA |<--| Border MTA |
+-----+ +-----+ +------------------+ +------------+
Generally, it is assumed that the work of applying message authentication schemes takes place at a border MTA or a delivery MTA. This specification is written with that assumption in mind. However, there are some sites at which the entire mail infrastructure consists of a single host. In such cases, such terms as "border MTA" and "delivery MTA" may well apply to the same machine or even the very same agent. It is also possible that some message authentication tests could take place on an intermediate MTA. Although this document doesn't specifically describe such cases, they are not meant to be excluded from this specification.
通常，假定应用邮件身份验证方案的工作发生在边界MTA或传递MTA上。编写本规范时要牢记这一假设。但是，在某些站点上，整个邮件基础结构由一台主机组成。在这种情况下，“边界MTA”和“交付MTA”等术语很可能适用于同一台机器，甚至是同一个代理。某些邮件身份验证测试也可能在中间MTA上进行。尽管本文件未具体描述此类情况，但本规范并不排除此类情况。
See [EMAIL-ARCH] for further discussion on general email system architecture, and Appendix C of this memo for discussion about the common aspects of email authentication in current environments.
有关一般电子邮件系统体系结构的进一步讨论，请参见[EMAIL-ARCH]，有关当前环境中电子邮件身份验证的常见方面的讨论，请参见本备忘录附录C。
This new header field permits one or more message validation mechanisms to communicate its output to one or more separate assessment mechanisms. These mechanisms operate within a unified trust boundary that defines an Administrative Management Domain (ADMD). An ADMD contains one or more entities that perform validation and generate the header field, and one or more that consume it for some type of assessment. The field contains no integrity or validation mechanism of its own, so its presence must be trusted implicitly. Hence, use of the header field depends upon ensuring that mail entering the ADMD has instances of the header field claiming to be valid within its boundaries removed, so that occurrences of such header fields can be used safely by consumers.
这个新的头字段允许一个或多个消息验证机制将其输出传递给一个或多个单独的评估机制。这些机制在定义管理管理域（ADMD）的统一信任边界内运行。ADMD包含一个或多个执行验证和生成标题字段的实体，以及一个或多个为某种类型的评估使用该字段的实体。该字段本身不包含完整性或验证机制，因此必须隐式信任其存在。因此，头字段的使用取决于确保进入ADMD的邮件已删除声称在其边界内有效的头字段实例，以便消费者可以安全地使用此类头字段。
The "authserv-id" token defined in Section 2.2 can be used to label an entire ADMD or a specific validation engine within an ADMD. Although the labeling scheme is left as an operational choice, some guidance for selecting a token is provided within this proposal.
第2.2节中定义的“authserv id”标记可用于标记整个ADMD或ADMD中的特定验证引擎。虽然标签方案是一种操作选择，但本提案中提供了一些选择代币的指导。
This section gives a general overview of the format of the header field being defined, and then provides more formal specification.
本节概述了正在定义的标题字段的格式，然后提供了更正式的规范。
The new header field being defined here is called "Authentication-Results". It is a Structured Header Field as defined in [MAIL] and thus all of the related definitions in that document apply.
此处定义的新标题字段称为“身份验证结果”。它是[MAIL]中定义的结构化标题字段，因此该文档中的所有相关定义均适用。
This new header field SHOULD be added at the top of the message as it transits MTAs that do authentication checks so some idea of how far away the checks were done can be inferred. It therefore should be treated as a Trace Field as defined in [MAIL], and thus all of the related definitions in that document apply.
在传输进行身份验证检查的MTA时，应在邮件顶部添加此新的标头字段，以便推断检查完成的距离。因此，应将其视为[邮件]中定义的跟踪字段，因此该文档中的所有相关定义均适用。
The value of the header field (after removing [MAIL] comments) consists of an authentication identifier, an optional version, and then a series of "method=result" statements indicating which authentication method(s) were applied and their respective results, and then, for each applied method, an optional "reason" string plus optional "property=value" statements indicating which message properties were evaluated to reach that conclusion.
标题字段的值（删除[MAIL]注释后）由身份验证标识符、可选版本和一系列“method=result”语句组成，这些语句指示应用了哪些身份验证方法及其各自的结果，然后，对于每个应用的方法，可选的“reason”字符串加上可选的“property=value”语句，指示对哪些消息属性进行了评估以得出该结论。
The header field MAY appear more than once in a single message, or more than one result MAY be represented in a single header field, or a combination of these MAY be applied.
报头字段可以在单个消息中出现多次，或者可以在单个报头字段中表示多个结果，或者可以应用这些结果的组合。
Formally, the header field is specified as follows using [ABNF]:
在形式上，头字段使用[ABNF]指定如下：
authres-header = "Authentication-Results:" [CFWS] authserv-id
[ CFWS version ]
( [CFWS] ";" [CFWS] "none" / 1*resinfo ) [CFWS] CRLF
; the special case of "none" is used to indicate that no
; message authentication is performed
authres-header = "Authentication-Results:" [CFWS] authserv-id
[ CFWS version ]
( [CFWS] ";" [CFWS] "none" / 1*resinfo ) [CFWS] CRLF
; the special case of "none" is used to indicate that no
; message authentication is performed
authserv-id = dot-atom ; see below for a description of this element
authserv id=点原子；有关此元素的说明，请参见下文
version = 1*DIGIT [CFWS]
; indicates which version of this specification is in use;
; this specification is version "1"; the absence of a
; version implies this version of the specification
version = 1*DIGIT [CFWS]
; indicates which version of this specification is in use;
; this specification is version "1"; the absence of a
; version implies this version of the specification
resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ]
*( CFWS propspec )
resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ]
*( CFWS propspec )
methodspec = [CFWS] method [CFWS] "=" [CFWS] result
; indicates which authentication method was evaluated
methodspec = [CFWS] method [CFWS] "=" [CFWS] result
; indicates which authentication method was evaluated
reasonspec = "reason" [CFWS] "=" [CFWS] value ; a free-form comment on the reason the given result ; was returned
reasonspec=“reason”[CFWS]“=”[CFWS]值；对给定结果原因的自由形式评论；被退回
propspec = ptype [CFWS] "." [CFWS] property [CFWS] "=" pvalue
; an indication of which properties of the message
; were evaluated by the authentication scheme being
; applied to yield the reported result and would be
; useful to reveal to end users as authenticated
propspec = ptype [CFWS] "." [CFWS] property [CFWS] "=" pvalue
; an indication of which properties of the message
; were evaluated by the authentication scheme being
; applied to yield the reported result and would be
; useful to reveal to end users as authenticated
method = dot-atom [ [CFWS] "/" [CFWS] version ]
; a method indicates which method's result is
; represented by "result", and is one of the methods
; explicitly defined as valid in this document
; or is an extension method as defined below
method = dot-atom [ [CFWS] "/" [CFWS] version ]
; a method indicates which method's result is
; represented by "result", and is one of the methods
; explicitly defined as valid in this document
; or is an extension method as defined below
result = dot-atom ; indicates the results of the attempt to authenticate ; the message; see below for details
结果=点原子；指示尝试验证的结果；信息；详情见下文
ptype = "smtp" / "header" / "body" / "policy"
; indicates whether the property being evaluated was
; a parameter to an [SMTP] command, or was a value taken
; from a message header field, or was some property of
; the message body, or some other property evaluated by
; the receiving MTA
ptype = "smtp" / "header" / "body" / "policy"
; indicates whether the property being evaluated was
; a parameter to an [SMTP] command, or was a value taken
; from a message header field, or was some property of
; the message body, or some other property evaluated by
; the receiving MTA
property = dot-atom
; if "ptype" is "smtp", this indicates which [SMTP]
; command provided the value that was evaluated by the
; authentication scheme being applied; if "ptype" is
; "header", this indicates from which header field the
; value being evaluated was extracted; if "ptype" is
; "body", this indicates the offset into the body at which
; content of interest was detected; if "ptype" is "policy"
; then this indicates the name of the policy that caused
; this header field to be added (see below)
property = dot-atom
; if "ptype" is "smtp", this indicates which [SMTP]
; command provided the value that was evaluated by the
; authentication scheme being applied; if "ptype" is
; "header", this indicates from which header field the
; value being evaluated was extracted; if "ptype" is
; "body", this indicates the offset into the body at which
; content of interest was detected; if "ptype" is "policy"
; then this indicates the name of the policy that caused
; this header field to be added (see below)
pvalue = [CFWS] ( value / [ [ local-part ] "@" ] domain-name )
[CFWS]
; the value extracted from the message property defined
; by the "ptype.property" construction; if the value
; identifies something intended to be an e-mail identity,
; then it MUST use the right hand portion of this ABNF
; definition
pvalue = [CFWS] ( value / [ [ local-part ] "@" ] domain-name )
[CFWS]
; the value extracted from the message property defined
; by the "ptype.property" construction; if the value
; identifies something intended to be an e-mail identity,
; then it MUST use the right hand portion of this ABNF
; definition
The "local-part" is as defined in Section 3.4.1, and "dot-atom" is defined in Section 3.2.3, of [MAIL].
“本地部分”的定义见[邮件]第3.4.1节，“点原子”的定义见[邮件]第3.2.3节。
The "value" is as defined in Section 5.1 of [MIME].
“值”的定义见[MIME]第5.1节。
The "domain-name" is as defined in Section 3.5 of [DKIM].
“域名”的定义见[DKIM]第3.5节。
The "dot-atom" used in a "result" above is further constrained by the necessity of being enumerated in Section 2.4 or an amendment to it.
上述“结果”中使用的“点原子”进一步受到第2.4节或其修正案中列举的必要性的限制。
See Section 2.3 for a description of the "authserv-id" element.
有关“authserv id”元素的描述，请参见第2.3节。
The list of commands eligible for use with the "smtp" ptype can be found in [SMTP] and subsequent amendments.
可与“smtp”ptype一起使用的命令列表可在[smtp]和后续修订中找到。
"CFWS" is as defined in Section 3.2.2 of [MAIL].
“CFWS”的定义见[邮件]第3.2.2节。
The "propspec" may be omitted if, for example, the method was unable to extract any properties to do its evaluation yet has a result to report.
例如，如果该方法无法提取任何属性进行评估，但有结果要报告，则可以省略“propspec”。
The "ptype" and "property" values used by each authentication method should be defined in the specification for that method (or its amendments).
每个身份验证方法使用的“ptype”和“property”值应在该方法（或其修订版）的规范中定义。
The "ptype" and "property" are case-insensitive.
“ptype”和“property”不区分大小写。
A "ptype" value of "policy" indicates a policy decision about the message not specific to a property of the message that could be extracted. For example, if a method would normally report a "ptype.property" of "header.From" and no From: header field was present, the method can use "policy" to indicate that no conclusion about the authenticity of the message could be reached.
“policy”的“ptype”值表示有关消息的策略决策，该决策不特定于可提取消息的属性。例如，如果一个方法通常会报告“header.From”的“ptype.property”，并且不存在From:header字段，那么该方法可以使用“policy”来表示无法得出关于消息真实性的任何结论。
Every Authentication-Results header field has an authentication identifier field ("authserv-id" above). This is similar in syntax to a fully-qualified domain name.
每个身份验证结果标头字段都有一个身份验证标识符字段（“上面的authserv id”）。这在语法上类似于完全限定的域名。
The authentication identifier field provides a unique identifier that refers to the authenticating service within a given ADMD. The uniqueness of the identifier MUST be guaranteed by the ADMD that generates it and must pertain to exactly that one ADMD. This identifier is intended to be machine-readable and not necessarily meaningful to users. MUAs or downstream filters SHOULD use this identifier to determine whether or not the data contained in an Authentication-Results header field should be used.
authentication identifier（身份验证标识符）字段提供一个唯一标识符，该标识符引用给定ADMD中的身份验证服务。标识符的唯一性必须由生成它的ADMD保证，并且必须与该ADMD完全相关。该标识符是机器可读的，不一定对用户有意义。MUA或下游过滤器应使用此标识符确定是否应使用身份验证结果标头字段中包含的数据。
For simplicity and scalability, the authentication identifier SHOULD be a common token used throughout the ADMD, such as the DNS domain name used by or within that ADMD.
为了简单性和可伸缩性，身份验证标识符应该是整个ADMD中使用的通用令牌，例如该ADMD使用的DNS域名或在该ADMD中使用的DNS域名。
For tracing and debugging purposes, the authentication identifier MAY instead be the hostname of the MTA performing the authentication check whose result is being reported. This is also useful for another purpose, as described in Section 4. Moreover, some implementations have considered appending a delimiter such as "/" and following it with useful transport tracing data such as the [SMTP] queue ID or a timestamp.
出于跟踪和调试目的，身份验证标识符可以改为执行身份验证检查（其结果正在报告）的MTA的主机名。如第4节所述，这对于另一个目的也很有用。此外，一些实现还考虑添加分隔符，如“/”，并在其后添加有用的传输跟踪数据，如[SMTP]队列ID或时间戳。
It should be noted, however, that using a local, relative identifier like a single hostname, rather than a hierarchical and globally unique ADMD identifier like a DNS domain name, makes configuration more difficult for large sites. The hierarchical identifier permits aggregating related, trusted systems together under a single, parent identifier, which in turn permits assessing the trust relationship with a single reference. The alternative is a flat namespace requiring individually listing each trusted system. Since consumers must use the identifier to determine whether to use the contents of the header field:
但是，应该注意的是，使用本地相对标识符（如单个主机名）而不是层次结构和全局唯一的ADMD标识符（如DNS域名），会使大型站点的配置更加困难。层次标识符允许在单个父标识符下聚合相关的受信任系统，从而允许使用单个引用评估信任关系。另一种选择是一个平面名称空间，要求单独列出每个受信任的系统。由于使用者必须使用标识符来确定是否使用标题字段的内容：
o Changes to the identifier impose a large, centralized administrative burden.
o 对标识符的更改会带来巨大的集中管理负担。
o Ongoing administrative changes require constantly updating this centralized table, making it difficult to ensure that an MUA or downstream filter will have access to accurate information for assessing the usability of the header field's content. In particular, consumers of the header field will need to know not only the current identifier(s) in use, but previous ones as well to account for delivery latency or later re-assessment of the header field's contents.
o 正在进行的管理更改需要不断更新这个集中的表，这使得MUA或下游过滤器很难获得准确的信息来评估标题字段内容的可用性。特别是，标头字段的使用者不仅需要知道当前使用的标识符，还需要知道以前使用的标识符，以说明交付延迟或以后重新评估标头字段的内容。
Examples of valid authentication identifiers are "example.com", "mail.example.org", "ms1.newyork.example.com", and "example-auth".
有效身份验证标识符的示例有“example.com”、“mail.example.org”、“ms1.newyork.example.com”和“example auth”。
Each individual authentication method returns one of a set of specific result values. The subsections below define these results for the authentication methods specifically supported by this memo, and verifiers SHOULD use these values as described below. New methods not specified in this document intended to be supported by the header field defined in this memo MUST include a similar result table either in its defining memo or in a supplementary one.
每个单独的身份验证方法返回一组特定结果值中的一个。下面的小节为本备忘录特别支持的认证方法定义了这些结果，验证者应使用这些值，如下所述。本备忘录中定义的标题字段支持的本文档中未指定的新方法必须在其定义备忘录或补充备忘录中包含类似的结果表。
The result values used by [DKIM] and [DOMAINKEYS] are as follows:
[DKIM]和[DOMAINKEYS]使用的结果值如下：
none: The message was not signed.
无：邮件未签名。
pass: The message was signed, the signature or signatures were acceptable to the verifier, and the signature(s) passed verification tests.
通过：消息已签名，一个或多个签名被验证者接受，并且签名通过了验证测试。
fail: The message was signed and the signature or signatures were acceptable to the verifier, but they failed the verification test(s).
失败：消息已签名，且签名可被验证者接受，但未通过验证测试。
policy: The message was signed but the signature or signatures were not acceptable to the verifier.
策略：消息已签名，但验证者不接受签名。
neutral: The message was signed but the signature or signatures contained syntax errors or were not otherwise able to be processed. This result SHOULD also be used for other failures not covered elsewhere in this list.
中立：消息已签名，但签名包含语法错误或无法处理。该结果还应用于本列表其他地方未涵盖的其他故障。
temperror: The message could not be verified due to some error that is likely transient in nature, such as a temporary inability to retrieve a public key. A later attempt may produce a final result.
temperror：由于某些可能是暂时性的错误，例如暂时无法检索公钥，因此无法验证消息。以后的尝试可能会产生最终结果。
permerror: The message could not be verified due to some error that is unrecoverable, such as a required header field being absent. A later attempt is unlikely to produce a final result.
permerror：由于某些无法恢复的错误，例如缺少必需的标头字段，因此无法验证消息。以后的尝试不太可能产生最终结果。
A signature is "acceptable to the verifier" if it passes local policy checks (or there are no specific local policy checks). For example, a verifier might require that the signature(s) on the message be added using the DNS domain present in the From: header field of the message, thus making third-party signatures unacceptable.
如果签名通过了本地策略检查（或没有特定的本地策略检查），则签名是“验证者可以接受的”。例如，验证器可能要求使用消息的From:头字段中存在的DNS域添加消息上的签名，从而使第三方签名不可接受。
[DKIM] advises that if a message fails verification, it should be treated as an unsigned message. A report of "fail" here permits the receiver of the report to decide how to handle the failure. A report of "neutral" or "none" preempts that choice, ensuring the message will be treated as if it had not been signed.
[DKIM]建议，如果消息验证失败，则应将其视为未签名消息。此处的“失败”报告允许报告接收者决定如何处理失败。“中立”或“无”的报告优先考虑了这一选择，确保消息将被视为未经签名。
The result values are used by [SPF] and [SENDERID] as follows:
[SPF]和[SENDERID]使用的结果值如下：
none: No policy records were published at the sender's DNS domain.
无：在发件人的DNS域中未发布任何策略记录。
neutral: The sender's ADMD has asserted that it cannot or does not want to assert whether or not the sending IP address is authorized to send mail using the sender's DNS domain.
中立：发件人的ADMD声明它不能或不想声明发送IP地址是否有权使用发件人的DNS域发送邮件。
pass: The client is authorized by the sender's ADMD to inject or relay mail on behalf of the sender's DNS domain.
通过：发送方的ADMD授权客户端代表发送方的DNS域注入或中继邮件。
policy: The client is authorized to inject or relay mail on behalf of the sender's DNS domain according to the authentication method's algorithm, but local policy dictates that the result is unacceptable.
策略：根据身份验证方法的算法，客户端有权代表发件人的DNS域注入或中继邮件，但本地策略规定结果是不可接受的。
hardfail: This client is explicitly not authorized to inject or relay mail using the sender's DNS domain.
hardfail：此客户端未明确授权使用发件人的DNS域注入或中继邮件。
softfail: The sender's ADMD believes the client was not authorized to inject or relay mail using the sender's DNS domain, but is unwilling to make a strong assertion to that effect.
softfail：发送方的ADMD认为客户端未被授权使用发送方的DNS域注入或中继邮件，但不愿意对此做出强有力的断言。
temperror: The message could not be verified due to some error that is likely transient in nature, such as a temporary inability to retrieve a policy record from DNS. A later attempt may produce a final result.
temperror:由于某些可能是暂时性的错误，例如暂时无法从DNS检索策略记录，因此无法验证消息。以后的尝试可能会产生最终结果。
permerror: The message could not be verified due to some error that is unrecoverable, such as a required header field being absent or a syntax error in a retrieved DNS TXT record. A later attempt is unlikely to produce a final result.
permerror：由于某些无法恢复的错误，例如缺少必需的标头字段或检索到的DNS TXT记录中存在语法错误，因此无法验证消息。以后的尝试不太可能产生最终结果。
The distinction between and interpretation of "none" and "neutral" under these methods is discussed further in [SPF].
[SPF]中进一步讨论了这些方法下“无”和“中性”的区别和解释。
The "policy" result would be returned if, for example, [SPF] returned as "pass" result, but a local policy check matches the sending DNS domain to one found in an explicit list of unacceptable DNS domains (e.g., spammers).
例如，如果[SPF]返回为“通过”结果，但本地策略检查将发送DNS域与不可接受DNS域（例如垃圾邮件发送者）的显式列表中找到的域相匹配，则将返回“策略”结果。
If the retrieved sender policies used to evaluate [SPF] and [SENDERID] do not contain explicit provisions for authenticating the local-part (see Section 3.4.1 of [MAIL]) of an address, the "pvalue" reported along with results for these mechanisms SHOULD NOT include the local-part.
如果用于评估[SPF]和[SENDERID]的检索发件人策略不包含验证地址的本地部分（见[MAIL]第3.4.1节）的明确规定，则与这些机制的结果一起报告的“pvalue”不应包括本地部分。
The result values are used by the "iprev" method, defined in Section 3, are as follows:
第3节中定义的“iprev”方法使用的结果值如下：
pass: The DNS evaluation succeeded, i.e., the "reverse" and "forward" lookup results were returned and were in agreement.
通过：DNS评估成功，即返回“反向”和“正向”查找结果并一致。
fail: The DNS evaluation failed. In particular, the "reverse" and "forward" lookups each produced results but they were not in agreement, or the "forward" query completed but produced no result, e.g., a DNS RCODE of 3, commonly known as NXDOMAIN, or an RCODE of 0 (NOERROR) in a reply containing no answers, was returned.
失败：DNS评估失败。特别是，“反向”和“正向”查找都产生了结果，但结果不一致，或者“正向”查询已完成但未产生任何结果，例如，返回DNS RCODE为3（通常称为NXDOMIN），或者在不包含答案的回复中返回RCODE为0（无错误）。
temperror: The DNS evaluation could not be completed due to some error that is likely transient in nature, such as a temporary DNS error, e.g., a DNS RCODE of 2, commonly known as SERVFAIL, or other error condition resulted. A later attempt may produce a final result.
temperror:DNS评估无法完成，因为某些错误可能是暂时性的，例如临时DNS错误，例如DNS RCODE为2，通常称为SERVFAIL，或导致其他错误情况。以后的尝试可能会产生最终结果。
permerror: The DNS evaluation could not be completed because no PTR data are published for the connecting IP address, e.g., a DNS RCODE of 3, commonly known as NXDOMAIN, or an RCODE of 0 (NOERROR) in a reply containing no answers, was returned. This prevented completion of the evaluation.
permerror:无法完成DNS评估，因为没有为连接的IP地址发布PTR数据，例如，返回了DNS RCODE为3（通常称为NXDOMAIN）或答复中的RCODE为0（无错误）。这妨碍了评估的完成。
There is no "none" for this method since any TCP connection delivering email has an IP address associated with it, so some kind of evaluation will always be possible.
这种方法没有“无”，因为任何发送电子邮件的TCP连接都有一个与之关联的IP地址，所以总是可以进行某种评估。
For discussion of the format of DNS replies, see [DNS].
有关DNS回复格式的讨论，请参阅[DNS]。
The result values are used by the [AUTH] method are as follows:
[AUTH]方法使用的结果值如下：
none: SMTP authentication was not attempted.
无：未尝试SMTP身份验证。
pass: The SMTP client had authenticated to the server reporting the result using the protocol described in [AUTH].
通过：SMTP客户端已使用[AUTH]中描述的协议向报告结果的服务器进行身份验证。
fail: The SMTP client had attempted to authenticate to the server using the protocol described in [AUTH] but was not successful, yet continued to send the message about which a result is being reported.
失败：SMTP客户端尝试使用[AUTH]中描述的协议向服务器进行身份验证，但未成功，但仍继续发送报告结果的消息。
temperror: The SMTP client attempted to authenticate using the protocol described in [AUTH] but was not able to complete the attempt due to some error which is likely transient in nature, such as a temporary Lightweight Directory Access Protocol (LDAP) lookup error. A later attempt may produce a final result.
temperror:SMTP客户端试图使用[AUTH]中描述的协议进行身份验证，但由于某些可能是暂时性错误，例如临时轻型目录访问协议（LDAP）查找错误，无法完成此尝试。以后的尝试可能会产生最终结果。
permerror: The SMTP client attempted to authenticate using the protocol described in [AUTH] but was not able to complete the attempt due to some error that is likely not transient in nature, such as a permanent LDAP lookup error. A later attempt is not likely produce a final result.
permerror:SMTP客户端试图使用[AUTH]中描述的协议进行身份验证，但由于某些可能不是暂时性的错误（例如永久性LDAP查找错误），无法完成此尝试。以后的尝试不太可能产生最终结果。
Note that an agent making use of the data provided by this header field SHOULD consider "fail" and "temperror" to be the synonymous in terms of message authentication, i.e., the client did not authenticate.
注意，使用这个头字段提供的数据的代理应该考虑“失败”和“回火”在消息认证方面是同义的，即客户端没有进行认证。
Additional result codes (extension results) might be defined in the future by later revisions or extensions to this specification. Extension results beginning with "x-" will never be defined as standard fields; such names are reserved for experimental use. Result codes not beginning with "x-" MUST be registered with the Internet Assigned Numbers Authority (IANA) and published in an RFC. See Section 6 for further details.
其他结果代码（扩展结果）可能在将来由本规范的后续修订或扩展定义。以“x-”开头的扩展结果永远不会定义为标准字段；这些名称保留供实验使用。不以“x-”开头的结果代码必须在互联网分配号码管理局（IANA）注册并在RFC中公布。详见第6节。
Implementations reporting new result codes MUST use the "x-" prefix until such time as the new method is registered by IANA.
在IANA注册新方法之前，报告新结果代码的实现必须使用“x-”前缀。
Extension results MUST only be used within ADMDs that have explicitly consented to use them. These results and the parameters associated with them are not documented in RFCs. Therefore, they are subject to change at any time and not suitable for production use. Any MTA, MUA or downstream filter intended for production use SHOULD ignore or delete any Authentication-Results header field that includes an extension result.
扩展结果只能在明确同意使用它们的ADMD中使用。RFCs中未记录这些结果及其相关参数。因此，它们随时可能发生变化，不适合生产使用。任何用于生产的MTA、MUA或下游过滤器都应忽略或删除包含扩展结果的任何身份验证结果标题字段。
This section defines the supported authentication methods and discusses the proper means for applying experimental and other extension methods.
本节定义了支持的身份验证方法，并讨论了应用实验方法和其他扩展方法的适当方法。
As they are currently existing specifications for message authentication, it is appropriate to define an authentication method identifier for each of [AUTH], [DKIM], [DOMAINKEYS], [SENDERID], and [SPF]. Therefore, the authentication method identifiers "auth", "dkim", "domainkeys", "sender-id", and "spf", respectively are hereby defined for MTAs applying those specifications for email message authentication.
由于它们是消息身份验证的现有规范，因此适合为[AUTH]、[DKIM]、[DOMAINKEYS]、[SENDERID]和[SPF]中的每一个定义身份验证方法标识符。因此，在此分别为MTA定义认证方法标识符“auth”、“dkim”、“domainkeys”、“发送者id”和“spf”，并将这些规范应用于电子邮件消息认证。
Furthermore, method "iprev" is defined in Section 3.
此外，第3节定义了方法“iprev”。
See Section 6 for details.
详见第6节。
Additional authentication method identifiers (extension methods) may be defined in the future by later revisions or extensions to this specification. Extension methods beginning with "x-" will never be defined as standard fields; such names are reserved for experimental use. Method identifiers not beginning with "x-" MUST be registered with the Internet Assigned Numbers Authority (IANA) and published in an RFC. See Section 6 for further details.
其他认证方法标识符（扩展方法）可在将来通过本规范的后续修订或扩展进行定义。以“x-”开头的扩展方法永远不会被定义为标准字段；这些名称保留供实验使用。不以“x-”开头的方法标识符必须在互联网分配号码管理局（IANA）注册并在RFC中发布。详见第6节。
Extension methods may be defined for the following reasons:
可根据以下原因定义扩展方法：
1. To allow additional information from new authentication systems to be communicated to MUAs or downstream filters. The names of such identifiers should reflect the name of the method being defined, but should not be needlessly long.
1. 允许将来自新认证系统的附加信息传送给MUA或下游过滤器。此类标识符的名称应反映所定义方法的名称，但不应过长。
2. To allow the creation of "sub-identifiers" that indicate different levels of authentication and differentiate between their relative strengths, e.g., "auth1-weak" and "auth1-strong".
2. 允许创建指示不同身份验证级别并区分其相对强度的“子标识符”，例如“auth1弱”和“auth1强”。
Implementations of new methods MUST use the "x-" prefix until such time as the new method is registered by IANA.
在IANA注册新方法之前，新方法的实现必须使用“x-”前缀。
Authentication method implementors are encouraged to provide adequate information, via [MAIL] comments if necessary, to allow an MUA developer to understand or relay ancillary details of authentication results. For example, if it might be of interest to relay what data was used to perform an evaluation, such information could be relayed as a comment in the header field, such as:
鼓励认证方法实施者在必要时通过[邮件]评论提供足够的信息，以允许MUA开发人员理解或转发认证结果的辅助细节。例如，如果可能有兴趣转发用于执行评估的数据，则可以将此类信息作为标题字段中的注释转发，例如：
Authentication-Results: example.com;
foo=pass bar.baz=blob (2 of 3 tests OK)
Authentication-Results: example.com;
foo=pass bar.baz=blob (2 of 3 tests OK)
Experimental method identifiers MUST only be used within ADMDs that have explicitly consented to use them. These method identifiers and the parameters associated with them are not documented in RFCs. Therefore, they are subject to change at any time and not suitable for production use. Any MTA, MUA, or downstream filter intended for production use SHOULD ignore or delete any Authentication-Results header field that includes an experimental method identifier.
实验方法标识符只能在明确同意使用它们的ADMD中使用。RFCs中未记录这些方法标识符及其相关参数。因此，它们随时可能发生变化，不适合生产使用。任何用于生产的MTA、MUA或下游过滤器都应忽略或删除包含实验方法标识符的任何身份验证结果标题字段。
This section defines an additional authentication method called "iprev".
本节定义了一种称为“iprev”的附加身份验证方法。
In general, "iprev" is an attempt to verify that a client appears to be valid based on some DNS queries. Upon receiving a session initiation of some kind from a client, the IP address of the client peer is queried for matching names (i.e., a number-to-name translation, also known as a "reverse lookup" or a "PTR" record query). Once that result is acquired, a lookup of each of the names (i.e., a name-to-number translation, or an "A" or "AAAA" record query) thus retrieved is done. The response to this second check should result in at least one mapping back to the client's IP address.
通常，“iprev”是基于某些DNS查询验证客户端是否有效的尝试。在从客户端接收到某种会话发起后，将查询客户端对等方的IP地址以查找匹配的名称（即，从数字到名称的转换，也称为“反向查找”或“PTR”记录查询）。一旦获得该结果，就完成对由此检索到的每个名称的查找（即，名称到数字的转换，或“a”或“AAAA”记录查询）。对第二个检查的响应应导致至少一个映射回客户端的IP地址。
More algorithmically: if the client peer's IP address is I, the list of names to which I maps (after a "PTR" query) is the set N, and the union of IP addresses to which each member of N maps (after corresponding "A" and "AAAA" queries) is L, then this test is successful if I is an element of L.
从算法上来说：如果客户端对等方的IP地址是I，I映射到的名称列表（在“PTR”查询之后）是集合N，N的每个成员映射到的IP地址的并集（在相应的“a”和“AAAA”查询之后）是L，那么如果I是L的一个元素，则此测试成功。
The response to a PTR query could contain multiple names. To prevent heavy DNS loads, agents performing these queries MUST be implemented such that the number of names evaluated by generation of corresponding A or AAAA queries is finite, though it MAY be configurable by an administrator. As an example, Section 5.5 of [SPF] chose a limit of 10 for its implementation of this algorithm.
对PTR查询的响应可能包含多个名称。为了防止DNS负载过大，必须实现执行这些查询的代理，以便通过生成相应的A或AAAA查询来评估的名称数量是有限的，尽管管理员可以对其进行配置。例如，[SPF]第5.5节为实现该算法选择了10的限制。
[DNS-IP6] discusses the query formats for the IPv6 case.
[DNS-IP6]讨论IPv6案例的查询格式。
A successful test using this algorithm constitutes a result of "pass" since the ADMD in which the client's PTR claims it belongs has confirmed that claim by including corresponding data in its DNS domain. A failure to match constitutes a "fail". There is no case in which a "neutral" result can be returned. The remaining "temperror" and "permerror" cases refer, respectively, to temporary and permanent DNS query errors.
使用此算法的成功测试构成“通过”的结果，因为客户端的PTR声明其所属的ADMD已通过在其DNS域中包含相应数据来确认该声明。不匹配构成“失败”。不存在可以返回“中性”结果的情况。其余的“temperror”和“permerror”案例分别指临时和永久DNS查询错误。
There is some contention regarding the wisdom and reliability of this test. For example, in some regions it can be difficult for this test ever to pass because the practice of arranging to match the forward and reverse DNS is infrequently observed. Therefore, the actual implementation details of how a verifier performs an "iprev" test are not specified here. The verifier MAY report a successful or failed "iprev" test at its discretion having done some kind of check of the validity of the connection's identity using DNS. It is incumbent upon an agent making use of the reported "iprev" result to understand what exactly that particular verifier is attempting to report.
关于这项测试的智慧和可靠性有一些争论。例如，在某些地区，该测试可能很难通过，因为很少观察到安排匹配正向和反向DNS的实践。因此，这里没有指定验证器如何执行“iprev”测试的实际实现细节。在使用DNS对连接身份的有效性进行某种检查后，验证者可自行决定报告成功或失败的“iprev”测试。代理人有义务使用报告的“iprev”结果来了解特定验证者试图报告的内容。
Extensive discussion of reverse DNS mapping and its implications can be found in [DNSOP-REVERSE]. In particular, it recommends that applications avoid using this test as a means of authentication or security. Its presence in this memo is not an endorsement, but is merely acknowledgement that the method remains common and provides the means to relay the results of that test.
[DNSOP-reverse]中对反向DNS映射及其含义进行了广泛的讨论。特别是，它建议应用程序避免使用此测试作为身份验证或安全性的手段。其出现在本备忘录中并不是认可，而只是承认该方法仍然通用，并提供了传递该测试结果的方法。
This specification makes no attempt to evaluate the relative strengths of various message authentication methods that may become available. As such, the order of the presented authentication methods and results MUST NOT be used either to imply or infer the importance or strength of any given method over another. Instead, the MUA or downstream filter consuming this header field must interpret the result of each method based on its own knowledge of what that method evaluates.
本规范不试图评估可能出现的各种消息身份验证方法的相对强度。因此，所述认证方法和结果的顺序不得用于暗示或推断任何给定方法相对于另一种方法的重要性或强度。相反，使用此标头字段的MUA或下游过滤器必须根据其自身对每个方法计算结果的了解来解释每个方法的结果。
Each "method" MUST refer to an authentication method declared in the IANA registry, or an extension method as defined in Section 2.5.2, and each "result" MUST refer to a result code declared in the IANA registry, or an extension result code as defined in Section 2.4.5. See Section 6 for further information about the registered methods and result codes.
每个“方法”必须指IANA注册表中声明的认证方法，或第2.5.2节中定义的扩展方法，每个“结果”必须指IANA注册表中声明的结果代码，或第2.4.5节中定义的扩展结果代码。有关注册方法和结果代码的更多信息，请参见第6节。
An MTA compliant with this specification MUST add this header field (after performing one or more message authentication tests) to indicate which MTA or ADMD performed the test, which test got applied and what the result was. If an MTA applies more than one such test, it MUST add this header field either once per test, or once indicating all of the results. An MTA MUST NOT add a result to an existing header field.
符合此规范的MTA必须添加此标头字段（在执行一个或多个邮件身份验证测试后），以指示哪个MTA或ADMD执行了测试、应用了哪个测试以及结果如何。如果MTA应用多个此类测试，则必须在每个测试中添加一次此标题字段，或者添加一次指示所有结果的标题字段。MTA不得将结果添加到现有标题字段中。
An MTA MAY add this header field containing only the authentication identifier portion to indicate explicitly that no message authentication schemes were applied prior to delivery of this message.
MTA可以添加仅包含身份验证标识符部分的此标头字段，以明确指示在传递此邮件之前未应用任何邮件身份验证方案。
An MTA adding this header field must take steps to identify it as legitimate to the MUAs or downstream filters that will ultimately consume its content. One required process to do so is described in Section 5. Further measures may be required in some environments. Some possible solutions are enumerated in Section 7.1. This memo does not mandate any specific solution to this issue as each environment has its own facilities and limitations.
添加此标头字段的MTA必须采取步骤将其标识为MUA或最终将使用其内容的下游筛选器的合法字段。第5节描述了一个必要的过程。在某些环境中可能需要采取进一步的措施。第7.1节列举了一些可能的解决方案。由于每个环境都有自己的设施和限制，本备忘录不强制要求对此问题采取任何具体的解决方案。
For MTAs that add this header field, adding header fields in order (at the top), per Section 3.6 of [MAIL], is particularly important. Moreover, this header field SHOULD be inserted above any other trace header fields such MTAs might prepend. This allows easy detection of header fields that can be trusted.
对于添加此标头字段的MTA，根据[MAIL]第3.6节，按顺序（在顶部）添加标头字段尤其重要。此外，此头字段应插入到MTA可能前置的任何其他跟踪头字段的上方。这允许轻松检测可信任的标题字段。
End users making direct use of this header field may inadvertently trust information that has not been properly vetted. If, for example, a basic [SPF] result were to be relayed that claims an authenticated addr-spec, the local-part of that addr-spec has actually not been authenticated. Thus, an MTA adding this header field SHOULD NOT include any data that has not been authenticated by the method(s) being applied. Moreover, MUAs SHOULD NOT render to users such information if it is presented by a method known not to authenticate it.
直接使用此标题字段的最终用户可能无意中信任未经适当审查的信息。例如，如果要中继一个基本[SPF]结果，该结果声明一个经过身份验证的addr规范，则该addr规范的本地部分实际上尚未经过身份验证。因此，添加此标头字段的MTA不应包含任何未通过所应用方法验证的数据。此外，如果这些信息是通过一种已知的方法呈现的，而该方法没有对其进行身份验证，则MUA不应向用户呈现这些信息。
In order to ensure non-ambiguous results and avoid the impact of false header fields, MUAs and downstream filters SHOULD NOT interpret this header field unless specifically instructed to do so by the user or administrator. That is, this interpretation should not be "on by default". Naturally then, users or administrators should not activate such a feature unless they are certain the header field will be added by the border MTA that accepts the mail that is ultimately read by the MUA, and instances of the header field appearing to be from within the ADMD but actually added by foreign MTAs will be removed before delivery.
为了确保结果不含糊并避免虚假标题字段的影响，除非用户或管理员明确指示，否则MUA和下游过滤器不应解释此标题字段。也就是说，这种解释不应“默认开启”。因此，用户或管理员自然不应激活此类功能，除非他们确定接收MUA最终读取的邮件的边界MTA将添加标题字段，并且标题字段的实例看似来自ADMD，但实际上是由外部MTA添加的，将在交付前删除。
Furthermore, MUAs and downstream filters SHOULD NOT interpret this header field unless the authentication identifier it bears appears to be one used within its own ADMD as configured by the user or administrator.
此外，MUA和下游过滤器不应解释此标头字段，除非其承载的身份验证标识符似乎是用户或管理员配置的在其自身ADMD中使用的标识符。
MUAs and downstream filters MUST ignore any result reported using a "result" not specified in the result code registry, or a "ptype" not listed in the corresponding registry for such values as defined in Section 6. Moreover, such agents MUST ignore a result indicated for any "method" they do not specifically support.
MUA和下游过滤器必须忽略使用结果代码注册表中未指定的“结果”报告的任何结果，或者对于第6节中定义的值，相应注册表中未列出的“ptype”。此外，这些代理必须忽略他们不特别支持的任何“方法”的结果。
An MUA SHOULD NOT reveal these results to end users unless the results are accompanied by, at a minimum, some associated reputation data about the authenticated origin identifiers within the message. For example, an attacker could register examp1e.com (note the digit "one") and send signed mail to intended victims; a verifier would detect that the signature was valid and report a "pass" even though it's clear the DNS domain name was intended to mislead. See Section 7.2 for further discussion.
MUA不应将这些结果透露给最终用户，除非这些结果至少伴随着一些与消息中经过身份验证的来源标识符相关的信誉数据。例如，攻击者可以注册examp1e.com（注意数字“1”）并向目标受害者发送签名邮件；验证者将检测签名是否有效并报告“通过”，即使DNS域名显然是有意误导。进一步讨论见第7.2节。
As stated in Section 2.1, this header field SHOULD be treated as though it were a trace header field as defined in Section 3.6.7 of [MAIL], and hence MUST NOT be reordered and MUST be prepended to the message, so that there is generally some indication upon delivery of where in the chain of handling MTAs the message authentication was done.
如第2.1节所述，应将此头字段视为[邮件]第3.6.7节中定义的跟踪头字段，因此不得重新排序，且必须在邮件前加上前缀，以便在传递MTA时，通常会有一些指示，说明在处理MTA的链中在何处进行了邮件身份验证。
MUAs SHOULD ignore instances of this header field discovered within message/rfc822 [MIME] attachments.
MUA应忽略在message/rfc822[MIME]附件中发现的此标头字段的实例。
Further discussion of this can be found in Section 7 below.
关于这一点的进一步讨论见下文第7节。
If a site's local policy is to consider a non-recoverable failure result (e.g., "fail" for DKIM, "hardfail" for SPF) for any particular authentication method as justification to reject the message completely, the border MTA SHOULD issue an [SMTP] rejection response to the message rather than adding this header field with the failure result and allowing it to proceed toward delivery. This is more desirable than allowing the message to reach an internal host's MTA or spam filter, thus possibly generating a local rejection such as a [DSN] to a forged originator.
如果一个站点的本地策略考虑一个不可恢复的失败结果（例如，对于一个特定的身份验证方法来说，对于一个特定的身份验证方法来说，DKIM的“失败”、“Hard失败”是完全拒绝消息的理由，那么边界MTA应该发出一个[SMTP]。拒绝对消息的响应，而不是将此标头字段与失败结果一起添加，并允许其继续进行传递。这比允许邮件到达内部主机的MTA或垃圾邮件过滤器更可取，因此可能会生成本地拒绝，例如对伪造的原始发件人的[DSN]。
The same MAY also be done for local policy decisions overriding the results of the authentication methods (e.g., the "policy" result codes described in Section 2.4).
对于覆盖认证方法结果的本地策略决策（例如，第2.4节中描述的“策略”结果代码），也可以这样做。
Such rejections at the SMTP protocol level are not possible if local policy is enforced at the MUA and not the MTA. Unfortunately, this may be a common scenario.
如果在MUA而不是MTA强制实施本地策略，则无法在SMTP协议级别执行此类拒绝。不幸的是，这可能是一种常见的情况。
For security reasons, any MTA conforming to this specification MUST delete any discovered instance of this header field that claims to have been added within its trust boundary and that did not come from another trusted MTA. For example, an MTA (border or otherwise) for example.com receiving a message MUST delete any instance of this
出于安全原因，任何符合此规范的MTA都必须删除发现的、声称已添加到其信任边界内且不是来自另一个受信任MTA的此标头字段的任何实例。例如，接收邮件的MTA（border或其他）例如.com必须删除此邮件的任何实例
header field bearing an authentication identifier indicating the header field was added within example.com prior to adding its own header fields. This may mean each MTA will have to be equipped with a list of internal MTAs known to be compliant (and hence trustworthy).
带有身份验证标识符的标头字段，该标识符指示在添加自己的标头字段之前已在example.com中添加了标头字段。这可能意味着每个MTA必须配备一份已知符合要求（因此值得信赖）的内部MTA列表。
For simplicity and maximum security, a border MTA MAY remove all instances of this header field on mail crossing into its trust boundary. However, this may conflict with the desire to access authentication results performed by trusted external service providers. It may also invalidate signed messages whose signatures cover external instances of this header field. A more robust border MTA could allow a specific list of authenticating MTAs whose information should be let in, removing all others.
为了简单和最大的安全性，border MTA可以在邮件跨入其信任边界时删除此标头字段的所有实例。但是，这可能与访问受信任的外部服务提供商执行的身份验证结果的愿望相冲突。它还可能使签名覆盖此标头字段外部实例的已签名消息无效。一个更强大的边界MTA可以允许特定的身份验证MTA列表，这些MTA的信息应该被允许进入，从而删除所有其他MTA。
As stated in Section 1.2, a formal definition of "trust boundary" is deliberately not made here. It is entirely possible that a border MTA for example.com might explicitly trust authentication results asserted by upstream host example.net even though they exist in completely disjoint administrative boundaries. In that case, the border MTA MAY elect not to delete those results; moreover, the upstream host doing some authentication work could apply a signing technology such as [DKIM] on its own results to assure downstream hosts of their authenticity. An example of this is provided in Appendix B.
如第1.2节所述，“信托边界”的正式定义在此特意不做。边界MTA（例如example.com）完全可能明确信任上游主机example.net断言的身份验证结果，即使它们存在于完全不相交的管理边界中。在这种情况下，边境MTA可能选择不删除这些结果；此外，执行一些身份验证工作的上游主机可以在其自己的结果上应用签名技术，如[DKIM]，以确保下游主机的真实性。附录B中提供了一个示例。
Similarly, in the case of messages signed using [DKIM] or other message signing methods that sign header fields, this may invalidate one or more signatures on the message if they covered the header field to be removed at the time of signing. This behavior can be desirable since there's little value in validating the signature on a message with forged headers. However, signing agents MAY therefore elect to omit these header fields from signing to avoid this situation.
类似地，如果使用[DKIM]或其他消息签名方法对消息头字段进行签名，这可能会使消息上的一个或多个签名失效，如果这些签名覆盖了签名时要删除的头字段。这种行为是可取的，因为验证带有伪造头的消息上的签名没有什么价值。但是，签名代理可能因此选择在签名时忽略这些头字段以避免这种情况。
An MTA SHOULD remove any instance of this header field bearing a version (express or implied) that it does not support. However, an MTA MUST remove such a header if the [SMTP] connection relaying the message is not from a trusted internal MTA.
MTA应删除此标题字段中包含其不支持的版本（明示或暗示）的任何实例。但是，如果中继邮件的[SMTP]连接不是来自受信任的内部MTA，则MTA必须删除此类标头。
IANA has registered a new header field and created two new tables as described below.
IANA注册了一个新的标题字段，并创建了两个新表，如下所述。
Per [IANA-HEADERS], the "Authentication-Results" header field has been added to the IANA Permanent Message Header Field Registry. The following is the registration template:
根据[IANA-HEADERS]，已将“身份验证结果”标题字段添加到IANA永久消息标题字段注册表中。以下是注册模板：
Header field name: Authentication-Results Applicable protocol: mail ([MAIL]) Status: Standard Author/Change controller: IETF Specification document(s): RFC 5451 Related information: Requesting review of any proposed changes and additions to this field is recommended.
标题字段名称：认证结果适用协议：邮件（[mail]）状态：标准作者/变更控制者：IETF规范文件：RFC 5451相关信息：建议请求审查该字段的任何拟议变更和增补。
Names of message authentication methods supported by this specification must be registered with IANA, with the exception of experimental names as described in Section 2.5.2.
本规范支持的消息认证方法的名称必须向IANA注册，第2.5.2节所述的实验名称除外。
New entries are assigned only for values that have been documented in a published RFC that has had IETF Review, per [IANA-CONSIDERATIONS]. Each method must register a name, the specification that defines it, one or more "ptype" values appropriate for use with that method, which "property" value(s) should be reported by that method, and a description of the "value" to be used with each.
根据[IANA-注意事项]，新条目仅分配给已发布RFC中记录的值，该RFC已经过IETF审查。每个方法必须注册一个名称、定义它的规范、一个或多个适用于该方法的“ptype”值、该方法应报告的“property”值，以及每个方法要使用的“value”的描述。
The initial set of entries in this registry is as follows:
此注册表中的初始项集如下所示：
+------------+----------+--------+----------------+--------------------+
| Method | Defined | ptype | property | value |
+------------+----------+--------+----------------+--------------------+
| auth | RFC4954 | smtp | auth | AUTH parameter of |
| | | | | the SMTP MAIL |
| | | | | command |
+------------+----------+--------+----------------+--------------------+
| dkim | RFC4871 | header | d | value of |
| | | | | signature "d" tag |
| | | +----------------+--------------------+
| | | | i | value of |
| | | | | signature "i" tag |
+------------+----------+--------+----------------+--------------------+
| domainkeys | RFC4870 | header | d | value of |
| | | | | signature "d" tag |
| | | +----------------+--------------------+
| | | | from | value of From |
| | | | | header field after |
| | | | | removing comments |
| | | | | and local-part if |
| | | | | not authenticated |
| | | +----------------+--------------------+
| | | | sender | value of Sender |
| | | | | header field after |
| | | | | removing comments |
| | | | | and local-part if |
| | | | | not authenticated |
+------------+----------+--------+----------------+--------------------+
| iprev | this | policy | iprev | client IP address |
| | document | | | |
+------------+----------+--------+----------------+--------------------+
| sender-id | RFC4406 | header | name of header | value of header |
| | | | field used by | field used by PRA |
| | | | the Purported | after removing |
| | | | Responsible | comments and parts |
| | | | Address (PRA) | not authenticated |
+------------+----------+--------+----------------+--------------------+
| spf | RFC4408 | smtp | mailfrom | envelope sender |
| | | | | after removing |
| | | | | parts not |
| | | | | authenticated |
| | +--------+----------------+--------------------+
| | | smtp | helo | HELO/EHLO value |
+------------+----------+--------+----------------+--------------------+
+------------+----------+--------+----------------+--------------------+
| Method | Defined | ptype | property | value |
+------------+----------+--------+----------------+--------------------+
| auth | RFC4954 | smtp | auth | AUTH parameter of |
| | | | | the SMTP MAIL |
| | | | | command |
+------------+----------+--------+----------------+--------------------+
| dkim | RFC4871 | header | d | value of |
| | | | | signature "d" tag |
| | | +----------------+--------------------+
| | | | i | value of |
| | | | | signature "i" tag |
+------------+----------+--------+----------------+--------------------+
| domainkeys | RFC4870 | header | d | value of |
| | | | | signature "d" tag |
| | | +----------------+--------------------+
| | | | from | value of From |
| | | | | header field after |
| | | | | removing comments |
| | | | | and local-part if |
| | | | | not authenticated |
| | | +----------------+--------------------+
| | | | sender | value of Sender |
| | | | | header field after |
| | | | | removing comments |
| | | | | and local-part if |
| | | | | not authenticated |
+------------+----------+--------+----------------+--------------------+
| iprev | this | policy | iprev | client IP address |
| | document | | | |
+------------+----------+--------+----------------+--------------------+
| sender-id | RFC4406 | header | name of header | value of header |
| | | | field used by | field used by PRA |
| | | | the Purported | after removing |
| | | | Responsible | comments and parts |
| | | | Address (PRA) | not authenticated |
+------------+----------+--------+----------------+--------------------+
| spf | RFC4408 | smtp | mailfrom | envelope sender |
| | | | | after removing |
| | | | | parts not |
| | | | | authenticated |
| | +--------+----------------+--------------------+
| | | smtp | helo | HELO/EHLO value |
+------------+----------+--------+----------------+--------------------+
Names of message authentication result codes supported by this specification must be registered with IANA, with the exception of experimental codes as described in Section 2.4.5.
本规范支持的消息认证结果代码的名称必须向IANA注册，第2.4.5节所述的实验代码除外。
New entries are assigned only for result codes that have been documented in a published RFC that has had IETF Review, per [IANA-CONSIDERATIONS]. Each code must register a name, the document that establishes the registration, the authentication method(s) that uses it, and either a definition of the semantics of its use or a reference to the place where those semantics are defined.
根据[IANA-注意事项]，新条目仅分配给已发布的RFC中记录的结果代码，该RFC已经过IETF审查。每个代码必须注册一个名称、建立注册的文档、使用它的身份验证方法，以及它的使用语义的定义或对定义这些语义的位置的引用。
The initial set of entries in this registry is as follows:
此注册表中的初始项集如下所示：
+-----------+----------+----------------+------------------------------+
| Code | Defined | Auth Method(s) | Meaning |
+-----------+----------+----------------+------------------------------+
| none | this | dkim | section 2.4.1 |
| | document | domainkeys | |
| | +----------------+------------------------------+
| | | spf | section 2.4.2 |
| | | sender-id | |
| | +----------------+------------------------------+
| | | auth | section 2.4.4 |
+-----------+----------+----------------+------------------------------+
| pass | this | dkim | section 2.4.1 |
| | document | domainkeys | |
| | +----------------+------------------------------+
| | | spf | section 2.4.2 |
| | | sender-id | |
| | +----------------+------------------------------+
| | | iprev | section 2.4.3 |
| | +----------------+------------------------------+
| | | auth | section 2.4.4 |
+-----------+----------+----------------+------------------------------+
| fail | this | dkim | section 2.4.1 |
| | document | domainkeys | |
| | +----------------+------------------------------+
| | | iprev | section 2.4.3 |
| | +----------------+------------------------------+
| | | auth | section 2.4.4 |
+-----------+----------+----------------+------------------------------+
+-----------+----------+----------------+------------------------------+
| Code | Defined | Auth Method(s) | Meaning |
+-----------+----------+----------------+------------------------------+
| none | this | dkim | section 2.4.1 |
| | document | domainkeys | |
| | +----------------+------------------------------+
| | | spf | section 2.4.2 |
| | | sender-id | |
| | +----------------+------------------------------+
| | | auth | section 2.4.4 |
+-----------+----------+----------------+------------------------------+
| pass | this | dkim | section 2.4.1 |
| | document | domainkeys | |
| | +----------------+------------------------------+
| | | spf | section 2.4.2 |
| | | sender-id | |
| | +----------------+------------------------------+
| | | iprev | section 2.4.3 |
| | +----------------+------------------------------+
| | | auth | section 2.4.4 |
+-----------+----------+----------------+------------------------------+
| fail | this | dkim | section 2.4.1 |
| | document | domainkeys | |
| | +----------------+------------------------------+
| | | iprev | section 2.4.3 |
| | +----------------+------------------------------+
| | | auth | section 2.4.4 |
+-----------+----------+----------------+------------------------------+
| policy | this | dkim | section 2.4.1 |
| | document | domainkeys | |
| | +----------------+------------------------------+
| | | spf | section 2.4.2 |
| | | sender-id | |
+-----------+----------+----------------+------------------------------+
| neutral | this | dkim | section 2.4.1 |
| | document | domainkeys | |
| | +----------------+------------------------------+
| | | spf | section 2.4.2 |
| | | sender-id | |
+-----------+----------+----------------+------------------------------+
| temperror | this | dkim | section 2.4.1 |
| | document | domainkeys | |
| | +----------------+------------------------------+
| | | spf | section 2.4.2 |
| | | sender-id | |
| | +----------------+------------------------------+
| | | iprev | section 2.4.3 |
| | +----------------+------------------------------+
| | | auth | section 2.4.4 |
+-----------+----------+----------------+------------------------------+
| permerror | this | dkim | section 2.4.1 |
| | document | domainkeys | |
| | +----------------+------------------------------+
| | | spf | section 2.4.2 |
| | | sender-id | |
| | +----------------+------------------------------+
| | | iprev | section 2.4.3 |
| | +----------------+------------------------------+
| | | auth | section 2.4.4 |
+-----------+----------+----------------+------------------------------+
| hardfail | this | spf | section 2.4.2 |
| | document | sender-id | |
+-----------+----------+----------------+------------------------------+
| softfail | this | spf | section 2.4.2 |
| | document | sender-id | |
+-----------+----------+----------------+------------------------------+
| policy | this | dkim | section 2.4.1 |
| | document | domainkeys | |
| | +----------------+------------------------------+
| | | spf | section 2.4.2 |
| | | sender-id | |
+-----------+----------+----------------+------------------------------+
| neutral | this | dkim | section 2.4.1 |
| | document | domainkeys | |
| | +----------------+------------------------------+
| | | spf | section 2.4.2 |
| | | sender-id | |
+-----------+----------+----------------+------------------------------+
| temperror | this | dkim | section 2.4.1 |
| | document | domainkeys | |
| | +----------------+------------------------------+
| | | spf | section 2.4.2 |
| | | sender-id | |
| | +----------------+------------------------------+
| | | iprev | section 2.4.3 |
| | +----------------+------------------------------+
| | | auth | section 2.4.4 |
+-----------+----------+----------------+------------------------------+
| permerror | this | dkim | section 2.4.1 |
| | document | domainkeys | |
| | +----------------+------------------------------+
| | | spf | section 2.4.2 |
| | | sender-id | |
| | +----------------+------------------------------+
| | | iprev | section 2.4.3 |
| | +----------------+------------------------------+
| | | auth | section 2.4.4 |
+-----------+----------+----------------+------------------------------+
| hardfail | this | spf | section 2.4.2 |
| | document | sender-id | |
+-----------+----------+----------------+------------------------------+
| softfail | this | spf | section 2.4.2 |
| | document | sender-id | |
+-----------+----------+----------------+------------------------------+
The following security considerations apply when adding or processing the "Authentication-Results" header field:
添加或处理“Authentication Results”标题字段时，以下安全注意事项适用：
An MUA or filter that accesses a mailbox whose mail is handled by a non-conformant MTA, and understands Authentication-Results header fields, could potentially make false conclusions based on forged header fields. A malicious user or agent could forge a header field using the DNS domain of a receiving ADMD as the authserv-id token in the value of the header field, and with the rest of the value claim that the message was properly authenticated. The non-conformant MTA would fail to strip the forged header field, and the MUA could inappropriately trust it.
如果MUA或筛选器访问其邮件由不符合要求的MTA处理的邮箱，并了解身份验证结果标题字段，则可能根据伪造的标题字段得出错误结论。恶意用户或代理可以使用接收ADMD的DNS域作为头字段值中的authserv id令牌伪造头字段，并使用其余值声明消息已正确验证。不一致的MTA将无法剥离伪造的标头字段，MUA可能会不适当地信任它。
It is for this reason an MUA should not have processing of the "Authentication-Results" header field enabled by default; instead it should be ignored, at least for the purposes of enacting filtering decisions, unless specifically enabled by the user or administrator after verifying that the border MTA is compliant. It is acceptable to have an MUA aware of this specification, but have an explicit list of hostnames whose "Authentication-Results" header fields are trustworthy; however, this list should initially be empty.
因此，MUA在默认情况下不应启用“验证结果”标题字段的处理；相反，它应该被忽略，至少出于制定过滤决策的目的，除非用户或管理员在验证border MTA是否符合要求后特别启用。可以让MUA知道该规范，但有一个明确的主机名列表，其“身份验证结果”头字段是可信的；但是，此列表最初应为空。
Proposed alternate solutions to this problem are nascent:
针对这一问题提出的备选解决方案还处于萌芽阶段：
1. Possibly the simplest is a digital signature protecting the header field, such as using [DKIM], that can be verified by an MUA by using a posted public key. Although one of the main purposes of this memo is to relieve the burden of doing message authentication work at the MUA, this only requires that the MUA learn a single authentication scheme even if a number of them are in use at the border MTA. Note that [DKIM] requires that the From header field be signed, although in this application, the signing agent (a trusted MTA) likely cannot authenticate that value, so the fact that it is signed should be ignored.
1. 可能最简单的是保护报头字段的数字签名，例如使用[DKIM]，MUA可以使用发布的公钥对其进行验证。尽管本备忘录的主要目的之一是减轻MUA进行邮件身份验证工作的负担，但这只要求MUA学习一个身份验证方案，即使在边境MTA使用了多个方案。请注意，[DKIM]要求对From header字段进行签名，但在此应用程序中，签名代理（受信任的MTA）可能无法验证该值，因此应忽略该值已签名的事实。
2. Another would be a means to interrogate the MTA that added the header field to see if it is actually providing any message authentication services and saw the message in question, but this isn't especially palatable given the work required to craft and implement such a scheme.
2. 另一种方法是询问添加了header字段的MTA，看看它是否真的提供了任何消息身份验证服务，并看到了有问题的消息，但考虑到制定和实施这样一个方案所需的工作，这并不特别令人满意。
3. Yet another might be a method to interrogate the internal MTAs that apparently handled the message (based on Received: header
3. 还有一种方法可能是询问显然处理消息的内部MTA（基于Received:header）
fields) to determine whether any of them conform to Section 5 of this memo. This, too, has potentially high barriers-to-entry.
字段）以确定其中任何字段是否符合本备忘录第5节的要求。这也有潜在的高进入壁垒。
4. Extensions to [IMAP], [SMTP], and [POP3] could be defined to allow an MUA or filtering agent to acquire the "authserv-id" in use within an ADMD, thus allowing it to identify which Authentication-Results header fields it can trust.
4. 可以定义对[IMAP]、[SMTP]和[POP3]的扩展，以允许MUA或筛选代理获取ADMD中正在使用的“authserv id”，从而允许其识别可以信任的身份验证结果标头字段。
5. On the presumption that internal MTAs are fully compliant with Section 3.6 of [MAIL], and the compliant internal MTAs are using their own host names or the ADMD's DNS domain name as the "authserv-id" token, the header field proposed here should always appear above a Received: header added by a trusted MTA. This can be used as a test for header field validity.
5. 假定内部MTA完全符合[MAIL]第3.6节的要求，且符合要求的内部MTA使用自己的主机名或ADMD的DNS域名作为“authserv id”标记，此处建议的标头字段应始终显示在受信任MTA添加的Received:标头上方。这可以用作标题字段有效性的测试。
Support for some of these is planned for future work.
计划在今后的工作中为其中一些项目提供支持。
In any case, a mechanism needs to exist for an MUA or filter to verify that the host that appears to have added the header field (a) actually did so, and (b) is legitimately adding that header field for this delivery. Given the variety of messaging environments deployed today, consensus appears to be that specifying a particular mechanism for doing so is not appropriate for this memo.
在任何情况下，MUA或筛选器都需要存在一种机制，以验证似乎添加了头字段的主机（a）是否确实添加了头字段，以及（b）是否为此传递合法地添加了头字段。考虑到目前部署的消息传递环境的多样性，共识似乎是指定特定的机制不适合此备忘录。
Mitigation of the forged header field attack can also be accomplished by moving the authentication results data into meta-data associated with the message. In particular, an [SMTP] extension could be established which is used to communicate authentication results from the border MTA to intermediate and delivery MTAs; the latter of these could arrange to store the authentication results as meta-data retrieved and rendered along with the message by an [IMAP] client aware of a similar extension in that protocol. The delivery MTA would be told to trust data via this extension only from MTAs it trusts, and border MTAs would not accept data via this extension from any source. There is no vector in such an arrangement for forgery of authentication data by an outside agent.
还可以通过将身份验证结果数据移动到与消息相关联的元数据中来减轻伪造报头字段攻击。特别是，可以建立[SMTP]扩展，用于将认证结果从边界MTA传送到中间MTA和传递MTA；后者可以安排将身份验证结果存储为元数据，由知道该协议中类似扩展的[IMAP]客户机随消息一起检索和呈现。传递MTA将被告知仅通过此扩展信任来自其信任的MTA的数据，而border MTA不会通过此扩展接受来自任何源的数据。在这种安排中不存在由外部代理伪造认证数据的向量。
Until some form of service for querying the reputation of a sending agent is widely deployed, the existence of this header field indicating a "pass" does not render the message trustworthy. It is possible for an arriving piece of spam or other undesirable mail to pass checks by several of the methods enumerated above (e.g., a piece of spam signed using [DKIM] by the originator of the spam, which might be a spammer or a compromised system). In particular, this issue is not resolved by forged header field removal discussed above.
在广泛部署用于查询发送代理的信誉的某种形式的服务之前，指示“通过”的此头字段的存在不会使消息可信。到达的垃圾邮件或其他不受欢迎的邮件可能通过上述几种方法的检查（例如，由垃圾邮件的发起人使用[DKIM]签名的垃圾邮件，可能是垃圾邮件发送者或受损系统）。特别是，上述伪造报头字段删除无法解决此问题。
Hence, MUAs and downstream filters must take some care with use of this header even after possibly malicious headers are scrubbed.
因此，即使在清除了可能的恶意头之后，MUA和下游过滤器也必须注意使用此头。
Despite the requirements of [MAIL], header fields can sometimes be reordered enroute by intermediate MTAs. The goal of requiring header field addition only at the top of a message is an acknowledgement that some MTAs do reorder header fields, but most do not. Thus, in the general case, there will be some indication of which MTAs (if any) handled the message after the addition of the header field defined here.
尽管有[MAIL]的要求，但中间MTA有时可以对标题字段重新排序。要求仅在邮件顶部添加标题字段的目的是确认某些MTA确实会对标题字段重新排序，但大多数MTA不会。因此，在一般情况下，在添加此处定义的标头字段后，将有一些指示，表明哪些MTA（如果有）处理了消息。
Section 5.5 of [SPF] describes a DNS-based denial-of-service attack for verifiers that attempt DNS-based identity verification of arriving client connections. A verifier wishing to do this check and report this information SHOULD take care not to go to unbounded lengths to resolve "A" and "PTR" queries. MUAs or other filters making use of an "iprev" result specified by this memo SHOULD be aware of the algorithm used by the verifier reporting the result and thus be aware of its limitations.
[SPF]的第5.5节描述了针对尝试对到达的客户端连接进行基于DNS的身份验证的验证器的基于DNS的拒绝服务攻击。希望执行此检查并报告此信息的验证者应注意不要使用无界长度来解决“A”和“PTR”查询。使用本备忘录规定的“iprev”结果的MUA或其他过滤器应了解报告结果的验证者使用的算法，从而了解其局限性。
Failing to follow the instructions of Section 4.2 can result in a denial-of-service attack caused by the generation of [DSN] messages (or equivalent) to addresses that did not send the messages being rejected.
不遵守第4.2节的说明可能导致拒绝服务攻击，这是由于向未发送被拒绝消息的地址生成[DSN]消息（或等效消息）而导致的。
Section 5 describes a procedure for scrubbing headers that may contain forged authentication results about a message. A compliant installation will have to include, at each MTA, a list of other MTAs known to be compliant and trustworthy. Failing to keep this list current as internal infrastructure changes may expose an ADMD to attack.
第5节描述了清除可能包含有关消息的伪造身份验证结果的标头的过程。符合要求的安装必须在每个MTA上包含已知符合要求且值得信赖的其他MTA的列表。无法保持此列表的最新状态，因为内部基础结构更改可能会使ADMD受到攻击。
If an attack becomes known against an authentication method, clearly then the agent verifying that method can be fooled into thinking an inauthentic message is authentic, and thus the value of this header field can be misleading. It follows that any attack against the authentication methods supported by this document (and later amendments to it) is also a security consideration here.
如果已知针对身份验证方法的攻击，那么验证该方法的代理显然会被愚弄，认为不真实的消息是真实的，因此此头字段的值可能会产生误导。因此，对本文档（及其后续修订）支持的身份验证方法的任何攻击也是一个安全问题。
It is possible for an attacker to add an Authentication-Results header field that is extraordinarily large or otherwise malformed in an attempt to discover or exploit weaknesses in header field parsing code. Implementors must thoroughly verify all such header fields received from MTAs and be robust against intentionally as well as unintentionally malformed header fields.
攻击者可能会添加一个非常大或格式不正确的身份验证结果标头字段，试图发现或利用标头字段解析代码中的弱点。实现者必须彻底验证从MTA收到的所有此类头字段，并对有意或无意的错误头字段具有鲁棒性。
An internal MUA or MTA that has been compromised could generate mail with a forged From header field and a forged Authentication-Results header field that endorses it. Although it is clearly a larger concern to have compromised internal machines than it is to prove the value of this header field, this risk can be mitigated by arranging that internal MTAs will remove this header field if it claims to have been added by a trusted border MTA (as described above), yet the [SMTP] connection is not coming from an internal machine known to be running an authorized MTA. However, in such a configuration, legitimate MTAs will have to add this header field when legitimate internal-only messages are generated. This is also covered in Section 5.
已被破坏的内部MUA或MTA可能会生成带有伪造发件人标头字段和签名的伪造身份验证结果标头字段的邮件。尽管与证明此标头字段的价值相比，内部机器受损显然是一个更大的问题，但如果内部MTA声称此标头字段是由受信任的边界MTA（如上所述）添加的，则可以通过安排内部MTA删除此标头字段来减轻此风险，[SMTP]连接不是来自已知正在运行授权MTA的内部计算机。但是，在这种配置中，当生成仅限合法内部消息时，合法MTA必须添加此标头字段。第5节也介绍了这一点。
[MIME] messages may contain attachments of type "message/rfc822", which contain other [MAIL] messages. Such an encapsulated message may also contain an Authentication-Results header field. Although the processing of these is outside of the intended scope of this document (see Section 1.3), some early guidance to MUA developers is appropriate here.
[MIME]消息可能包含类型为“message/rfc822”的附件，其中包含其他[MAIL]消息。这样的封装消息还可以包含认证结果报头字段。尽管这些处理超出了本文件的预期范围（见第1.3节），但此处适用于MUA开发人员的一些早期指导。
Since MTAs are unlikely to strip Authentication-Results header fields after mailbox delivery, MUAs are advised in Section 4.1 to ignore such instances within [MIME] attachments. Moreover, when extracting a message digest to separate mail store messages or other media, such header fields should be removed so that they will never be interpreted improperly by MUAs that might later consume them.
由于MTA不太可能在邮箱传递后剥离身份验证结果标头字段，因此在第4.1节中建议MUA忽略[MIME]附件中的此类实例。此外，当提取消息摘要以分离邮件存储消息或其他媒体时，应删除此类头字段，以便MUA不会对其进行不正确的解释，而MUA随后可能会使用这些头字段。
Although Section 3 of this memo includes explicit support for the "iprev" method, its value as an authentication mechanism is limited. Implementors of both this proposal and agents that use the data it relays are encouraged to become familiar with the issues raised by [DNSOP-REVERSE] when deciding whether or not to include support for "iprev".
尽管本备忘录第3节明确支持“iprev”方法，但其作为身份验证机制的价值是有限的。在决定是否包括对“iprev”的支持时，鼓励本提案的实施者和使用其转发数据的代理熟悉[DNSOP-REVERSE]提出的问题。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[IANA-HEADERS] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[IANA-HEADERS]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[邮件]Resnick，P.，Ed.，“互联网信息格式”，RFC5322，2008年10月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[AUTH] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.
[AUTH]Siemborski，R.和A.Melnikov，“用于身份验证的SMTP服务扩展”，RFC 49542007年7月。
[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
[DKIM]Allman，E.，Callas，J.，Delany，M.，Libbey，M.，Fenton，J.，和M.Thomas，“域密钥识别邮件（DKIM）签名”，RFC 48712007年5月。
[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DNS]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[DNS-IP6]Thomson，S.，Huitema，C.，Ksinant，V.，和M.Souissi，“支持IP版本6的DNS扩展”，RFC 3596，2003年10月。
[DNSOP-REVERSE] Senie, D. and A. Sullivan, "Considerations for the use of DNS Reverse Mapping", Work in Progress, March 2008.
[DNSOP-REVERSE]Senie，D.和A.Sullivan，“使用DNS反向映射的注意事项”，正在进行的工作，2008年3月。
[DOMAINKEYS] Delany, M., "Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, May 2007.
[DOMAINKEYS]Delany，M.，“使用DNS中公布的公钥进行基于域的电子邮件身份验证（DOMAINKEYS）”，RFC 48702007年5月。
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[DSN]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，2003年1月。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", Work in Progress, October 2008.
[EMAIL-ARCH]Crocker，D.，“互联网邮件架构”，正在进行的工作，2008年10月。
[IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[IANA注意事项]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[POP3]迈尔斯，J.和M.罗斯，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[SECURITY] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[安全]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月。
[SENDERID] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, April 2006.
[SENDERID]Lyon，J.和M.Wong，“发件人ID:验证电子邮件”，RFC 4406，2006年4月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006.
[SPF]Wong，M.和W.Schlitt，“授权在电子邮件中使用域的发件人策略框架（SPF），第1版”，RFC 4408，2006年4月。
Implementors of this proposal should be aware that many MUAs are unlikely to be retrofitted to support the new header field and its semantics. In the interests of convenience and quicker adoption, a delivery MTA might want to consider adding things that are processed by existing MUAs in addition to the Authentication-Results header field. One suggestion is to include a Priority header field, on messages that don't already have such a header field, containing a value that reflects the strength of the authentication that was accomplished, e.g., "low" for weak or no authentication, "normal" or "high" for good or strong authentication.
该方案的实施者应该知道，许多MUA不太可能被改装以支持新的头字段及其语义。为了方便和更快地采用，传递MTA可能想考虑添加由现有MUAS处理的除了认证结果报头字段之外的处理。一种建议是在尚未包含此类标头字段的消息上包含优先级标头字段，其中包含反映已完成的身份验证强度的值，例如，“低”表示弱身份验证或无身份验证，“正常”或“高”表示良好或强身份验证。
Some modern MUAs can already filter based on the content of this header field. However, there is keen interest in having MUAs make some kind of graphical representation of this header field's meaning to end users. Until this capability is added, other interim means of conveying authentication results may be necessary while this proposal and its successors are adopted.
一些现代MUA已经可以基于此标头字段的内容进行过滤。然而，让MUA以某种图形形式表示此标题字段对最终用户的意义，这是一种浓厚的兴趣。在添加此功能之前，在采用此方案及其后续方案时，可能需要其他传递认证结果的临时方法。
This section presents some examples of the use of this header field to indicate authentication results.
本节介绍使用此标头字段指示身份验证结果的一些示例。
The trivial case:
小案例：
Received: from mail-router.example.com
(mail-router.example.com [192.0.2.1])
by server.example.org (8.11.6/8.11.6)
with ESMTP id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800
From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Message-Id: <12345.abc@example.com>
Subject: here's a sample
Received: from mail-router.example.com
(mail-router.example.com [192.0.2.1])
by server.example.org (8.11.6/8.11.6)
with ESMTP id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800
From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Message-Id: <12345.abc@example.com>
Subject: here's a sample
Hello! Goodbye!
你好再见
Example 1: Trivial case
例1：小案例
The "Authentication-Results" header field is completely absent. The MUA may make no conclusion about the validity of the message. This could be the case because the message authentication services were not available at the time of delivery, or no service is provided, or the MTA is not in compliance with this specification.
“Authentication Results”标头字段完全不存在。MUA可能不会对消息的有效性做出任何结论。这种情况可能是因为邮件身份验证服务在传递时不可用，或者没有提供任何服务，或者MTA不符合此规范。
A message that was delivered by an MTA that conforms to this specification but provides no actual message authentication service:
由符合此规范但不提供实际邮件身份验证服务的MTA传递的邮件：
Authentication-Results: example.org; none
Received: from mail-router.example.com
(mail-router.example.com [192.0.2.1])
by server.example.org (8.11.6/8.11.6)
with ESMTP id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800
From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Message-Id: <12345.abc@example.com>
Subject: here's a sample
Authentication-Results: example.org; none
Received: from mail-router.example.com
(mail-router.example.com [192.0.2.1])
by server.example.org (8.11.6/8.11.6)
with ESMTP id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800
From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Message-Id: <12345.abc@example.com>
Subject: here's a sample
Hello! Goodbye!
你好再见
Example 2: Header present but no authentication done
示例2：存在标头，但未完成身份验证
The "Authentication-Results" header field is present, showing that the delivering MTA conforms to this specification. It used its DNS domain name as the authserv-id. The presence of "none" (and the absence of any method and result tokens) indicates that no message authentication was done.
“Authentication Results”标头字段存在，表明交付MTA符合此规范。它使用其DNS域名作为authserv-id。如果出现“无”（并且没有任何方法和结果标记），则表明未进行消息身份验证。
A message that was delivered by an MTA that conforms to this specification and applied some message authentication:
由符合此规范并应用了某些邮件身份验证的MTA传递的邮件：
Authentication-Results: example.com;
spf=pass smtp.mailfrom=example.net
Received: from dialup-1-2-3-4.example.net
(dialup-1-2-3-4.example.net [192.0.2.200])
by mail-router.example.com (8.11.6/8.11.6)
with ESMTP id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800
From: sender@example.net
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.com
Message-Id: <12345.abc@example.net>
Subject: here's a sample
Authentication-Results: example.com;
spf=pass smtp.mailfrom=example.net
Received: from dialup-1-2-3-4.example.net
(dialup-1-2-3-4.example.net [192.0.2.200])
by mail-router.example.com (8.11.6/8.11.6)
with ESMTP id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800
From: sender@example.net
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.com
Message-Id: <12345.abc@example.net>
Subject: here's a sample
Hello! Goodbye!
你好再见
Example 3: Header reporting results
示例3：标题报告结果
The "Authentication-Results" header field is present, indicating that the border MTA conforms to this specification. The authserv-id is once again the DNS domain name. Furthermore, the message was authenticated by that MTA via the method specified in [SPF]. Note that since that method cannot authenticate the local-part, it has been omitted from the result's value. The MUA could extract and relay this extra information if desired.
“Authentication Results”标头字段存在，表明边界MTA符合此规范。authserv id再次成为DNS域名。此外，该MTA通过[SPF]中指定的方法对邮件进行了身份验证。请注意，由于该方法无法对本地部分进行身份验证，因此已将其从结果值中忽略。如果需要，MUA可以提取并传递这些额外信息。
A message that was relayed inbound via a single MTA that conforms to this specification and applied three different message authentication checks:
通过符合此规范并应用三种不同邮件身份验证检查的单个MTA中继入站的邮件：
Authentication-Results: example.com;
auth=pass (cram-md5) smtp.auth=sender@example.com;
spf=pass smtp.mailfrom=example.com
Authentication-Results: example.com;
sender-id=pass header.from=example.com
Received: from dialup-1-2-3-4.example.net (8.11.6/8.11.6)
(dialup-1-2-3-4.example.net [192.0.2.200])
by mail-router.example.com (8.11.6/8.11.6)
with ESMTP id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.net
From: sender@example.com
Message-Id: <12345.abc@example.com>
Subject: here's a sample
Authentication-Results: example.com;
auth=pass (cram-md5) smtp.auth=sender@example.com;
spf=pass smtp.mailfrom=example.com
Authentication-Results: example.com;
sender-id=pass header.from=example.com
Received: from dialup-1-2-3-4.example.net (8.11.6/8.11.6)
(dialup-1-2-3-4.example.net [192.0.2.200])
by mail-router.example.com (8.11.6/8.11.6)
with ESMTP id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.net
From: sender@example.com
Message-Id: <12345.abc@example.com>
Subject: here's a sample
Hello! Goodbye!
你好再见
Example 4: Headers reporting results from one MTA
示例4：从一个MTA报告结果的标题
The "Authentication-Results" header field is present, indicating the delivering MTA conforms to this specification. Once again, the receiving DNS domain name is used as the authserv-id. Furthermore, the sender authenticated herself/himself to the MTA via a method specified in [AUTH], and both [SPF] and [SENDERID] checks were done and passed. The MUA could extract and relay this extra information if desired.
“Authentication Results”标头字段存在，表明交付的MTA符合此规范。再次使用接收DNS域名作为authserv-id。此外，发件人通过[AUTH]中指定的方法向MTA验证了自己的身份，并且完成并通过了[SPF]和[SENDERID]检查。如果需要，MUA可以提取并传递这些额外信息。
Two "Authentication-Results" header fields are not required since the same host did all of the checking. The authenticating agent could have consolidated all the results into one header field.
由于同一主机执行了所有检查，因此不需要两个“Authentication Results”头字段。身份验证代理可以将所有结果合并到一个标题字段中。
This example illustrates a scenario in which a remote user on a dialup connection (example.net) sends mail to a border MTA (example.com) using SMTP authentication to prove identity. The dialup provider has been explicitly authorized to relay mail as "example.com" resulting in passes by the SPF and SenderID checks.
此示例演示了一个场景，其中拨号连接（例如.net）上的远程用户使用SMTP身份验证向边界MTA（例如.com）发送邮件以证明身份。拨号提供商已被明确授权将邮件作为“example.com”中继，从而通过SPF和SenderID检查。
A message that was relayed inbound by two different MTAs that conform to this specification and applied multiple message authentication checks:
由两个不同MTA（符合此规范并应用了多个邮件身份验证检查）中继入站的邮件：
Authentication-Results: example.com;
sender-id=hardfail header.from=example.com;
dkim=pass (good signature) header.i=sender@example.com
Received: from mail-router.example.com
(mail-router.example.com [192.0.2.1])
by auth-checker.example.com (8.11.6/8.11.6)
with ESMTP id i7PK0sH7021929;
Fri, Feb 15 2002 17:19:22 -0800
Authentication-Results: example.com;
auth=pass (cram-md5) smtp.auth=sender@example.com;
spf=hardfail smtp.mailfrom=example.com
Received: from dialup-1-2-3-4.example.net
(dialup-1-2-3-4.example.net [192.0.2.200])
by mail-router.example.com (8.11.6/8.11.6)
with ESMTP id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800
DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=example.com;
i=sender@example.com; t=1188964191; c=simple/simple;
h=From:Date:To:Message-Id:Subject;
bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70;
b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.com
Message-Id: <12345.abc@example.com>
Subject: here's a sample
Authentication-Results: example.com;
sender-id=hardfail header.from=example.com;
dkim=pass (good signature) header.i=sender@example.com
Received: from mail-router.example.com
(mail-router.example.com [192.0.2.1])
by auth-checker.example.com (8.11.6/8.11.6)
with ESMTP id i7PK0sH7021929;
Fri, Feb 15 2002 17:19:22 -0800
Authentication-Results: example.com;
auth=pass (cram-md5) smtp.auth=sender@example.com;
spf=hardfail smtp.mailfrom=example.com
Received: from dialup-1-2-3-4.example.net
(dialup-1-2-3-4.example.net [192.0.2.200])
by mail-router.example.com (8.11.6/8.11.6)
with ESMTP id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800
DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=example.com;
i=sender@example.com; t=1188964191; c=simple/simple;
h=From:Date:To:Message-Id:Subject;
bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70;
b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.com
Message-Id: <12345.abc@example.com>
Subject: here's a sample
Hello! Goodbye!
你好再见
Example 5: Headers reporting results from multiple MTAs
示例5：报告多个MTA结果的标题
The "Authentication-Results" header field is present, indicating conformance to this specification. Once again, the authserv-id used is the recipient's DNS domain name. The header field is present twice because two different MTAs in the chain of delivery did authentication tests. The first, "mail-router.example.com" reports that [AUTH] and [SPF] were both used, and [AUTH] passed but [SPF] failed. In the [AUTH] case, additional data is provided in the comment field, which the MUA can choose to render if desired.
“Authentication Results”标头字段存在，表示符合本规范。同样，使用的authserv id是收件人的DNS域名。标头字段出现两次，因为传递链中的两个不同MTA进行了身份验证测试。第一个“mail router.example.com”报告同时使用了[AUTH]和[SPF]，并且[AUTH]通过了，但[SPF]失败。在[AUTH]情况下，注释字段中提供了附加数据，如果需要，MUA可以选择呈现这些数据。
The second MTA, "auth-checker.example.com", reports that it did a [SENDERID] test (which failed) and a [DKIM] test (which passed). Again, additional data about one of the tests is provided as a comment, which the MUA may choose to render.
第二个MTA“auth checker.example.com”报告它进行了[SENDERID]测试（失败）和[DKIM]测试（通过）。同样，关于其中一个测试的附加数据作为注释提供，MUA可以选择呈现。
Since different hosts did the two sets of authentication checks, the header fields cannot be consolidated in this example.
由于不同的主机执行了两组身份验证检查，因此在本例中无法合并头字段。
This example illustrates more typical transmission of mail into "example.com" from a user on a dialup connection "example.net". The user appears to be legitimate as he/she had a valid password allowing authentication at the border MTA using [AUTH]. The [SPF] and [SENDERID] tests failed since "example.com" has not granted "example.net" authority to relay mail on its behalf. However, the [DKIM] test passed because the sending user had a private key matching one of "example.com"'s published public keys and used it to sign the message.
此示例演示了更典型的通过拨号连接“example.net”将邮件传输到“example.com”的过程。该用户似乎是合法的，因为他/她有一个有效的密码，允许在边界MTA使用[AUTH]进行身份验证。[SPF]和[SENDERID]测试失败，因为“example.com”未授予“example.net”代表其中继邮件的权限。但是，[DKIM]测试通过了，因为发送用户有一个私钥与“example.com”发布的公钥之一匹配，并使用它对消息进行签名。
A message that had authentication done at various stages, one of which was outside the receiving ADMD:
在不同阶段进行身份验证的消息，其中一个阶段在接收ADMD之外：
Authentication-Results: example.com;
dkim=pass (good signature) header.i=@mail-router.example.net;
dkim=fail (bad signature) header.i=@newyork.example.com
Received: from mail-router.example.net
(mail-router.example.net [192.0.2.250])
by chicago.example.com (8.11.6/8.11.6)
for <recipient@chicago.example.com>
with ESMTP id i7PK0sH7021929;
Fri, Feb 15 2002 17:19:22 -0800
DKIM-Signature: v=1; a=rsa-sha256; s=furble;
d=mail-router.example.net; t=1188964198; c=relaxed/simple;
h=From:Date:To:Message-Id:Subject:Authentication-Results;
bh=ftA9J6GtX8OpwUECzHnCkRzKw1uk6FNiLfJl5Nmv49E=;
b=oINEO8hgn/gnunsg ... 9n9ODSNFSDij3=
Authentication-Results: example.net;
dkim=pass (good signature) header.i=@newyork.example.com
Received: from smtp.newyork.example.com
(smtp.newyork.example.com [192.0.2.220])
by mail-router.example.net (8.11.6/8.11.6)
with ESMTP id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800
DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=newyork.example.com;
t=1188964191; c=simple/simple;
h=From:Date:To:Message-Id:Subject;
bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=;
b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
From: sender@newyork.example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: meetings@example.net
Message-Id: <12345.abc@newyork.example.com>
Subject: here's a sample
Authentication-Results: example.com;
dkim=pass (good signature) header.i=@mail-router.example.net;
dkim=fail (bad signature) header.i=@newyork.example.com
Received: from mail-router.example.net
(mail-router.example.net [192.0.2.250])
by chicago.example.com (8.11.6/8.11.6)
for <recipient@chicago.example.com>
with ESMTP id i7PK0sH7021929;
Fri, Feb 15 2002 17:19:22 -0800
DKIM-Signature: v=1; a=rsa-sha256; s=furble;
d=mail-router.example.net; t=1188964198; c=relaxed/simple;
h=From:Date:To:Message-Id:Subject:Authentication-Results;
bh=ftA9J6GtX8OpwUECzHnCkRzKw1uk6FNiLfJl5Nmv49E=;
b=oINEO8hgn/gnunsg ... 9n9ODSNFSDij3=
Authentication-Results: example.net;
dkim=pass (good signature) header.i=@newyork.example.com
Received: from smtp.newyork.example.com
(smtp.newyork.example.com [192.0.2.220])
by mail-router.example.net (8.11.6/8.11.6)
with ESMTP id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800
DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=newyork.example.com;
t=1188964191; c=simple/simple;
h=From:Date:To:Message-Id:Subject;
bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=;
b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
From: sender@newyork.example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: meetings@example.net
Message-Id: <12345.abc@newyork.example.com>
Subject: here's a sample
Example 6: Headers reporting results from multiple MTAs in different ADMDs
示例6：报告不同ADMD中多个MTA结果的标头
In this example we see multi-tiered authentication with an extended trust boundary.
在本例中，我们看到了具有扩展信任边界的多层身份验证。
The message was sent from someone at example.com's New York office (newyork.example.com) to a mailing list managed at an intermediary. The message was signed at the origin using [DKIM].
该邮件由example.com纽约办事处（newyork.example.com）的某人发送到中介机构管理的邮件列表。消息是使用[DKIM]在源站签名的。
The message was sent to a mailing list service provider called example.net, which is used by example.com. There, meetings@example.net is expanded to a long list of recipients, one of that is at the Chicago office. In this example, we will assume that the trust boundary for chicago.example.com includes the mailing list server at example.net.
该邮件被发送给一个名为example.net的邮件列表服务提供商，example.com使用该服务。那里meetings@example.net扩展到一个长长的收件人列表，其中一个在芝加哥办事处。在本例中，我们假设chicago.example.com的信任边界包括example.net上的邮件列表服务器。
The mailing list server there first authenticated the message and affixed an Authentication-Results header field indicating such using its DNS domain name for the authserv-id. It then altered the message by affixing some footer text to the body, including some administrivia such as unsubscription instructions. Finally, the mailing list server affixes a second [DKIM] signature and begins distribution of the message.
那里的邮件列表服务器首先对邮件进行了身份验证，并使用其DNS域名为authserv-id附加了一个身份验证结果标题字段，指示这样做。然后，它通过在正文中附加一些页脚文本（包括一些管理员权限，如取消订阅说明）来更改邮件。最后，邮件列表服务器附加第二个[DKIM]签名并开始分发消息。
The border MTA for chicago.example.com explicitly trusts results from mail-router.example.net so that header field is not removed. It performs evaluation of both signatures and determines that the first (most recent) is a "pass" but, because of the aforementioned modifications, the second is a "fail". However, the first signature included the Authentication-Results header added at mail-router.example.net that validated the second signature. Thus, indirectly, it can be determined that the authentications claimed by both signatures are indeed valid.
border MTA for chicago.example.com显式信任mail-router.example.net的结果，因此不会删除标头字段。它执行两个签名的评估，并确定第一个（最近的）是“通过”，但由于上述修改，第二个是“失败”。但是，第一个签名包括在mail-router.example.net上添加的验证结果头，该头验证了第二个签名。因此，可以间接地确定由两个签名声明的认证确实有效。
This proposal is predicated on the idea that authentication (and presumably in the future, reputation) work is typically done by border MTAs rather than MUAs or intermediate MTAs; the latter merely make use of the results determined by the former. Certainly this is not mandatory for participation in electronic mail or message authentication, but the work of this proposal and its deployment to date is based on that model. The assumption satisfies several common ADMD requirements:
这一提议的前提是，认证（以及未来可能的信誉）工作通常由边境MTA而不是MUA或中间MTA完成；后者仅利用前者确定的结果。当然，这对于参与电子邮件或消息认证不是强制性的，但该提案的工作及其迄今为止的部署都基于该模型。该假设满足几个常见的ADMD要求：
1. Service operators prefer to resolve the handling of problem messages as close to the border of the ADMD as possible. This enables, for example, rejections of messages at the SMTP level rather than generating a DSN internally. Thus, doing any of the authentication or reputation work exclusively at the MUA or intermediate MTA renders this desire unattainable.
1. 服务运营商更愿意在尽可能靠近ADMD边界的地方解决问题消息的处理。例如，这允许在SMTP级别拒绝邮件，而不是在内部生成DSN。因此，仅在MUA或中间MTA进行任何身份验证或声誉工作都会使这一愿望无法实现。
2. Border MTAs are more likely to have direct access to external sources of authentication or reputation information since modern MUAs are more likely to be heavily firewalled. Thus, some MUAs might not even be able to complete the task of performing authentication or reputation evaluations without complex proxy configurations or similar burdens.
2. 边境MTA更有可能直接访问外部身份验证或声誉信息源，因为现代MUA更可能受到严重的防火墙攻击。因此，一些MUA甚至可能无法在没有复杂代理配置或类似负担的情况下完成执行身份验证或信誉评估的任务。
3. MUAs rely upon the upstream MTAs within their trust boundaries to make correct (as much as that is possible) evaluations about the message's envelope, header and content. Thus, MUAs don't need to know how to do the work that upstream MTAs do; they only need the results of that work.
3. MUA依靠其信任边界内的上游MTA对消息的信封、标头和内容进行正确（尽可能多）评估。因此，MUA不需要知道如何做上游MTA所做的工作；他们只需要那项工作的结果。
4. Evaluations about the quality of a message, from simple token matching (e.g., a list of preferred DNS domains) to cryptanalysis (e.g., public/private key work), are at least a little bit expensive and thus should be minimized. To that end, performing those tests at the border MTA is far preferred to doing that work at each MUA that handles a message. If an ADMD's environment adheres to common messaging protocols, a reputation query or an authentication check performed by a border MTA would return the same result as the same query performed by an MUA. By contrast, in an environment where the MUA does the work, a message arriving for multiple recipients would thus cause authentication or reputation evaluation to be done more than once for the same message (i.e., at each MUA) causing needless amplification of resource use and creating a possible denial-of-service attack vector.
4. 从简单的令牌匹配（例如，首选DNS域的列表）到密码分析（例如，公钥/私钥工作），对消息质量的评估至少有点昂贵，因此应该最小化。为此，在边界MTA上执行这些测试远比在处理消息的每个MUA上执行这些测试要好。如果ADMD的环境遵循通用消息传递协议，则边界MTA执行的信誉查询或身份验证检查将返回与MUA执行的相同查询相同的结果。相反，在MUA执行该工作的环境中，为多个接收者到达的消息将因此导致对同一消息（即，在每个MUA）进行多次或多个认证或信誉评估，从而导致资源使用的不必要的放大，并产生可能的拒绝服务攻击向量。
5. Minimizing change is good. As new authentication and reputation methods emerge, the list of methods supported by this header field would presumably be extended. If MUAs simply consume the contents of this header field rather than actually attempting to do authentication and/or reputation work, then MUAs only need to learn to parse this header field once; emergence of new methods requires only a configuration change at the MUAs and software changes at the MTAs (which are presumably fewer in number). When choosing to implement these functions in MTAs vs MUAs, the issues of individual flexibility, infrastructure inertia and scale of effort must be considered. It is typically easier to change a single MUA than an MTA because the modification affects fewer users and can be pursued with less care. However, changing many MUAs is more effort than changing a smaller number of MTAs.
5. 尽量减少变化是好的。随着新的身份验证和信誉方法的出现，此标头字段支持的方法列表可能会扩展。如果MUA只是使用这个头字段的内容，而不是实际尝试进行身份验证和/或信誉工作，那么MUA只需要学习解析这个头字段一次；新方法的出现只需要MUA的配置更改和MTA的软件更改（据推测数量较少）。选择在MTA与MUA中实现这些功能时，必须考虑个人灵活性、基础设施惯性和工作规模等问题。通常，更改单个MUA比更改MTA更容易，因为修改影响的用户较少，并且可以不太小心地进行。但是，更改许多MUA比更改少量MTA更费劲。
6. For decisions affecting message delivery and display, assessment based on authentication and reputation is best performed close to the time of message transit, as a message makes its journey toward a user's inbox, not afterwards. DKIM keys and IP address reputations, etc., can change over time or even become invalid, and users can take a long time to read a message once delivered. The value of this work thus degrades, perhaps quickly, once the delivery process has completed. This seriously diminishes the value of this work when done other than at MTAs.
6. 对于影响消息传递和显示的决策，基于身份验证和信誉的评估最好在消息传输时间附近执行，因为消息将向用户的收件箱发送，而不是之后。DKIM密钥和IP地址信誉等可能会随着时间的推移而改变，甚至变得无效，用户在收到消息后可能需要很长时间才能阅读消息。因此，一旦交付过程完成，这项工作的价值可能会迅速下降。当在MTA以外的地方完成时，这会严重降低此工作的价值。
Many operational choices are possible within an ADMD, including the venue for performing authentication and/or reputation assessment. The current specification does not dictate any of those choices. Rather, it facilitates those cases in which information produced by one stage of analysis needs to be transported with the message to the next stage.
ADMD中有许多操作选择，包括执行身份验证和/或声誉评估的场所。当前的规范没有规定任何这些选择。相反，它有助于将一个分析阶段生成的信息与消息一起传输到下一个阶段。
Acknowledgements
致谢
The author wishes to acknowledge the following for their review and constructive criticism of this proposal: Eric Allman, Mark Delany, Victor Duchovni, Frank Ellermann, Jim Fenton, Philip Guenther, Tony Hansen, Paul Hoffman, Scott Kitterman, Eliot Lear, John Levine, Miles Libbey, Charles Lindsey, Alexey Melnikov, Douglas Otis, Juan Altmayer Pizzorno, Michael Thomas, and Kazu Yamamoto.
作者希望感谢以下各方对本提案的审查和建设性批评：埃里克·奥尔曼、马克·德拉尼、维克多·杜科夫尼、弗兰克·埃勒曼、吉姆·芬顿、菲利普·根瑟、托尼·汉森、保罗·霍夫曼、斯科特·基特曼、艾略特·李尔、约翰·莱文、迈尔斯·利比、查尔斯·林赛、亚历克赛·梅尔尼科夫、道格拉斯·奥蒂斯、，胡安·阿尔特迈耶·皮佐诺、迈克尔·托马斯和山本和津。
Special thanks to Dave Crocker and S. Moonesamy for their logistical support, and feedback on and contributions to the numerous proposed edits throughout the lifetime of this work.
特别感谢戴夫·克罗克（Dave Crocker）和S.穆内萨米（S.Moonesay）提供的后勤支持，以及在这部作品的整个生命周期中对众多拟议编辑的反馈和贡献。
Author's Address
作者地址
Murray S. Kucherawy Sendmail, Inc. 6475 Christie Ave., Suite 350 Emeryville, CA 94608 US
Murray S.Kucherawy Sendmail，Inc.美国加利福尼亚州埃默里维尔克里斯蒂大道6475号350室，邮编94608
Phone: +1 510 594 5400
EMail: msk+ietf@sendmail.com
Phone: +1 510 594 5400
EMail: msk+ietf@sendmail.com