非官方中文译本声明：本页为 IETF RFC 8617《The Authenticated Received Chain (ARC)（已认证接收链）》 的中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布，受 BCP 78 与 IETF 信托法律条款约束；本译本保留原文编号与结构，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc8617。

RFC 8617：已认证接收链（ARC）

独立提交 · K. Andersen（LinkedIn）、B. Long（编辑，Google）、S. Blank（编辑，V国内主流企业邮箱）、M. Kucherawy（编辑，TDP）· 2019 年 7 月 · 类别：Experimental（实验性）· ISSN: 2070-1721

摘要

已认证接收链（ARC）协议为消息提供了一种已认证的"监管链（chain of custody）"，使处理该消息的每个实体都能看到此前是哪些实体处理过它，以及在处理的每一步该消息的认证评估是怎样的。

ARC 允许 Internet 邮件处理器将关于消息认证评估的断言附加到各个消息上。随着消息穿越支持 ARC 的 Internet 邮件处理器，可以将额外的 ARC 断言附加到消息上，形成有序的 ARC 断言集合，这些集合代表了消息在处理路径每一步的认证评估。

支持 ARC 的 Internet 邮件处理器可以处理这些 ARC 断言集合，从而为消息处置决策提供信息、识别可能破坏既有认证机制（mechanisms）的 Internet 邮件处理器，并在信任边界之间传递原始的认证评估。

本备忘录的状态

本文档并非互联网标准跟踪规范；它出于审查、实验性实现与评估的目的而发布。

本文档为互联网社区定义了一个实验性协议。本文档是互联网工程任务组（IETF）的成果，代表了 IETF 社区的共识。它已经过公开评审，并由互联网工程指导组（IESG）批准发布。并非所有经 IESG 批准的文档都是任何级别互联网标准的候选；参见 RFC 7841 第 2 节。

关于本文档当前状态、任何勘误以及如何提供反馈的信息，可在 https://www.rfc-editor.org/info/rfc8617 获取。

Copyright (c) 2019 IETF 信托及被列为文档作者的个人。保留所有权利。

本文档受 BCP 78 以及 IETF 信托的《IETF 文档相关法律规定》（https://trustee.ietf.org/license-info）约束，以本文档发布之日生效的版本为准。请仔细审阅这些文档，因为它们描述了您就本文档所享有的权利与限制。从本文档提取的代码组件必须包含《简化 BSD 许可证》文本（如信托法律条款第 4.e 节所述），并按该许可证"不提供担保"的方式提供。

目录

1. 引言

广泛部署的电子邮件认证技术，如发送方策略框架（SPF）[RFC7208] 与域名密钥识别邮件（DKIM）[RFC6376]，其效用会受到中间处理器对 Internet 邮件处理的影响。这种影响在 SPF 与 DKIM 的定义文档中有详尽记录，并在 [RFC6377] 与 [RFC7960] 中作了进一步讨论。

基于域的消息认证、报告与一致性（DMARC）[RFC7489] 同样依赖于 SPF 与 DKIM 认证机制。由中间处理器行为所导致的认证失败，可能使合法邮件被错误地拒收或误投。

已认证接收链（ARC）创建了一种机制，使各个 Internet 邮件处理器能够将其认证评估添加到消息有序的处理结果集合中。ARC 将认证评估封装在 DKIM 签名的衍生形式中，从而赋予其他处理器验证单个评估断言以及结果集合与顺序的真实性的能力。

有序的认证评估集合可被支持 ARC 的 Internet 邮件处理器用来为消息处理处置提供信息、识别消息内容可能在何处被改动，并提供用于理解消息处理路径的额外跟踪信息。

2. 通用概念

ARC 松散地基于证据收集中的一些概念。证据通常以特定的方式被收集、标注、存储与运输，以保存证据的状态并记录所有的处理步骤。

2.1. 证据

在 ARC 的语境中，"证据"是消息在从发源到最终投递的传递路径上任一点上的认证评估。当中间处理器修改消息内容（头字段和/或正文内容）、使消息经由未预见的路径路由，或更改信封信息时，消息认证的确定会受到影响。

消息的认证评估在收到消息时确定，并记录在 Authentication-Results 头字段中。ARC 扩展了这一机制，使其能够穿越中间行政管理域（ADMD）。

由于认证评估的初次确定无法由其他处理器重现，对该认证评估的断言更类似于可验证一方的证词，而非可独立评估的硬证据。

2.2. 保管（Custody）

