Internet Engineering Task Force (IETF) K. Andersen
Request for Comments: 8617 LinkedIn
Category: Experimental B. Long, Ed.
ISSN: 2070-1721 Google
S. Blank, Ed.
Valimail
M. Kucherawy, Ed.
TDP
July 2019
Internet Engineering Task Force (IETF) K. Andersen
Request for Comments: 8617 LinkedIn
Category: Experimental B. Long, Ed.
ISSN: 2070-1721 Google
S. Blank, Ed.
Valimail
M. Kucherawy, Ed.
TDP
July 2019
The Authenticated Received Chain (ARC) Protocol
认证接收链（ARC）协议
Abstract
摘要
The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before and what the message's authentication assessment was at each step in the handling.
经过身份验证的接收链（ARC）协议为消息提供经过身份验证的“监管链”，允许处理消息的每个实体查看之前处理过消息的实体以及处理过程中每个步骤的消息身份验证评估。
ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of the message-handling paths.
ARC允许Internet邮件处理程序将消息身份验证评估断言附加到单个消息。当消息通过启用ARC的Internet邮件处理程序时，可以将其他ARC断言附加到消息，以形成ARC断言的有序集，这些ARC断言表示消息处理路径每个步骤的身份验证评估。
ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, identify Internet Mail Handlers that might break existing authentication mechanisms, and convey original authentication assessments across trust boundaries.
启用ARC的Internet邮件处理程序可以处理ARC断言集，以通知消息处置决策，识别可能破坏现有身份验证机制的Internet邮件处理程序，并跨信任边界传递原始身份验证评估。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8617.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8617.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. General Concepts . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Custody . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Chain of Custody . . . . . . . . . . . . . . . . . . . . 6
2.4. Validation of Chain of Custody . . . . . . . . . . . . . 6
3. Terminology and Definitions . . . . . . . . . . . . . . . . . 6
3.1. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Authenticated Received Chain (ARC) . . . . . . . . . . . 7
3.3. Internet Mail Handlers / Intermediaries . . . . . . . . . 7
3.4. Authentication Assessment . . . . . . . . . . . . . . . . 7
3.5. Signing vs. Sealing . . . . . . . . . . . . . . . . . . . 8
3.6. Sealer . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.7. Validator . . . . . . . . . . . . . . . . . . . . . . . . 8
3.8. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . 8
3.9. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . 8
4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 9
4.1. ARC Header Fields . . . . . . . . . . . . . . . . . . . . 9
4.1.1. ARC-Authentication-Results (AAR) . . . . . . . . . . 9
4.1.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . 9
4.1.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . 11
4.1.4. Internationalized Email (EAI) . . . . . . . . . . . . 12
4.2. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 12
4.3. Authenticated Received Chain . . . . . . . . . . . . . . 13
4.4. Chain Validation Status . . . . . . . . . . . . . . . . . 13
5. Protocol Actions . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Sealer Actions . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Header Fields to Include in ARC-Seal Signatures . . . 15
5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains . . . 15
5.1.3. Only One Authenticated Received Chain per Message . . 16
5.1.4. Broad Ability to Seal . . . . . . . . . . . . . . . . 16
5.1.5. Sealing Is Always Safe . . . . . . . . . . . . . . . 16
5.2. Validator Actions . . . . . . . . . . . . . . . . . . . . 17
5.2.1. All Failures Are Permanent . . . . . . . . . . . . . 18
5.2.2. Responding to ARC Validation Failures during the SMTP
Transaction . . . . . . . . . . . . . . . . . . . . . 19
6. Communication of Validation Results . . . . . . . . . . . . . 19
7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Communicate Authentication Assessment across Trust
Boundaries . . . . . . . . . . . . . . . . . . . . . . . 19
7.1.1. Message-Scanning Services . . . . . . . . . . . . . . 20
7.1.2. Multi-tier MTA Processing . . . . . . . . . . . . . . 20
7.1.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 20
7.2. Inform Message Disposition Decisions . . . . . . . . . . 21
7.2.1. DMARC Local Policy Overrides . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. General Concepts . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Custody . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Chain of Custody . . . . . . . . . . . . . . . . . . . . 6
2.4. Validation of Chain of Custody . . . . . . . . . . . . . 6
3. Terminology and Definitions . . . . . . . . . . . . . . . . . 6
3.1. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Authenticated Received Chain (ARC) . . . . . . . . . . . 7
3.3. Internet Mail Handlers / Intermediaries . . . . . . . . . 7
3.4. Authentication Assessment . . . . . . . . . . . . . . . . 7
3.5. Signing vs. Sealing . . . . . . . . . . . . . . . . . . . 8
3.6. Sealer . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.7. Validator . . . . . . . . . . . . . . . . . . . . . . . . 8
3.8. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . 8
3.9. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . 8
4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 9
4.1. ARC Header Fields . . . . . . . . . . . . . . . . . . . . 9
4.1.1. ARC-Authentication-Results (AAR) . . . . . . . . . . 9
4.1.2. ARC-Message-Signature (AMS) . . . . . . . . . . . . . 9
4.1.3. ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . . 11
4.1.4. Internationalized Email (EAI) . . . . . . . . . . . . 12
4.2. ARC Set . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1. Instance Tags . . . . . . . . . . . . . . . . . . . . 12
4.3. Authenticated Received Chain . . . . . . . . . . . . . . 13
4.4. Chain Validation Status . . . . . . . . . . . . . . . . . 13
5. Protocol Actions . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Sealer Actions . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Header Fields to Include in ARC-Seal Signatures . . . 15
5.1.2. Marking and Sealing "cv=fail" (Invalid) Chains . . . 15
5.1.3. Only One Authenticated Received Chain per Message . . 16
5.1.4. Broad Ability to Seal . . . . . . . . . . . . . . . . 16
5.1.5. Sealing Is Always Safe . . . . . . . . . . . . . . . 16
5.2. Validator Actions . . . . . . . . . . . . . . . . . . . . 17
5.2.1. All Failures Are Permanent . . . . . . . . . . . . . 18
5.2.2. Responding to ARC Validation Failures during the SMTP
Transaction . . . . . . . . . . . . . . . . . . . . . 19
6. Communication of Validation Results . . . . . . . . . . . . . 19
7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Communicate Authentication Assessment across Trust
Boundaries . . . . . . . . . . . . . . . . . . . . . . . 19
7.1.1. Message-Scanning Services . . . . . . . . . . . . . . 20
7.1.2. Multi-tier MTA Processing . . . . . . . . . . . . . . 20
7.1.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 20
7.2. Inform Message Disposition Decisions . . . . . . . . . . 21
7.2.1. DMARC Local Policy Overrides . . . . . . . . . . . . 21
7.2.2. DMARC Reporting . . . . . . . . . . . . . . . . . . . 22
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9.1. Increased Header Field Size . . . . . . . . . . . . . . . 23
9.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 23
9.3. Message Content Suspicion . . . . . . . . . . . . . . . . 24
9.4. Message Sealer Suspicion . . . . . . . . . . . . . . . . 24
9.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10.1. Update to Email Authentication Result Names Registry . . 25
10.2. Update to Email Authentication Methods Registry . . . . 25
10.3. New Header Fields in Permanent Message Header Field
Registry . . . . . . . . . . . . . . . . . . . . . . . . 26
10.4. New Status Code in Enumerated Status Codes Registry . . 26
11. Experimental Considerations . . . . . . . . . . . . . . . . . 27
11.1. Success Consideration . . . . . . . . . . . . . . . . . 27
11.2. Failure Considerations . . . . . . . . . . . . . . . . . 27
11.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 27
11.3.1. Value of the ARC-Seal (AS) Header Field . . . . . . 27
11.3.2. Usage and/or Signals from Multiple Selectors and/or
Domains in ARC Sets . . . . . . . . . . . . . . . . 28
11.3.3. DNS Overhead . . . . . . . . . . . . . . . . . . . . 28
11.3.4. What Trace Information Is Valuable? . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Design Requirements . . . . . . . . . . . . . . . . 32
A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 32
A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 32
Appendix B. Example Usage . . . . . . . . . . . . . . . . . . . 32
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
7.2.2. DMARC Reporting . . . . . . . . . . . . . . . . . . . 22
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9.1. Increased Header Field Size . . . . . . . . . . . . . . . 23
9.2. DNS Operations . . . . . . . . . . . . . . . . . . . . . 23
9.3. Message Content Suspicion . . . . . . . . . . . . . . . . 24
9.4. Message Sealer Suspicion . . . . . . . . . . . . . . . . 24
9.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10.1. Update to Email Authentication Result Names Registry . . 25
10.2. Update to Email Authentication Methods Registry . . . . 25
10.3. New Header Fields in Permanent Message Header Field
Registry . . . . . . . . . . . . . . . . . . . . . . . . 26
10.4. New Status Code in Enumerated Status Codes Registry . . 26
11. Experimental Considerations . . . . . . . . . . . . . . . . . 27
11.1. Success Consideration . . . . . . . . . . . . . . . . . 27
11.2. Failure Considerations . . . . . . . . . . . . . . . . . 27
11.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 27
11.3.1. Value of the ARC-Seal (AS) Header Field . . . . . . 27
11.3.2. Usage and/or Signals from Multiple Selectors and/or
Domains in ARC Sets . . . . . . . . . . . . . . . . 28
11.3.3. DNS Overhead . . . . . . . . . . . . . . . . . . . . 28
11.3.4. What Trace Information Is Valuable? . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Design Requirements . . . . . . . . . . . . . . . . 32
A.1. Primary Design Criteria . . . . . . . . . . . . . . . . . 32
A.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 32
Appendix B. Example Usage . . . . . . . . . . . . . . . . . . . 32
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
The utility of widely deployed email authentication technologies such as Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified Mail (DKIM) [RFC6376] is impacted by the processing of Internet Mail by intermediate handlers. This impact is thoroughly documented in the defining documents for SPF and DKIM and further discussed in [RFC6377] and [RFC7960].
广泛部署的电子邮件身份验证技术（如发件人策略框架（SPF）[RFC7208]和域密钥识别邮件（DKIM）[RFC6376]等）的效用受到中间处理程序处理Internet邮件的影响。SPF和DKIM的定义文件详细记录了这种影响，并在[RFC6377]和[RFC7960]中进一步讨论。
Domain-based Message Authentication, Reporting, and Conformance (DMARC) [RFC7489] also relies upon SPF and DKIM authentication mechanisms. Failures of authentication caused by the actions of intermediate handlers can cause legitimate mail to be incorrectly rejected or misdirected.
基于域的消息身份验证、报告和一致性（DMARC）[RFC7489]还依赖于SPF和DKIM身份验证机制。由中间处理程序的操作导致的身份验证失败可能会导致合法邮件被错误拒绝或定向错误。
Authenticated Received Chain (ARC) creates a mechanism for individual Internet Mail Handlers to add their authentication assessment to a message's ordered set of handling results. ARC encapsulates the authentication assessment in a DKIM signature derivative to grant other handlers the ability to verify the authenticity of the individual assessment assertion as well as the aggregate set and sequence of results.
Authenticated Received Chain（ARC）为单个Internet邮件处理程序创建一种机制，将其身份验证评估添加到邮件的有序处理结果集中。ARC将身份验证评估封装在DKIM签名派生中，以授予其他处理程序验证单个评估断言以及聚合集和结果序列的真实性的能力。
Ordered sets of authentication assessments can be used by ARC-enabled Internet Mail Handlers to inform message-handling disposition, identify where alteration of message content might have occurred, and provide additional trace information for use in understanding message-handling paths.
启用ARC的Internet邮件处理程序可以使用有序的身份验证评估集来通知邮件处理处置，识别可能发生邮件内容更改的位置，并提供用于理解邮件处理路径的附加跟踪信息。
ARC is loosely based on concepts from evidence collection. Evidence is usually collected, labeled, stored, and transported in specific ways to preserve the state of evidence and to document all processing steps.
ARC松散地基于证据收集的概念。证据通常以特定的方式收集、标记、存储和运输，以保存证据状态并记录所有处理步骤。
In ARC's situation, the "evidence" is a message's authentication assessment at any point along the delivery path between origination and final delivery. Determination of message authentication can be affected when intermediate handlers modify message content (header fields and/or body content), route messages through unforeseen paths, or change envelope information.
在ARC的情况下，“证据”是消息在发起和最终传递之间的传递路径上的任何一点上的身份验证评估。当中间处理程序修改消息内容（头字段和/或正文内容）、通过不可预见的路径路由消息或更改信封信息时，消息身份验证的确定可能会受到影响。
The authentication assessment for a message is determined upon receipt of a message and documented in the Authentication-Results header field(s). ARC extends this mechanism to survive transit through intermediary Administrative Management Domains (ADMDs).
消息的身份验证评估在收到消息时确定，并记录在身份验证结果标头字段中。ARC扩展了这一机制，以在通过中间管理域（ADMD）的传输中生存。
Because the first-hand determination of an authentication assessment can never be reproduced by other handlers, the assertion of the authentication assessment is more akin to testimony by a verifiable party than to hard evidence, which can be independently evaluated.
由于认证评估的第一手决定永远无法由其他处理人员复制，因此认证评估的主张更类似于可验证方的证词，而不是可以独立评估的硬证据。
"Custody" refers to when an Internet Mail Handler processes a message. When a handler takes custody of a message, the handler becomes a custodian and attaches its own evidence (authentication assessment upon receipt) to the message if it is ARC enabled. Evidence is added in such a way that future handlers can verify the authenticity of both evidence and custody.
“保管”指互联网邮件处理程序处理邮件的时间。当处理程序保管邮件时，如果启用了ARC，则处理程序将成为保管人并将其自己的证据（收到时的身份验证评估）附加到邮件。证据是以这样一种方式添加的，未来的处理者可以验证证据和监护权的真实性。
The "chain of custody" of ARC is the entire set of evidence and custody that travels with a message.
ARC的“监管链”是一整套证据和监管信息。
Any ARC-enabled Internet Mail Handler can validate the entire set of custody and the authentication assessments asserted by each party to yield a valid chain of custody. If the evidence-supplying custodians can be trusted, then the validated chain of custody describes the (possibly changing) authentication assessment as the message traveled through various custodians.
任何启用ARC的Internet邮件处理程序都可以验证各方声明的整个托管集和身份验证评估，以生成有效的托管链。如果可以信任提供证据的保管人，那么经过验证的保管链将在消息通过各个保管人时描述（可能会更改）身份验证评估。
Even though a message's authentication assessment might have changed, the validated chain of custody can be used to determine if the changes (and the custodians responsible for the changes) can be tolerated.
即使消息的身份验证评估可能已更改，也可以使用经过验证的保管链来确定是否可以容忍更改（以及负责更改的保管人）。
This section defines terms used in the rest of the document.
本节定义了文档其余部分中使用的术语。
Readers should to be familiar with the contents, core concepts, and definitions found in [RFC5598]. The potential roles of transit services in the delivery of email are directly relevant.
读者应熟悉[RFC5598]中的内容、核心概念和定义。运输服务在电子邮件传递中的潜在作用是直接相关的。
Language, syntax (including some ABNF constructs), and concepts are imported from DKIM [RFC6376]. Specific references to DKIM are made throughout this document. The following terms are imported from [RFC5598]:
语言、语法（包括一些ABNF构造）和概念从DKIM[RFC6376]导入。本文件中对DKIM进行了具体引用。以下术语从[RFC5598]导入：
o Administrative Management Domain (ADMD), Section 2.3
o 行政管理领域（ADMD），第2.3节
o Message Transfer Agent (MTA), Section 4.3.2
o 邮件传输代理（MTA），第4.3.2节
o Message Submission Agent (MSA), Section 4.3.1
o 消息提交代理（MSA），第4.3.1节
o Message Delivery Agent (MDA), Section 4.3.3
o 消息传递代理（MDA），第4.3.3节
Syntax descriptions use ABNF [RFC5234] [RFC7405].
语法描述使用ABNF[RFC5234][RFC7405]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Section 4.1 introduces three (3) ARC header fields that are added to a message by an ARC-enabled Internet Mail Handler. Together, these three header fields compose a single "ARC Set". An ARC Set provides the means for an Internet Mail Handler to attach an authentication assessment to a message in a manner that can be verified by future handlers. A single message can contain multiple ARC Sets.
第4.1节介绍了三（3）个ARC头字段，这些字段由启用ARC的Internet邮件处理程序添加到邮件中。这三个标题字段一起构成一个“弧集”。ARC集为Internet邮件处理程序提供了将身份验证评估附加到消息的方法，该方法可以由将来的处理程序进行验证。一条消息可以包含多个弧集。
In general concept terms, an ARC Set represents Evidence and Custody.
在一般概念术语中，弧集表示证据和监护权。
The sequence of ARC Sets attached to a message at a given time is called the "Authenticated Received Chain" or "ARC". An Authenticated Received Chain is the record of individual authentication assessments as a message traverses through ARC-participating ADMDs.
在给定时间附加到消息的ARC集序列称为“已验证的接收链”或“ARC”。已验证的接收链是消息通过参与ARC的ADMD时，单个验证评估的记录。
The first attachment of an ARC Set to a message causes an Authenticated Received Chain to be created. Additional attachments of ARC Sets cause the Authenticated Received Chain to be extended.
将ARC集的第一个附件附加到消息会导致创建经过身份验证的接收链。ARC集合的附加附件导致已验证的接收链被扩展。
In general concept terms, an Authenticated Received Chain represents a chain of custody.
在一般概念术语中，经过身份验证的接收链表示保管链。
Internet Mail Handlers process and deliver messages across the Internet and include MSAs, MTAs, MDAs, gateways, and mailing lists as defined in [RFC5598].
Internet邮件处理程序跨Internet处理和传递邮件，包括[RFC5598]中定义的MSA、MTA、MDA、网关和邮件列表。
Throughout this document, the term "intermediaries" refers to both regular MTAs as well as delivery/reposting agents such as mailing lists covered within the scope of transit services per [RFC5598].
在本文件中，“中间人”一词既指常规MTA，也指交付/转售代理，如[RFC5598]规定的运输服务范围内的邮件列表。
"Intermediaries" and "Internet Mail Handlers" are used synonymously throughout this document.
“中间人”和“Internet邮件处理程序”在本文档中同义使用。
The authentication assessment that is affixed to a message as part of each ARC Set consists of the "authres-payload" [RFC8601]. For the integrity of an ARC Set, the authentication assessment only needs to be properly encapsulated within the ARC Set as defined in Section 4.1. The accuracy or syntax of the authres-payload field does not affect the validity of the ARC Chain itself.
作为每个ARC集的一部分附加到消息的身份验证评估由“authres有效负载”[RFC8601]组成。为了保证ARC集的完整性，认证评估只需正确封装在第4.1节定义的ARC集内。authres有效载荷字段的准确性或语法不影响ARC链本身的有效性。
Signing is the process of affixing a digital signature to a message as a header field, such as when a DKIM-Signature (as in [RFC6376], Section 2.1), an AMS, or an AS is added. Sealing is when an ADMD affixes a complete and valid ARC Set to a message to create or continue an Authenticated Received Chain.
签名是将数字签名作为标题字段粘贴到消息的过程，例如添加DKIM签名（如[RFC6376]第2.1节）、AMS或as时。密封是指ADMD将完整有效的弧集附加到消息，以创建或继续经过身份验证的接收链。
A Sealer is an Internet Mail Handler that attaches a complete and valid ARC Set to a message.
封箱是一种Internet邮件处理程序，它将完整有效的弧集附加到邮件。
In general concept terms, a Sealer adds its testimony (assertion of authentication assessment) and proof of custody to the chain of custody.
在一般概念术语中，封口商将其证词（认证评估断言）和保管证明添加到保管链中。
A Validator is an ARC-enabled Internet Mail Handler that evaluates an Authenticated Received Chain for validity and content. The process of evaluation of the individual ARC Sets that compose an Authenticated Received Chain is described in Section 5.2.
验证器是一个启用ARC的Internet邮件处理程序，用于评估经过身份验证的接收链的有效性和内容。第5.2节描述了组成认证接收链的单个ARC集的评估过程。
In general concept terms, a Validator inspects the chain of custody to determine the content and validity of individual evidence supplied by custodians.
一般来说，验证者检查保管链，以确定保管人提供的个人证据的内容和有效性。
The following ABNF tokens are imported:
将导入以下ABNF令牌：
o tag-list ([RFC6376], Section 3.2)
o 标签列表（[RFC6376]，第3.2节）
o authres-payload ([RFC8601], Section 2.2)
o 授权有效载荷（[RFC8601]，第2.2节）
o CFWS ([RFC5322], Section 3.2.2)
o CFWS（[RFC5322]，第3.2.2节）
The following ABNF tokens are used elsewhere in this document:
以下ABNF代币在本文件其他地方使用：
position = 1*2DIGIT ; 1 - 50
instance = [CFWS] %s"i" [CFWS] "="
[CFWS] position
chain-status = ("none" / "fail" / "pass")
seal-cv-tag = %s"cv" [CFWS] "="
[CFWS] chain-status
position = 1*2DIGIT ; 1 - 50
instance = [CFWS] %s"i" [CFWS] "="
[CFWS] position
chain-status = ("none" / "fail" / "pass")
seal-cv-tag = %s"cv" [CFWS] "="
[CFWS] chain-status
ARC introduces three new header fields. The syntax for new header fields adapts existing specifications. This document only describes where ARC-specific changes in syntax and semantics differ from existing specifications.
ARC引入了三个新的标题字段。新标题字段的语法适用于现有规范。本文档仅描述特定于ARC的语法和语义更改与现有规范的不同之处。
The ARC-Authentication-Results (AAR) header field records the message authentication assessment as processed by an ARC-participating ADMD at message arrival time.
ARC身份验证结果（AAR）标头字段记录ARC参与的ADMD在消息到达时处理的消息身份验证评估。
In general concept terms, the AAR header field is where evidence is recorded by a custodian.
在一般概念术语中，AAR标题字段是保管人记录证据的地方。
The AAR header field is similar in syntax and semantics to an Authentication-Results field [RFC8601], with two (2) differences:
AAR头字段在语法和语义上与身份验证结果字段[RFC8601]相似，但有两（2）个区别：
o the name of the header field itself and
o 标题字段本身的名称，以及
o the presence of the instance tag. Additional information on the instance tag can be found in Section 4.2.1.
o 实例标记的存在。有关实例标记的其他信息，请参见第4.2.1节。
The formal ABNF for the AAR header field is:
AAR标题字段的正式ABNF为：
arc-info = instance [CFWS] ";" authres-payload
arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info
arc-info = instance [CFWS] ";" authres-payload
arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info
Because there is only one AAR allowed per ARC Set, the AAR MUST contain the combined authres-payload with all of the authentication results from within the participating ADMD, regardless of how many Authentication-Results header fields are attached to the message.
因为每个ARC集只允许一个AAR，所以AAR必须包含组合的authres有效负载以及参与ADMD内的所有身份验证结果，而不管消息附加了多少身份验证结果头字段。
The ARC-Message-Signature (AMS) header field allows an ARC-participating ADMD to convey some responsibility (custodianship) for a message and possible message modifications to future ARC-participating custodians.
ARC消息签名（AMS）标题字段允许ARC参与ADMD向未来ARC参与保管人传达一些消息责任（保管）和可能的消息修改。
In general concept terms, the AMS header field identifies a custodian.
在一般概念术语中，AMS标题字段标识保管人。
The AMS header field has the same syntax and semantics as the DKIM-Signature field [RFC6376], with three (3) differences:
AMS标头字段与DKIM签名字段[RFC6376]具有相同的语法和语义，但有三（3）个区别：
o the name of the header field itself;
o 标题字段本身的名称；
o no version tag ("v") is defined for the AMS header field. As required for undefined tags (in [RFC6376]), if seen, a version tag MUST be ignored; and
o 没有为AMS标题字段定义版本标记（“v”）。对于未定义的标记（在[RFC6376]中），如果看到，则必须忽略版本标记；和
o the "i" (Agent or User Identifier (AUID)) tag is not imported from DKIM; instead, this tag is replaced by the instance tag as defined in Section 4.2.1.
o “i”（代理或用户标识符（AUID））标记不是从DKIM导入的；相反，该标记将替换为第4.2.1节中定义的实例标记。
ARC places no requirements on the selectors and/or domains used for the AMS header field signatures.
ARC对用于AMS标题字段签名的选择器和/或域没有任何要求。
The formal ABNF for the AMS header field is:
AMS标题字段的正式ABNF为：
arc-ams-info = instance [CFWS] ";" tag-list
arc-message-signature = "ARC-Message-Signature:" [CFWS] arc-ams-info
arc-ams-info = instance [CFWS] ";" tag-list
arc-message-signature = "ARC-Message-Signature:" [CFWS] arc-ams-info
To reduce the chances of accidental invalidation of AMS signatures:
为减少AMS签名意外失效的可能性：
o AMS header fields are added by ARC-participating ADMDs as messages exit the ADMD. AMS header fields SHOULD be attached so that any modifications made by the ADMD are included in the signature of the AMS header field.
o 当消息退出ADMD时，参与ARC的ADMD会添加AMS标头字段。应附加AMS标题字段，以便ADMD所做的任何修改都包含在AMS标题字段的签名中。
o Authentication-Results header fields MUST NOT be included in AMS signatures as they are likely to be deleted by downstream ADMDs (per [RFC8601], Section 5).
o 认证结果标题字段不得包含在AMS签名中，因为下游ADMD可能会删除这些字段（根据[RFC8601]，第5节）。
o ARC-related header fields (ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal) MUST NOT be included in the list of header fields covered by the signature of the AMS header field.
o 与ARC相关的标题字段（ARC认证结果、ARC消息签名和ARC印章）不得包含在AMS标题字段签名所涵盖的标题字段列表中。
To preserve the ability to verify the integrity of a message, the signature of the AMS header field SHOULD include any DKIM-Signature header fields already present in the message.
为保持验证消息完整性的能力，AMS头字段的签名应包括消息中已存在的任何DKIM签名头字段。
The AS header field permits ARC-participating ADMDs to verify the integrity of AAR header fields and corresponding AMS header fields.
AS标头字段允许ARC参与ADMD验证AAR标头字段和相应AMS标头字段的完整性。
In general concept terms, the AS header field is how custodians bind their authentication assessments (testimonials) into a chain of custody so that Validators can inspect individual evidence and custodians.
在一般概念术语中，AS头字段是保管人如何将其身份验证评估（证明）绑定到保管链中，以便验证者可以检查个人证据和保管人。
The AS header field is similar in syntax and semantics to DKIM-Signature header fields [RFC6376], with the following differences:
AS头字段在语法和语义上与DKIM签名头字段[RFC6376]相似，但有以下区别：
o the "i" (AUID) tag is not imported from DKIM; instead, this tag is replaced by the instance tag as defined in Section 4.2.1;
o “i”（AUID）标签不是从DKIM导入的；相反，该标签由第4.2.1节中定义的实例标签替换；
o the signature of the AS header field does not cover the body of the message; therefore, there is no "bh" tag. The signature of the AS header field only covers specific header fields as defined in Section 5.1.1;
o AS标头字段的签名不包括消息的正文；因此，没有“bh”标签。AS标题字段的签名仅包括第5.1.1节中定义的特定标题字段；
o no body canonicalization is performed as the AS signature does not cover the body of a message;
o 不执行正文规范化，因为as签名不覆盖消息正文；
o only "relaxed" header field canonicalization ([RFC6376], Section 3.4.2) is used;
o 仅使用“宽松”标题字段规范化（[RFC6376]，第3.4.2节）；
o the only supported tags are "i" (from Section 4.2.1 of this document), and "a", "b", "d", "s", and "t" from [RFC6376], Section 3.5. Note especially that the DKIM "h" tag is NOT allowed and, if found, MUST result in a cv status of "fail" (for more information, see Section 5.1.1); and
o 唯一受支持的标签是“i”（来自本文件第4.2.1节），以及[RFC6376]第3.5节中的“a”、“b”、“d”、“s”和“t”。特别注意，不允许使用DKIM“h”标签，如果发现，必须导致cv状态为“失败”（有关更多信息，请参阅第5.1.1节）；和
o an additional tag, "cv" ("seal-cv-tag" in the ARC-Seal ABNF definition), is used to communicate the Chain Validation Status to subsequent ADMDs.
o 另一个标签“cv”（“ARC seal ABNF定义中的“seal cv tag”）用于向后续ADMD传达链验证状态。
ARC places no requirements on the selectors and/or domains used for the AS header field signatures.
ARC对用于AS标头字段签名的选择器和/或域没有任何要求。
The formal ABNF for the AS header field is:
AS标头字段的正式ABNF为：
arc-as-info = instance [CFWS] ";" tag-list
arc-seal = "ARC-Seal:" [CFWS] arc-as-info
arc-as-info = instance [CFWS] ";" tag-list
arc-seal = "ARC-Seal:" [CFWS] arc-as-info
In internationalized messages [RFC6532], many header fields can contain UTF-8 as well as ASCII text. The changes for EAI are all inherited from DKIM as updated by [RFC8616] and Authentication-Results (A-R) as updated in [RFC8601], but they are called out here for emphasis.
在国际化消息[RFC6532]中，许多头字段可以包含UTF-8以及ASCII文本。EAI的更改都是从[RFC8616]更新的DKIM和[RFC8601]更新的身份验证结果（A-R）继承而来的，但此处调用这些更改是为了强调。
In all ARC header fields, the d= and s= tags can contain U-labels. In all tags, non-ASCII characters need not be quoted in dkim-quoted-printable.
在所有弧头字段中，d=和s=标记可以包含U形标签。在所有标记中，dkim quoted printable中不需要引用非ASCII字符。
The AAR header allows UTF-8 in the same places that Authentication-Results does, as described in [RFC8601].
AAR报头允许UTF-8与身份验证结果位于相同的位置，如[RFC8601]中所述。
An "ARC Set" is a single collection of three ARC header fields (AAR, AMS, and AS). ARC header fields of an ARC Set share the same "instance" value.
“弧集”是三个弧头字段（AAR、AMS和AS）的单个集合。弧集的弧头字段共享相同的“实例”值。
By adding all ARC header fields to a message, an ARC Sealer adds an ARC Set to a message. A description of how Sealers add an ARC Set to a message is found in Section 5.1.
通过将所有弧头字段添加到消息中，弧密封器将弧集添加到消息中。第5.1节介绍了密封剂如何将弧集添加到信息中。
Instance tags describe which ARC header fields belong to an ARC Set. Each ARC header field of an ARC Set shares the same instance tag value.
实例标记描述哪些弧头字段属于弧集。弧集的每个弧头字段共享相同的实例标记值。
Instance tag values are integers that begin at 1 and are incremented by each addition of an ARC Set. Through the incremental values of instance tags, an ARC Validator can determine the order in which ARC Sets were added to a message.
实例标记值是从1开始的整数，每次添加弧集都会递增。通过实例标记的增量值，ARC验证器可以确定将ARC集添加到消息中的顺序。
Instance tag values can range from 1-50 (inclusive).
实例标记值的范围为1-50（包括1-50）。
_INFORMATIONAL_: The upper limit of 50 was picked based on some initial observations reported by early working group members. The value was chosen to balance the risk of excessive header field growth (see Section 9.1) against expert opinion regarding the probability of long-tail, but non-looping, multiple-intermediary mail flows. Longer ARC Chains will also impose a load on Validators and DNS to support additional verification steps. Observed quantities of "Received" header fields were also considered in establishing this as an experimental initial value.
_信息：50的上限是根据早期工作组成员报告的一些初步观察结果确定的。选择该值是为了平衡标头字段过度增长的风险（见第9.1节）与专家关于长尾但非循环的多个中间邮件流概率的意见。较长的ARC链还将对验证器和DNS施加负载，以支持额外的验证步骤。在将其确定为实验初始值时，还考虑了观察到的“接收”标题字段数量。
Valid ARC Sets MUST have exactly one instance of each ARC header field (AAR, AMS, and AS) for a given instance value and signing algorithm.
对于给定的实例值和签名算法，有效的弧集必须具有每个弧头字段（AAR、AMS和AS）的一个实例。
For handling multiple signing algorithms, see [ARC-MULTI].
有关处理多个签名算法的信息，请参阅[ARC-MULTI]。
An Authenticated Received Chain is an ordered collection of ARC Sets. As ARC Sets are enumerated sets of ARC header fields, an Authenticated Received Chain represents the output of message authentication assessments along the handling path of ARC-enabled processors.
经过身份验证的接收链是弧集的有序集合。由于ARC集是ARC头字段的枚举集，因此经过身份验证的接收链表示沿启用ARC的处理器的处理路径的消息身份验证评估的输出。
Authentication assessments determined at each step of the ARC-enabled handling path are present in an Authenticated Received Chain in the form of AAR header fields. The ability to verify the identity of message handlers and the integrity of message content is provided by AMS header fields. AS header fields allow message handlers to validate the assertions, order, and sequence of the Authenticated Received Chain itself.
在启用ARC的处理路径的每个步骤中确定的身份验证评估以AAR头字段的形式存在于经过身份验证的接收链中。AMS头字段提供了验证消息处理程序身份和消息内容完整性的功能。AS头字段允许消息处理程序验证经过身份验证的接收链本身的断言、顺序和序列。
In general concept terms, an Authenticated Received Chain represents a message's chain of custody. Validators can consult a message's chain of custody to gain insight regarding each custodian of a message and the evidence collected by each custodian.
在一般概念术语中，经过身份验证的接收链表示消息的保管链。验证器可以咨询邮件的保管链，以了解邮件的每个保管人以及每个保管人收集的证据。
The state of the Authenticated Received Chain at a specific processing step is called the "Chain Validation Status". Chain Validation Status information is communicated in several ways:
在特定的处理步骤中，经过身份验证的接收链的状态称为“链验证状态”。链验证状态信息通过以下几种方式传达：
o as the AS header field in the "cv" tag and
o 作为“cv”标记中的as标头字段，以及
o as part of the Authentication-Results and AAR header field(s).
o 作为身份验证结果和AAR标头字段的一部分。
Chain Validation Status has one of three possible values:
链验证状态有三个可能值之一：
o none: There was no Authenticated Received Chain on the message when it arrived for validation. Typically, this occurs when a message is received directly from a message's original Message Transfer Agent (MTA) or Message Submission Agent (MSA), or from an upstream Internet Mail Handler that is not participating in ARC handling.
o 无：消息到达进行验证时，消息上没有经过身份验证的接收链。通常，当直接从邮件的原始邮件传输代理（MTA）或邮件提交代理（MSA），或从不参与ARC处理的上游Internet邮件处理程序接收邮件时，会发生这种情况。
o fail: The message contains an Authenticated Received Chain whose validation failed.
o 失败：消息包含验证失败的已验证接收链。
o pass: The message contains an Authenticated Received Chain whose validation succeeded.
o pass：消息包含已验证的已接收链，其验证成功。
ARC-enabled Internet Mail Handlers generally act as both ARC Validators (when receiving messages) and ARC Sealers (when sending messages onward, not originated locally).
启用ARC的Internet邮件处理程序通常充当ARC验证器（在接收邮件时）和ARC密封器（在向前发送邮件时，不在本地发起）。
An Authenticated Received Chain with a Chain Validation Status of "pass" (or "none") allows Internet Mail Handlers to ascertain:
链验证状态为“通过”（或“无”）的已验证接收链允许Internet邮件处理程序确定：
o all ARC-participating ADMDs that claim responsibility for handling (and possibly modifying) the message in transit and
o 声称负责处理（并可能修改）传输中的邮件的所有ARC参与ADMD，以及
o the authentication assessments of the message as determined by each ADMD (from AAR header fields).
o 由每个ADMD确定的消息的身份验证评估（来自AAR标头字段）。
With this information, Internet Mail Handlers MAY inform local policy decisions regarding disposition of messages that experience authentication failure due to intermediate processing.
有了这些信息，Internet邮件处理程序可以通知本地策略决定如何处置由于中间处理而遇到身份验证失败的邮件。
To "seal" a message, an ARC Sealer adds an ARC Set (the three ARC header fields AAR, AMS, and AS) to a message. All ARC header fields in an ARC Set share the same instance tag value.
要“密封”消息，ARC密封器会向消息中添加一个ARC集（三个ARC标题字段AAR、AMS和AS）。弧集中的所有弧头字段共享相同的实例标记值。
To perform sealing (aka to build and attach a new ARC Set), the following actions must be taken by an ARC Sealer when presented with a message:
要执行密封（又名构建和连接新的电弧组），电弧密封器在显示消息时必须执行以下操作：
1. All message modifications (including adding a DKIM-Signature header field(s)) MUST be performed before sealing.
1. 所有消息修改（包括添加DKIM签名头字段）必须在密封之前执行。
2. If the message already contains an Authenticated Received Chain with the most recent AS reporting "cv=fail", there is no need to proceed and the algorithm stops here.
2. 如果消息已经包含一个经过身份验证的接收链，最近的AS报告为“cv=fail”，则无需继续，算法在此停止。
3. Calculate the instance value. If the message already contains an Authenticated Received Chain, the instance value is 1 more than the highest instance number found in the Authenticated Received Chain. If no Authenticated Received Chain exists, the instance value is 1.
3. 计算实例值。如果消息已包含经过身份验证的接收链，则实例值比在经过身份验证的接收链中找到的最高实例号多1。如果不存在经过身份验证的接收链，则实例值为1。
4. Using the calculated instance value, generate and attach a complete ARC Set to the message as follows:
4. 使用计算的实例值，生成完整的弧集并将其附加到消息，如下所示：
A. Generate and attach an ARC-Authentication-Results header field as defined in Section 4.1.1.
A.生成并附加第4.1.1节中定义的ARC认证结果标题字段。
B. Generate and attach an ARC-Message-Signature header field as defined in Section 4.1.2.
B.生成并附加第4.1.2节中定义的ARC消息签名头字段。
C. Generate and attach an ARC-Seal header field using the AS definition found in Section 4.1.3, the prescribed headers defined in Section 5.1.1, and the Chain Validation Status as determined during ARC validation.
C.使用第4.1.3节中的AS定义、第5.1.1节中定义的规定标题以及ARC验证期间确定的链验证状态，生成并附加ARC密封标题字段。
The ARC-Seal is generated in a manner similar to how DKIM-Signature header fields are added to messages ([RFC6376], Section 3.7), with explicit requirements on the header fields and ordering of those fields.
ARC印章的生成方式类似于将DKIM签名头字段添加到消息中的方式（[RFC6376]，第3.7节），对头字段和这些字段的顺序有明确的要求。
The signature of an AS header field signs a canonicalized form of the ARC Set header field values. The ARC Set header field values are supplied to the hash function in increasing instance order, starting at 1, and include the ARC Set being added at the time of sealing the message.
AS标头字段的签名对弧集标头字段值的规范化形式进行签名。ARC Set头字段值以递增的实例顺序提供给哈希函数，从1开始，并包括在密封消息时添加的ARC集合。
Within an ARC Set, header fields are supplied to the hash function in the following order:
在弧集中，头字段按以下顺序提供给哈希函数：
1. ARC-Authentication-Results
1. ARC身份验证结果
2. ARC-Message-Signature
2. ARC消息签名
3. ARC-Seal
3. 电弧密封
Note that when an Authenticated Received Chain has failed validation, the signing scope for the ARC-Seal is modified as specified in Section 5.1.2.
请注意，当认证接收链未通过验证时，ARC印章的签名范围将按照第5.1.2节的规定进行修改。
In the case of a failed Authenticated Received Chain, the header fields included in the signature scope of the AS header field b= value MUST only include the ARC Set header fields created by the MTA that detected the malformed chain, as if this newest ARC Set was the only set present.
如果接收到的链未通过身份验证，则AS header field b=值的签名范围中包含的头字段必须仅包括由检测到错误链的MTA创建的弧集头字段，就像此最新弧集是唯一存在的弧集一样。
_INFORMATIONAL_: This approach is mandated to handle the case of a malformed or otherwise invalid Authenticated Received Chain. There is no way to generate a deterministic set of AS header fields (Section 5.1.1) in most cases of invalid chains.
_信息：此方法用于处理格式错误或以其他方式无效的已验证接收链的情况。在大多数无效链的情况下，无法生成一组确定的AS标头字段（第5.1.1节）。
A message can have only one Authenticated Received Chain on it at a time. Once broken, the chain cannot be continued, as the chain of custody is no longer valid, and responsibility for the message has been lost. For further discussion of this topic and the design restriction that prevents chain continuation or re-establishment, see [ARC-USAGE].
消息一次只能有一个经过身份验证的接收链。一旦中断，该链将无法继续，因为保管链不再有效，并且对该消息的责任已丢失。有关此主题和阻止链继续或重建的设计限制的进一步讨论，请参阅[ARC-USERATION]。
ARC is not solely intended for perimeter MTAs. Any Internet Mail Handler MAY seal a message by adding a complete ARC Set, whether or not they have modified or are aware of having modified the message. For additional information, see Section 7.1.
ARC并非仅用于周边MTA。任何Internet邮件处理程序都可以通过添加完整的ARC集来密封邮件，无论他们是否已修改或知道已修改邮件。有关更多信息，请参见第7.1节。
The utility of an Authenticated Received Chain is limited to very specific cases. Authenticated Received Chains are designed to provide additional information to an Internet Mail Handler when evaluating messages for delivery in the context of authentication failures. Specifically:
经过身份验证的接收链的效用仅限于非常特定的情况。经过身份验证的接收链设计用于在身份验证失败的情况下评估邮件传递时向Internet邮件处理程序提供附加信息。明确地：
o Properly adding an ARC Set to a message does not damage or invalidate an existing Authenticated Received Chain.
o 正确地将ARC集添加到消息不会损坏或使现有的已验证接收链无效。
o Sealing an Authenticated Received Chain when a message has not been modified does not negatively affect the chain.
o 在消息未被修改时密封经过身份验证的接收链不会对链产生负面影响。
o Validating a message exposes no new threat vectors (see Section 9).
o 验证消息不会暴露新的威胁向量（参见第9节）。
o An ADMD may choose to seal all inbound messages whether or not a message has been modified or will be retransmitted.
o ADMD可以选择密封所有入站邮件，无论邮件是否已被修改或将被重新传输。
A Validator performs the following steps, in sequence, to process an Authenticated Received Chain. Canonicalization, hash functions, and signature validation methods are imported from [RFC6376], Section 5.
验证器按顺序执行以下步骤来处理经过身份验证的接收链。规范化、散列函数和签名验证方法从[RFC6376]第5节导入。
1. Collect all ARC Sets currently attached to the message.
1. 收集当前附加到邮件的所有弧集。
* If there are none, the Chain Validation Status is "none", and the algorithm stops here.
* 如果没有，则链验证状态为“无”，算法在此停止。
* The maximum number of ARC Sets that can be attached to a message is 50. If more than the maximum number exist, the Chain Validation Status is "fail", and the algorithm stops here.
* 可附加到消息的最大弧集数为50。如果存在的数量超过最大数量，则链验证状态为“失败”，算法在此停止。
* In the following algorithm, the maximum discovered ARC instance value is referred to as "N".
* 在以下算法中，发现的最大弧实例值称为“N”。
2. If the Chain Validation Status of the highest instance value ARC Set is "fail", then the Chain Validation Status is "fail", and the algorithm stops here.
2. 如果最高实例值弧集的链验证状态为“失败”，则链验证状态为“失败”，算法在此停止。
3. Validate the structure of the Authenticated Received Chain. A valid ARC has the following conditions:
3. 验证经过身份验证的接收链的结构。有效弧具有以下条件：
A. Each ARC Set MUST contain exactly one each of the three ARC header fields (AAR, AMS, and AS).
A.每个弧集必须仅包含三个弧头字段（AAR、AMS和AS）中的一个。
B. The instance values of the ARC Sets MUST form a continuous sequence from 1..N with no gaps or repetition.
B.弧集的实例值必须形成1..N的连续序列，没有间隙或重复。
C. The "cv" value for all ARC-Seal header fields MUST NOT be "fail". For ARC Sets with instance values > 1, the values MUST be "pass". For the ARC Set with instance value = 1, the value MUST be "none".
C.所有ARC Seal标题字段的“cv”值不得为“fail”。对于实例值大于1的圆弧集，值必须为“通过”。对于实例值为1的圆弧集，该值必须为“无”。
* If any of these conditions are not met, the Chain Validation Status is "fail", and the algorithm stops here.
* 如果不满足这些条件中的任何一个，则链验证状态为“失败”，算法在此停止。
4. Validate the AMS with the greatest instance value (most recent). If validation fails, then the Chain Validation Status is "fail", and the algorithm stops here.
4. 验证具有最大实例值（最近）的AMS。如果验证失败，则链验证状态为“失败”，算法在此停止。
5. _OPTIONAL_: Determine the "oldest-pass" value from the ARC Set by validating each prior AMS beginning with N-1 and proceeding in decreasing order to the AMS with the instance value of 1:
5. _可选：通过验证从N-1开始的每个先前的AMS，并以实例值1的降序进行AMS，从ARC集合中确定“最早的通过”值：
A. If an AMS fails to validate (for instance value "M"), then set the oldest-pass value to the lowest AMS instance value that passed (M+1), and go to the next step (there is no need to check any other (older) AMS header fields). This does not affect the validity of the Authenticated Received Chain.
A.如果AMS未能验证（例如值“M”），则将最旧的通过值设置为通过的最低AMS实例值（M+1），并转至下一步（无需检查任何其他（旧的）AMS标题字段）。这不会影响经过身份验证的接收链的有效性。
B. If all AMS header fields verify, set the oldest-pass value to zero (0).
B.如果所有AMS标题字段均已验证，则将最早的通过值设置为零（0）。
6. Validate each AS beginning with the greatest instance value and proceeding in decreasing order to the AS with the instance value of 1. If any AS fails to validate, the Chain Validation Status is "fail", and the algorithm stops here.
6. 从最大实例值开始验证每个AS，然后按降序继续验证实例值为1的AS。如果任何AS未能验证，则链验证状态为“fail”，算法在此停止。
7. If the algorithm reaches this step, then the Chain Validation Status is "pass", and the algorithm is complete.
7. 如果算法达到此步骤，则链验证状态为“通过”，且算法完成。
The end result of this validation algorithm SHOULD be included within the Authentication-Results header field for the ADMD.
此验证算法的最终结果应包含在ADMD的“身份验证结果”标题字段中。
As with a DKIM signature ([RFC6376], Section 6.3) that fails verification, a message with an Authenticated Received Chain with a Chain Validation Status of "fail" MUST be treated the same as a message with no Authenticated Received Chain.
与验证失败的DKIM签名（[RFC6376]，第6.3节）一样，具有链验证状态为“失败”的已验证接收链的消息必须被视为与未经验证接收链的消息相同。
_INFORMATIONAL_: Recipients of an invalid or failing Authenticated Received Chain can use that information as part of a wider handling context. ARC adoption cannot be assumed by intermediaries; many intermediaries will continue to modify messages without adding ARC seals.
_信息性：无效或未通过身份验证的接收链的收件人可以将该信息用作更广泛的处理上下文的一部分。中介机构不能假设采用ARC；许多中介机构将继续修改消息而不添加ARC密封。
Authenticated Received Chains represent the traversal of messages through one or more intermediaries. All errors, including DNS failures, become unrecoverable and are considered permanent.
经过身份验证的接收链表示消息通过一个或多个中介的遍历。所有错误（包括DNS故障）都将无法恢复，并被视为永久性错误。
Any error validating an Authenticated Received Chain results in a Chain Validation Status of "fail". For further discussion of this topic and the design restriction that prevents chain continuation or re-establishment, see [ARC-USAGE].
验证已验证的接收链的任何错误都会导致链验证状态为“失败”。有关此主题和阻止链继续或重建的设计限制的进一步讨论，请参阅[ARC-USERATION]。
5.2.2. Responding to ARC Validation Failures during the SMTP Transaction
5.2.2. 在SMTP事务期间响应ARC验证失败
If an ARC Validator determines that the incoming message fails ARC validation, the Validator MAY signal the breakage through the extended SMTP response code 5.7.29 ("ARC validation failure") and the corresponding SMTP basic response code. Because ARC failures are likely only to be detected in the context of other underlying authentication mechanism failures, Validators MAY use the more general 5.7.26 ("Multiple authentication checks failed") instead of the ARC-specific code.
如果ARC验证程序确定传入消息未通过ARC验证，则验证程序可能会通过扩展SMTP响应代码5.7.29（“ARC验证失败”）和相应的SMTP基本响应代码发出中断信号。由于ARC故障可能仅在其他底层身份验证机制故障的情况下检测到，因此验证器可以使用更通用的5.7.26（“多重身份验证检查失败”），而不是ARC特定的代码。
Chain Validation Status (described in Section 4.4) is communicated via Authentication-Results (and AAR) header fields using the authentication method "arc". This authentication method is described in Section 10.1.
链验证状态（如第4.4节所述）通过使用认证方法“arc”的认证结果（和AAR）头字段进行通信。第10.1节描述了该认证方法。
If necessary data is available, the ptypes and properties defined in Section 10.2 SHOULD be recorded in an Authentication-Results header field:
如果有必要的数据可用，则第10.2节中定义的P类型和属性应记录在认证结果标题字段中：
o smtp.remote-ip - The address of the connection-initiating SMTP server, from which the message is being relayed.
o smtp.remote-ip—启动smtp服务器的连接的地址，邮件将从该服务器进行中继。
o header.oldest-pass - The instance number of the oldest AMS that still validates, or 0 if all pass.
o header.oldest-pass—仍在验证的最旧AMS的实例号，如果全部通过，则为0。
This section explores several message handling use cases that are addressed by ARC.
本节探讨ARC处理的几个消息处理用例。
When an intermediary ADMD adds an ARC Set to a message's Authenticated Received Chain (or creates the initial ARC Set), the ADMD communicates its authentication assessment to the next ARC-participating ADMD in the message-handling path.
当中间ADMD向消息的已验证接收链添加ARC集（或创建初始ARC集）时，ADMD会将其验证评估传递给消息处理路径中的下一个ARC参与ADMD。
If ARC-enabled ADMDs are trusted, Authenticated Received Chains can be used to bridge administrative boundaries.
如果启用ARC的ADMD是可信的，则可以使用经过身份验证的接收链来桥接管理边界。
Message services are available to perform anti-spam, anti-malware, and anti-phishing scanning. Such services typically remove malicious content, replace HTTP links in messages with sanitized links, and/or attach footers to messages advertising the abilities of the message-scanning service. These modifications almost always break signature-based authentication (such as DKIM).
邮件服务可用于执行反垃圾邮件、反恶意软件和反钓鱼扫描。此类服务通常会删除恶意内容，用经过消毒的链接替换消息中的HTTP链接，和/或在消息上附加页脚，以宣传消息扫描服务的功能。这些修改几乎总是破坏基于签名的身份验证（如DKIM）。
Scanning services typically require clients to point MX records of an Internet domain to the scanning service. Messages destined for the Internet domain are initially delivered to the scanning service. Once scanning is performed, messages are then routed to the client's own mail-handling infrastructure. Rerouting messages in this way almost always breaks path-based authentication (such as SPF).
扫描服务通常要求客户端将Internet域的MX记录指向扫描服务。发送到Internet域的消息最初会传递到扫描服务。执行扫描后，邮件将被路由到客户端自己的邮件处理基础结构。以这种方式重新路由消息几乎总是破坏基于路径的身份验证（如SPF）。
Message-scanning services can attach Authenticated Received Chains to messages to communicate authentication assessment into client ADMDs. Clients can then benefit from the message-scanning service while processing messages as if the client's infrastructure were the original destination of the Internet domain's MX record.
消息扫描服务可以将经过身份验证的接收链连接到消息，以将身份验证评估传递到客户端ADMD。然后，客户端可以从消息扫描服务中获益，同时处理消息，就好像客户端的基础结构是Internet域MX记录的原始目的地一样。
A large message-processing infrastructure is often divided into several processing tiers that can break authentication information between tiers. For example, a large site may maintain a cluster of MTAs dedicated to connection handling and enforcement of IP-based reputation filtering. A secondary cluster of MTAs may be dedicated and optimized for content-based processing of messages.
大型消息处理基础架构通常分为几个处理层，这些处理层可以中断层之间的身份验证信息。例如，大型站点可能会维护一个MTA集群，专门用于连接处理和基于IP的信誉过滤的实施。MTA的第二个集群可以专用，并针对基于内容的邮件处理进行优化。
Authenticated Received Chains can be used to communicate authentication assessment between processing tiers.
经过身份验证的接收链可用于在处理层之间传递身份验证评估。
Mailing lists take delivery of messages and repost them to subscribers. A full description of authentication-related mailing list issues can be found in [RFC7960], Section 3.2.3.
邮件列表接收邮件并将其转发给订阅者。与身份验证相关的邮件列表问题的完整描述见[RFC7960]，第3.2.3节。
Mailing list services can implement ARC to convey the authentication assessment of posted messages sent to the list's subscriber base. The ADMDs of the mailing list subscribers can then use the Authenticated Received Chain to determine the authentication assessment of the original message before mailing list handling.
邮件列表服务可以实现ARC，以传递发送到列表订户群的已发布消息的身份验证评估。然后，邮件列表订阅者的ADMD可以在处理邮件列表之前，使用经过身份验证的接收链来确定原始消息的身份验证评估。
Intermediaries often break authentication through content modification, interfere with path-based authentication (such as SPF), and strip authentication results (if an MTA removes Authentication-Results header fields).
中介体通常通过内容修改中断身份验证，干扰基于路径的身份验证（如SPF），并剥离身份验证结果（如果MTA删除身份验证结果标头字段）。
Authenticated Received Chains allow ARC Validators to:
已验证的接收链允许ARC验证器：
1. identify ARC-enabled ADMDs that break authentication while processing messages and
1. 识别在处理消息和数据时中断身份验证的启用ARC的ADMD
2. gain extended visibility into the authentication-preserving abilities of ADMDs that relay messages into ARC-enabled ADMDs.
2. 进一步了解ADMD的身份验证保护功能，这些功能将消息中继到启用ARC的ADMD中。
Through the collection of ARC-related data, an ADMD can identify handling paths that have broken authentication.
通过收集ARC相关数据，ADMD可以识别已破坏身份验证的处理路径。
An Authenticated Received Chain allows an Internet Mail Handler to potentially base decisions of message disposition on authentication assessments provided by different ADMDs.
经过身份验证的接收链允许Internet邮件处理程序根据不同ADMD提供的身份验证评估来潜在地决定邮件的处置。
DMARC introduces a policy model where Domain Owners can request email receivers to reject or quarantine messages that fail DMARC alignment. Interoperability issues between DMARC and indirect email flows are documented in [RFC7960].
DMARC引入了一个策略模型，域所有者可以请求电子邮件接收者拒绝或隔离未通过DMARC对齐的邮件。[RFC7960]中记录了DMARC和间接电子邮件流之间的互操作性问题。
Authenticated Received Chains allow DMARC processors to consider authentication assessments provided by other ADMDs. As a matter of local policy, a DMARC processor MAY choose to accept the authentication assessments provided by an Authenticated Received Chain when determining if a message is DMARC compliant.
认证的接收链允许DMALC处理器考虑由其他ADMD提供的认证评估。作为本地策略的一个事项，当确定消息是否符合DMARC时，DMARC处理器可以选择接受已认证接收链提供的认证评估。
When an Authenticated Received Chain is used to determine message disposition, the DMARC processor can communicate this local policy decision to Domain Owners as described in Section 7.2.2.
当使用经过验证的接收链来确定消息处置时，DMARC处理器可以将此本地策略决策传达给域所有者，如第7.2.2节所述。
DMARC-enabled receivers indicate when ARC validation influences DMARC-related local policy decisions. When an ARC-enabled handler generates a DMARC report, it MAY indicate the influence of ARC on their local policy decision(s) by adding a reason of "local_policy" with a comment string (per [RFC7489], Appendix C) containing a list of data discovered during ARC validation, which at a minimum includes:
启用DMARC的接收器指示ARC验证何时影响与DMARC相关的本地策略决策。当启用ARC的处理程序生成DMARC报告时，它可以通过添加带有注释字符串的“本地_策略”原因（根据[RFC7489]，附录C）来指示ARC对其本地策略决策的影响，该注释字符串包含ARC验证期间发现的数据列表，至少包括：
o the Chain Validation Status,
o 链验证状态，
o the domain and selector for each AS, and
o 每个AS的域和选择器，以及
o the originating IP address from the first ARC Set.
o 来自第一个ARC集合的原始IP地址。
EXAMPLE:
例子：
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
<reason>
<type>local_policy</type>
<comment>arc=pass as[2].d=d2.example as[2].s=s2
as[1].d=d1.example as[1].s=s3
remote-ip[1]=2001:DB8::1A</comment>
</reason>
</policy_evaluated>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
<reason>
<type>local_policy</type>
<comment>arc=pass as[2].d=d2.example as[2].s=s2
as[1].d=d1.example as[1].s=s3
remote-ip[1]=2001:DB8::1A</comment>
</reason>
</policy_evaluated>
In the example DMARC XML reporting fragment above, data relating to specific validated ARC Sets are enumerated using array syntax (e.g., "as[2]" means an AS header field with an instance value of 2). d2.example is the sealing domain for ARC Set #2 (i=2), and d1.example is the sealing domain for ARC Set #1 (i=1).
在上面的示例DMARC XML报告片段中，使用数组语法（例如，“as[2]”表示实例值为2的as标头字段）枚举与特定已验证ARC集相关的数据。d2.示例是弧集#2（i=2）的密封域，d1.示例是弧集#1（i=1）的密封域。
Depending on the reporting practices of intermediate message handlers, Domain Owners may receive multiple DMARC reports for a single message. Receivers of DMARC reports should be aware of this behavior and make the necessary accommodations.
根据中间消息处理程序的报告实践，域所有者可能会收到单个消息的多个DMARC报告。DMARC报告的接收者应意识到这种行为，并做出必要的调整。
The Authenticated Received Chain provides a verifiable record of the handlers for a message. This record may include personally identifiable information such as an IP address(es) and domain names. Such information is also included in existing non-ARC-related header fields such as the "Received" header fields.
经过身份验证的接收链提供消息处理程序的可验证记录。该记录可能包括个人识别信息，如IP地址和域名。此类信息还包括在现有的非ARC相关的标题字段中，如“已接收”标题字段。
The Security Considerations of [RFC6376] and [RFC8601] apply directly to this specification.
[RFC6376]和[RFC8601]的安全注意事项直接适用于本规范。
As with other domain-based authentication technologies (such as SPF, DKIM, and DMARC), ARC makes no claims about the semantic content of messages. A received message with a validated ARC Chain provides evidence (at instance N) that:
与其他基于域的身份验证技术（如SPF、DKIM和DMARC）一样，ARC对消息的语义内容不作任何声明。接收到的带有已验证ARC链的消息提供了以下证据（在实例N）：
1. the sealing domain (ARC-Seal[N] d=) emitted the message with this body,
1. 密封域（ARC Seal[N]d=）发出带有此主体的消息，
2. the authentication assessment reported in the ARC-Authentication-Results was determined upon receipt of the corresponding message at the sealing domain, and
2. ARC认证结果中报告的认证评估是在密封域收到相应消息后确定的，并且
3. the preceding ARC Chain (1..N-1) (with the validation status as reported in the cv field) existed on the message that was received and assessed.
3. 接收和评估的消息上存在前面的ARC链（1..N-1）（验证状态如cv字段中所报告）。
Inclusion of Authenticated Received Chains into messages may cause issues for older or constrained MTAs due to increased total header field size. Large header field blocks, in general, may cause failures to deliver or other outage scenarios for such MTAs. ARC itself would not cause problems.
将经过身份验证的接收链包含到邮件中可能会导致旧的或受约束的MTA出现问题，因为总标头字段大小增加。通常，较大的标题字段块可能会导致此类MTA的交付失败或其他停机情况。ARC本身不会引起问题。
The validation of an Authenticated Received Chain composed of N ARC Sets can require up to 2*N DNS queries (not including any DNS redirection mechanisms that can increase the total number of queries). This leads to two considerations:
验证由N个ARC集组成的经过身份验证的接收链最多需要2*N个DNS查询（不包括可增加查询总数的任何DNS重定向机制）。这导致了两个考虑因素：
1. An attacker can send a message to an ARC participant with a concocted sequence of ARC Sets bearing the domains of intended victims, and all of them will be queried by the participant until a failure is discovered. DNS caching and the difficulty of forging the signature values should limit the extent of this load to domains under control of the attacker. Query traffic pattern analysis may expose information about a downstream validating ADMD infrastructure.
1. 攻击者可以向ARC参与者发送一条消息，其中包含一系列伪造的ARC集，其中包含目标受害者的域，参与者将查询所有这些ARC集，直到发现故障。DNS缓存和伪造签名值的难度应限制攻击者控制的域的负载范围。查询流量模式分析可能会公开有关下游验证ADMD基础结构的信息。
2. DKIM only performs one DNS query per signature, while ARC can introduce many (per chain). Absent caching, slow DNS responses can cause SMTP timeouts and backlogged delivery queues on validating systems. This could be exploited as a DoS attack.
2. DKIM只对每个签名执行一个DNS查询，而ARC可以引入许多（每个链）。如果没有缓存，缓慢的DNS响应可能会导致SMTP超时和验证系统上积压的传递队列。这可能被利用为DoS攻击。
Recipients are cautioned to treat messages bearing Authenticated Received Chains with the same suspicion applied to all other messages. This includes appropriate content scanning and other checks for potentially malicious content.
收件人应谨慎对待带有经过身份验证的接收链的邮件，并将相同的怀疑应用于所有其他邮件。这包括适当的内容扫描和对潜在恶意内容的其他检查。
ARC authenticates the identity of some email-handling actors. It does not make any assessment of their trustworthiness.
ARC验证某些电子邮件处理参与者的身份。它没有对他们的可信度进行任何评估。
Just as passing message authentication is not an indication of message safety, forwarding that information through the mechanism of ARC is also not an indication of message safety. Even if all ARC-enabled ADMDs are trusted, ADMDs may have become compromised, may miss unsafe content, or may not properly authenticate messages.
正如通过消息身份验证并不表示消息安全，通过ARC机制转发该信息也不表示消息安全。即使所有启用ARC的ADMD都是可信的，ADMD也可能已受损，可能会丢失不安全的内容，或者可能无法正确验证消息。
Recipients are cautioned to treat every Sealer of the ARC Chain with suspicion. Just as with a validated DKIM signature, responsibility for message handling is attributed to the sealing domain, but whether or not that Sealer is a malicious actor is out of scope of the authentication mechanism. Since ARC aids message delivery in the event of an authentication failure, ARC Sealers should be treated with suspicion, so that a malicious actor cannot seal spam or other fraudulent messages to aid their delivery, too.
收件人应谨慎对待ARC链的每个密封件。与已验证的DKIM签名一样，消息处理的责任归于密封域，但密封器是否是恶意参与者不在身份验证机制的范围之内。由于ARC在身份验证失败的情况下有助于邮件传递，因此应怀疑ARC密封器，以便恶意参与者也不能密封垃圾邮件或其他欺诈邮件以帮助其传递。
Since ARC inherits heavily from DKIM, it has similar attack vectors. In particular, the replay attack described in [RFC6376], Section 8.6 is potentially amplified by ARC's chained statuses. In an ARC replay attack, a malicious actor would take an intact and passing ARC Chain and resend it to many recipients without making any modifications that invalidate the latest AMS or AS. The impact to a receiver would be more DNS lookups and signature evaluations. The scope of this attack can be limited by caching DNS queries and following the same signing scope guidance from [RFC6376], Section 5.4.1.
由于ARC大量继承自DKIM，因此它具有相似的攻击向量。特别是[RFC6376]第8.6节中描述的重放攻击可能会因ARC的链式状态而加剧。在ARC重放攻击中，恶意参与者将获取完整且通过的ARC链，并将其重新发送给多个收件人，而无需进行任何使最新AMS或AS无效的修改。对接收者的影响将是更多的DNS查找和签名评估。通过缓存DNS查询并遵循[RFC6376]第5.4.1节中相同的签名范围指导，可以限制此攻击的范围。
This document defines one new authentication method and several status codes (Section 10.1), new ptypes and properties (Section 10.2), three new headers fields (Section 10.3), and a new enumerated status code (Section 10.4).
本文件定义了一种新的身份验证方法和若干状态代码（第10.1节）、新的P类型和属性（第10.2节）、三个新的标题字段（第10.3节）和一个新的枚举状态代码（第10.4节）。
Per this document, IANA has added one authentication method with three codes to the IANA "Email Authentication Result Names" registry:
根据本文件，IANA在IANA“电子邮件验证结果名称”注册表中添加了一种带有三个代码的验证方法：
o Auth Method: arc Code: "none", "pass", "fail" Specification: RFC 8617, Section 4.4 Status: active
o 认证方法：arc代码：“无”、“通过”、“失败”规范：RFC 8617，第4.4节状态：激活
Per this document, IANA has added the following to the "Email Authentication Methods" registry, which is defined in [RFC8601]:
根据本文件，IANA在[RFC8601]中定义的“电子邮件身份验证方法”注册表中添加了以下内容：
o Method: arc Definition: RFC 8617, Section 6 ptype: smtp Property: remote-ip Value: IP address (v4 or v6) of originating SMTP connection Status: active Version: 1
o 方法：arc定义：RFC 8617，第6节类型：smtp属性：远程ip值：原始smtp连接状态的ip地址（v4或v6）：活动版本：1
o Method: arc Definition: RFC 8617, Section 6 ptype: header Property: oldest-pass Value: The instance id of the oldest validating AMS or 0 if they all pass (see Section 5.2) Status: active Version: 1
o 方法：arc定义：RFC 8617，第6节P类型：标题属性：最早通过值：最早验证AMS的实例id或0（如果它们都通过）（参见第5.2节）状态：活动版本：1
Per this document, IANA has added the following three new header fields to the "Permanent Message Header Field Names" registry:
根据本文档，IANA已将以下三个新标题字段添加到“永久邮件标题字段名称”注册表中：
o Header field name: ARC-Seal Applicable protocol: mail Status: experimental Author/Change controller: IETF Specification document(s): RFC 8617 Related information: RFC 6376
o 标题字段名称：ARC密封适用协议：邮件状态：实验作者/变更控制器：IETF规范文件：RFC 8617相关信息：RFC 6376
o Header field name: ARC-Message-Signature Applicable protocol: mail Status: experimental Author/Change controller: IETF Specification document(s): RFC 8617 Related information: RFC 6376
o 标题字段名称：ARC消息签名适用协议：邮件状态：实验作者/变更控制器：IETF规范文件：RFC 8617相关信息：RFC 6376
o Header field name: ARC-Authentication-Results Applicable protocol: mail Status: experimental Author/Change controller: IETF Specification document(s): RFC 8617 Related information: RFC 8601
o 标题字段名称：ARC认证结果适用协议：邮件状态：实验作者/变更控制器：IETF规范文件：RFC 8617相关信息：RFC 8601
Per this document, IANA has added the following value to the "Enumerated Status Codes" registry:
根据本文件，IANA向“枚举状态代码”注册表添加了以下值：
o Code: X.7.29 Sample Text: ARC validation failure Associated basic status code: 550 Description: This status code may be returned when a message fails ARC validation. Reference: RFC 8617 Submitter: K. Andersen Change controller: IESG
o 代码：X.7.29示例文本：ARC验证失败相关基本状态代码：550说明：当消息未通过ARC验证时，可能会返回此状态代码。参考：RFC 8617提交人：K.安达信变更控制员：IESG
The ARC protocol is designed to address common interoperability issues introduced by intermediate message handlers. Interoperability issues are described in [RFC6377] and [RFC7960].
ARC协议旨在解决中间消息处理程序引入的常见互操作性问题。[RFC6377]和[RFC7960]中描述了互操作性问题。
As the ARC protocol is implemented by Internet Mail Handlers over time, the following should be evaluated in order to determine the success of the protocol in accomplishing the intended benefits.
由于ARC协议是由Internet邮件处理程序随着时间的推移实施的，因此应评估以下内容，以确定协议在实现预期效益方面是否成功。
In an attempt to deliver legitimate messages that users desire, many receivers use heuristic-based methods to identify messages that arrive via indirect delivery paths.
为了传递用户想要的合法消息，许多接收者使用基于启发式的方法来识别通过间接传递路径到达的消息。
ARC will be a success if the presence of Authenticated Received Chains allows for improved decision making when processing legitimate messages, specifically resulting in equal or better delivery rates than achieved through the use of heuristic approaches.
如果认证接收链的存在允许在处理合法消息时改进决策，特别是产生与使用启发式方法相同或更好的传递率，ARC将是成功的。
ARC should function without introducing significant new vectors for abuse (see Section 9). If unforeseen vectors are enabled by ARC, this protocol will be a failure. Note that the weaknesses inherent in the mail protocols ARC is built upon (such as DKIM replay attacks and other known issues) are not new vectors that can be attributed to this specification.
ARC应在不引入新的滥用载体的情况下发挥作用（见第9节）。如果ARC启用了不可预见的向量，则该协议将失败。请注意，邮件协议ARC所固有的弱点（如DKIM重播攻击和其他已知问题）并非本规范的新载体。
The following open questions are academic and have no clear answer at the time this document was published. However, additional deployments should be able to gather the necessary data to answer some or all of them.
以下开放性问题属于学术性问题，在本文件发布时没有明确答案。但是，其他部署应该能够收集必要的数据来回答部分或全部问题。
Data should be collected to show if the AS provides value beyond the AMS for either making delivery decisions or catching malicious actors trying to craft or replay malicious chains.
应收集数据，以显示AS是否提供了超出AMS的价值，用于做出交付决策或捕获试图构建或重播恶意链的恶意参与者。
11.3.2. Usage and/or Signals from Multiple Selectors and/or Domains in ARC Sets
11.3.2. ARC集合中多个选择器和/或域的使用和/或信号
Any selectors and/or (sub)domains (under the control of the sealing ADMD) may be used for ARC header field signatures.
任何选择器和/或（子）域（在密封ADMD的控制下）均可用于ARC标头字段签名。
While implementers may choose to use various selectors and/or domains for ARC Set header fields, no compelling argument for or against such usage has been made within the working group. As such, we have chosen to allow maximum freedom for the experimental definition of this protocol.
虽然实施者可能会选择使用各种选择器和/或域作为弧集标题字段，但在工作组内尚未提出支持或反对这种使用的有力论据。因此，我们选择允许最大限度的自由来定义该协议。
Wider deployment experience and higher volumes of traffic may show whether this is useful.
更广泛的部署经验和更高的通信量可能会表明这是否有用。
Longer Authenticated Received Chains will require more queries to retrieve the keys for validating the chain. While this is not believed to be a security issue (see Section 9.2), it is unclear how much overhead will truly be added. This is similar to some of the initial processing and query load concerns that were debated at the time of the DKIM specification development.
更长的已认证接收链将需要更多的查询来检索密钥以验证链。虽然这不被认为是一个安全问题（见第9.2节），但不清楚到底会增加多少开销。这类似于DKIM规范开发时讨论的一些初始处理和查询负载问题。
Data should be collected to better understand usable length and distribution of lengths found in valid Authenticated Received Chains along with the DNS impact of processing Authenticated Received Chains.
应收集数据，以便更好地了解有效的已验证接收链中的可用长度和长度分布，以及处理已验证接收链的DNS影响。
An effective operational maximum will have to be developed through deployment experience in the field.
必须通过实地部署经验，制定有效的最大行动计划。
There are several edge cases where the information in the AAR can make the difference between message delivery or rejection. For example, if there is a well-known mailing list that seals with ARC but doesn't do its own initial DMARC enforcement, an Internet Mail Handler with this knowledge could make a delivery decision based upon the authentication information it sees in the corresponding AAR header field.
在一些边缘情况下，AAR中的信息可以决定消息的传递或拒绝。例如，如果有一个众所周知的邮件列表使用ARC进行密封，但不执行其自己的初始DMARC强制，那么具有此知识的Internet邮件处理程序可以根据其在相应的AAR标头字段中看到的身份验证信息做出传递决策。
Certain trace information in the AAR is useful/necessary in the construction of DMARC reports.
AAR中的某些跟踪信息在构建DMARC报告时非常有用/必要。
Further, certain receivers believe the entire set of trace information would be valuable to feed into machine learning systems to identify fraud and/or provide other signals related to message delivery.
此外，某些接收者认为，整套跟踪信息将有助于输入机器学习系统，以识别欺诈和/或提供与消息传递相关的其他信号。
At this point, however, it is unclear what trace information will be valuable for all receivers, regardless of size.
然而，在这一点上，不清楚什么样的跟踪信息对所有接收者来说都是有价值的，无论其大小。
Data should be collected on what trace information receivers are using that provides useful signals that affect deliverability and what portions of the trace data are left untouched or provide no useful information.
应收集以下方面的数据：哪些跟踪信息接收者正在使用哪些跟踪信息来提供影响可交付性的有用信号，哪些跟踪数据部分未被触及或未提供有用信息。
Since many such systems are intentionally proprietary or confidential to prevent gaming by abusers, it may not be viable to reliably answer this particular question. The evolving nature of attacks can also shift the landscape of "useful" information over time.
由于许多这类系统是故意专有或保密的，以防止滥用者玩游戏，因此可能无法可靠地回答这一特定问题。随着时间的推移，攻击不断演变的性质也会改变“有用”信息的格局。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<https://www.rfc-editor.org/info/rfc5234>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[RFC5322]Resnick，P.，Ed.，“互联网信息格式”，RFC 5322，DOI 10.17487/RFC5322，2008年10月<https://www.rfc-editor.org/info/rfc5322>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, <https://www.rfc-editor.org/info/rfc5598>.
[RFC5598]Crocker，D.，“互联网邮件体系结构”，RFC 5598，DOI 10.17487/RFC5598，2009年7月<https://www.rfc-editor.org/info/rfc5598>.
[RFC6376] 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, <https://www.rfc-editor.org/info/rfc6376>.
[RFC6376]Crocker，D.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，STD 76，RFC 6376，DOI 10.17487/RFC6376，2011年9月<https://www.rfc-editor.org/info/rfc6376>.
[RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, September 2011, <https://www.rfc-editor.org/info/rfc6377>.
[RFC6377]Kucherawy，M.，“域密钥识别邮件（DKIM）和邮件列表”，BCP 167，RFC 6377，DOI 10.17487/RFC6377，2011年9月<https://www.rfc-editor.org/info/rfc6377>.
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 2012, <https://www.rfc-editor.org/info/rfc6532>.
[RFC6532]Yang，A.，Steele，S.，和N.Freed，“国际化电子邮件头”，RFC 6532，DOI 10.17487/RFC6532，2012年2月<https://www.rfc-editor.org/info/rfc6532>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <https://www.rfc-editor.org/info/rfc7208>.
[RFC7208]Kitterman，S.，“授权在电子邮件中使用域的发件人策略框架（SPF），第1版”，RFC 7208，DOI 10.17487/RFC7208，2014年4月<https://www.rfc-editor.org/info/rfc7208>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/info/rfc7405>.
[RFC7405]Kyzivat，P.，“ABNF中的区分大小写字符串支持”，RFC 7405，DOI 10.17487/RFC7405，2014年12月<https://www.rfc-editor.org/info/rfc7405>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8601] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 8601, DOI 10.17487/RFC8601, May 2019, <https://www.rfc-editor.org/info/rfc8601>.
[RFC8601]Kucherawy，M.，“用于指示消息身份验证状态的消息头字段”，RFC 8601，DOI 10.17487/RFC8601，2019年5月<https://www.rfc-editor.org/info/rfc8601>.
[RFC8616] Levine, J., "Email Authentication for Internationalized Mail", RFC 8616, DOI 10.17487/RFC8616, June 2019, <https://www.rfc-editor.org/info/rfc8616>.
[RFC8616]Levine，J.，“国际邮件的电子邮件认证”，RFC 8616，DOI 10.17487/RFC8616，2019年6月<https://www.rfc-editor.org/info/rfc8616>.
[ARC-MULTI] Andersen, K., Blank, S., Ed., and J. Levine, Ed., "Using Multiple Signing Algorithms with the ARC (Authenticated Received Chain) Protocol", Work in Progress, draft-ietf-dmarc-arc-multi-03, March 2019.
[ARC-MULTI]安徒生，K.，布兰克，S.，Ed.，和J.莱文，Ed.，“使用ARC（认证接收链）协议的多重签名算法”，正在进行的工作，草案-ietf-dmarc-ARC-MULTI-032019年3月。
[ARC-USAGE] Jones, S., Ed. and K. Andersen, "Recommended Usage of the Authenticated Received Chain (ARC)", Work in Progress, draft-ietf-dmarc-arc-usage-07, April 2019.
[ARC-USAGE]Jones，S.，Ed.和K.Andersen，“认证接收链（ARC）的建议使用”，正在进行的工作，草案-ietf-dmarc-ARC-USAGE-072019年4月。
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <https://www.rfc-editor.org/info/rfc7489>.
[RFC7489]Kucherawy，M.，Ed.和E.Zwicky，Ed.，“基于域的消息验证、报告和一致性（DMARC）”，RFC 7489，DOI 10.17487/RFC7489，2015年3月<https://www.rfc-editor.org/info/rfc7489>.
[RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, E., Ed., and K. Andersen, Ed., "Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows", RFC 7960, DOI 10.17487/RFC7960, September 2016, <https://www.rfc-editor.org/info/rfc7960>.
[RFC7960]马丁，F.，Ed.，李尔，E.，Ed.，德雷根。Ed.，T.，Zwicky，E.，Ed.，和K.Andersen，Ed.，“基于域的消息验证、报告和一致性（DMARC）与间接电子邮件流之间的互操作性问题”，RFC 7960，DOI 10.17487/RFC7960，2016年9月<https://www.rfc-editor.org/info/rfc7960>.
The specification of the ARC framework is driven by the following high-level goals, security considerations, and practical operational requirements.
ARC框架的规范由以下高层目标、安全考虑和实际操作需求驱动。
o Provide a verifiable "chain of custody" for email messages;
o 为电子邮件提供可验证的“监管链”；
o Not require changes for originators of email;
o 不要求更改电子邮件的发起人；
o Support the verification of the ARC header field set by each hop in the handling chain;
o 支持验证处理链中每个跃点设置的弧头字段；
o Work at Internet scale; and
o 互联网规模的工作；和
o Provide a trustable mechanism for the communication of Authentication-Results across trust boundaries.
o 为跨信任边界的身份验证结果通信提供可信任的机制。
ARC is not a trust framework. Users of the ARC header fields are cautioned against making unsubstantiated conclusions when encountering a "broken" ARC sequence.
ARC不是一个信任框架。ARC标题字段的用户在遇到“断开的”ARC序列时，应注意不要做出未经证实的结论。
The following message is an example of one that has passed through several intermediary handlers, some of which have modified the message and others which have not:
以下消息是一个已通过多个中间处理程序的消息示例，其中一些已修改消息，另一些未修改：
Return-Path: <jqd@d1.example>
Received: from example.org (example.org [208.69.40.157])
by gmail.example with ESMTP id d200mr22663000ykb.93.1421363207
for <fmartin@example.com>; Thu, 14 Jan 2015 15:02:40 -0800 (PST)
Received: from segv.d1.example (segv.d1.example [72.52.75.15])
by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
for <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
(envelope-from jqd@d1.example)
Received: from [2001:DB8::1A] (w-x-y-z.dsl.static.isp.example [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
Received: from mail-ob0-f188.google.example
(mail-ob0-f188.google.example [208.69.40.157]) by
clochette.example.org with ESMTP id d200mr22663000ykb.93.1421363268
for <fmartin@example.org>; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
ARC-Seal: i=3; a=rsa-sha256; cv=pass; d=clochette.example.org; s=
clochette; t=12345; b=CU87XzXlNlk5X/yW4l73UvPUcP9ivwYWxyBWcVrRs7
+HPx3K05nJhny2fvymbReAmOA9GTH/y+k9kEc59hAKVg==
ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=
clochette.example.org; h=message-id:date:from:to:subject; s=
clochette; t=12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZY
LQ=; b=o71vwyLsK+Wm4cOSlirXoRwzEvi0vqIjd/2/GkYFYlSd/GGfKzkAgPqxf
K7ccBMP7Zjb/mpeggswHjEMS8x5NQ==
ARC-Authentication-Results: i=3; clochette.example.org; spf=fail
smtp.from=jqd@d1.example; dkim=fail (512-bit key)
header.i=@d1.example; dmarc=fail; arc=pass (as.2.gmail.example=pass,
ams.2.gmail.example=pass, as.1.lists.example.org=pass,
ams.1.lists.example.org=fail (message has been altered))
Authentication-Results: clochette.example.org; spf=fail
smtp.from=jqd@d1.example; dkim=fail (512-bit key)
header.i=@d1.example; dmarc=fail; arc=pass (as.2.gmail.example=pass,
ams.2.gmail.example=pass, as.1.lists.example.org=pass,
ams.1.lists.example.org=fail (message has been altered))
ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=gmail.example; s=20120806; t=
12345; b=Zpukh/kJL4Q7Kv391FKwTepgS56dgHIcdhhJZjsalhqkFIQQAJ4T9BE
8jjLXWpRNuh81yqnT1/jHn086RwezGw==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=
gmail.example; h=message-id:date:from:to:subject; s=20120806; t=
12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYLQ=; b=CVoG44
cVZvoSs2mMig2wwqPaJ4OZS5XGMCegWqQs1wvRZJS894tJM0xO1RJLgCPsBOxdA5
Return-Path: <jqd@d1.example>
Received: from example.org (example.org [208.69.40.157])
by gmail.example with ESMTP id d200mr22663000ykb.93.1421363207
for <fmartin@example.com>; Thu, 14 Jan 2015 15:02:40 -0800 (PST)
Received: from segv.d1.example (segv.d1.example [72.52.75.15])
by lists.example.org (8.14.5/8.14.5) with ESMTP id t0EKaNU9010123
for <arc@example.org>; Thu, 14 Jan 2015 15:01:30 -0800 (PST)
(envelope-from jqd@d1.example)
Received: from [2001:DB8::1A] (w-x-y-z.dsl.static.isp.example [w.x.y.z])
(authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example)
Received: from mail-ob0-f188.google.example
(mail-ob0-f188.google.example [208.69.40.157]) by
clochette.example.org with ESMTP id d200mr22663000ykb.93.1421363268
for <fmartin@example.org>; Thu, 14 Jan 2015 15:03:15 -0800 (PST)
ARC-Seal: i=3; a=rsa-sha256; cv=pass; d=clochette.example.org; s=
clochette; t=12345; b=CU87XzXlNlk5X/yW4l73UvPUcP9ivwYWxyBWcVrRs7
+HPx3K05nJhny2fvymbReAmOA9GTH/y+k9kEc59hAKVg==
ARC-Message-Signature: i=3; a=rsa-sha256; c=relaxed/relaxed; d=
clochette.example.org; h=message-id:date:from:to:subject; s=
clochette; t=12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZY
LQ=; b=o71vwyLsK+Wm4cOSlirXoRwzEvi0vqIjd/2/GkYFYlSd/GGfKzkAgPqxf
K7ccBMP7Zjb/mpeggswHjEMS8x5NQ==
ARC-Authentication-Results: i=3; clochette.example.org; spf=fail
smtp.from=jqd@d1.example; dkim=fail (512-bit key)
header.i=@d1.example; dmarc=fail; arc=pass (as.2.gmail.example=pass,
ams.2.gmail.example=pass, as.1.lists.example.org=pass,
ams.1.lists.example.org=fail (message has been altered))
Authentication-Results: clochette.example.org; spf=fail
smtp.from=jqd@d1.example; dkim=fail (512-bit key)
header.i=@d1.example; dmarc=fail; arc=pass (as.2.gmail.example=pass,
ams.2.gmail.example=pass, as.1.lists.example.org=pass,
ams.1.lists.example.org=fail (message has been altered))
ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=gmail.example; s=20120806; t=
12345; b=Zpukh/kJL4Q7Kv391FKwTepgS56dgHIcdhhJZjsalhqkFIQQAJ4T9BE
8jjLXWpRNuh81yqnT1/jHn086RwezGw==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=
gmail.example; h=message-id:date:from:to:subject; s=20120806; t=
12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYLQ=; b=CVoG44
cVZvoSs2mMig2wwqPaJ4OZS5XGMCegWqQs1wvRZJS894tJM0xO1RJLgCPsBOxdA5
9WSqI9s9DfyKDfWg==
ARC-Authentication-Results: i=2; gmail.example; spf=fail
smtp.from=jqd@d1.example; dkim=fail (512-bit key)
header.i=@example.org; dmarc=fail; arc=pass
(as.1.lists.example.org=pass, ams.1.lists.example.org=pass)
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.org; s=dk-lists;
t=12345; b=TlCCKzgk3TrAa+G77gYYO8Fxk4q/Ml0biqduZJeOYh6+0zhwQ8u/
lHxLi21pxu347isLSuNtvIagIvAQna9a5A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=
lists.example.org; h=message-id:date:from:to:subject; s=
dk-lists; t=12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYL
Q=; b=DsoD3n3hiwlrN1ma8IZQFgZx8EDO7Wah3hUjIEsYKuShRKYB4LwGUiKD5Y
yHgcIwGHhSc/4+ewYqHMWDnuFxiQ==
ARC-Authentication-Results: i=1; lists.example.org; spf=pass
smtp.mfrom=jqd@d1.example; dkim=pass (512-bit key)
header.i=@d1.example; dmarc=pass
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=d1.example; h=
message-id:date:from:to:subject; s=origin2015; bh=bIxxaeIQvmOBdT
AitYfSNFgzPP4=; b=qKjd5fYibKXWWIcMKCgRYuo1vJ2fD+IAQPjX+uamXIGY2Q
0HjQ+Lq3/yHzG3JHJp6780/nKQPOWt2UDJQrJkEA==
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@dmarc.example
Subject: [List 2] Example 1
9WSqI9s9DfyKDfWg==
ARC-Authentication-Results: i=2; gmail.example; spf=fail
smtp.from=jqd@d1.example; dkim=fail (512-bit key)
header.i=@example.org; dmarc=fail; arc=pass
(as.1.lists.example.org=pass, ams.1.lists.example.org=pass)
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.org; s=dk-lists;
t=12345; b=TlCCKzgk3TrAa+G77gYYO8Fxk4q/Ml0biqduZJeOYh6+0zhwQ8u/
lHxLi21pxu347isLSuNtvIagIvAQna9a5A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=
lists.example.org; h=message-id:date:from:to:subject; s=
dk-lists; t=12345; bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYL
Q=; b=DsoD3n3hiwlrN1ma8IZQFgZx8EDO7Wah3hUjIEsYKuShRKYB4LwGUiKD5Y
yHgcIwGHhSc/4+ewYqHMWDnuFxiQ==
ARC-Authentication-Results: i=1; lists.example.org; spf=pass
smtp.mfrom=jqd@d1.example; dkim=pass (512-bit key)
header.i=@d1.example; dmarc=pass
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=d1.example; h=
message-id:date:from:to:subject; s=origin2015; bh=bIxxaeIQvmOBdT
AitYfSNFgzPP4=; b=qKjd5fYibKXWWIcMKCgRYuo1vJ2fD+IAQPjX+uamXIGY2Q
0HjQ+Lq3/yHzG3JHJp6780/nKQPOWt2UDJQrJkEA==
Message-ID: <54B84785.1060301@d1.example>
Date: Thu, 14 Jan 2015 15:00:01 -0800
From: John Q Doe <jqd@d1.example>
To: arc@dmarc.example
Subject: [List 2] Example 1
Hey gang, This is a test message. --J.
嘿，伙计们，这是一条测试信息--J
Acknowledgments
致谢
This document originated with the work of OAR-Dev Group.
本文件源于OAR开发小组的工作。
The authors thank all of the OAR-Dev and the subsequent DMARC WG for the ongoing help and thought-provoking discussions from all the participants, especially J. Trent Adams, Marc Bradshaw, Alex Brotman, Greg Colburn, Dave Crocker, Tim Draegen, Mark Eissler, Peter Goldstein, Bron Gondwana, Mike Hammer, Mike Jones, Steve Jones, Scott Kitterman, Barry Leiba, Franck Martin, John Rae-Grant, Paul Rock, Gene Shuman, Terry Zink, and Elizabeth Zwicky.
作者感谢所有OAR开发人员和随后的DMARC工作组，感谢所有参与者的持续帮助和发人深省的讨论，特别是J.Trent Adams、Marc Bradshaw、Alex Brotman、Greg Colburn、Dave Crocker、Tim Draegen、Mark Eisler、Peter Goldstein、Bron Gondwana、Mike Hammer、Mike Jones、Steve Jones、Scott Kitterman、，巴里·莱巴、弗兰克·马丁、约翰·雷·格兰特、保罗·洛克、吉恩·舒曼、特里·津克和伊丽莎白·兹威基。
Grateful appreciation is extended to the people who provided feedback through the arc-discuss mailing list.
感谢通过arc讨论邮件列表提供反馈的人员。
Authors' Addresses
作者地址
Kurt Andersen LinkedIn 1000 West Maude Ave Sunnyvale, California 94085 United States of America
美国加利福尼亚州森尼维尔西莫德大道1000号库尔特安徒生LinkedIn 94085
Email: kurt+ietf@drkurt.com
Email: kurt+ietf@drkurt.com
Brandon Long (editor) Google
布兰登·朗（编辑）谷歌
Email: blong@google.com
Email: blong@google.com
Seth Blank (editor) Valimail
塞思·布兰克（编辑）Valimail
Email: seth@valimail.com
Email: seth@valimail.com
Murray Kucherawy (editor) TDP
默里·库切拉维（编辑）TDP
Email: superuser@gmail.com
Email: superuser@gmail.com