Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 7601 August 2015
Obsoletes: 7001, 7410
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 7601 August 2015
Obsoletes: 7001, 7410
Category: Standards Track
ISSN: 2070-1721
Message Header Field for Indicating Message Authentication Status
用于指示消息身份验证状态的消息头字段
Abstract
摘要
This document specifies a message header field called Authentication-Results 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), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions.
此文档指定了一个名为“身份验证结果”的消息头字段，用于电子邮件，以指示消息身份验证工作的结果。任何接收方软件，如邮件过滤器或邮件用户代理（MUA），都可以使用此标题字段以方便且有意义的方式将该信息转发给用户，或做出排序和过滤决策。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7601.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7601.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Trust Boundary . . . . . . . . . . . . . . . . . . . . . 5
1.3. Processing Scope . . . . . . . . . . . . . . . . . . . . 6
1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 6
1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
1.5.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 6
1.5.2. Security . . . . . . . . . . . . . . . . . . . . . . 7
1.5.3. Email Architecture . . . . . . . . . . . . . . . . . 7
1.5.4. Other Terms . . . . . . . . . . . . . . . . . . . . . 8
1.6. Trust Environment . . . . . . . . . . . . . . . . . . . . 8
2. Definition and Format of the Header Field . . . . . . . . . . 9
2.1. General Description . . . . . . . . . . . . . . . . . . . 9
2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 10
2.3. Property Types (ptypes) and Properties . . . . . . . . . 12
2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . 13
2.5. Authentication Identifier Field . . . . . . . . . . . . . 14
2.6. Version Tokens . . . . . . . . . . . . . . . . . . . . . 15
2.7. Defined Methods and Result Values . . . . . . . . . . . . 15
2.7.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 16
2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 18
2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 20
2.7.5. Other Registered Codes . . . . . . . . . . . . . . . 21
2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 21
2.7.7. Extension Result Codes . . . . . . . . . . . . . . . 22
3. The "iprev" Authentication Method . . . . . . . . . . . . . . 22
4. Adding the Header Field to a Message . . . . . . . . . . . . 23
4.1. Header Field Position and Interpretation . . . . . . . . 25
4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . 26
5. Removing Existing Header Fields . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6.1. The Authentication-Results Header Field . . . . . . . . . 27
6.2. "Email Authentication Methods" Registry Description . . . 28
6.3. "Email Authentication Methods" Registry Update . . . . . 29
6.4. "Email Authentication Property Types" Registry . . . . . 30
6.5. "Email Authentication Result Names" Description . . . . . 31
6.6. "Email Authentication Result Names" Update . . . . . . . 32
6.7. SMTP Enhanced Status Codes . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . 33
7.2. Misleading Results . . . . . . . . . . . . . . . . . . . 35
7.3. Header Field Position . . . . . . . . . . . . . . . . . . 35
7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . 35
7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 36
7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . 36
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Trust Boundary . . . . . . . . . . . . . . . . . . . . . 5
1.3. Processing Scope . . . . . . . . . . . . . . . . . . . . 6
1.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 6
1.5. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
1.5.1. Key Words . . . . . . . . . . . . . . . . . . . . . . 6
1.5.2. Security . . . . . . . . . . . . . . . . . . . . . . 7
1.5.3. Email Architecture . . . . . . . . . . . . . . . . . 7
1.5.4. Other Terms . . . . . . . . . . . . . . . . . . . . . 8
1.6. Trust Environment . . . . . . . . . . . . . . . . . . . . 8
2. Definition and Format of the Header Field . . . . . . . . . . 9
2.1. General Description . . . . . . . . . . . . . . . . . . . 9
2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 10
2.3. Property Types (ptypes) and Properties . . . . . . . . . 12
2.4. The "policy" ptype . . . . . . . . . . . . . . . . . . . 13
2.5. Authentication Identifier Field . . . . . . . . . . . . . 14
2.6. Version Tokens . . . . . . . . . . . . . . . . . . . . . 15
2.7. Defined Methods and Result Values . . . . . . . . . . . . 15
2.7.1. DKIM and DomainKeys . . . . . . . . . . . . . . . . . 16
2.7.2. SPF and Sender ID . . . . . . . . . . . . . . . . . . 18
2.7.3. "iprev" . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.4. SMTP AUTH . . . . . . . . . . . . . . . . . . . . . . 20
2.7.5. Other Registered Codes . . . . . . . . . . . . . . . 21
2.7.6. Extension Methods . . . . . . . . . . . . . . . . . . 21
2.7.7. Extension Result Codes . . . . . . . . . . . . . . . 22
3. The "iprev" Authentication Method . . . . . . . . . . . . . . 22
4. Adding the Header Field to a Message . . . . . . . . . . . . 23
4.1. Header Field Position and Interpretation . . . . . . . . 25
4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . 26
5. Removing Existing Header Fields . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6.1. The Authentication-Results Header Field . . . . . . . . . 27
6.2. "Email Authentication Methods" Registry Description . . . 28
6.3. "Email Authentication Methods" Registry Update . . . . . 29
6.4. "Email Authentication Property Types" Registry . . . . . 30
6.5. "Email Authentication Result Names" Description . . . . . 31
6.6. "Email Authentication Result Names" Update . . . . . . . 32
6.7. SMTP Enhanced Status Codes . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . 33
7.2. Misleading Results . . . . . . . . . . . . . . . . . . . 35
7.3. Header Field Position . . . . . . . . . . . . . . . . . . 35
7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . 35
7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 36
7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . 36
7.7. Attacks against Authentication Methods . . . . . . . . . 36
7.8. Intentionally Malformed Header Fields . . . . . . . . . . 36
7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . 36
7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . 37
7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 37
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. Normative References . . . . . . . . . . . . . . . . . . 37
8.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . 42
Appendix B. Authentication-Results Examples . . . . . . . . . . 42
B.1. Trivial Case; Header Field Not Present . . . . . . . . . 42
B.2. Nearly Trivial Case; Service Provided, but No
Authentication Done . . . . . . . . . . . . . . . . . . . 43
B.3. Service Provided, Authentication Done . . . . . . . . . . 44
B.4. Service Provided, Several Authentications Done, Single
MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
B.5. Service Provided, Several Authentications Done, Different
MTAs . . . . . . . . . . . . . . . . . . . . . . . . . . 46
B.6. Service Provided, Multi-tiered Authentication Done . . . 48
B.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 49
Appendix C. Operational Considerations about Message
Authentication . . . . . . . . . . . . . . . . . . . 50
Appendix D. Changes since RFC 7001 . . . . . . . . . . . . . . . 51
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 53
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 53
7.7. Attacks against Authentication Methods . . . . . . . . . 36
7.8. Intentionally Malformed Header Fields . . . . . . . . . . 36
7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . 36
7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . 37
7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 37
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. Normative References . . . . . . . . . . . . . . . . . . 37
8.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Legacy MUAs . . . . . . . . . . . . . . . . . . . . 42
Appendix B. Authentication-Results Examples . . . . . . . . . . 42
B.1. Trivial Case; Header Field Not Present . . . . . . . . . 42
B.2. Nearly Trivial Case; Service Provided, but No
Authentication Done . . . . . . . . . . . . . . . . . . . 43
B.3. Service Provided, Authentication Done . . . . . . . . . . 44
B.4. Service Provided, Several Authentications Done, Single
MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
B.5. Service Provided, Several Authentications Done, Different
MTAs . . . . . . . . . . . . . . . . . . . . . . . . . . 46
B.6. Service Provided, Multi-tiered Authentication Done . . . 48
B.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 49
Appendix C. Operational Considerations about Message
Authentication . . . . . . . . . . . . . . . . . . . 50
Appendix D. Changes since RFC 7001 . . . . . . . . . . . . . . . 51
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 53
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 53
This document describes a header field called Authentication-Results for electronic mail messages that presents the results of a message authentication effort in a machine-readable format. The intent of the header field 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 safety and integrity of its content.
本文档描述了一个名为“电子邮件验证结果”的标题字段，该字段以机器可读的格式显示消息验证工作的结果。标题字段的目的是在使用消息身份验证机制时创建一个收集此类数据的位置，以便邮件用户代理（MUA）和下游过滤器可以做出过滤决定和/或向用户提供关于消息来源的有效性及其内容的安全性和完整性的建议。
This document revises the original definition found in [RFC5451] based upon various authentication protocols in current use and incorporates errata logged since the publication of the original specification.
本文件根据当前使用的各种认证协议修改了[RFC5451]中的原始定义，并纳入了自原始规范发布以来记录的勘误表。
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 such data or render it in a human-usable form.
最终用户不应是此标题字段的直接使用者。此标头字段供程序使用，这些程序随后将使用此类数据或将其呈现为人类可用的形式。
This document specifies the format of this header field and discusses the implications of its presence or absence. However, it does not discuss how the data contained in the header field ought to be used, such as what filtering decisions are appropriate or how an MUA might render those results, as these are local policy and/or user interface design questions that are not appropriate for this document.
本文档指定此标题字段的格式，并讨论其存在或不存在的含义。但是，它没有讨论应该如何使用标题字段中包含的数据，例如什么过滤决策是合适的，或者MUA如何呈现这些结果，因为这些是本地策略和/或用户界面设计问题，不适用于本文档。
At the time of publication of this document, the following are published email authentication methods:
在本文档发布时，以下是已发布的电子邮件身份验证方法：
o Author Domain Signing Practices ([ADSP]) (Historic)
o 作者域签名实践（[ADSP]）（历史）
o SMTP Service Extension for Authentication ([AUTH])
o 用于身份验证的SMTP服务扩展（[AUTH]）
o DomainKeys Identified Mail Signatures ([DKIM])
o 域密钥识别邮件签名（[DKIM]）
o Domain-based Message Authentication, Reporting and Conformance ([DMARC])
o 基于域的消息身份验证、报告和一致性（[DMARC]）
o Sender Policy Framework ([SPF])
o 发件人策略框架（[SPF]）
o reverse IP address name validation ("iprev", defined in Section 3)
o 反向IP地址名称验证（“iprev”，定义见第3节）
o Require-Recipient-Valid-Since Header Field and SMTP Service Extension ([RRVS])
o 要求收件人有效，因为标头字段和SMTP服务扩展名（[RRVS]）
o S/MIME Signature Verification ([SMIME-REG])
o S/MIME签名验证（[SMIME-REG]）
o Vouch By Reference ([VBR])
o 通过引用进行担保（[VBR]）
o DomainKeys ([DOMAINKEYS]) (Historic)
o DomainKeys（[DomainKeys]）（历史）
o Sender ID ([SENDERID]) (Experimental)
o 发送者ID（[SENDERID]）（实验性）
There exist registries for tokens used within this header field that refer to the specifications listed above. Section 6 describes the registries and their contents and specifies the process by which entries are added or updated. It also updates the existing contents to match the current states of these specifications.
此标头字段中使用的令牌存在引用上述规范的注册表。第6节描述了注册表及其内容，并指定了添加或更新条目的过程。它还更新现有内容以匹配这些规范的当前状态。
This specification is not intended to be restricted to domain-based authentication schemes, but the existing schemes in that family have proven to be a good starting point for implementations. The goal is to give current and future authentication schemes a common framework within which to deliver their results to downstream agents and discourage the creation of unique header fields for each.
本规范并不限于基于域的身份验证方案，但该系列中的现有方案已被证明是实现的良好起点。其目标是为当前和未来的身份验证方案提供一个通用框架，在该框架内，将其结果交付给下游代理，并阻止为每个代理创建唯一的头字段。
Although SPF defined a header field called "Received-SPF" and the historic 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. In addition, many SPF implementations have adopted the header field specified here at least as an option, and DomainKeys has been obsoleted by DKIM.
尽管SPF为此定义了一个称为“Received SPF”的头字段，而历史域密钥则定义了一个称为“DomainKey Status”的头字段，但这些头字段仅用于传输各自的结果，因此不足以满足下面列举的要求。此外，许多SPF实现都采用了此处指定的头字段（至少作为一个选项），并且域密钥已被DKIM淘汰。
The header field defined in this document is expected to serve several purposes:
本文档中定义的标题字段预期有多种用途：
1. Convey the results of various message authentication checks, which are applied by upstream filters and Mail Transfer Agents (MTAs) and then passed to MUAs and downstream filters within the same "trust domain". Such agents might wish to render those results to end users or to use those 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 does not mean its contents are valid. Rather, the header field is reporting assertions made by one or more authentication schemes (supposedly) applied somewhere upstream. For an MUA or downstream filter to treat the assertions as actually valid, there must be an assessment of the trust relationship among such agents, the validating MTA, and the mechanism for conveying the information.
特别是，仅此标题字段的存在并不意味着其内容有效。相反，header字段报告由一个或多个（假定）应用于上游某处的身份验证方案所做的断言。要使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 producer of the header field to the consumer must occur within a context that permits the consumer to treat assertions by the producer as being reliable and accurate (trustworthy). 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. Services that are internal -- within the trust boundary -- are provided by the ADMD's infrastructure for its users. Those that are external are outside of the authority of the ADMD. By this definition, hosts that are within a trust boundary are subject to the ADMD's authority and policies, independent of their physical placement or their physical operation. For example, a host within a trust boundary might actually be operated by a remote service provider and reside physically within its data center.
因此，本文件将“信托边界”定义为“外部”和“内部”实体之间的界限。在信任边界内的内部服务由ADMD的基础设施为其用户提供。外部的不属于ADMD的权限范围。根据此定义，位于信任边界内的主机受ADMD权限和策略的约束，与它们的物理位置或物理操作无关。例如，信任边界内的主机实际上可能由远程服务提供商操作，并实际驻留在其数据中心内。
It is possible for a message to be evaluated inside a trust boundary but then depart and re-enter the trust boundary. An example might be a forwarded message such as a message/rfc822 attachment (see Multipurpose Internet Mail Extensions [MIME]) or one that is part of a multipart/digest. The details reported by this field cannot be trusted in that case. Thus, this field found within one of those media types is typically ignored.
消息可以在信任边界内进行评估，但随后离开并重新进入信任边界。例如，转发的消息，例如消息/rfc822附件（请参阅多用途Internet邮件扩展[MIME]），或者是多部分/摘要的一部分。在这种情况下，此字段报告的详细信息不可信。因此，在这些媒体类型之一中找到的此字段通常被忽略。
The content of this header field is meant to convey to message consumers that authentication work on the message was already done within its trust boundary, and those results are being presented. It is not intended to provide message parameters to consumers so that they can perform authentication protocols on their own.
此标头字段的内容旨在向消息使用者传达消息的身份验证工作已经在其信任边界内完成，并且正在显示这些结果。它的目的不是向使用者提供消息参数，以便他们能够自己执行身份验证协议。
This document establishes no new requirements on existing protocols or servers.
本文件未对现有协议或服务器提出任何新要求。
In particular, this document establishes no requirement on MTAs to reject or filter arriving messages that do not pass authentication checks. The data conveyed by the specified header field's contents are for the information of MUAs and filters and are to 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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
"Guidelines for Writing RFC Text on Security Considerations" ([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:
“关于安全注意事项的RFC文本编写指南”（[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 Sender ID 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 Simple Mail Transfer Protocol ([SMTP]) client to relay messages on its behalf, but they do not actually validate any other property of the message itself. By contrast, DKIM is agnostic as to the routing of a message but uses cryptographic signatures to authenticate agents, assign (some) responsibility for the message (which implies authorization), and ensure that the listed portions of the message were 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), other handling agents, or any combination.
例如：SPF和发件人ID是授权机制，因为它们表示的结果表明，显然发送邮件的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 any MTA that is not a delivery MTA and is also not the first MTA to handle the message.
o “中间MTA”是指不是传递MTA且不是处理邮件的第一个MTA的任何MTA。
The following diagram illustrates the flow of mail among these defined components. See Internet Mail Architecture [EMAIL-ARCH] for further discussion on general email system architecture, which includes detailed descriptions of these components, and Appendix C of this document for discussion about the common aspects of email authentication in current environments.
下图说明了这些已定义组件之间的邮件流。有关通用电子邮件系统体系结构（包括这些组件的详细说明）的进一步讨论，请参见Internet邮件体系结构[EMAIL-ARCH]，有关当前环境中电子邮件身份验证的常见方面的讨论，请参见本文档附录C。
+-----+ +-----+ +------------+
| 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" might 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.
通常，假定应用邮件身份验证方案的工作发生在边界MTA或传递MTA上。编写本规范时要牢记这一假设。但是，在某些站点上，整个邮件基础结构由一台主机组成。在这种情况下，“border MTA”和“delivery MTA”等术语很可能适用于同一台机器，甚至是同一个代理。某些邮件身份验证测试也可能在中间MTA上进行。尽管本文件未具体描述此类情况，但并不排除此类情况。
In this document, the term "producer" refers to any component that adds this header field to messages it is handling, and "consumer" refers to any component that identifies, extracts, and parses the header field to use as part of a handling decision.
在本文档中，术语“生产者”是指将此头字段添加到其正在处理的消息中的任何组件，“消费者”是指识别、提取和解析头字段以用作处理决策一部分的任何组件。
This header field permits one or more message validation mechanisms to communicate 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
此标头字段允许一个或多个消息验证机制将输出传递给一个或多个单独的评估机制。这些机制在定义管理管理域（ADMD）的统一信任边界内运行。ADMD包含一个或多个执行验证并生成标题字段的实体
and one or more that consume it for some type of assessment. The field often contains no integrity or validation mechanism of its own, so its presence must be trusted implicitly. Hence, valid use of the header field requires removing any occurrences of it that are present when the message enters the ADMD. This ensures that later occurrences have been added within the trust boundary of the ADMD.
以及一个或多个使用它进行某种评估的人。字段通常不包含其自身的完整性或验证机制，因此必须隐式信任其存在。因此，要有效使用标头字段，需要删除消息进入ADMD时出现的任何标头字段。这可确保在ADMD的信任边界内添加了后续事件。
The authserv-id token defined in Section 2.2 can be used to reference 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 in later sections of this document.
第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 header field specified here is called Authentication-Results. It is a Structured Header Field as defined in Internet Message Format ([MAIL]), and thus all of the related definitions in that document apply.
此处指定的标头字段称为身份验证结果。它是Internet消息格式（[MAIL]）中定义的结构化标题字段，因此该文档中的所有相关定义都适用。
This header field is 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 is therefore considered to be a trace field as defined in [MAIL], and thus all of the related definitions in that document apply.
此标头字段添加在邮件顶部，因为它传输执行身份验证检查的MTA，因此可以推断检查完成的距离。因此，它被认为是[MAIL]中定义的跟踪字段，因此该文档中的所有相关定义均适用。
The value of the header field (after removing comments) consists of an authentication identifier, an optional version, and then a series of statements and supporting data. The statements are of the form "method=result" and indicate which authentication method(s) were applied and their respective results. For each such statement, the supporting data can include a "reason" string and one or more "property=value" statements indicating which message properties were evaluated to reach that conclusion.
标题字段的值（删除注释后）由身份验证标识符、可选版本、以及一系列语句和支持数据组成。声明的形式为“方法=结果”，并指出应用了哪些认证方法及其各自的结果。对于每个这样的语句，支持数据可以包括一个“原因”字符串和一个或多个“property=value”语句，这些语句指示对哪些消息属性进行了评估以得出该结论。
The header field can appear more than once in a single message, more than one result can be represented in a single header field, or a combination of these can be applied.
标题字段可以在单个消息中出现多次，可以在单个标题字段中表示多个结果，或者可以应用这些结果的组合。
Formally, the header field is specified as follows using Augmented Backus-Naur Form ([ABNF]):
形式上，使用扩展的Backus Naur表单（[ABNF]）指定标题字段如下：
authres-header = "Authentication-Results:" [CFWS] authserv-id [ CFWS authres-version ] ( no-result / 1*resinfo ) [CFWS] CRLF
authres header=“身份验证结果：”[CFWS]authserv id[CFWS-authres-version]（无结果/1*resinfo）[CFWS]CRLF
authserv-id = value ; see below for a description of this element
authserv id=值；有关此元素的说明，请参见下文
authres-version = 1*DIGIT [CFWS]
; indicates which version of this specification is in use;
; this specification is version "1", and the absence of a
; version implies this version of the specification
authres-version = 1*DIGIT [CFWS]
; indicates which version of this specification is in use;
; this specification is version "1", and the absence of a
; version implies this version of the specification
no-result = [CFWS] ";" [CFWS] "none"
; the special case of "none" is used to indicate that no
; message authentication was performed
no-result = [CFWS] ";" [CFWS] "none"
; the special case of "none" is used to indicate that no
; message authentication was performed
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
; and what its output was
methodspec = [CFWS] method [CFWS] "=" [CFWS] result
; indicates which authentication method was evaluated
; and what its output was
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
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
method = Keyword [ [CFWS] "/" [CFWS] method-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 = Keyword [ [CFWS] "/" [CFWS] method-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-version = 1*DIGIT [CFWS]
; indicates which version of the method specification is
; in use, corresponding to the matching entry in the IANA
; "Email Authentication Methods" registry; a value of "1"
; is assumed if this version string is absent
method-version = 1*DIGIT [CFWS]
; indicates which version of the method specification is
; in use, corresponding to the matching entry in the IANA
; "Email Authentication Methods" registry; a value of "1"
; is assumed if this version string is absent
result = Keyword ; indicates the results of the attempt to authenticate ; the message; see below for details
结果=关键字；指示尝试验证的结果；信息；详情见下文
ptype = Keyword
; indicates whether the property being evaluated was
; a parameter to an [SMTP] command, was a value taken
; from a message header field, was some property of
; the message body, or was some other property evaluated by
; the receiving MTA; expected to be one of the "property
; types" explicitly defined as valid, or an extension
; ptype, as defined below
ptype = Keyword
; indicates whether the property being evaluated was
; a parameter to an [SMTP] command, was a value taken
; from a message header field, was some property of
; the message body, or was some other property evaluated by
; the receiving MTA; expected to be one of the "property
; types" explicitly defined as valid, or an extension
; ptype, as defined below
property = special-smtp-verb / Keyword
; indicates more specifically than "ptype" what the
; source of the evaluated property is; the exact meaning
; is specific to the method whose result is being reported
; and is defined more clearly below
property = special-smtp-verb / Keyword
; indicates more specifically than "ptype" what the
; source of the evaluated property is; the exact meaning
; is specific to the method whose result is being reported
; and is defined more clearly below
special-smtp-verb = "mailfrom" / "rcptto"
; special cases of [SMTP] commands that are made up
; of multiple words
special-smtp-verb = "mailfrom" / "rcptto"
; special cases of [SMTP] commands that are made up
; of multiple words
pvalue = [CFWS] ( value / [ [ local-part ] "@" ] domain-name )
[CFWS]
; the value extracted from the message property defined
; by the "ptype.property" construction
pvalue = [CFWS] ( value / [ [ local-part ] "@" ] domain-name )
[CFWS]
; the value extracted from the message property defined
; by the "ptype.property" construction
"local-part" is defined in Section 3.4.1 of [MAIL], and "CFWS" is defined in Section 3.2.2 of [MAIL].
“本地部分”的定义见[邮件]第3.4.1节，“CFWS”的定义见[邮件]第3.2.2节。
"Keyword" is defined in Section 4.1.2 of [SMTP].
[SMTP]第4.1.2节定义了“关键字”。
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 "Keyword" used in "result" above is further constrained by the necessity of being enumerated in Section 2.7.
上述“结果”中使用的“关键字”还受到第2.7节中列举的必要性的限制。
See Section 2.5 for a description of the authserv-id element.
有关authserv id元素的描述，请参见第2.5节。
If the value portion of a "pvalue" construction identifies something intended to be an email identity, then it MUST use the right hand portion of that ABNF definition.
如果“pvalue”构造的值部分标识了某个邮件标识，那么它必须使用ABNF定义的右侧部分。
The list of commands eligible for use with the "smtp" ptype can be found in Section 4.1 of [SMTP].
可以在[smtp]的第4.1节中找到符合“smtp”ptype使用条件的命令列表。
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”。
Where an SMTP command name is being reported as a "property", the agent generating the header field represents that command by converting it to lowercase and dropping any spaces (e.g., "MAIL FROM" becomes "mailfrom", "RCPT TO" becomes "rcptto", etc.).
当SMTP命令名被报告为“属性”时，生成标头字段的代理通过将其转换为小写并删除任何空格来表示该命令（例如，“邮件发件人”变为“邮件发件人”，“RCPT to”变为“rcptto”，等等）。
A "ptype" value of "policy" indicates a policy decision about the message not specific to a property of the message that could be extracted. See Section 2.4 for details.
“policy”的“ptype”值表示有关消息的策略决策，该决策不特定于可提取消息的属性。详见第2.4节。
Examples of complete messages using this header field can be found in Appendix B.
使用此标题字段的完整消息示例见附录B。
The "ptype" in the ABNF above indicates the general type of property being described by the result being reported, upon which the reported result was based. Coupled with the "property", which is more specific, they indicate from which particular part of the message the reported data were extracted.
上述ABNF中的“ptype”表示报告结果所描述的属性的一般类型，报告结果基于该类型。再加上更具体的“属性”，它们指示从消息的哪个特定部分提取报告的数据。
Combinations of ptypes and properties are registered and described in the "Email Authentication Methods" registry, coupled with the authentication methods with which they are used. This is further described in Section 6.
ptype和属性的组合在“电子邮件身份验证方法”注册表中注册和描述，并与使用它们的身份验证方法结合使用。第6节对此作了进一步说明。
Legal values of "ptype" are as defined in the IANA "Email Authentication Property Types" registry, created by [RFC7410]. The initial values and what they typically indicate are as follows, based on [RFC7001]:
“ptype”的合法值在[RFC7410]创建的IANA“电子邮件身份验证属性类型”注册表中定义。根据[RFC7001]，初始值及其通常指示如下：
body: Information that was extracted from the body of the message. This might be an arbitrary string of bytes, a hash of a string of bytes, a Uniform Resource Identifier, or some other content of interest. The "property" is an indication of where within the message body the extracted content was found, and can indicate an offset, identify a MIME part, etc.
正文：从消息正文中提取的信息。这可能是一个任意的字节字符串、一个字节字符串的散列、一个统一的资源标识符或其他感兴趣的内容。“属性”表示提取内容在消息体中的位置，可以表示偏移量、标识MIME部分等。
header: Indicates information that was extracted from the header of the message. This might be the value of a header field or some portion of a header field. The "property" gives a more precise indication of the place in the header from which the extraction took place.
header：表示从消息头提取的信息。这可能是标题字段的值或标题字段的某些部分。“属性”给出了更精确的指示，说明了提取发生在标题中的位置。
policy: A local policy mechanism was applied that augments or overrides the result returned by the authentication mechanism. (See Section 2.4.)
策略：应用了一个本地策略机制，用于增强或覆盖身份验证机制返回的结果。（见第2.4节。）
smtp: Indicates information that was extracted from an SMTP command that was used to relay the message. The "property" indicates which SMTP command included the extracted content as a parameter.
smtp：表示从用于中继邮件的smtp命令中提取的信息。“属性”指示哪个SMTP命令将提取的内容作为参数包含。
Results reported using unknown ptypes MUST NOT be used in making handling decisions. They can be safely ignored by consumers.
使用未知类型报告的结果不得用于做出处理决策。消费者可以放心地忽略它们。
Entries in the "Email Authentication Methods" registry can define properties that deviate from these definitions when appropriate. Such deviations need to be clear in the registry and/or in the defining document. See Section 2.7.1 for an example.
“电子邮件身份验证方法”注册表中的条目可以在适当时定义与这些定义不同的属性。此类偏差需要在注册表和/或定义文件中明确。示例见第2.7.1节。
A special ptype value of "policy" is also defined. This ptype is provided to indicate that some local policy mechanism was applied that augments or even replaces (i.e., overrides) the result returned by the authentication mechanism. The property and value in this case identify the local policy that was applied and the result it returned.
还定义了一个特殊的ptype值“policy”。提供此ptype是为了指示应用了某些本地策略机制，以增强或甚至替换（即覆盖）身份验证机制返回的结果。本例中的属性和值标识应用的本地策略及其返回的结果。
For example, a DKIM signature is not required to include the Subject header field in the set of fields that are signed. An ADMD receiving such a message might decide that such a signature is unacceptable, even if it passes, because the content of the Subject header field could be altered post-signing without invalidating the signature. Such an ADMD could replace the DKIM "pass" result with a "policy" result and then also include the following in the corresponding Authentication-Result field:
例如，DKIM签名不需要在签名的字段集中包含主题标题字段。接收此类消息的ADMD可能会认为此类签名是不可接受的，即使它通过了，因为在签名后可以更改主题标头字段的内容，而不会使签名无效。这样的ADMD可以用“策略”结果替换DKIM“通过”结果，然后在相应的身份验证结果字段中还包括以下内容：
... dkim=fail policy.dkim-rules=unsigned-subject ...
... dkim=失败策略。dkim规则=未签名主题。。。
In this case, the property is "dkim-rules", indicating some local check by that name took place and that check returned a result of "unsigned-subject". These are arbitrary names selected by (and presumably used within) the ADMD making use of them, so they are not normally registered with IANA or otherwise specified apart from setting syntax restrictions that allow for easy parsing within the rest of the header field.
在本例中，属性是“dkim rules”，表示使用该名称进行了一些本地检查，该检查返回了“unsigned subject”的结果。这些名称是ADMD使用它们选择的任意名称（可能在ADMD中使用），因此通常不会向IANA注册这些名称，也不会指定其他名称，除非设置语法限制，以便在标题字段的其余部分中轻松解析。
This ptype existed in the original specification for this header field, but without a complete description or example of intended use.
此ptype存在于该标题字段的原始规范中，但没有完整的说明或预期用途示例。
As a result, it has not seen any practical use to date that matches its intended purpose. These added details are provided to guide implementers toward proper use.
因此，迄今为止，它还没有看到任何与预期用途相符的实际用途。提供这些添加的细节是为了指导实现者正确使用。
Every Authentication-Results header field has an authentication service identifier field (authserv-id above). Specifically, this is any string intended to identify the authentication service within the ADMD that conducted authentication checks on the message. This identifier is intended to be machine-readable and not necessarily meaningful to users.
每个身份验证结果标头字段都有一个身份验证服务标识符字段（上面的authserv id）。具体而言，这是用于标识ADMD中对消息执行身份验证检查的身份验证服务的任何字符串。该标识符是机器可读的，不一定对用户有意义。
Since agents consuming this field will use this identifier to determine whether its contents are of interest (and are safe to use), the uniqueness of the identifier MUST be guaranteed by the ADMD that generates it and MUST pertain to that ADMD. MUAs or downstream filters SHOULD use this identifier to determine whether or not the data contained in an Authentication-Results header field ought to be used or ignored.
由于使用此字段的代理将使用此标识符来确定其内容是否感兴趣（并且可以安全使用），因此生成该标识符的ADMD必须保证该标识符的唯一性，并且该标识符必须属于该ADMD。MUA或下游过滤器应使用此标识符来确定是否应使用或忽略身份验证结果标头字段中包含的数据。
For simplicity and scalability, the authentication service identifier SHOULD be a common token used throughout the ADMD. Common practice is to use the DNS domain name used by or within that ADMD, sometimes called the "organizational domain", but this is not strictly necessary.
为了简单性和可伸缩性，身份验证服务标识符应该是整个ADMD中使用的通用令牌。通常的做法是使用该ADMD使用的DNS域名，有时称为“组织域”，但这并不是严格必要的。
For tracing and debugging purposes, the authentication identifier can instead be the specific hostname of the MTA performing the authentication check whose result is being reported. Moreover, some implementations define a substructure to the identifier; these are outside of the scope of this specification.
出于跟踪和调试目的，身份验证标识符可以改为执行身份验证检查并报告其结果的MTA的特定主机名。此外，一些实现定义了标识符的子结构；这些不在本规范的范围内。
Note, however, that using a local, relative identifier like a flat 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 will 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”。
The grammar above provides for the optional inclusion of versions on both the header field itself (attached to the authserv-id token) and on each of the methods being reported. The method version refers to the method itself, which is specified in the documents describing those methods, while the authserv-id version refers to this document and thus the syntax of this header field.
上面的语法提供了在头字段本身（附加到authserv id标记）和正在报告的每个方法上可选地包含版本。方法版本指的是描述这些方法的文档中指定的方法本身，而authserv id版本指的是此文档，因此指的是此标头字段的语法。
The purpose of including these is to avoid misinterpretation of the results. That is, if a parser finds a version after an authserv-id that it does not explicitly know, it can immediately discontinue trying to parse since what follows might not be in an expected format. For a method version, the parser SHOULD ignore a method result if the version is not supported in case the semantics of the result have a different meaning than what is expected. For example, if a hypothetical DKIM version 2 yielded a "pass" result for different reasons than version 1 does, a consumer of this field might not want to use the altered semantics. Allowing versions in the syntax is a way to indicate this and let the consumer of the header field decide.
包含这些内容的目的是避免对结果的误解。也就是说，如果解析器在它不明确知道的authserv id之后找到一个版本，它可以立即停止尝试解析，因为后面的内容可能不是预期的格式。对于一个方法版本，如果该版本不受支持，那么解析器应该忽略该方法结果，以防结果的语义具有与预期不同的含义。例如，如果假设的DKIM版本2由于与版本1不同的原因产生了“通过”结果，则此字段的使用者可能不希望使用更改后的语义。在语法中允许版本是一种表明这一点的方法，并让header字段的使用者决定。
Each individual authentication method returns one of a set of specific result values. The subsections below provide references to the documents defining the authentication methods specifically supported by this document, and their corresponding result values. Verifiers SHOULD use these values as described below. New methods not specified in this document, but intended to be supported by the header field defined here, MUST include a similar result table either in their defining documents or in supplementary ones.
每个单独的身份验证方法返回一组特定结果值中的一个。下面的小节提供了对定义本文档特别支持的身份验证方法的文档及其相应结果值的参考。验证器应使用这些值，如下所述。本文档中未指定但此处定义的标题字段支持的新方法必须在其定义文档或补充文档中包含类似的结果表。
DKIM is represented by the "dkim" method and is defined in [DKIM]. DomainKeys is defined in [DOMAINKEYS] and is represented by the "domainkeys" method.
DKIM由“DKIM”方法表示，并在[DKIM]中定义。DomainKeys在[DomainKeys]中定义，并由“DomainKeys”方法表示。
Section 3.8 of [DOMAINKEYS] enumerates some possible results of a DomainKeys evaluation. Those results are not used when generating this header field; rather, the results returned are listed below.
[DOMAINKEYS]第3.8节列举了DOMAINKEYS评估的一些可能结果。生成此标题字段时不使用这些结果；下面列出了返回的结果。
A signature is "acceptable to the ADMD" if it passes local policy checks (or there are no specific local policy checks). For example, an ADMD policy 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 even if they verify.
如果签名通过本地策略检查（或没有特定的本地策略检查），则该签名是“ADMD可接受的”。例如，ADMD策略可能要求使用消息的From标头字段中存在的DNS域添加消息上的签名，从而使第三方签名即使经过验证也不可接受。
Both DKIM and DomainKeys use the same result set, as follows:
DKIM和DomainKeys都使用相同的结果集，如下所示：
none: The message was not signed.
无：邮件未签名。
pass: The message was signed, the signature or signatures were acceptable to the ADMD, and the signature(s) passed verification tests.
通过：消息已签名，ADMD可接受一个或多个签名，并且签名通过了验证测试。
fail: The message was signed and the signature or signatures were acceptable to the ADMD, but they failed the verification test(s).
失败：消息已签名，且ADMD可接受一个或多个签名，但未通过验证测试。
policy: The message was signed, but some aspect of the signature or signatures was not acceptable to the ADMD.
策略：邮件已签名，但ADMD不接受签名的某些方面。
neutral: The message was signed, but the signature or signatures contained syntax errors or were not otherwise able to be processed. This result is also 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：由于某些无法恢复的错误，例如缺少必需的标头字段，因此无法验证消息。以后的尝试不太可能产生最终结果。
DKIM results are reported using a ptype of "header". The property, however, represents one of the tags found in the DKIM-Signature header field rather than a distinct header field. For example, the
DKIM结果使用“标题”类型报告。但是，该属性表示在DKIM签名头字段中找到的标记之一，而不是一个独特的头字段。例如
ptype-property combination "header.d" refers to the content of the "d" (signing domain) tag from within the signature header field, and not a distinct header field called "d".
ptype属性组合“header.d”是指签名头字段中的“d”（签名域）标记的内容，而不是称为“d”的不同头字段。
The ability to report different DKIM results for a message with multiple signatures is described in [RFC6008].
[RFC6008]中描述了为具有多个签名的消息报告不同DKIM结果的能力。
[DKIM] advises that if a message fails verification, it is to 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]建议，如果消息验证失败，则将其视为未签名消息。此处的“失败”报告允许报告接收者决定如何处理失败。“中立”或“无”的报告优先考虑了这一选择，确保消息将被视为未经签名。
Section 3.1 of [DOMAINKEYS] describes a process by which the sending address of the message is determined. DomainKeys results are thus reported along with the signing domain name, the sending address of the message, and the name of the header field from which the latter was extracted. This means that a DomainKeys result includes a ptype-property combination of "header.d", plus one of "header.from" and "header.sender". The sending address extracted from the header is included with any [MAIL]-style comments removed; moreover, the local-part of the address and the "@" character are removed if it has not been authenticated in some way.
[DOMAINKEYS]第3.1节描述了确定消息发送地址的过程。因此，DomainKeys结果将与签名域名、消息的发送地址以及从中提取消息的头字段的名称一起报告。这意味着DomainKeys结果包括一个ptype属性组合“header.d”，加上一个“header.from”和“header.sender”。从报头提取的发送地址包含在删除的任何[MAIL]样式的注释中；此外，如果地址的本地部分和“@”字符未通过某种方式的身份验证，则会将其删除。
SPF and Sender ID use the "spf" and "sender-id" method names, respectively. The result values for SPF are defined in Section 2.6 of [SPF], and those definitions are included here by reference:
SPF和发送方ID分别使用“SPF”和“发送方ID”方法名。SPF的结果值在[SPF]的第2.6节中定义，这些定义通过引用包含在此处：
+-----------+--------------------------------+
| Code | Meaning |
+-----------+--------------------------------+
| none | [RFC7208], Section 2.6.1 |
+-----------+--------------------------------+
| pass | [RFC7208], Section 2.6.3 |
+-----------+--------------------------------+
| fail | [RFC7208], Section 2.6.4 |
+-----------+--------------------------------+
| softfail | [RFC7208], Section 2.6.5 |
+-----------+--------------------------------+
| policy | RFC 7601, Section 2.4 |
+-----------+--------------------------------+
| neutral | [RFC7208], Section 2.6.2 |
+-----------+--------------------------------+
| temperror | [RFC7208], Section 2.6.6 |
+-----------+--------------------------------+
| permerror | [RFC7208], Section 2.6.7 |
+-----------+--------------------------------+
+-----------+--------------------------------+
| Code | Meaning |
+-----------+--------------------------------+
| none | [RFC7208], Section 2.6.1 |
+-----------+--------------------------------+
| pass | [RFC7208], Section 2.6.3 |
+-----------+--------------------------------+
| fail | [RFC7208], Section 2.6.4 |
+-----------+--------------------------------+
| softfail | [RFC7208], Section 2.6.5 |
+-----------+--------------------------------+
| policy | RFC 7601, Section 2.4 |
+-----------+--------------------------------+
| neutral | [RFC7208], Section 2.6.2 |
+-----------+--------------------------------+
| temperror | [RFC7208], Section 2.6.6 |
+-----------+--------------------------------+
| permerror | [RFC7208], Section 2.6.7 |
+-----------+--------------------------------+
These result codes are used in the context of this specification to reflect the result returned by the component conducting SPF evaluation.
这些结果代码在本规范的上下文中用于反映执行SPF评估的组件返回的结果。
For SPF, the ptype used is "smtp", and the property is either "mailfrom" or "helo", since those values are the ones SPF can evaluate. (If the SMTP client issued the EHLO command instead of HELO, the property used is "helo".)
对于SPF，使用的ptype为“smtp”，属性为“mailfrom”或“helo”，因为这些值是SPF可以计算的值。（如果SMTP客户端发出了EHLO命令而不是HELO，则使用的属性为“HELO”。）
The "sender-id" method is described in [SENDERID]. For this method, the ptype used is "header" and the property will be the name of the header field from which the Purported Responsible Address (see [PRA]) was extracted -- namely, one of "Resent-Sender", "Resent-From", "Sender", or "From".
[SENDERID]中描述了“发送者id”方法。对于这种方法，使用的ptype是“header”，属性是从中提取声称的责任地址（参见[PRA]）的头字段的名称，即“Resent Sender”、“Resent from”、“Sender”或“from”中的一个。
The results for Sender ID are listed and described in Section 4.2 of [SENDERID], but for the purposes of this specification, the SPF definitions enumerated above are used instead. Also, [SENDERID] specifies result codes that use mixed case, but they are typically used all lowercase in this context.
发送方ID的结果在[SENDERID]的第4.2节中列出和描述，但在本规范中，使用上述SPF定义。此外，[SENDERID]指定了使用大小写混合的结果代码，但在此上下文中它们通常都是小写的。
For both methods, an additional result of "policy" is defined, which means the client was 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. For example, "policy" might be used if SPF returns a "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).
对于这两种方法，定义了“策略”的附加结果，这意味着根据身份验证方法的算法，客户端被授权代表发送方的DNS域注入或中继邮件，但本地策略规定结果是不可接受的。例如，如果SPF返回“通过”结果，但本地策略检查将发送DNS域与在不可接受DNS域（例如垃圾邮件发送者）的显式列表中找到的域相匹配，则可以使用“策略”。
If the retrieved sender policies used to evaluate SPF and Sender ID 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 or the following "@" character.
如果用于评估SPF和发件人ID的检索发件人策略不包含验证地址的本地部分（请参阅[邮件]第3.4.1节）的明确规定，则随这些机制的结果一起报告的“pvalue”不应包括本地部分或以下“@”字符。
The result values 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. A later attempt is unlikely to produce a final result.
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地址，所以总是可以进行某种评估。
The result is reported using a ptype of "policy" (as this is not part of any established protocol) and a property of "iprev".
使用“policy”的ptype（因为这不是任何已建立协议的一部分）和“iprev”属性报告结果。
For discussion of the format of DNS replies, see "Domain Names - Implementation and Specification" ([DNS]).
有关DNS回复格式的讨论，请参阅“域名-实现和规范”（[DNS]）。
SMTP AUTH (defined in [AUTH]) is represented by the "auth" method. Its result values are as follows:
SMTP验证（在[AUTH]中定义）由“AUTH”方法表示。其结果值如下：
none: SMTP authentication was not attempted.
无：未尝试SMTP身份验证。
pass: The SMTP client authenticated to the server reporting the result using the protocol described in [AUTH].
通过：SMTP客户端使用[AUTH]中描述的协议向报告结果的服务器进行身份验证。
fail: The SMTP client attempted to authenticate to the server using the protocol described in [AUTH] but was not successful (such as providing a valid identity but an incorrect password).
失败：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 that is likely transient in nature, such as a temporary directory service lookup error. A later attempt may produce a final result.
temperror:SMTP客户端尝试使用[AUTH]中描述的协议进行身份验证，但由于某些可能是暂时性错误（例如临时目录服务查找错误），无法完成此尝试。以后的尝试可能会产生最终结果。
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 directory service lookup error. A later attempt is not likely to produce a final result.
permerror:SMTP客户端试图使用[AUTH]中描述的协议进行身份验证，但由于某些可能不是暂时性的错误（例如永久目录服务查找错误），无法完成此尝试。以后的尝试不太可能产生最终结果。
The result of AUTH is reported using a ptype of "smtp" and a property of either:
使用ptype“smtp”和以下属性之一报告身份验证结果：
o "auth", in which case the value is the authorization identity generated by the exchange initiated by the AUTH command; or
o “auth”，在这种情况下，该值是由auth命令启动的交换生成的授权标识；或
o "mailfrom", in which case the value is the mailbox identified by the AUTH parameter used with the MAIL FROM command.
o “mailfrom”，在这种情况下，该值是由与mailfrom命令一起使用的AUTH参数标识的邮箱。
If both identities are available, both can be reported. For example, consider this command issued by a client that has completed session authentication with the AUTH command resulting in an authorized identity of "client@c.example":
如果两个身份都可用，则可以报告这两个身份。例如，考虑由已完成会话认证的客户端发出的命令，该命令与Auth-Cube命令的授权身份相同。client@c.example":
MAIL FROM:<alice@a.example> AUTH=<bob@b.example>
MAIL FROM:<alice@a.example> AUTH=<bob@b.example>
This could result in a "resinfo" construction like so:
这可能会导致“resinfo”构造，如下所示：
; auth=pass smtp.auth=client@c.example smtp.mailfrom=bob@b.example
; auth=pass smtp.auth=client@c.example smtp.mailfrom=bob@b.example
Note that in all cases other than "pass", the message was sent by an unauthenticated client. All non-"pass" cases SHOULD thus be treated as equivalent with respect to this method.
请注意，在除“pass”之外的所有情况下，消息都是由未经验证的客户端发送的。因此，所有非“通过”情况应视为与此方法等效。
Result codes were also registered in other RFCs as follows:
结果代码也登记在其他RFC中，如下所示：
o Vouch By Reference (in [AR-VBR], represented by "vbr");
o 参考凭证（在[AR-VBR]中，用“VBR”表示）；
o Authorized Third-Party Signatures (in [ATPS], represented by "dkim-atps");
o 授权第三方签名（在[ATPS]中，由“dkim ATPS”代表）；
o Author Domain Signing Practices (in [ADSP], represented by "dkim-adsp");
o 作者域签名实践（在[ADSP]中，以“dkim ADSP”为代表）；
o Require-Recipient-Valid-Since (in [RRVS], represented by "rrvs");
o 要求收件人自（在[RRV]中，以“RRV”表示）起生效；
o S/MIME (in [SMIME-REG], represented by "smime").
o S/MIME（在[SMIME-REG]中，由“SMIME”表示）。
Additional authentication method identifiers (extension methods) may be defined in the future by later revisions or extensions to this specification. These method identifiers are registered with the Internet Assigned Numbers Authority (IANA) and, preferably, published in an RFC. See Section 6 for further details.
其他认证方法标识符（扩展方法）可在将来通过本规范的后续修订或扩展进行定义。这些方法标识符在互联网分配号码管理局（IANA）注册，最好在RFC中发布。详见第6节。
Extension methods can 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 ought to reflect the name of the method being defined but ought 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强”。
Authentication method implementers are encouraged to provide adequate information, via message header field 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 (unknown) method identifier.
实验方法标识符只能在明确同意使用它们的ADMD中使用。RFCs中未记录这些方法标识符及其相关参数。因此，它们随时可能发生变化，不适合生产使用。任何用于生产的MTA、MUA或下游过滤器都应忽略或删除包含实验（未知）方法标识符的任何身份验证结果标题字段。
Additional result codes (extension results) might be defined in the future by later revisions or extensions to this specification. Result codes MUST be registered with the Internet Assigned Numbers Authority (IANA) and preferably published in an RFC. See Section 6 for further details.
其他结果代码（扩展结果）可能在将来由本规范的后续修订或扩展定义。结果代码必须在互联网分配号码管理局（IANA）注册，最好在RFC中公布。详见第6节。
Experimental results MUST only be used within ADMDs that have explicitly consented to use them. These results and the parameters associated with them are not formally documented. 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内使用。这些结果及其相关参数没有正式记录。因此，它们随时可能发生变化，不适合生产使用。任何用于生产的MTA、MUA或下游筛选器都应忽略或删除包含扩展结果的任何身份验证结果标题字段。
This section defines an additional authentication method called "iprev".
本节定义了一种称为“iprev”的附加身份验证方法。
"iprev" is an attempt to verify that a client appears to be valid based on some DNS queries, which is to say that the IP address is explicitly associated with a domain name. 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 will typically result in at least one mapping back to the client's IP address.
“iprev”是根据一些DNS查询验证客户端是否有效的尝试，也就是说，IP地址与域名显式关联。在从客户端接收到某种会话发起后，将查询客户端对等方的IP地址以查找匹配的名称（即，从数字到名称的转换，也称为“反向查找”或“PTR”记录查询）。一旦获得该结果，就完成对由此检索到的每个名称的查找（即，名称到数字的转换，或“a”或“AAAA”记录查询）。对第二个检查的响应通常会导致至少一个映射回客户端的IP地址。
Expressed as an algorithm: 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的元素，则此测试成功。
Often an MTA receiving a connection that fails this test will simply reject the connection using the enhanced status code defined in [AUTH-ESC]. If an operator instead wishes to make this information available to downstream agents as a factor in handling decisions, it records a result in accordance with Section 2.7.3.
通常，如果MTA接收到的连接未通过此测试，它将使用[AUTH-ESC]中定义的增强状态代码拒绝该连接。如果运营商希望将此信息作为处理决策的一个因素提供给下游代理，则运营商将根据第2.7.3节记录结果。
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 limited so as not to be unduly taxing to the DNS infrastructure, though it MAY be configurable by an administrator. As an example, Section 4.6.4 of [SPF] chose a limit of 10 for its implementation of this algorithm.
对PTR查询的响应可能包含多个名称。为了防止沉重的DNS负载，必须实现执行这些查询的代理，以限制通过生成相应的A或AAAA查询来评估的名称的数量，从而不会对DNS基础设施造成不适当的负担，尽管管理员可以对其进行配置。例如，[SPF]的第4.6.4节为实现该算法选择了10个限制。
"DNS Extensions to Support IP Version 6" ([DNS-IP6]) discusses the query formats for the IPv6 case.
“支持IP版本6的DNS扩展”（[DNS-IP6]）讨论了IPv6案例的查询格式。
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 precise 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 "Considerations for the use of DNS Reverse Mapping" ([DNSOP-REVERSE]). In particular, it recommends that applications avoid using this test as a means of authentication or security. Its presence in this document is not an endorsement but is merely acknowledgment that the method remains common and provides the means to relay the results of that test.
有关反向DNS映射及其含义的广泛讨论，请参见“DNS反向映射使用注意事项”（[DNSOP-reverse]）。特别是，它建议应用程序避免使用此测试作为身份验证或安全性的手段。其在本文件中的存在不是认可，而是确认该方法仍然通用，并提供了传递该试验结果的方法。
This specification makes no attempt to evaluate the relative strengths of various message authentication methods that may become available. The methods listed are an order-independent set; their sequence does not indicate relative strength or importance of one method over another. Instead, the MUA or downstream filter consuming this header field is to 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 described in Section 2.7.6, and each "result" MUST refer to a result code declared in the IANA registry or an extension result code as defined in Section 2.7.7. See Section 6 for further information about the registered methods and result codes.
每个“方法”必须指在IANA注册表中声明的认证方法或第2.7.6节中描述的扩展方法，每个“结果”必须指在IANA注册表中声明的结果代码或第2.7.7节中定义的扩展结果代码。有关注册方法和结果代码的更多信息，请参见第6节。
An MTA compliant with this specification adds 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 adds 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 and the "none" token (see Section 2.2) to indicate explicitly that no message authentication schemes were applied prior to delivery of this message.
MTA可以添加此标头字段，其中仅包含身份验证标识符部分和“无”令牌（请参见第2.2节），以明确表示在传递此邮件之前未应用任何邮件身份验证方案。
An MTA adding this header field has to take steps to identify it as legitimate to the MUAs or downstream filters that will ultimately consume its content. One process to do so is described in Section 5. Further measures may be necessary in some environments. Some possible solutions are enumerated in Section 7.1. This document does not mandate any specific solution to this issue as each environment has its own facilities and limitations.
添加此标头字段的MTA必须采取步骤，将其标识为MUA或最终将使用其内容的下游筛选器的合法字段。第5节中描述了一个这样做的过程。在某些环境中，可能需要采取进一步的措施。第7.1节列举了一些可能的解决方案。由于每个环境都有自己的设施和限制，因此本文件不强制要求对此问题采取任何具体的解决方案。
Most known message authentication methods focus on a particular identifier to evaluate. SPF and Sender ID differ in that they can yield a result based on more than one identifier; specifically, SPF can evaluate the RFC5321.HELO parameter or the RFC5321.MailFrom parameter, and Sender ID can evaluate the RFC5321.MailFrom parameter or the Purported Responsible Address (PRA) identity. When generating this field to report those results, only the parameter that yielded the result is included.
大多数已知的消息身份验证方法侧重于要评估的特定标识符。SPF和发送方ID的不同之处在于，它们可以基于多个标识符生成结果；具体而言，SPF可以评估RFC5321.HELO参数或RFC5321.MailFrom参数，发送方ID可以评估RFC5321.MailFrom参数或声称的责任地址（PRA）标识。生成此字段以报告这些结果时，仅包含生成结果的参数。
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 placement allows easy detection of header fields that can be trusted.
对于添加此标头字段的MTA，根据[MAIL]第3.6节，按顺序（在顶部）添加标头字段尤其重要。此外，此头字段应插入到MTA可能前置的任何其他跟踪头字段的上方。此位置允许轻松检测可信任的标题字段。
End users making direct use of this header field might 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
直接使用此标题字段的最终用户可能会无意中信任未经适当审查的信息。例如，如果要中继一个基本SPF结果，该结果声明一个经过身份验证的addr规范，则该addr规范的本地部分实际上尚未经过身份验证。因此，MTA将添加此标头
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.
字段不应包括任何未通过所应用方法验证的数据。此外，如果这些信息是通过一种已知的方法呈现的，而该方法没有对其进行身份验证，则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 configured to do so by the user or administrator. That is, this interpretation should not be "on by default". Naturally then, users or administrators ought not activate such a feature unless (1) they are certain the header field will be validly added by an agent within the ADMD that accepts the mail that is ultimately read by the MUA, and (2) instances of the header field that appear to originate within the ADMD but are actually added by foreign MTAs will be removed before delivery.
为了确保结果不含糊并避免虚假标题字段的影响，MUA和下游过滤器不应解释此标题字段，除非用户或管理员专门配置为这样做。也就是说，这种解释不应“默认开启”。因此，用户或管理员自然不应激活此类功能，除非（1）他们确定接收MUA最终读取的邮件的ADMD中的代理将有效添加标题字段，以及（2）看似源自ADMD但实际上由外部MTA添加的标题字段实例将在交付前删除。
Furthermore, MUAs and downstream filters SHOULD NOT interpret this header field unless the authentication service 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 IANA "Result Code" registry or a "ptype" not listed in the "Email Authentication Property Types" 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和下游过滤器必须忽略使用IANA“结果代码”注册表中未指定的“结果”或“电子邮件验证属性类型”注册表中未列出的“ptype”报告的任何结果，如第6节中定义的值。此外，这些代理必须忽略他们不特别支持的任何“方法”的结果。
An MUA SHOULD NOT reveal these results to end users, absent careful human factors design considerations and testing, for the presentation of trust-related materials. For example, an attacker could register examp1e.com (note the digit "1" (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 MUST 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节所述，必须将此标头字段视为[MAIL]第3.6.7节中定义的跟踪标头字段，因此不得重新排序，且必须在邮件前加上前缀，以便在传递MTA时，通常会有一些指示，说明在处理MTA的链中在何处进行了邮件身份验证。
Note that there are a few message handlers that are only capable of appending new header fields to a message. Strictly speaking, these handlers are not compliant with this specification. They can still add the header field to carry authentication details, but any signal
请注意，有一些消息处理程序只能将新的头字段附加到消息中。严格来说，这些处理程序不符合此规范。他们仍然可以添加头字段来携带身份验证详细信息，但不包括任何信号
about where in the handling chain the work was done may be lost. Consumers SHOULD be designed such that this can be tolerated, especially from a producer known to have this limitation.
关于在搬运链中完成工作的位置可能会丢失。消费者的设计应使其能够被容忍，尤其是已知有此限制的生产商。
MUAs SHOULD ignore instances of this header field discovered within message/rfc822 MIME attachments.
MUA应忽略在message/rfc822 MIME附件中发现的此标头字段的实例。
Further discussion of these topics can be found in Section 7 below.
关于这些主题的进一步讨论见下文第7节。
Some sites have a local policy that considers any particular authentication policy's non-recoverable failure results (typically "fail" or similar) as justification for rejecting the message. In such cases, the border MTA SHOULD issue an SMTP rejection response to the message, rather than adding this header field and allowing the message 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 Delivery Status Notification (DSN) [DSN] to a forged originator. Such generated rejections are colloquially known as "backscatter".
某些站点有一个本地策略，该策略将任何特定身份验证策略的不可恢复失败结果（通常为“失败”或类似结果）视为拒绝消息的理由。在这种情况下，border MTA应该对邮件发出SMTP拒绝响应，而不是添加此标头字段并允许邮件继续传递。这比允许邮件到达内部主机的MTA或垃圾邮件过滤器更可取，因此可能会生成本地拒绝，例如发送状态通知（DSN）[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.7).
对于覆盖认证方法结果的本地策略决策（例如，第2.7节中描述的“策略”结果代码），也可以这样做。
Such rejections at the SMTP protocol level are not possible if local policy is enforced at the MUA and not the MTA.
如果在MUA而不是MTA强制实施本地策略，则无法在SMTP协议级别执行此类拒绝。
For security reasons, any MTA conforming to this specification MUST delete any discovered instance of this header field that claims, by virtue of its authentication service identifier, to have been added within its trust boundary but that did not come directly from another trusted MTA. For example, an MTA for example.com receiving a message MUST delete or otherwise obscure any instance of this header field bearing an authentication service identifier indicating that the header field was added within example.com prior to adding its own header fields. This could mean each MTA will have to be equipped with a list of internal MTAs known to be compliant (and hence trustworthy).
出于安全原因，任何符合本规范的MTA都必须删除发现的此标头字段的任何实例，这些实例根据其身份验证服务标识符声称已添加到其信任边界内，但并非直接来自另一个受信任的MTA。例如，接收邮件的MTA For example.com必须删除或以其他方式隐藏此标头字段的任何实例，该标头字段带有身份验证服务标识符，指示在添加其自己的标头字段之前已在example.com中添加了标头字段。这可能意味着每个MTA都必须配备一份已知符合要求（因此值得信赖）的内部MTA列表。
For simplicity and maximum security, a border MTA could 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
为了简单和最大的安全性，border MTA可以在邮件跨入其信任边界时删除此标头字段的所有实例。但是，这可能与访问受信任的外部服务提供商执行的身份验证结果的愿望相冲突。它还可能使签名无效的已签名消息无效
cover external instances of this header field. A more robust border MTA could allow a specific list of authenticating MTAs whose information is to be admitted, removing the header field originating from all others.
覆盖此标题字段的外部实例。更健壮的边界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 will 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 removal action could invalidate one or more signatures on the message if they covered the header field to be removed. This behavior can be desirable since there's little value in validating the signature on a message with forged header fields. 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 field if the [SMTP] connection relaying the message is not from a trusted internal MTA. This means the MTA needs to be able to understand versions of this header field at least as late as the ones understood by the MUAs or other consumers within its ADMD.
MTA应删除此标题字段中包含其不支持的版本（明示或暗示）的任何实例。但是，如果中继邮件的[SMTP]连接不是来自受信任的内部MTA，则MTA必须删除此类标头字段。这意味着MTA需要能够理解此标题字段的版本，至少与MUA或其ADMD中的其他使用者理解的版本一样晚。
IANA has registered the defined header field and created tables as described below. These registry actions were originally defined by [RFC5451] and updated by [RFC6577] and [RFC7001]. The created registries are being further updated here to increase their completeness.
IANA已注册定义的标题字段并创建了如下所述的表。这些注册表操作最初由[RFC5451]定义，并由[RFC6577]和[RFC7001]更新。此处将进一步更新创建的注册表，以提高其完整性。
[RFC5451] added the Authentication-Results header field to the IANA "Permanent Message Header Field Names" registry, per the procedure found in [IANA-HEADERS]. That entry has been updated to reference this document. The following is the registration template:
[RFC5451]按照[IANA-HEADERS]中的过程，将身份验证结果标头字段添加到IANA“永久消息标头字段名称”注册表中。该条目已更新以引用此文档。以下是注册模板：
Header field name: Authentication-Results
Applicable protocol: mail ([MAIL])
Status: Standard
Author/Change controller: IETF
Specification document(s): RFC 7601
Related information: none
Header field name: Authentication-Results
Applicable protocol: mail ([MAIL])
Status: Standard
Author/Change controller: IETF
Specification document(s): RFC 7601
Related information: none
Names of message authentication methods supported by this specification have been registered with IANA, with the exception of experimental names as described in Section 2.7.6. Along with each method is recorded the properties that accompany the method's result.
本规范支持的消息认证方法的名称已向IANA注册，但第2.7.6节所述的实验名称除外。每个方法都会记录方法结果的属性。
The "Email Authentication Parameters" group, and within it the "Email Authentication Methods" registry, were created by [RFC5451] for this purpose. [RFC6577] added a "status" field for each entry. [RFC7001] amended the rules governing that registry and also added a "version" field to the registry.
[RFC5451]为此目的创建了“电子邮件身份验证参数”组以及其中的“电子邮件身份验证方法”注册表。[RFC6577]为每个条目添加了一个“状态”字段。[RFC7001]修改了管理该注册表的规则，并在注册表中添加了“版本”字段。
The reference for that registry has been updated to reference this document.
该注册表的引用已更新为引用此文档。
New entries are assigned only for values that have received Expert Review, per [IANA-CONSIDERATIONS]. The designated expert shall be appointed by the IESG. The designated expert has discretion to request that a publication be referenced if a clear, concise definition of the authentication method cannot be provided such that interoperability is assured. Registrations should otherwise be permitted. The designated expert can also handle requests to mark any current registration as "deprecated".
根据[IANA-注意事项]，新条目仅分配给已接受专家评审的值。指定专家应由IESG任命。如果无法提供清晰、简洁的认证方法定义以确保互操作性，指定专家有权要求参考出版物。否则应允许注册。指定专家还可以处理将任何当前注册标记为“已弃用”的请求。
No two entries can have the same combination of method, ptype, and property.
两个条目不能具有相同的方法、ptype和属性组合。
An entry in this registry contains the following:
此注册表中的条目包含以下内容：
Method: the name of the method.
方法：方法的名称。
Definition: a reference to the document that created this entry, if any (see below).
定义：对创建此条目的文档的引用（如有）（见下文）。
ptype: a "ptype" value appropriate for use with that method.
ptype：适合与该方法一起使用的“ptype”值。
property: a "property" value matching that "ptype" also appropriate for use with that method.
property：与“ptype”匹配的“property”值也适用于该方法。
Value: a brief description of the value to be supplied with that method/ptype/property tuple.
Value：该方法/ptype/property元组提供的值的简要描述。
Status: the status of this entry, which is either:
状态：此条目的状态，可以是：
active: The entry is in current use.
活动：该条目当前正在使用中。
deprecated: The entry is no longer in current use.
已弃用：该条目不再在当前使用中。
Version: a version number associated with the method (preferably starting at "1").
版本：与方法相关联的版本号（最好从“1”开始）。
The "Definition" field will typically refer to a permanent document, or at least some descriptive text, where additional information about the entry being added can be found. This might in turn reference the document where the method is defined so that all of the semantics around creating or interpreting an Authentication-Results header field using this method, ptype, and property can be understood.
“定义”字段通常指的是永久性文档，或至少是一些描述性文本，可以在其中找到有关所添加条目的附加信息。这可能反过来引用定义了该方法的文档，以便可以理解使用该方法、ptype和属性创建或解释身份验证结果头字段的所有语义。
The following changes have been made to this registry per this document:
根据本文档对此注册表进行了以下更改：
1. The "Defined" field has been renamed "Definition", to be consistent with the other registries in this group.
1. “已定义”字段已重命名为“定义”，以与该组中的其他注册表保持一致。
2. The entry for the "dkim" method, "header" ptype, and "b" property now reference [RFC6008] as the defining document, and the reference has be removed from the description.
2. “dkim”方法、“header”ptype和“b”属性的条目现在引用[RFC6008]作为定义文档，并且该引用已从描述中删除。
3. All other "dkim", "domainkeys", "iprev", "sender-id", and "spf" method entries have had their "Definition" fields changed to refer to this document, as this document contains a complete description of the registry and these corresponding values.
3. 所有其他“dkim”、“domainkeys”、“iprev”、“sender id”和“spf”方法项的“Definition”字段都已更改，以引用本文档，因为本文档包含注册表的完整描述和这些对应值。
4. All "smime" entries have had their "Definition" fields changed to [SMIME-REG].
4. 所有“smime”条目的“定义”字段都已更改为[smime-REG]。
5. The "value" field of the "smime" entry using property "smime-part" has been changed to read: "The MIME body part reference that contains the S/MIME signature. See Section 3.2.1 of RFC 7281 for full syntax."
5. 使用属性“smime part”的“smime”条目的“value”字段已更改为：“包含S/MIME签名的MIME正文部分引用。有关完整语法，请参阅RFC 7281的第3.2.1节。”
6. The single entry for the "auth" method was intended to reflect the identity indicated by the "AUTH" parameter to the SMTP "MAIL FROM" command verb. However, there is also an "AUTH" command verb. To clarify this ambiguity, the entry for the "auth" method has had its "property" field changed to "mailfrom", and its "Definition" field changed to this document.
6. “auth”方法的单个条目旨在将“auth”参数指示的标识反映到SMTP“MAIL FROM”命令动词。但是，还有一个“AUTH”命令动词。为了澄清这种歧义，“auth”方法的条目已将其“property”字段更改为“mailfrom”，其“Definition”字段更改为此文档。
7. The following entry has been added:
7. 已添加以下条目：
Method: auth
方法：auth
Definition: this document (RFC 7601)
定义：本文件（RFC 7601）
ptype: smtp
p类型：smtp
property: auth
属性：auth
Value: identity confirmed by the AUTH command
值：由AUTH命令确认的标识
Status: active
状态：活动
Version: 1
版本:1
8. The values of the "domainkeys" entries for ptype "header" have been updated as follows:
8. ptype“header”的“domainkeys”条目的值已更新如下：
from: contents of the [MAIL] From: header field, after removing comments, and removing the local-part and following "@" if not authenticated
from:[MAIL]from:标头字段的内容，在删除注释和本地部分后，如果未经过身份验证，则在“@”之后
sender: contents of the [MAIL] Sender: header field, after removing comments, and removing the local-part and following "@" if not authenticated
发件人：[MAIL]发件人：标题字段的内容，在删除注释和本地部分后，如果未经身份验证，则在“@”之后
9. For all entries for "dkim-adsp" and "domainkeys", their Status values have been changed to "deprecated", reflecting the fact that the corresponding specifications now have Historic status. Their "Definition" fields have also been modified to include a reference to this document.
9. 对于“dkim adsp”和“domainkeys”的所有条目，它们的状态值已更改为“已弃用”，反映了相应规范现在具有历史状态的事实。其“定义”字段也已修改，以包含对本文档的引用。
[RFC7410] created the "Email Authentication Property Types" registry.
[RFC7410]创建了“电子邮件身份验证属性类型”注册表。
Entries in this registry are subject to the Expert Review rules as described in [IANA-CONSIDERATIONS]. Each entry in the registry requires the following values:
本登记册中的条目应遵守[IANA-注意事项]中所述的专家评审规则。注册表中的每个条目都需要以下值：
ptype: The name of the ptype being registered, which must fit within the ABNF described in Section 2.2.
ptype：注册的ptype的名称，必须符合第2.2节所述的ABNF。
Definition: An optional reference to a defining specification.
定义：对定义规范的可选引用。
Description: A brief description of what sort of information this "ptype" is meant to cover.
描述：简要描述此“ptype”要包含的信息类型。
For new entries, the Designated Expert needs to assure that the description provided for the new entry adequately describes the intended use. An example would be helpful to include in the entry's defining document, if any, although entries in the "Email Authentication Methods" registry or the "Email Authentication Result Names" registry might also serve as examples of intended use.
对于新条目，指定专家需要确保为新条目提供的说明充分描述了预期用途。在条目的定义文档（如果有的话）中包含一个示例会很有帮助，尽管“电子邮件身份验证方法”注册表或“电子邮件身份验证结果名称”注册表中的条目也可以作为预期用途的示例。
As this is a complete restatement of the definition and rules for this registry, IANA has updated this registry to show Section 2.3 of this document as the current definitions for the "body", "header", "policy", and "smtp" entries of that registry. References to [RFC7001] and [RFC7410] have been removed.
由于这是对该注册表定义和规则的完整重述，IANA已更新该注册表，将本文件第2.3节显示为该注册表“正文”、“标题”、“策略”和“smtp”条目的当前定义。已删除对[RFC7001]和[RFC7410]的引用。
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.7.7. A registry was created by [RFC5451] for this purpose. [RFC6577] added the "status" column and [RFC7001] updated the rules governing that registry.
本规范支持的消息认证结果代码的名称必须向IANA注册，第2.7.7节所述的实验代码除外。[RFC5451]为此目的创建了一个注册表。[RFC6577]添加了“状态”列，[RFC7001]更新了管理该注册表的规则。
New entries are assigned only for values that have received Expert Review, per [IANA-CONSIDERATIONS]. The designated expert shall be appointed by the IESG. The designated expert has discretion to request that a publication be referenced if a clear, concise definition of the authentication result cannot be provided such that interoperability is assured. Registrations should otherwise be permitted. The designated expert can also handle requests to mark any current registration as "deprecated".
根据[IANA-注意事项]，新条目仅分配给已接受专家评审的值。指定专家应由IESG任命。如果无法提供清晰、简洁的认证结果定义以确保互操作性，指定专家有权要求引用出版物。否则应允许注册。指定专家还可以处理将任何当前注册标记为“已弃用”的请求。
No two entries can have the same combination of method and code.
没有两个条目可以具有相同的方法和代码组合。
An entry in this registry contains the following:
此注册表中的条目包含以下内容：
Auth Method: an authentication method for which results are being returned using the header field defined in this document.
Auth Method：使用此文档中定义的头字段返回结果的身份验证方法。
Code: a result code that can be returned for this authentication method.
代码：可为此身份验证方法返回的结果代码。
Specification: either free form text explaining the meaning of this method-code combination, or a reference to such a definition.
规范：解释此方法代码组合含义的自由格式文本，或对此类定义的引用。
Status: the status of this entry, which is either:
状态：此条目的状态，可以是：
active: The entry is in current use.
活动：该条目当前正在使用中。
deprecated: The entry is no longer in current use.
已弃用：该条目不再在当前使用中。
This document includes a complete description of the registry, obsoleting [RFC7001]. Accordingly, the following changes have been made to this registry per this document:
本文件包括注册表的完整说明，已淘汰[RFC7001]。因此，根据本文件对本注册表进行了以下更改：
o The "Defined" field has been removed.
o “已定义”字段已被删除。
o The "Meaning" field has been renamed "Specification", as described above.
o 如上所述，“含义”字段已重命名为“规范”。
o The "Auth Method" field now appears before the "Code" field.
o “验证方法”字段现在显示在“代码”字段之前。
o For easier searching, the table has been arranged such that it is sorted first by Auth Method, then by Code within each Auth Method grouping.
o 为了便于搜索，表的排列方式是先按Auth方法排序，然后按每个Auth方法分组中的代码排序。
o All entries for the "dkim", "domainkeys", "spf", "sender-id", "auth", and "iprev" methods have had their "Specification" fields replaced as follows:
o “dkim”、“domainkeys”、“spf”、“sender id”、“auth”和“iprev”方法的所有条目的“Specification”字段替换如下：
dkim: Section 2.7.1 of this document (RFC 7601)
dkim：本文件第2.7.1节（RFC 7601）
domainkeys: Section 2.7.1 of this document (RFC 7601)
域密钥：本文件第2.7.1节（RFC 7601）
spf: for "hardfail", Section 2.4.2 of [RFC5451]; for all others, Section 2.7.2 of this document (RFC 7601)
spf:[RFC5451]第2.4.2节“硬失效”；对于所有其他文件，请参见本文件第2.7.2节（RFC 7601）
sender-id: for "hardfail", Section 2.4.2 of [RFC5451]; for all others, Section 2.7.2 of this document (RFC 7601)
发送方id:[RFC5451]第2.4.2节中的“硬失败”；对于所有其他文件，请参见本文件第2.7.2节（RFC 7601）
auth: Section 2.7.4 of this document (RFC 7601)
认证：本文件第2.7.4节（RFC 7601）
iprev: Section 2.7.3 of this document (RFC 7601)
iprev：本文件第2.7.3节（RFC 7601）
o All entries for "dkim-adsp" that were missing an explicit reference to a defining document now reference [ADSP] in their "Specification" fields.
o “dkim adsp”的所有条目缺少对定义文档的明确引用，现在在其“规范”字段中引用[adsp]。
o All entries for "dmarc" have had their "Specification" fields changed to reference Section 11.2 of [DMARC].
o “dmarc”的所有条目的“规格”字段已更改为参考[dmarc]第11.2节。
o All entries for "dkim-adsp" and "domainkeys" have had their Status values changed to "deprecated", reflecting the fact that the corresponding specifications now have Historic status. Their "Specification" fields have also been modified to include a reference to this document.
o “dkim adsp”和“domainkeys”的所有条目的状态值都已更改为“deprecated”，这反映了相应规范现在具有历史状态的事实。其“规范”字段也已修改，以包含对本文件的引用。
The entry for X.7.25 in the "Enumerated Status Codes" sub-registry of the "Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry" has been updated to refer to this document instead of [RFC7001].
“简单邮件传输协议（SMTP）增强状态代码注册表”的“枚举状态代码”子注册表中的X.7.25条目已更新，以引用本文档而不是[RFC7001]。
The following security considerations apply when adding or processing the Authentication-Results header field:
添加或处理身份验证结果标头字段时，应考虑以下安全因素：
An MUA or filter that accesses a mailbox whose messages are 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可能会不适当地信任它。
For this reason, it is best not to 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.
出于这个原因，最好不要在默认情况下启用身份验证结果头字段的处理；相反，应该忽略它，至少是为了制定过滤决策，除非用户或管理员在验证border MTA是否符合要求后特别启用。可以让MUA知道该规范，但有一个明确的主机名列表，其验证结果头字段是可信的；但是，此列表最初应为空。
Proposed alternative solutions to this problem were made some time ago and are listed below. To date, they have not been developed due to lack of demand but are documented here should the information be useful at some point in the future:
这一问题的备选解决方案是在一段时间前提出的，如下所示。到目前为止，由于需求不足，尚未开发这些信息，但如果这些信息在未来某个时候有用，则在此记录：
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 document 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. Where the authserv-id is the ADMD's domain name, the authserv-id matching this valid internal signature's "d=" DKIM value is sufficient.
1. 可能最简单的是保护报头字段的数字签名，例如使用[DKIM]，MUA可以使用发布的公钥对其进行验证。尽管本文档的主要目的之一是减轻MUA进行消息身份验证工作的负担，但这只要求MUA学习一个身份验证方案，即使在边境MTA使用了多个方案。请注意，[DKIM]要求对From header字段进行签名，但在此应用程序中，签名代理（受信任的MTA）可能无法验证该值，因此应忽略该值已签名的事实。如果authserv id是ADMD的域名，则与此有效内部签名的“d=”DKIM值匹配的authserv id就足够了。
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 fields) to determine whether any of them conform to Section 5 of this memo. This, too, has potentially high barriers to entry.
3. 另一种方法可能是询问显然处理该消息的内部MTA（基于收到的标题字段），以确定其中是否有任何MTA符合本备忘录第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 hostnames 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添加的接收标头上方。这可以用作标题字段有效性的测试。
Support for some of these is being considered 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 document.
在任何情况下，MUA或筛选器都需要存在一种机制来验证似乎添加了标头字段的主机（a）是否确实添加了标头字段，以及（b）是否为此传递合法地添加了标头字段。考虑到目前部署的消息传递环境的多样性，一致认为指定一种特定的机制不适合本文档。
Mitigation of the forged header field attack can also be accomplished by moving the authentication results data into metadata associated with the message. In particular, an [SMTP] extension could be established 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 metadata 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 en route by intermediate MTAs. The goal of requiring header field addition only at the top of a message is an acknowledgment 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 4.6.4 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 needs to 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 document need to be aware of the algorithm used by the verifier reporting the result and, especially, its limitations.
[SPF]的第4.6.4节描述了针对尝试对到达的客户端连接进行基于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 header fields 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 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. Implementers 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 can contain attachments of type "message/rfc822", which contain other messages. Such an encapsulated message can 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”的附件，其中包含其他消息。这样的封装消息还可以包含身份验证结果头字段。尽管这些处理超出了本文件的预期范围（见第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. Implementers 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., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[ABNF]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[IANA-HEADERS] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <http://www.rfc-editor.org/info/rfc3864>.
[IANA-HEADERS]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，DOI 10.17487/RFC3864，2004年9月<http://www.rfc-editor.org/info/rfc3864>.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[邮件]Resnick，P.，Ed.，“互联网信息格式”，RFC 5322，DOI 10.17487/RFC5322，2008年10月<http://www.rfc-editor.org/info/rfc5322>.
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <http://www.rfc-editor.org/info/rfc2045>.
[MIME]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 2045，DOI 10.17487/RFC20451996年11月<http://www.rfc-editor.org/info/rfc2045>.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.
[SMTP]Klensin，J.，“简单邮件传输协议”，RFC 5321DOI 10.17487/RFC5321，2008年10月<http://www.rfc-editor.org/info/rfc5321>.
[ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, DOI 10.17487/RFC5617, August 2009, <http://www.rfc-editor.org/info/rfc5617>.
[ADSP]Allman，E.，Fenton，J.，Delany，M.，和J.Levine，“域密钥识别邮件（DKIM）作者域签名实践（ADSP）”，RFC 5617，DOI 10.17487/RFC5617，2009年8月<http://www.rfc-editor.org/info/rfc5617>.
[AR-VBR] Kucherawy, M., "Authentication-Results Registration for Vouch by Reference Results", RFC 6212, DOI 10.17487/RFC6212, April 2011, <http://www.rfc-editor.org/info/rfc6212>.
[AR-VBR]Kucherawy，M.，“通过参考结果验证的认证结果注册”，RFC 6212，DOI 10.17487/RFC6212，2011年4月<http://www.rfc-editor.org/info/rfc6212>.
[ATPS] Kucherawy, M., "DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures", RFC 6541, DOI 10.17487/RFC6541, February 2012, <http://www.rfc-editor.org/info/rfc6541>.
[ATPS]Kucherawy，M.，“域密钥识别邮件（DKIM）授权第三方签名”，RFC 6541，DOI 10.17487/RFC654112012年2月<http://www.rfc-editor.org/info/rfc6541>.
[AUTH] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, DOI 10.17487/RFC4954, July 2007, <http://www.rfc-editor.org/info/rfc4954>.
[AUTH]Siemborski，R.，Ed.和A.Melnikov，Ed.，“用于身份验证的SMTP服务扩展”，RFC 4954，DOI 10.17487/RFC4954，2007年7月<http://www.rfc-editor.org/info/rfc4954>.
[AUTH-ESC] Kucherawy, M., "Email Authentication Status Codes", RFC 7372, DOI 10.17487/RFC7372, September 2014, <http://www.rfc-editor.org/info/rfc7372>.
[AUTH-ESC]Kucherawy，M.，“电子邮件身份验证状态代码”，RFC 7372，DOI 10.17487/RFC7372，2014年9月<http://www.rfc-editor.org/info/rfc7372>.
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <http://www.rfc-editor.org/info/rfc6376>.
[DKIM]Crocker，D.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，STD 76，RFC 6376，DOI 10.17487/RFC6376，2011年9月<http://www.rfc-editor.org/info/rfc6376>.
[DMARC] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <http://www.rfc-editor.org/info/rfc7489>.
[DMARC]Kucherawy，M.，Ed.和E.Zwicky，Ed.，“基于域的消息验证、报告和一致性（DMARC）”，RFC 7489，DOI 10.17487/RFC7489，2015年3月<http://www.rfc-editor.org/info/rfc7489>.
[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[DNS]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<http://www.rfc-editor.org/info/rfc1035>.
[DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, DOI 10.17487/RFC3596, October 2003, <http://www.rfc-editor.org/info/rfc3596>.
[DNS-IP6]Thomson，S.，Huitema，C.，Ksinant，V.，和M.Souissi，“支持IP版本6的DNS扩展”，RFC 3596，DOI 10.17487/RFC3596，2003年10月<http://www.rfc-editor.org/info/rfc3596>.
[DNSOP-REVERSE] Senie, D. and A. Sullivan, "Considerations for the use of DNS Reverse Mapping", Work in Progress, draft-ietf-dnsop-reverse-mapping-considerations-06, March 2008.
[DNSOP-REVERSE]Senie，D.和A.Sullivan，“使用DNS反向映射的注意事项”，正在进行的工作，草稿-ietf-DNSOP-REVERSE-Mapping-Adversions-062008年3月。
[DOMAINKEYS] Delany, M., "Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, DOI 10.17487/RFC4870, May 2007, <http://www.rfc-editor.org/info/rfc4870>.
[DOMAINKEYS]Delany，M.，“使用DNS中公布的公钥进行基于域的电子邮件身份验证（DOMAINKEYS）”，RFC 4870，DOI 10.17487/RFC4870，2007年5月<http://www.rfc-editor.org/info/rfc4870>.
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, DOI 10.17487/RFC3464, January 2003, <http://www.rfc-editor.org/info/rfc3464>.
[DSN]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，DOI 10.17487/RFC3464，2003年1月<http://www.rfc-editor.org/info/rfc3464>.
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, <http://www.rfc-editor.org/info/rfc5598>.
[EMAIL-ARCH]Crocker，D.，“互联网邮件体系结构”，RFC 5598，DOI 10.17487/RFC5598，2009年7月<http://www.rfc-editor.org/info/rfc5598>.
[IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[IANA注意事项]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <http://www.rfc-editor.org/info/rfc3501>.
[IMAP]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 3501，DOI 10.17487/RFC3501，2003年3月<http://www.rfc-editor.org/info/rfc3501>.
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, <http://www.rfc-editor.org/info/rfc1939>.
[POP3]迈尔斯，J.和M.罗斯，“邮局协议-第3版”，STD 53，RFC 1939，DOI 10.17487/RFC1939，1996年5月<http://www.rfc-editor.org/info/rfc1939>.
[PRA] Lyon, J., "Purported Responsible Address in E-Mail Messages", RFC 4407, DOI 10.17487/RFC4407, April 2006, <http://www.rfc-editor.org/info/rfc4407>.
[PRA]Lyon，J.，“电子邮件中声称的责任地址”，RFC 4407，DOI 10.17487/RFC4407，2006年4月<http://www.rfc-editor.org/info/rfc4407>.
[RFC5451] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, DOI 10.17487/RFC5451, April 2009, <http://www.rfc-editor.org/info/rfc5451>.
[RFC5451]Kucherawy，M.，“用于指示消息身份验证状态的消息头字段”，RFC 5451，DOI 10.17487/RFC5451，2009年4月<http://www.rfc-editor.org/info/rfc5451>.
[RFC6008] Kucherawy, M., "Authentication-Results Registration for Differentiating among Cryptographic Results", RFC 6008, DOI 10.17487/RFC6008, September 2010, <http://www.rfc-editor.org/info/rfc6008>.
[RFC6008]Kucherawy，M.，“用于区分加密结果的认证结果注册”，RFC 6008，DOI 10.17487/RFC6008，2010年9月<http://www.rfc-editor.org/info/rfc6008>.
[RFC6577] Kucherawy, M., "Authentication-Results Registration Update for Sender Policy Framework (SPF) Results", RFC 6577, DOI 10.17487/RFC6577, March 2012, <http://www.rfc-editor.org/info/rfc6577>.
[RFC6577]Kucherawy，M.，“发件人策略框架（SPF）结果的认证结果注册更新”，RFC 6577，DOI 10.17487/RFC6577，2012年3月<http://www.rfc-editor.org/info/rfc6577>.
[RFC7001] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7001, DOI 10.17487/RFC7001, September 2013, <http://www.rfc-editor.org/info/rfc7001>.
[RFC7001]Kucherawy，M.，“用于指示消息身份验证状态的消息头字段”，RFC 7001，DOI 10.17487/RFC7001，2013年9月<http://www.rfc-editor.org/info/rfc7001>.
[RFC7410] Kucherawy, M., "A Property Types Registry for the Authentication-Results Header Field", RFC 7410, DOI 10.17487/RFC7410, December 2014, <http://www.rfc-editor.org/info/rfc7410>.
[RFC7410]Kucherawy，M.，“身份验证结果标头字段的属性类型注册表”，RFC 7410，DOI 10.17487/RFC7410，2014年12月<http://www.rfc-editor.org/info/rfc7410>.
[RRVS] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid-Since Header Field and SMTP Service Extension", RFC 7293, DOI 10.17487/RFC7293, July 2014, <http://www.rfc-editor.org/info/rfc7293>.
[RRVS]Mills，W.和M.Kucherawy，“要求收件人自标头字段和SMTP服务扩展起有效”，RFC 7293，DOI 10.17487/RFC7293，2014年7月<http://www.rfc-editor.org/info/rfc7293>.
[SECURITY] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <http://www.rfc-editor.org/info/rfc3552>.
[安全]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，DOI 10.17487/RFC3552，2003年7月<http://www.rfc-editor.org/info/rfc3552>.
[SENDERID] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, DOI 10.17487/RFC4406, April 2006, <http://www.rfc-editor.org/info/rfc4406>.
[SENDERID]Lyon，J.和M.Wong，“发件人ID：验证电子邮件”，RFC 4406，DOI 10.17487/RFC4406，2006年4月<http://www.rfc-editor.org/info/rfc4406>.
[SMIME-REG] Melnikov, A., "Authentication-Results Registration for S/MIME Signature Verification", RFC 7281, DOI 10.17487/RFC7281, June 2014, <http://www.rfc-editor.org/info/rfc7281>.
[SMIME-REG]Melnikov，A.，“S/MIME签名验证的认证结果注册”，RFC 7281，DOI 10.17487/RFC7281，2014年6月<http://www.rfc-editor.org/info/rfc7281>.
[SPF] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <http://www.rfc-editor.org/info/rfc7208>.
[SPF]Kitterman，S.，“授权在电子邮件中使用域的发件人策略框架（SPF），第1版”，RFC 7208，DOI 10.17487/RFC7208，2014年4月<http://www.rfc-editor.org/info/rfc7208>.
[VBR] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By Reference", RFC 5518, DOI 10.17487/RFC5518, April 2009, <http://www.rfc-editor.org/info/rfc5518>.
[VBR]Hoffman，P.，Levine，J.和A.Hathcock，“参考凭证”，RFC 5518，DOI 10.17487/RFC5518，2009年4月<http://www.rfc-editor.org/info/rfc5518>.
Implementers of this protocol 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 (i.e., while this proposal and its successors are being adopted), other interim means of conveying authentication results may be necessary.
一些现代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.
身份验证结果标头字段完全不存在。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 1; 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 1; 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 or result tokens) indicates that no message authentication was done. The version number of the specification to which the field's content conforms is explicitly provided.
“身份验证结果”标题字段存在，表明传递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.
“身份验证结果”标头字段存在，表明边界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.net;
spf=pass smtp.mailfrom=example.net
Authentication-Results: example.com;
sender-id=pass header.from=example.net
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 ESMTPA id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.com
From: sender@example.net
Message-Id: <12345.abc@example.net>
Subject: here's a sample
Authentication-Results: example.com;
auth=pass (cram-md5) smtp.auth=sender@example.net;
spf=pass smtp.mailfrom=example.net
Authentication-Results: example.com;
sender-id=pass header.from=example.net
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 ESMTPA id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.com
From: sender@example.net
Message-Id: <12345.abc@example.net>
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 that 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 Sender ID checks were done and passed. The MUA could extract and relay this extra information if desired.
“身份验证结果”标头字段存在，表明传递MTA符合此规范。再次，接收DNS域名用作authserv-id。此外，发件人通过[AUTH]中指定的方法向MTA验证了自己的身份，并且完成并通过了SPF和发件人id检查。如果需要，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.
由于同一主机执行了所有检查，因此不需要两个身份验证结果标头字段。身份验证代理可以将所有结果合并到一个标题字段中。
This example illustrates a scenario in which a remote user on a dial-up connection (example.net) sends mail to a border MTA (example.com) using SMTP authentication to prove identity. The dial-up provider has been explicitly authorized to relay mail as example.com, producing "pass" results from the SPF and Sender ID checks.
此示例演示了一个场景，其中拨号连接（例如.net）上的远程用户使用SMTP身份验证向边界MTA（例如.com）发送邮件以证明身份。拨号服务提供商已被明确授权将邮件转发到example.com，通过SPF和发件人ID检查生成“通过”结果。
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=fail header.from=example.com;
dkim=pass (good signature) header.d=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
DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=example.com;
t=1188964191; c=simple/simple; h=From:Date:To:Subject:
Message-Id:Authentication-Results;
bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70;
b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
Authentication-Results: example.com;
auth=pass (cram-md5) smtp.auth=sender@example.com;
spf=fail 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 ESMTPA 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.com
Message-Id: <12345.abc@example.com>
Subject: here's a sample
Authentication-Results: example.com;
sender-id=fail header.from=example.com;
dkim=pass (good signature) header.d=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
DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=example.com;
t=1188964191; c=simple/simple; h=From:Date:To:Subject:
Message-Id:Authentication-Results;
bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70;
b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
Authentication-Results: example.com;
auth=pass (cram-md5) smtp.auth=sender@example.com;
spf=fail 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 ESMTPA 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.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 MTA, mail-router.example.com, reports that SMTP AUTH and SPF were both used and that the former passed while the latter failed. In the SMTP AUTH case, additional information is provided in the comment field, which the MUA can choose to render if desired.
“身份验证结果”标头字段存在，表示符合此规范。同样，使用的authserv id是收件人的DNS域名。标头字段出现两次，因为传递链中的两个不同MTA进行了身份验证测试。第一个MTA，mail-router.example.com，报告都使用了SMTP验证和SPF，前者通过，而后者失败。在SMTP验证案例中，注释字段中提供了附加信息，如果需要，MUA可以选择呈现这些信息。
The second MTA, auth-checker.example.com, reports that it did a Sender ID 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. Also noteworthy here is the fact that there is a DKIM signature added by example.com that assured the integrity of the lower Authentication-Results field.
第二个MTA auth-checker.example.com报告它进行了发件人ID测试（失败）和DKIM测试（通过）。同样，关于其中一个测试的附加数据作为注释提供，MUA可以选择呈现。这里还值得注意的是，example.com添加了一个DKIM签名，确保了较低身份验证结果字段的完整性。
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 dial-up connection example.net. The user appears to be legitimate as he/she had a valid password allowing authentication at the border MTA using SMTP AUTH. The SPF and Sender ID 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使用SMTP身份验证。SPF和发件人ID测试失败，因为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 reason="good signature"
header.i=@mail-router.example.net;
dkim=fail reason="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 reason="good signature"
header.i=@mail-router.example.net;
dkim=fail reason="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 whom 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上添加的验证结果头，该头验证了第二个签名。因此，可以间接地确定由两个签名声明的认证确实有效。
Note that two styles of presenting metadata about the result are in use here. In one case, the "reason=" clause is present, which is intended for easy extraction by parsers; in the other case, the CFWS production of the ABNF is used to include such data as a header field comment. The latter can be harder for parsers to extract given the varied supported syntaxes of mail header fields.
请注意，这里使用了两种显示结果元数据的样式。在一种情况下，存在“reason=”子句，其目的是便于解析器提取；在另一种情况下，ABNF的CFWS产品用于包括诸如头字段注释之类的数据。考虑到邮件头字段支持的不同语法，后者可能更难让解析器提取。
The formal syntax permits comments within the content in a number of places. For the sake of illustration, this example is also legal:
形式语法允许在内容中的多个位置进行注释。为了便于说明，此示例也是合法的：
Authentication-Results: foo.example.net (foobar) 1 (baz);
dkim (Because I like it) / 1 (One yay) = (wait for it) fail
policy (A dot can go here) . (like that) expired
(this surprised me) = (as I wasn't expecting it) 1362471462
Authentication-Results: foo.example.net (foobar) 1 (baz);
dkim (Because I like it) / 1 (One yay) = (wait for it) fail
policy (A dot can go here) . (like that) expired
(this surprised me) = (as I wasn't expecting it) 1362471462
Example 7: A Very Comment-Heavy but Perfectly Legal Example
例句7：一个很重的评论，但完全合法的例子
This protocol 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 this protocol and its deployment to date are 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, rejection 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 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), do have a cost and thus need to 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 attempt 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 elsewhere 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中有许多操作选择，包括执行身份验证和/或声誉评估的场所。当前的规范没有规定任何这些选择。相反，它有助于将一个分析阶段生成的信息与消息一起传输到下一个阶段。
o Applied RFC 7410.
o 应用RFC 7410。
o Updated all references to RFC 4408 with RFC 7208.
o 用RFC 7208更新了对RFC 4408的所有参考。
o Added section explaining "property" values. (Addressed Erratum #4201.)
o 增加了解释“属性”值的部分。（勘误表4201）
o Did some minor text reorganization.
o 做了一些小的文本重组。
o Gave registry history -- enough that this is now the authoritative registry definition.
o 提供了注册表历史记录--足够了，现在这是权威的注册表定义。
o Added text explaining each of the method-ptype-property tuples registered by this document.
o 添加了解释此文档注册的每个方法ptype属性元组的文本。
o Changed the meaning of the "Defined" column of the methods registry to be the place where each entry was created and described; it is expected that this will then refer to the method's defining document. Provided IANA with corresponding update instructions.
o 将方法注册中心“已定义”列的含义更改为创建和描述每个条目的位置；预计这将引用该方法的定义文档。向IANA提供了相应的更新说明。
o Cleaned up registry structure and content, and replaced all references to RFC 7001 with pointers to this document.
o 清理注册表结构和内容，并用指向此文档的指针替换对RFC 7001的所有引用。
o Added references: [DMARC], [PRA], [RFC6008], [RFC6577], [RRVS], [SMIME-REG].
o 新增参考文献：[DMARC]、[PRA]、[RFC6008]、[RFC6577]、[RRVS]、[SMIME-REG]。
o Added description of values that can be extracted from SMTP AUTH sessions and an example.
o 添加了可从SMTP身份验证会话提取的值的说明和示例。
o Provided much more complete descriptions of reporting DomainKeys results.
o 提供了关于报告域密钥结果的更完整的描述。
o Added more detail about Sender ID.
o 添加了有关发件人ID的更多详细信息。
o Marked all ADSP and DomainKeys entries as deprecated since their defining documents are as well.
o 将所有ADSP和DomainKeys条目标记为已弃用，因为它们的定义文档也已弃用。
o Reworked some text around ignoring unknown ptypes.
o 重写了一些忽略未知类型的文本。
o Completely described the ptypes registry.
o 完整描述了ptypes注册表。
o Mentioned that EHLO is mapped to HELO for SPF.
o 提到EHLO映射到用于SPF的HELO。
o RFC 7208 uses all-lowercase result strings now, so adjusted prose accordingly.
o RFC 7208现在使用所有小写结果字符串，因此相应地调整了散文。
o Updated list of supported methods, and mentioned the registries immediately below.
o 更新了支持的方法列表，并在下面提到了注册表。
o Mentioned that when a local-part is removed, the "@" goes with it.
o 提到移除局部零件时，“@”会随之出现。
o Referred to RFC 7328 in the "iprev" definition.
o 参考“iprev”定义中的RFC 7328。
o Corrected the "smime-part" prose.
o 更正了“微笑部分”的散文。
o Updated examples that use SMTP AUTH to claim "with ESMTPA" in the Received fields.
o 更新了使用SMTP AUTH在接收字段中声明“使用ESMTPA”的示例。
o Made minor editorial adjustments.
o 做了一些小的编辑调整。
Acknowledgments
致谢
The author wishes to acknowledge the following individuals for their review and constructive criticism of this document: Stephane Bortzmeyer, Scott Kitterman, John Levine, Tom Petch, and Pete Resnick.
作者希望感谢以下个人对本文件的审查和建设性批评：Stephane Bortzmeyer、Scott Kitterman、John Levine、Tom Petch和Pete Resnick。
Author's Address
作者地址
Murray S. Kucherawy 270 Upland Drive San Francisco, CA 94127 United States
Murray S. Kucherawy 270高地驱动旧金山，CA 94127美国
Email: superuser@gmail.com
Email: superuser@gmail.com