"保管（Custody）"指 Internet 邮件处理器处理消息的时刻。当某处理器接管（take custody）一条消息时，该处理器即成为保管者（custodian），并在其支持 ARC 时将自己的证据（收到时的认证评估）附加到消息上。证据的添加方式须使后续处理器能够验证证据与保管二者的真实性。

2.3. 监管链（Chain of Custody）

ARC 的"监管链（chain of custody）"是随消息一同传递的整套证据与保管信息。

2.4. 监管链的验证

任何支持 ARC 的 Internet 邮件处理器都可以验证整套保管信息以及各方所断言的认证评估，从而得出一条有效的监管链。如果能够提供证据的保管者值得信任，那么经过验证的监管链就描述了消息穿越各个保管者时（可能变化的）认证评估。

即便消息的认证评估可能已发生变化，经过验证的监管链仍可用于判断这些变更（以及导致变更的保管者）是否可被容忍。

3. 术语与定义

本节定义文档其余部分使用的术语。

读者应当熟悉 [RFC5598] 的内容、核心概念与定义。传输服务在邮件投递过程中潜在角色与此直接相关。

语言、语法（包括一些 ABNF 构造）与概念引自 DKIM [RFC6376]。本文档各处都对 DKIM 作了具体引用。以下术语引自 [RFC5598]：

语法描述使用 ABNF [RFC5234] [RFC7405]。

本文档中的关键词"MUST（必须）"、"MUST NOT（不得）"、"REQUIRED（要求）"、"SHALL（应）"、"SHALL NOT（不应）"、"SHOULD（应该）"、"SHOULD NOT（不应该）"、"RECOMMENDED（推荐）"、"NOT RECOMMENDED（不推荐）"、"MAY（可以）"和"OPTIONAL（可选）"，当且仅当它们以如本文所示的全部大写形式出现时，应按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释。

3.1. ARC 集

第 4.1 节引入了由支持 ARC 的 Internet 邮件处理器添加到消息上的三个（3）ARC 头字段。这三个头字段共同组成一个单一的"ARC 集（ARC Set）"。一个 ARC 集使 Internet 邮件处理器能够以可被后续处理器验证的方式将认证评估附加到消息上。一条消息可以包含多个 ARC 集。

概括而言，一个 ARC 集代表证据与保管。

3.2. 已认证接收链（ARC）

在某一时刻附加到一条消息上的 ARC 集序列称为"已认证接收链（Authenticated Received Chain）"或"ARC"。已认证接收链是消息穿越参与 ARC 的 ADMD 时的各个认证评估的记录。

首次将 ARC 集附加到消息上会创建一条已认证接收链。后续附加 ARC 集会扩展这条已认证接收链。

概括而言，一条已认证接收链代表一条监管链。

3.3. Internet 邮件处理器 / 中介

Internet 邮件处理器跨越 Internet 处理并投递消息，包含 [RFC5598] 所定义的 MSA、MTA、MDA、网关与邮件列表。

在本文档中，术语"中介（intermediaries）"既指常规 MTA，也指投递/转发代理（如 [RFC5598] 中传输服务范围内的邮件列表）。

"中介（Intermediaries）"与"Internet 邮件处理器（Internet Mail Handlers）"在本文档中可互换使用。

3.4. 认证评估

作为每个 ARC 集一部分附加到消息上的认证评估，由"authres-payload" [RFC8601] 构成。就 ARC 集的完整性而言，认证评估只需按第 4.1 节的定义被妥善封装在 ARC 集内即可。authres-payload 字段的准确性或语法并不影响 ARC 链本身的有效性。

3.5. 签名 vs. 封印

签名（Signing）是指将数字签名作为头字段附加到消息上的过程，例如添加 DKIM-Signature（见 [RFC6376] 第 2.1 节）、AMS 或 AS。封印（Sealing）是指一个 ADMD 将完整且有效的 ARC 集附加到消息上，以创建或延续一条已认证接收链。

3.6. 封印者（Sealer）

封印者（Sealer）是将完整且有效的 ARC 集附加到消息上的 Internet 邮件处理器。

概括而言，封印者将其证词（认证评估的断言）与保管证明加入到监管链中。

3.7. 验证者（Validator）

验证者（Validator）是评估已认证接收链的有效性与内容的、支持 ARC 的 Internet 邮件处理器。对组成一条已认证接收链的单个 ARC 集的评估过程，见第 5.2 节。

概括而言，验证者检视监管链，以确定各保管者所提供的单个证据的内容与有效性。

3.8. 导入的 ABNF 令牌

以下 ABNF 令牌被导入：

3.9. 公共 ABNF 令牌

以下 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

4. 协议元素

4.1. ARC 头字段

