RFC 7001《表示邮件认证状态的头字段（Authentication-Results）》中文导读
诚实披露：本页为 IETF RFC 7001 的中文译介版本。原文由 IETF 发布，依 IETF Trust 条款可自由再制与翻译；本译本由 AI 基于人类权威一手文献（RFC 英文原文）辅助整理生成，非人类原创，亦非逐字全文翻译，仅供学习参考。任何规范性判断以英文原文为准，英文原文见 rfc-editor.org/rfc/rfc7001.txt。
摘要
RFC 7001 定义了 Authentication-Results 邮件头字段。当一个管理域（ADMD）在入站边界完成 SPF、DKIM、DomainKeys、反向解析核验（iprev）、SMTP AUTH 等身份认证动作后，可以把这些结果以机器可读的统一格式记入邮件头，交给下游的过滤器、邮件列表处理器乃至最终的 MUA 使用。
本文档在 RFC 5451 的基础上修订而成，并合并了 RFC 6577 的内容与发布后的勘误，因而同时废止（Obsoletes）这两份文档。需要注意的是，RFC 7001 本身其后又被 RFC 7601 取代，当前工程实践应以 RFC 7601 及 IANA 注册表的最新状态为准；本篇导读用于理解该字段的形成脉络与规范意图。
1. 引言、信任边界与适用范围
邮件认证机制（SPF、DKIM 等）的判定通常发生在接收方的边界 MTA 上，而真正需要这些判定结果的往往是下游组件。RFC 7001 解决的正是「结果如何跨组件传递」的问题：把判定固化为一个标准头字段，避免每个实现各造一套私有头。
文档反复强调 信任边界（trust boundary） 概念：该头字段的价值完全建立在「它确实由本 ADMD 内受信任的组件写入」这一前提之上。一旦无法确认来源，字段内容就毫无意义——这也是第 5 节存在的原因。
本规范只定义「如何表达结果」，不规定「拿到结果后应当如何处置」：是否拒信、是否打标、是否投入垃圾箱，均属接收方本地策略。
2. 头字段的定义与格式
字段的整体结构可概括为三段：
- authserv-id：执行认证动作的认证服务标识（通常是边界主机名或 ADMD 名），用于让下游判断「这条结果是谁写的」。
- 版本号（可选）：紧随 authserv-id 之后的数字，标识本字段所遵循的规范版本。
- 一个或多个 resinfo 段：每段以分号引导，形如
method=result，其后可选带reason=...说明，以及若干ptype.property=pvalue属性，用来记录判定所依据的具体输入。
其中 ptype 的取值集合为 smtp（取自 SMTP 会话，如 smtp.mailfrom）、header（取自邮件头，如 header.d、header.from）、body（取自正文）与 policy（表示该结果源自本地策略判定而非协议输出）。若本次未做任何认证，可使用 none 形式表明「无结果」。
ABNF 形式语法见原文第 2.2 节；本导读不逐条复刻语法产生式，实现时请直接对照英文原文。
2.6 已定义的认证方法与结果关键字
| method | 含义 | 常见 result 关键字 |
|---|---|---|
dkim / domainkeys | DKIM 签名校验 / 历史 DomainKeys | none、pass、fail、policy、neutral、temperror、permerror |
spf | SPF 校验 | none、pass、fail、softfail、policy、neutral、temperror、permerror |
sender-id | Sender ID 校验 | 同 SPF 集合 |
iprev | 客户端 IP 的反向/正向解析一致性核验 | pass、fail、temperror、permerror（无 none） |
auth | SMTP AUTH 认证 | none、pass、fail、temperror、permerror |
dkim-adsp | 作者域签名策略（ADSP）评估 | 见 IANA 注册表 |
此外，vbr（Vouch By Reference）与 dkim-atps 亦为已注册方法。方法与结果关键字均由 IANA 注册表维护，新增须经指定专家评审，因此实现不应把关键字集合写死。
3. iprev 认证方法
iprev 指对连接来源 IP 先做 PTR 反查得到域名，再对该域名做正查、确认能解析回原 IP 的一致性校验。RFC 7001 正式定义了这一方法在本字段中的表达形式，同时明确其可靠性存在争议：许多合法邮件源并未正确配置反向解析，因此文档不建议将 iprev 视为强认证手段，验证方可自行决定如何报告与使用其结果。
4. 向邮件添加该头字段
规范要求执行认证的 MTA 把新生成的字段加在邮件头顶部，从而与 Received 链的时序保持一致，便于下游按「自上而下＝由近及远」解析。关键约束是：
"An MTA MUST NOT add a result to an existing header field."（§4）
译：MTA 不得向一个已存在的该头字段实例中追加结果。
也就是说，每一次认证动作应写入新的独立实例，而不是就地改写别人写的字段——否则将破坏「每个实例可归因到唯一 authserv-id」的信任模型。
文档还指出，若本地策略决定拒收未通过认证的邮件，应尽量在 SMTP 会话阶段直接拒绝（给出 5xx），而不是先收下再退信，以避免制造反向散射（backscatter）。
5. 删除既有实例：防伪造的关键一步
这是全文最具安全意义的规定。攻击者完全可以在自己发出的邮件中预先伪造一条形如「本域已验证通过」的 Authentication-Results 字段，若边界 MTA 原样放行，下游组件就会被欺骗。因此规范要求：
"For security reasons, any MTA conforming to this specification MUST delete any discovered instance of this header field that claims, by virtue of its authentication service identifier, to have been added within its trust boundary but that did not come directly from another trusted MTA."（§5）
译：出于安全原因，符合本规范的 MTA 必须删除所发现的、凭其认证服务标识声称是在本信任边界内添加、但实际并非直接来自另一台受信 MTA 的任何该字段实例。
边界 MTA 有两种落地做法：一是删除全部外来实例（最简单、最安全）；二是维护受信 authserv-id 白名单，仅放行名单内的实例。无论哪种，都必须保证「带本域 authserv-id 的字段只可能由本域产生」。
6. IANA 考虑
IANA 完成了该头字段本身的注册，并维护两张注册表：Email Authentication Methods（认证方法）与 Email Authentication Result Names（结果名称）。新增条目采用「指定专家评审」策略；既有条目的引用在本文档发布时统一更新指向 RFC 7001。
7. 安全考量
- 伪造字段：最主要风险，缓解手段即第 5 节的强制删除规则。
- 结果具误导性：认证通过只代表「标识合法」，不代表内容可信——通过 SPF/DKIM 的钓鱼邮件完全可能存在。
- 字段位置：解析方必须依据位置与 Received 链判断实例的生成顺序，不能仅凭内容取信。
- 拒绝服务：认证动作涉及 DNS 与密码学运算，构造大量待验邮件可放大资源消耗。
- 内部主机沦陷：信任边界内任一主机被攻陷，即可注入任意可信结果，整个模型随之失效。
- MUA 行为：MUA 不应默认信任该字段，且必须忽略出现在 MIME 附件内部的实例（附件中的「邮件」不是本次投递的认证对象）。
8. 附录要点
原文附录包含：致谢；对旧版 MUA 的兼容建议；一组头字段书写示例；运维层面的考量；以及相对 RFC 5451 的变更记录。其中「变更记录」对从 5451 迁移的实现尤为有用。
参考链接
- RFC 7001 英文原文：https://www.rfc-editor.org/rfc/rfc7001.txt
- IETF Datatracker 页面：https://datatracker.ietf.org/doc/html/rfc7001
- 后继规范 RFC 7601（现行）：https://www.rfc-editor.org/rfc/rfc7601
- 被废止的 RFC 5451：https://www.rfc-editor.org/rfc/rfc5451
- IANA「Email Authentication Parameters」注册表：https://www.iana.org/assignments/email-auth/