ARC-Seal: i=1; a=rsa-sha256; t=1705461650; cv=none;
d=google.com; s=arc-20160816;
b=bePsTMCSPJSvcI4PHkyftF9oKMnJYmOW3EjbHyRk2CVJ6HNJj51ebDLVaSxnC6Lj+Y
iHS7I4y54xCr+bKrp1WQyaHgvCr5HxSeidD5uHtcDTaJczP1vOOnDo/am0RDMd2hnzpf
1usUPxlAPzDXzu2YD4uwZylsj93meB56Q2XKuUZlZlYV+L937skvQuXL3k63HzfYRnlN
/fdJWI0c9JH+J92TQPLu72CztiQdNEoTKk0A6GY1mHDBBwg1XkE8DUlMpyauxyuBBi4I
2y6q2OWgCsXbNOXT2y4IeuscjqvawjL6CCtQs1m+GEa6tVSCJ9e2SvYutafjfLMTjmvf
1xjg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=to:from:subject:message-id:list-id:feedback-id:list-unsubscribe
:precedence:reply-to:date:mime-version:dkim-signature;
bh=Mu/UddLDJcvMdY4+O7YC+2DZ+I/KNOoqdTr5l8JFL6Q=;
fh=vLHAub/c0gEkCboX9kcM4mEAL/fyqsD/IfHgEQaNOPE=;
b=QKElBGvLgMvnCUBpUJxEPHHQbfO44/u1O0pKEamBZdrVa0mOn19WDKJtgTI0XCOrng
uHROHVZ4Ko0f8V5XTPY2j3TB4CJR9ord1fsmjfeQwnuMiWdXMu4GgxZp1SNgK1/GYIwD
s9cMErvpDJaP9Wo3fyNut70ykCK7h4/VjgkBpC5xc1whK4wc6sQ/JCBHo3d0fJfXH57D
pfPqXyVBLhagfIfkKIfNm9IUD6qF+GfMKGM7x6WknFTiZwhDYP91LX7UhGJEJjM+HSfK
oNFoUs07nDkWo3Su18JHzvsbpdQKr3ySMYG9N8DX15eEYhPqozTVOymxLdVTst8PFlLn
RKmQ==
ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass header.i=@google.com header.s=20230601 header.b=fyAQXBXU;
spf=pass (google.com: domain of 3kkenzrekbvetgtermbvl-ghkxierzhhzex.vhfdpb5hhzftbe.vhf@scoutcamp.bounces.google.com designates 209.85.220.69 as permitted sender) smtp.mailfrom=3kkenZREKBvETgTermbVl-ghkXierZhhZeX.VhfDPB5HHZfTbe.Vhf@scoutcamp.bounces.google.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com
谷歌的邮件中看到 ARC-xxx 头，研究了一下，叫做 Authenticated Received Chain
好像中文资料还非常少，直译过来，可能应该叫做 可信邮件转发链。
解决的问题是邮件经过一些服务进行中转过程中，原有的安全措施 —— SPF，DKIM，DMARC —— 会失效的问题。
2016 年提出，2019 成为实验性 RFC。
维基百科中的信息
Authenticated Received Chain (ARC) is an email authentication system designed to allow an intermediate mail server like a mailing list or forwarding service to sign an email's original authentication results. This allows a receiving service to validate an email when the email's SPF and DKIM records are rendered invalid by an intermediate server's processing.
经过身份验证的接收链 （ARC） 是一种电子邮件身份验证系统，旨在允许中间邮件服务器（如邮件列表或转发服务）对电子邮件的原始身份验证结果进行签名。这允许接收服务在电子邮件的 SPF 和 DKIM 记录被中间服务器的处理变为无效时验证电子邮件。
ARC is defined in RFC 8617, published in July 2019, as "Experimental".
ARC 在 2019 年 7 月发布的 RFC 8617 中定义为“实验性”。
Overview 概要
DMARC allows a sender's domain to indicate that their emails are protected by SPF and/or DKIM, and tells a receiving service what to do if neither of those authentication methods passes - such as to reject the message. However, a strict DMARC policy may block legitimate emails sent through a mailing list or forwarder, as the DKIM signature will be invalidated if the message is modified, such as by adding a subject tag or footer, and the SPF check will either fail (if the forwarder didn't change the bounce address) or be aligned with the mailing list domain and not with the message author's domain (unless the mailing list rewrites the From: header field.)
DMARC 允许发件人的域表明其电子邮件受 SPF 和/或 DKIM 保护，并告诉接收服务如果这些身份验证方法均未通过该怎么办 - 例如拒绝邮件。
但是，严格的 DMARC 政策可能会阻止通过邮件列表或转发器发送的合法电子邮件，因为如果邮件被修改（例如通过添加主题标签或页脚），DKIM 签名将失效，并且 SPF 检查将失败（如果转发器没有更改退回地址）或与邮件列表域对齐，而不是与邮件作者的域对齐（除非邮件列表重写了 From: 标头字段）。
ARC was devised to solve this problem by giving intermediate servers a way to sign the original message's validation results. Even if the SPF and DKIM validation fail, the receiving service can choose to validate the ARC chain. If it indicates that the original message passed the SPF and DKIM checks, and the only modifications were made by intermediaries trusted by the receiving service, the receiving service may choose to accept the email. Validating an ARC chain only makes sense if the receiver trusts the ARC signers. In fact, an ARC chain can be counterfeited, so ARC processing applies when receivers trust the good faith of ARC signers, but not so much their filtering practices.
ARC 旨在通过为中间服务器提供一种对原始消息的验证结果进行签名的方法来解决此问题。
即使 SPF 和 DKIM 验证失败，接收服务也可以选择验证 ARC 链。
如果它指示原始邮件通过了 SPF 和 DKIM 检查，并且唯一的修改是由接收服务信任的中介进行的，则接收服务可以选择接受电子邮件。
仅当接收方信任 ARC 签名者时，验证 ARC 链才有意义。
事实上，ARC 链可以被伪造， 因此当接收者信任 ARC 签名者的善意时，ARC 处理适用，而不是他们的过滤实践。
Implementation 实现
ARC defines three new mail headers:
ARC 定义了三个新的邮件头：
ARC-Authentication-Results(abbreviated AAR) - A combination of an instance number (i) and the results of the SPF, DKIM, and DMARC validation
实例编码，以及 SPF DKIM DMARC 三种验证的结果ARC-Seal(abbreviated AS) - A combination of an instance number (i), a DKIM-like signature of the previous ARC-Seal headers, and the validity of the prior ARC entries.
实例编码，以及先前 ARC-Seal 头的签名，以及其他 ARC 条目的 "有效性"（？）ARC-Message-Signature(abbreviated AMS) - A combination of an instance number (i) and a DKIM-like signature of the entire message except for the ARC-Seal headers
实例编码，以及邮件内容 DKIM 类似签名
To sign a modification, an intermediate server performs the following steps:
要对修改进行签名，中间服务器将执行以下步骤：
- Copies the "Authentication-Results" field into a new AAR field (starting with i=1) and prepends it to the message.
将 Authentication-Results 字段复制到新的 AAR 字段（从 i=1 开始）中，并将其附加到邮件前面。 - Calculates the AMS for the message (with the AAR) and prepends it to the message.
计算消息的 AMS（使用 AAR）并将其附加到消息前面。 - Calculates the AS for the previous Arc-Seal headers and prepends it to the message.
计算先前的 Arc-Seal 标头的 AS，并将其附加到消息前面。
To validate an ARC, the recipient performs the following steps:
要验证 ARC，收件人将执行以下步骤：
- Validates the chain of ARC-Seal headers (no missing entries, all ARC-Seal messages state that the prior ARC entries are valid, etc.)
验证 ARC-Seal 标头链（没有丢失条目，所有 ARC-Seal 消息都声明先前的 ARC 条目有效等） - Validates the newest ARC-Message-Signature (based on the instance number)
验证最新的 ARC 消息签名（基于实例编号）
更多信息
Authentication-Results: mx.google.com;
dkim=pass header.i=@postmarkapp.com header.s=20130519032151.pm header.b=SaTOwM7u;
dkim=pass header.i=@pm.mtasv.net header.s=pm header.b=uUBEpN9j;
spf=pass (google.com: domain of pm_bounces@pmbounces.postmarkapp.com designates 50.31.156.124 as permitted sender)
ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass header.i=@postmarkapp.com header.s=20130519032151.pm header.b=SaTOwM7u;
dkim=pass header.i=@pm.mtasv.net header.s=pm header.b=uUBEpN9j;
spf=pass (google.com: domain of pm_bounces@pmbounces.postmarkapp.com designates 50.31.156.124 as permitted sender) smtp.mailfrom=pm_bounces@pmbounces.postmarkapp.com;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=postmarkapp.com