ARC 引入了三个新的头字段。新头字段的语法改编自既有规范。本文档仅描述 ARC 特定的语法与语义与既有规范不同之处。

4.1.1. ARC-Authentication-Results（AAR）

ARC-Authentication-Results（AAR）头字段记录消息到达时，参与 ARC 的 ADMD 所处理的消息认证评估。

概括而言，AAR 头字段是保管者记录证据之处。

AAR 头字段在语法与语义上类似于 Authentication-Results 字段 [RFC8601]，有两点（2）不同：

AAR 头字段的形式化 ABNF 为：

   arc-info = instance [CFWS] ";" authres-payload
   arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info

由于每个 ARC 集只允许一个 AAR，无论消息上附加了多少个 Authentication-Results 头字段，AAR 都必须包含来自参与 ADMD 内所有认证结果的、合并后的 authres-payload。

4.1.2. ARC-Message-Signature（AMS）

ARC-Message-Signature（AMS）头字段使参与 ARC 的 ADMD 能够向未来的、参与 ARC 的保管者传达对消息及其可能改动所承担的一定责任（保管）。

概括而言，AMS 头字段标识一个保管者。

AMS 头字段具有与 DKIM-Signature 字段 [RFC6376] 相同的语法与语义，有三点（3）不同：

ARC 对 AMS 头字段签名所用的选择器（selectors）和/或域不作要求。

AMS 头字段的形式化 ABNF 为：

   arc-ams-info = instance [CFWS] ";" tag-list
   arc-message-signature = "ARC-Message-Signature:" [CFWS] arc-ams-info

为降低 AMS 签名被意外失效的可能性：

为保留验证消息完整性的能力，AMS 头字段的签名应当包含消息中已有的任何 DKIM-Signature 头字段。

4.1.3. ARC-Seal（AS）

AS 头字段使参与 ARC 的 ADMD 能够验证 AAR 头字段及相应 AMS 头字段的完整性。

概括而言，AS 头字段是保管者将其认证评估（证词）绑定进监管链的方式，以便验证者能够检视单个证据与保管者。

AS 头字段在语法与语义上类似于 DKIM-Signature 头字段 [RFC6376]，但有以下不同：

ARC 对 AS 头字段签名所用的选择器和/或域不作要求。

AS 头字段的形式化 ABNF 为：

   arc-as-info = instance [CFWS] ";" tag-list
   arc-seal = "ARC-Seal:" [CFWS] arc-as-info

4.1.4. 国际化邮件（EAI）

在国际化消息 [RFC6532] 中，许多头字段可以包含 UTF-8 以及 ASCII 文本。针对 EAI 的改动全部继承自经 [RFC8616] 更新的 DKIM，以及经 [RFC8601] 更新的 Authentication-Results（A-R），这里特别指出以强调。

在所有 ARC 头字段中，d= 与 s= 标签可以包含 U-label。在所有标签中，非 ASCII 字符无需在 dkim-quoted-printable 中加引号。

AAR 头字段允许在与 Authentication-Results 相同的地方使用 UTF-8，如 [RFC8601] 所述。

4.2. ARC 集

"ARC 集"是三个 ARC 头字段（AAR、AMS 与 AS）的单一集合。一个 ARC 集的 ARC 头字段共享相同的"实例（instance）"值。

通过将所有 ARC 头字段添加到消息上，一个 ARC 封印者便将一条 ARC 集添加到了消息上。关于封印者如何向消息添加 ARC 集的描述见第 5.1 节。

4.2.1. 实例标签

实例标签描述哪些 ARC 头字段属于一个 ARC 集。一个 ARC 集的每个 ARC 头字段都共享相同的实例标签值。

实例标签值是从 1 开始的整数，并在每次添加 ARC 集时递增。凭借实例标签的递增值，ARC 验证者能够确定 ARC 集被添加到消息上的顺序。

实例标签值的取值范围是从 1 到 50（含端点）。

说明性（_INFORMATIONAL_）：上限 50 是基于早期工作组成员的某些初步观察选定的。该值旨在平衡过度头字段增长的风险（见第 9.1 节）与关于长尾但非循环的、多重中介邮件流的概率的专家意见。更长的 ARC 链还会给验证者与 DNS 带来额外负载以支持更多验证步骤。在确定这一实验性初始值时也考虑了观察到的 "Received" 头字段数量。

有效的 ARC 集对于给定的实例值与签名算法，必须恰好包含每个 ARC 头字段（AAR、AMS 与 AS）的一个实例。

关于处理多种签名算法，见 [ARC-MULTI]。

4.3. 已认证接收链

