将DMARC ARC重新归类为历史

# 将ARC重新分类为历史状态 来源：https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-to-historic/ `` 网络工作组 T. Adams 互联网草案 Proofpoint 废弃：8617（如获批） J. Levine 意向状态：信息性 Taughannock Networks 过期：2026年10月24日 2026年4月22日 # 将ARC重新分类为历史状态 draft-ietf-dmarc-arc-to-historic-00 ## 摘要 本文档呼吁结束由“认证接收链（ARC）协议”[RFC8617]定义的实验，并建议不再在不同发送方和接收方之间部署或依赖ARC。本文档总结了ARC的初衷，报告了运营经验，并解释了实验期间获得的经验如何被纳入拟议的DKIM2工作中，作为域密钥识别邮件[RFC6376]的继任者。为避免未来混淆，请求将ARC [RFC8617]重新分类为“历史状态”。 ## 本备忘录的状态 本互联网草案完全符合BCP 78和BCP 79的规定提交。 互联网草案是互联网工程任务组（IETF）的工作文档。请注意，其他团体也可能以互联网草案形式分发工作文档。当前互联网草案列表位于 https://datatracker.ietf.org/drafts/current/。 互联网草案是有效期为六个月的最大草案文档，随时可能被其他文档更新、替换或废弃。将互联网草案用作参考材料或以“进行中的工作”之外的方式引用是不恰当的。本互联网草案将于2026年10月24日过期。 ## 版权声明 版权所有（c）2026 IETF Trust和文档作者。保留所有权利。 本文档受BCP 78和IETF Trust关于IETF文档的法律条款（https://trustee.ietf.org/license-info）的约束，该条款在本文档发布之日生效。请仔细阅读这些文档，因为它们描述了您对本文档的权利和限制。从本文档中提取的代码组件必须包含修订版BSD许可证文本，如信托法律条款第4.e节所述，并按修订版BSD许可证的规定提供，不提供任何保证。 ## 目录 1. 引言............................................2 2. 背景............................................3 2.1. 问题空间：中介处的DMARC破坏.........................3 2.2. ARC概述...........................................3 2.3. ARC的范围和非目标..................................4 3. ARC实验分析...........................................4 3.1. 运营经验...........................................4 3.2. ARC的核心教训：签名不等于信任........................6 3.3. 无修改指示.........................................6 3.4. 每跳声誉运维负担重..................................6 3.5. 偏好DKIM2方法......................................6 3.6. ARC实验结论........................................7 4. 对实施者和运营者的指导..................................7 5. 致谢..................................................7 6. IANA考虑..............................................7 7. 安全考虑..............................................8 8. 参考文献..............................................8 8.1. 规范性参考文献......................................8 8.2. 信息性参考文献......................................8 作者地址..................................................9 ## 1. 引言 在DMARC [RFC7489]部署后，它使作者域名与SPF [RFC7208] / DKIM [RFC6376]对齐，并提供了请求接收方处理认证失败的方法，而DKIM继续提供消息级签名。但很明显，存在一个需要解决的失败案例。邮件列表管理器执行的现实世界转发和修改经常破坏支持DMARC的认证协议，这促使ARC实验成为一种潜在的缓解方案。 作为回应，ARC [RFC8617]被引入作为一项实验，旨在确定由重写消息的中介组装的电子邮件密码学可验证的“监管链”是否能够保留原始发送者的认证结果，跨越转发、邮件列表和其他中介。ARC的前提是每个处理者可以记录其对上游认证的视图，然后对该记录签名，使下游评估者能够看到路径上发生的情况。 Adams & Levine 过期 2026年10月24日 [第2页] 互联网草案 将ARC重新分类为历史状态 2026年4月 本文档报告了实验的结果，并解释了随着DKIM的拟议继任者（目前称为DKIM2）的出现，社区应淘汰ARC，并将有用的部分直接纳入DKIM的继任者中。 ## 2. 背景 ### 2.1. 问题空间：中介处的DMARC破坏 DMARC依赖成功的SPF和/或DKIM认证以及与作者域名的对齐。当中介修改消息（例如，主题或正文更改、页脚插入、MIME调整）时，来自原始发件人的DKIM签名可能无法验证；当中介通过不同于原始发件人SPF记录中定义的IP转发邮件时，SPF认证可能失败。结果，即使是合法的原始消息，在中介处理后也可能在下游显得未认证，即使中介处理是良性的。 ARC被提议让可信的中介证明他们在破坏发生前看到了什么，并为消息添加新签名，本质上创建了一个签名链。转发仍然是最普遍的认证结果破坏源之一。当接收者的邮件被自动转发（例如，通过邮件列表、自动转发规则或重定向）时，转发基础设施显示为发送IP，而非原始发送域名的IP，因此SPF认证本设计上就会失败。DKIM只有在签名通过转发保持完整时才能幸存，但许多转发系统会更改头部或正文（页脚、邮件列表标签、编码），从而使DKIM失效并导致DMARC失败。 由于转发方通常不在作者的域名控制范围内，且无法轻易在作者的SPF记录中列举，发送者要覆盖所有可能的转发者在操作上不可行。因此，转发器处的认证破坏代表了DMARC部署中的结构性缺口。转发者的参与和变换正是ARC实验瞄准的场景，即中介重写消息并破坏原始认证信号，并希望这些中介能够通过监管链证明原始作者的状态。 ### 2.2. ARC概述 为了解决这些故障模式，ARC定义了头部字段（ARC-Seal、ARC-Message-Signature、ARC-Authentication-Results），允许每个中介： * 捕获其输入的认证评估（通常与DMARC相关）， * 指示发生了某些变换，但不说明改变了什么， * 并对其贡献签名，形成可验证的链，后续接收者可以验证。 Adams & Levine 过期 2026年10月24日 [第3页] 互联网草案 将ARC重新分类为历史状态 2026年4月 ARC不主张消息的作者身份；它只断言那些参与ARC签名者的处理顺序和观察结果。验证产生两个输出：（1）链是否密码学有效，（2）上游评估（如果有）是什么。它不对电子邮件的价值或是否存在未参与ARC处理或签名的中介处理者做出任何价值断言。 ### 2.3. ARC的范围和非目标 实验明确限制了ARC的作用为信号传递：它可以揭示某些中介参与并重新签名了消息，但经过验证的ARC链本身并不旨在传达对任何签名者的信任。信任决策留给接收者的本地策略。因此，没有强大的声誉系统，ARC本身无法传达对未能通过DMARC的电子邮件的信任。设计的另一个局限性是ARC签名只指示处理消息的中介，但对中介对消息所做的任何更改保持沉默。因此，完全验证的ARC链可能包含修改后的消息，而最终评估者不知道进行了哪些更改。 ## 3. ARC实验分析 ### 3.1. 运营经验 本部分总结了ARC实验期间运营者和实施者广泛报告的部署观察。 * 数据中心和域内实用性：ARC的早期有效使用发生在单一管理域或严格控制的数据中心内，消息遍历多个内部跃点。运营者应用ARC以确保消息在其自身服务器之间不会意外修改。在这些情况下，运营者已经拥有隐式信任和运营控制。 Adams & Levine 过期 2026年10月24日 [第4页] 互联网草案 将ARC重新分类为历史状态 2026年4月 * 互联网规模对声誉的依赖：为了实现广泛的互操作性，ARC要求评估者为ARC签名者运行声誉系统。验证密码学是必要但不充分的；评估者需要决定是否信任链中的每个签名者，然后使用其断言覆盖DMARC结果。这创建了一个并行信任基础设施，与现有的域名或IP声誉分离（但与之交互）。 * 有限的声誉部署：即使是早期验证ARC链的部署者也没有部署强大的动态声誉。相反，他们实施了“允许列表”，其中包含其ARC断言总是（或大多数情况下）被接受的中介。这在特定的双边或联盟关系中提供了实用性，但未能扩展到开放互联网。 * 复杂的评估者策略：接收者面临策略问题：要信任多少个ARC跃点，如何处理部分或断裂的链，如何协调链环节中的冲突评估，以及在什么条件下ARC可以影响DMARC执行。由此产生的多样性限制了跨接收者的可预测互操作。 * 转发导致的破坏仍然占主导地位：由于电子邮件转发自动更改了明显的发送基础设施（例如，转发系统的IP而不是原始域名），许多经过良好认证的消息完全因为转发器而在最终接收者处失败DMARC。转发经常导致SPF失败（按设计）和由于头部或正文修改导致的DKIM失败。这强化了任何中介认证或链机制（如ARC）必须解决转发的非受控性质，这涉及无数未知和动态系统，而不仅仅是已知的邮件列表或企业中继。 * 生态系统转向继任工作：随着社区优先考虑解决DKIM重放和增强端到端真实性，DKIM工作组已开始着手所谓的DKIM2工作。该工作明确考虑在增加价值的地方纳入类似ARC的“处理断言”，同时避免为中介建立单独的全球信任结构。随着焦点从ARC转向DKIM2并纳入ARC实验的学习，不再有继续开发和部署ARC的有意义的努力。 Adams & Levine 过期 2026年10月24日 [第5页] 互联网草案 将ARC重新分类为历史状态 2026年4月 ### 3.2. ARC的核心教训：签名不等于信任 ARC成功证明了中介可以发布密码学可验证的处理历史。然而，没有声誉的可验证历史无法安全地覆盖DMARC或其他执行策略。任何互联网范围的解决方案必须将可验证信号与可扩展、防滥用的信任模型配对；临时允许列表是不够的。 ### 3.3. 无修改指示 当邮件内容被中介修改，破坏DKIM签名时，ARC能够通过签名识别执行修改的中介，但ARC没有定义识别消息中修改了什么或为什么修改的机制。这留下解释权给评估者通过确定中介的声誉来决定是否应该接受电子邮件。 ### 3.4. 每跳声誉运维负担重 为成千上万的中介运行、共享和刷新声誉既昂贵又复杂。没有共同的声誉框架，ARC导致了不一致的接收者行为，并为攻击者创造了渗透或模仿“可信”中介的动机。转发问题说明了这种运维负担：潜在转发者的数量庞大且动态，维护所有转发者的允许列表或声誉记录不现实。在实验的十年间，为ARC创建互联网规模声誉系统的尝试未能成功，而且据知没有进行中的计划，未来也不太可能有一个。 ### 3.5. 偏好DKIM2方法 DKIM2的动机将重放识别为关键缺口，并提出为每条消息的源和目的地签名，同时采用与当代路由模式更一致的机制。将ARC的有用元素（例如，关于处理的有签名断言）纳入DKIM2避免了并行链或签名栈，减少了对分离的逐跳声誉的依赖。 Adams & Levine 过期 2026年10月24日 [第6页] 互联网草案 将ARC重新分类为历史状态 2026年4月 ### 3.6. ARC实验结论 基于社区经验和DKIM2工作的方向： a. ARC实验已结束。实施者和运营者不应再依赖ARC，并应停止进一步的互联网范围部署。现有的ARC部署者应计划淘汰它们，或将使用限制在双边策略足够的受控域内。 b. ARC实验的经验正在推动DKIM2的开发。DKIM工作组正在积极开发DKIM2；应将相关的ARC见解，如上游认证状态的持久捕获和中介处理，在适当时纳入DKIM2设计。 c. RFC 8617应标记为“历史状态”。本文档请求在DMARC工作组接受本草案后，RFC编辑和IESG将RFC 8617标记为“历史状态”，以结束实验并阻止其新部署。 ## 4. 对实施者和运营者的指导 * 仍然解析ARC头部的接收者可以继续为法证或域内目的验证它们，但不应在缺乏强大的声誉信任信号和相关策略的情况下，基于ARC链有效性做出投递决策。 * 不鼓励新的ARC部署，因为它们不太可能为邮件处理提供有用信息。 * 任何对ARC感兴趣的人应关注DKIM2的发展，因为它通过IETF流程逐渐成熟。 ## 5. 致谢 RFC8617的作者和许多部署并评估ARC的运营者提供了使这些结论成为可能的数据和经验。DKIM工作组的当前努力，包括DKIM2动机和相关草案，指导了此处建议的方向。还要感谢帮助审查和编辑本草案的人，包括（但不限于）Todd Herr、Richard Clayton、Alex Brotman、Marc Bradshaw和Emanuel Schorsch。 ## 6. IANA考虑 本文档没有IANA操作。 Adams & Levine 过期 2026年10月24日 [第7页] 互联网草案 将ARC重新分类为历史状态 2026年4月 ## 7. 安全考虑 本文档不引入新协议或机制；它建议终止ARC实验，并将实验经验用于指导继任者协议。 未来的安全考虑应基于DKIM2和其他替代方案。运营者应注意，退化ARC支持可能会在遗留系统中给仍然依赖ARC的邮件带来安全外观，而无需评估者在没有适当声誉的情况下加以信任。 ## 8. 参考文献 ### 8.1. 规范性参考文献 [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>. [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>. [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>. [RFC8617] Backman, K., Ed., et al., "The Authenticated Received Chain (ARC) Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019, <https://www.rfc-editor.org/info/rfc8617>. ### 8.2. 信息性参考文献 （此部分在原文中未列出具体引用，但保持结构） ## 作者地址 Todd Adams Proofpoint, Inc. Email: [email protected] John Levine Taughannock Networks Email: [email protected] Adams & Levine 过期 2026年10月24日 [第8页] 互联网草案 将ARC重新分类为历史状态 2026年4月 （注意：原文在第9页有作者地址，但翻译时已包含在上一页末。为准确起见，此处保留结构，但实际翻译时按原文位置放置。）