已认证接收链是 ARC 集的有序集合。由于 ARC 集是 ARC 头字段的枚举集合，已认证接收链代表了支持 ARC 的处理器在处理路径上得出的消息认证评估结果。

在 ARC 支持的处理路径每一步确定的认证评估，以 AAR 头字段的形式存在于已认证接收链中。验证消息处理者身份与消息内容完整性的能力由 AMS 头字段提供。AS 头字段使消息处理者能够验证已认证接收链本身的断言、顺序与次序。

概括而言，已认证接收链代表消息的监管链。验证者可以查阅消息的监管链，以深入了解消息的每个保管者以及每个保管者所收集的证据。

4.4. 链验证状态

在特定处理步骤下已认证接收链的状态称为"链验证状态（Chain Validation Status）"。链验证状态信息通过以下几种方式传达：

链验证状态具有三种可能的值之一：

5. 协议动作

支持 ARC 的 Internet 邮件处理器通常同时充当 ARC 验证者（在接收消息时）与 ARC 封印者（在向外发送非本地发起的消息时）。

链验证状态为 "pass"（或 "none"）的已认证接收链，使 Internet 邮件处理器能够确定：

借助这些信息，Internet 邮件处理器可以就因中间处理而导致认证失败的邮件的处置，为本地策略决策提供信息。

5.1. 封印者动作

要"封印"一条消息，一个 ARC 封印者需向消息添加一个 ARC 集（三个 ARC 头字段 AAR、AMS 与 AS）。一个 ARC 集中的所有 ARC 头字段共享相同的实例标签值。

为执行封印（即构建并附加一个新的 ARC 集），当面对一条消息时，ARC 封印者必须采取以下动作：

  1. 所有消息修改（包括添加一个或多个 DKIM-Signature 头字段）必须在封印之前完成。
  2. 如果消息已经包含一条最近的 AS 报告 "cv=fail" 的已认证接收链，则无需继续，算法在此停止。
  3. 计算实例值。如果消息已包含一条已认证接收链，则实例值为该链中发现的最高实例编号加 1。如果不存在已认证接收链，则实例值为 1。
  4. 使用计算出的实例值，按如下方式生成并向消息附加一个完整的 ARC 集：
    1. 生成并附加一个 ARC-Authentication-Results 头字段，如第 4.1.1 节所定义。
    2. 生成并附加一个 ARC-Message-Signature 头字段，如第 4.1.2 节所定义。
    3. 使用第 4.1.3 节的 AS 定义、第 5.1.1 节规定的头字段，以及 ARC 验证期间确定的链验证状态，生成并附加一个 ARC-Seal 头字段。

5.1.1. ARC-Seal 签名中应包含的头字段

ARC-Seal 的生成方式类似于向消息添加 DKIM-Signature 头字段（[RFC6376] 第 3.7 节），但对头字段及其排序有明确要求。

AS 头字段的签名针对 ARC 集头字段值的一种规范化形式进行签名。ARC 集头字段值以实例递增的顺序（从 1 开始）提供给哈希函数，并包含封印消息时正在添加的 ARC 集。

在一个 ARC 集内部，头字段按以下顺序提供给哈希函数：

  1. ARC-Authentication-Results
  2. ARC-Message-Signature
  3. ARC-Seal

注意，当一条已认证接收链验证失败时，ARC-Seal 的签名范围会按第 5.1.2 节的规定进行修改。

5.1.2. 标记并封印 "cv=fail"（无效）链

在已认证接收链失败的情况下，AS 头字段 b= 值签名范围内所包含的头字段，必须仅包含检测到畸形链的 MTA 所创建的 ARC 集头字段，就如同这一最新的 ARC 集是唯一存在的集合一样。

说明性（_INFORMATIONAL_）：规定此做法是为了处理畸形或无效的已认证接收链的情形。在大多数无效链的情况下，无法生成确定性的 AS 头字段集合（第 5.1.1 节）。

5.1.3. 每封消息仅能有一条已认证接收链

一条消息在任一时刻只能承载一条已认证接收链。一旦断裂，链便无法继续，因为监管链已不再有效，且对消息的责任已经丢失。关于此主题以及阻止链延续或重建的设计限制的进一步讨论，见 [ARC-USAGE]。

5.1.4. 广泛的封印能力

ARC 并非仅面向边界 MTA 设计。任何 Internet 邮件处理器都可以通过添加一个完整的 ARC 集来封印一条消息，无论其是否修改过或是否知晓自己修改过该消息。更多信息见第 7.1 节。

5.1.5. 封印始终安全

已认证接收链的效用局限于非常特定的情形。已认证接收链旨在评估消息以进行投递、在认证失败的语境下，向 Internet 邮件处理器提供额外信息。具体而言：

5.2. 验证者动作

验证者按顺序执行以下步骤来处理一条已认证接收链。规范化、哈希函数与签名验证方法引自 [RFC6376] 第 5 节。

  1. 收集当前附加到消息上的所有 ARC 集。
    • 如果没有任何 ARC 集，则链验证状态为 "none"，算法在此停止。
    • 可以附加到一条消息上的 ARC 集的最大数量为 50。如果超过最大数量，则链验证状态为 "fail"，算法在此停止。
    • 在以下算法中，发现的最大 ARC 实例值称为 "N"。
  2. 如果最高实例值 ARC 集的链验证状态为 "fail"，则链验证状态为 "fail"，算法在此停止。
  3. 验证已认证接收链的结构。一条有效的 ARC 满足以下条件：
    1. 每个 ARC 集必须恰好包含一个各自（AAR、AMS 与 AS）的 ARC 头字段。
    2. ARC 集的实例值必须构成从 1 到 N 的连续序列，无缺口或重复。
    3. 所有 ARC-Seal 头字段的 "cv" 值不得为 "fail"。对于实例值大于 1 的 ARC 集，其值必须为 "pass"。对于实例值等于 1 的 ARC 集，其值必须为 "none"。
    • 如果不满足以上任何条件，则链验证状态为 "fail"，算法在此停止。
  4. 验证实例值最大（最新）的 AMS。如果验证失败，则链验证状态为 "fail"，算法在此停止。
  5. 可选（_OPTIONAL_）：通过从 N-1 开始、按递减顺序直至实例值为 1 的 AMS，验证每个先前的 AMS，从而由 ARC 集确定 "oldest-pass（最旧通过）"值：
    1. 如果某个 AMS 验证失败（对于实例值 "M"），则将 oldest-pass 值设为通过的最低 AMS 实例值（M+1），并进入下一步（无需检查任何其他（更旧的）AMS 头字段）。这不影响已认证接收链的有效性。
    2. 如果所有 AMS 头字段均验证通过，则将 oldest-pass 值设为 0。
  6. 从最大实例值开始、按递减顺序直至实例值为 1 的 AS，逐一验证每个 AS。如果任何 AS 验证失败，则链验证状态为 "fail"，算法在此停止。
  7. 如果算法执行到这一步，则链验证状态为 "pass"，算法完成。

此验证算法的最终结果应当包含在 ADMD 的 Authentication-Results 头字段中。

与验证失败的 DKIM 签名（[RFC6376] 第 6.3 节）一样，链验证状态为 "fail" 的已认证接收链的消息，必须被当作没有已认证接收链的消息同等对待。

说明性（_INFORMATIONAL_）：无效或失败的已认证接收链的接收方，可以将该信息作为更广泛处理上下文的一部分来使用。不能假定中介已采用 ARC；许多中介将继续修改消息而不添加 ARC 封印。

5.2.1. 所有失败都是永久性的

已认证接收链代表了消息穿越一个或多个中介的传输过程。所有错误，包括 DNS 失败，都变得不可恢复，并被视为永久性的。

验证已认证接收链的任何错误都会导致链验证状态为 "fail"。关于此主题以及阻止链延续或重建的设计限制的进一步讨论，见 [ARC-USAGE]。

5.2.2. 在 SMTP 事务期间响应 ARC 验证失败

如果 ARC 验证者确定入站消息未通过 ARC 验证，验证者可以通过扩展 SMTP 响应码 5.7.29（"ARC 验证失败"）及相应的 SMTP 基础响应码来示意这一损坏。由于 ARC 失败很可能仅在其他底层认证机制失败的语境下被检测到，验证者可以使用更通用的 5.7.26（"多项认证检查失败"）来代替 ARC 特定的代码。

6. 验证结果的传达

链验证状态（第 4.4 节描述）通过 Authentication-Results（与 AAR）头字段、使用认证方法 "arc" 来传达。该认证方法在第 10.1 节描述。

如果有必要的数据可用，则第 10.2 节定义的 ptype 与 property 应当记录在 Authentication-Results 头字段中：

7. 用例

本节探讨若干由 ARC 所应对的消息处理用例。

7.1. 跨越信任边界传达认证评估

当一个中介 ADMD 向消息的已认证接收链添加一个 ARC 集（或创建初始 ARC 集）时，该 ADMD 即将其认证评估传达给消息处理路径中的下一个参与 ARC 的 ADMD。

如果参与 ARC 的 ADMD 彼此信任，已认证接收链可用于桥接管理边界。

7.1.1. 邮件扫描服务

存在执行反垃圾邮件、反恶意软件与反钓鱼扫描的邮件服务。此类服务通常会移除恶意内容、将消息中的 HTTP 链接替换为净化后的链接，和/或将宣传该邮件扫描服务能力的页脚附加到消息上。这些改动几乎总会破坏基于签名的认证（如 DKIM）。

扫描服务通常要求客户将某个 Internet 域的 MX 记录指向扫描服务。发往该 Internet 域的消息最初被投递到扫描服务。扫描完成后，消息再被路由到客户自身的邮件处理基础设施。以此方式重路由消息几乎总会破坏基于路径的认证（如 SPF）。

邮件扫描服务可以将已认证接收链附加到消息上，以将认证评估传达进客户 ADMD。客户随后便可在处理消息时受益于邮件扫描服务，仿佛客户的基础设施是该 Internet 域 MX 记录的最初目的地。

7.1.2. 多层 MTA 处理

大型消息处理基础设施通常被划分为若干处理层，各层之间可能破坏认证信息。例如，一个大型站点可能维护一个专用于连接处理与基于 IP 的信誉过滤执行的 MTA 集群。第二层 MTA 集群可能专用于并优化于基于内容的消息处理。

已认证接收链可用于在处理层之间传达认证评估。

7.1.3. 邮件列表

邮件列表接收消息并将其转发（repost）给订阅者。关于与认证相关的邮件列表问题的完整描述，见 [RFC7960] 第 3.2.3 节。

邮件列表服务可以实施 ARC，以传达发给列表订阅者群的、所投递消息的认证评估。邮件列表订阅者的 ADMD 随后可以使用已认证接收链，确定在邮件列表处理之前原始消息的认证评估。

7.2. 为消息处置决策提供信息

中介常常通过内容修改破坏认证、干扰基于路径的认证（如 SPF），以及剥离认证结果（如果某 MTA 移除了 Authentication-Results 头字段）。

已认证接收链使 ARC 验证者能够：

  1. 识别在处理消息时破坏认证的支持 ARC 的 ADMD；以及
  2. 对将消息中继进支持 ARC 的 ADMD 的那些 ADMD 的、保留认证的能力获得更深入的可见性。

通过收集 ARC 相关数据，一个 ADMD 可以识别出已破坏认证的处理路径。

已认证接收链使 Internet 邮件处理器能够潜在地基于由不同 ADMD 提供的认证评估来作出消息处置决策。

7.2.1. DMARC 本地策略覆盖

DMARC 引入了一种策略模型，域名所有者可以请求邮件接收方拒收或隔离未通过 DMARC 一致性的消息。DMARC 与间接邮件流之间的互操作性问题记录在 [RFC7960] 中。

已认证接收链使 DMARC 处理器能够考虑由其他 ADMD 提供的认证评估。作为本地策略的事项，DMARC 处理器在判定一条消息是否符合 DMARC 时，可以选择接受由已认证接收链所提供的认证评估。

当使用已认证接收链来确定消息处置时，DMARC 处理器可以将此本地策略决策传达给域名所有者，如第 7.2.2 节所述。

7.2.2. DMARC 报告

支持 DMARC 的接收方会指明 ARC 验证何时影响了与 DMARC 相关的本地策略决策。当支持 ARC 的处理器生成 DMARC 报告时，它可以通过添加一个 "local_policy" 类型的理由、并在注释字符串（依据 [RFC7489] 附录 C）中包含 ARC 验证期间发现的、至少包括如下内容的数据列表，来指明 ARC 对其本地策略决策的影响：

示例：

<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>

在上面这个 DMARC XML 报告片段示例中，与特定已验证 ARC 集相关的数据使用数组语法枚举（例如，"as[2]" 表示实例值为 2 的 AS 头字段）。d2.example 是 ARC 集 #2（i=2）的封印域，d1.example 是 ARC 集 #1（i=1）的封印域。

取决于中间消息处理器的报告实践，域名所有者可能收到针对单条消息的多份 DMARC 报告。DMARC 报告的接收方应当意识到这一行为并作出必要的适应。

8. 隐私考量

已认证接收链提供了消息处理者的一种可验证记录。该记录可能包含个人可识别信息，如 IP 地址与域名。此类信息也包含在既有的非 ARC 相关头字段中，例如 "Received" 头字段。

9. 安全考量

[RFC6376] 与 [RFC8601] 的安全考量直接适用于本规范。

与其他基于域的认证技术（如 SPF、DKIM 与 DMARC）一样，ARC 不对消息的语义内容作任何声明。一条带有已验证 ARC 链的消息提供了（在实例 N 处）如下证据：

  1. 封印域（ARC-Seal[N] 的 d=）以该正文发出了消息；
  2. 在 ARC-Authentication-Results 中报告的认证评估，是在封印域收到相应消息时确定的；以及
  3. 前述 ARC 链（1..N-1）（连同 cv 字段所报告的验证状态）存在于被接收并评估的消息上。

9.1. 增大的头字段尺寸

将已认证接收链包含进消息，可能因总头字段尺寸增大而导致较旧或受限的 MTA 出现问题。大体而言，大型头字段块可能导致此类 MTA 投递失败或其他中断情形。ARC 本身不会造成问题。

9.2. DNS 操作

验证由 N 个 ARC 集组成的已认证接收链，最多可能需要 2*N 次 DNS 查询（不含可能进一步增加查询总数的任何 DNS 重定向机制）。这引出两点考量：

  1. 攻击者可以向 ARC 参与者发送一条消息，其捏造的 ARC 集序列带有预期受害者的域，参与者会一直查询这些域，直到发现失败为止。DNS 缓存以及伪造签名值的难度，应当将此负载的影响限制在攻击者控制之下的域内。对查询流量模式的分析可能暴露下游验证 ADMD 基础设施的信息。
  2. DKIM 每次签名仅执行一次 DNS 查询，而 ARC 可能引入许多次（每条链）。在缺少缓存的情况下，缓慢的 DNS 响应可能导致 SMTP 超时以及验证系统上积压的投递队列。这可能被利用为一种 DoS 攻击。

9.3. 对消息内容的怀疑

提醒接收方，对带有已认证接收链的消息，应施以与对所有其他消息相同的怀疑态度。这包括适当的内容扫描以及其他针对潜在恶意内容的检查。

ARC 认证某些邮件处理参与者的身份。它不对其可信度作任何评估。

正如通过消息认证并不代表消息安全一样，通过 ARC 机制转发该信息也不代表消息安全。即使所有支持 ARC 的 ADMD 都值得信任，这些 ADMD 也可能已被攻陷、可能漏掉不安全内容，或可能未能妥善认证消息。

9.4. 对消息封印者的怀疑

提醒接收方，对 ARC 链的每一个封印者都应持怀疑态度。正如同已验证的 DKIM 签名一样，消息处理的责任归属于封印域，但该封印者是否为恶意行为者则超出了认证机制的范围。由于 ARC 在认证失败的情况下有助于消息投递，应当对 ARC 封印者持怀疑态度，以免恶意行为者封印垃圾邮件或其他欺诈性消息以帮助其投递。

9.5. 重放攻击

由于 ARC 大量继承自 DKIM，它具有类似的攻击向量。特别是，[RFC6376] 第 8.6 节描述的重放攻击，可能被 ARC 的链式状态所放大。在一次 ARC 重放攻击中，恶意行为者会取一条完整且通过的 ARC 链，并在不做任何会使最新 AMS 或 AS 失效的修改的情况下，将其重新发送给许多接收方。对接收方的影响是更多的 DNS 查找与签名评估。此攻击的范围可通过缓存 DNS 查询并遵循 [RFC6376] 第 5.4.1 节的相同签名范围指引来加以限制。

10. IANA 考量

本文档定义了一个新的认证方法以及若干状态码（第 10.1 节）、新的 ptype 与 property（第 10.2 节）、三个新头字段（第 10.3 节），以及一个新枚举状态码（第 10.4 节）。

10.1. 对电子邮件认证结果名称注册表的更新

根据本文档，IANA 已向 IANA"电子邮件认证结果名称（Email Authentication Result Names）"注册表添加了一个带有三个代码的认证方法：

10.2. 对电子邮件认证方法注册表的更新

根据本文档，IANA 已向 [RFC8601] 定义的"电子邮件认证方法（Email Authentication Methods）"注册表添加如下内容：

10.3. 永久消息头字段注册表中的新头字段

根据本文档，IANA 已向"永久消息头字段名称（Permanent Message Header Field Names）"注册表添加以下三个新头字段：

10.4. 枚举状态码注册表中的新状态码

根据本文档，IANA 已向"枚举状态码（Enumerated Status Codes）"注册表添加如下值：

11. 实验性考量

ARC 协议旨在应对由中间消息处理器引入的常见互操作性问题。互操作性问题在 [RFC6377] 与 [RFC7960] 中描述。

随着 Internet 邮件处理器随时间实现 ARC 协议，应当评估以下内容，以确定该协议在实现预期收益方面是否成功。

11.1. 成功考量

为了投递用户期望的合法消息，许多接收方使用基于启发式的方法，来识别经由间接投递路径到达的消息。

如果已认证接收链的存在能够在处理合法消息时改善决策制定——具体而言，达到不低于（或优于）使用启发式方法所实现的投递率——则 ARC 将是成功的。

11.2. 失败考量

ARC 应当能在不引入显著的、可供滥用新向量的情况下运作（见第 9 节）。如果 ARC 启用了未预见的向量，则该协议将是失败的。请注意，ARC 所构建于其上的邮件协议所固有的弱点（如 DKIM 重放攻击及其他已知问题）并非可归因于本规范的新向量。

11.3. 开放问题

以下开放问题属于学术性讨论，在本文档发布时尚无明确答案。不过，更多的部署应当能够收集到必要数据，以回答其中部分或全部问题。

11.3.1. ARC-Seal（AS）头字段的价值

应当收集数据，以表明 AS 是否提供了超越 AMS 的价值——无论是为了作出投递决策，还是为了捕获试图构造或重放恶意链的恶意行为者。

11.3.2. ARC 集中多个选择器和/或域的使用与/或信号

任何（处于封印 ADMD 控制下的）选择器和/或（子）域都可用于 ARC 头字段签名。

虽然实现者可以选择为 ARC 集头字段使用不同的选择器和/或域，但工作组内对此类用法的支持或反对均未提出有说服力的论据。因此，我们选择为这一协议的实验性定义保留最大的自由度。

更广泛的部署经验与更高的流量水平，可能会揭示这种做法是否有用。

11.3.3. DNS 开销

更长的已认证接收链将需要更多查询来检索用于验证该链的密钥。虽然这不被认为是一个安全问题（见第 9.2 节），但尚不清楚到底会增加多少开销。这类似于在 DKIM 规范制定之时所争论的一些初始处理与查询负载担忧。

应当收集数据，以更好地理解有效已认证接收链中可用的长度与长度分布，以及处理已认证接收链的 DNS 影响。

一个有效的运维最大值将必须通过实际部署经验来确立。

11.3.4. 哪些跟踪信息有价值？

在一些边缘情况下，AAR 中的信息可以决定消息是被投递还是被拒收。例如，如果存在一个众所周知的、使用 ARC 封印但不自行进行初始 DMARC 强制执行的邮件列表，那么掌握此情况的 Internet 邮件处理器，便可基于其在相应 AAR 头字段中看到的认证信息来作出投递决策。

AAR 中的某些跟踪信息在构建 DMARC 报告时是有用/必需的。

此外，某些接收方认为整套跟踪信息对于输入机器学习系统以识别欺诈和/或提供与消息投递相关的其他信号是有价值的。

然而，在现阶段，尚不清楚对无论规模大小的接收方而言，哪些跟踪信息将是有价值的。

应当收集数据，关于接收方正在使用哪些跟踪信息、这些信息提供了影响可投递性的有用信号，以及跟踪数据的哪些部分未被触及或没有提供有用信息。

由于许多此类系统出于防止被滥用者钻空子的目的而有意保持专有或机密，可靠地回答这一特定问题可能并不可行。攻击手段的不断演化也可能随时间改变"有用"信息的格局。

12. 参考文献

12.1. 规范性参考文献

12.2. 资料性参考文献

附录 A. 设计需求

ARC 框架的规范由以下高层目标、安全考量与实际运维需求所驱动。

A.1. 主要设计准则

A.2. 范围之外

ARC 并非一种信任框架。提醒 ARC 头字段的使用者，在遇到一条"断裂"的 ARC 序列时，不要作出无根据的结论。

附录 B. 使用示例

以下消息是一封通过了若干中介处理器（其中一些修改了消息，另一些没有）的邮件示例：

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

Hey gang,
This is a test message.
--J.

致谢

本文档起源于 OAR-Dev 工作组的工作。

作者感谢所有 OAR-Dev 以及随后的 DMARC 工作组的持续帮助与发人深省的探讨，尤其是 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 与 Elizabeth Zwicky。

衷心感谢通过 arc-discuss 邮件列表提供反馈的人们。

作者地址

Kurt Andersen
LinkedIn
1000 West Maude Ave
Sunnyvale, California 94085
United States of America
Email: kurt+ietf@drkurt.com

Brandon Long（编辑）
Google
Email: blong@google.com

Seth Blank（编辑）
V国内主流企业邮箱
Email: seth@v国内主流企业邮箱.com

Murray Kucherawy（编辑）
TDP
Email: superuser@gmail.com