DMARCbis 中 forensic failure report（RUF）的报告机制和格式有什么变化？

鉴证失败报告（Forensic Failure Report，简称 RUF/FR）是 DMARC 体系中用于发送方获取具体认证失败邮件细节的机制。DMARCbis 对这一功能进行了全面修订，重点解决了原标准中学界和业界长期存在的若干争议。

一、原 RFC 7489 中 RUF 的问题

• 隐私风险过大：RFC 7489 要求 RUF 报告包含原始邮件的"全部内容"，包括邮件正文和附件。这在 GDPR 和其他隐私法规框架下几乎不可行
• 重复冗余：许多邮件内容重复发送，发送方收到的 RUF 报告数据量远大于实际需要
• 报告触发条件模糊：RFC 7489 使用 fo=（failure options）标签控制何时触发 RUF，但 fo 标签的含义不够明确，导致各接收方实现差异很大
• 格式不统一：实际使用中，RUF 的格式（AFRF, RFC 5965 格式）缺乏标准化细节

二、DMARCbis 中 RUF 的主要修订

1. 触发条件（fo=）的语义明确化

原 RFC 7489 定义了四个 fo 值（0、1、d、s），但语义重叠且实现不一致。DMARCbis 重新定义 fo 标签：

fo值	RFC 7489 含义	RFC 9989 含义（修订后）
0	仅 SPF/DKIM 均失败时生成RUF	仅 DMARC 验证失败时生成RUF（SPF且DKIM均不对齐）
1	SPF或DKIM任意一个失败时生成RUF	DMARC 验证失败或单个认证失败时生成RUF
d	DKIM 失败时生成RUF	保留，明确仅指 DKIM 验证失败
s	SPF 失败时生成RUF	保留，明确仅指 SPF 验证失败

最重要的变化：fo=0 的默认行为更窄了。在 RFC 7489 下，fo=0 的含义在实践中解释不一；DMARCbis 将其严格限制为"DMARC 评估结果为 fail 时才生成 RUF"，避免了过去"即使邮件通过了 DMARC 也会生成 RUF"的问题。

2. 原始邮件内容变为可选（OPTIONAL）

这是最受业界欢迎的修订之一。RFC 9989 明确：

• RUF 报告中的 original-mail 部分现在是可选的（OPTIONAL）而不是必选的（REQUIRED）
• 接收方可以选择发送摘要信息（邮件头 + 部分元数据）而非完整邮件内容
• 发送方可以在 ruf= URI 中附加参数指示是否期望完整内容

3. 新增结构化失败字段

DMARCbis 标准化的 AFRF（Abuse Feedback Report Format）扩展字段包括：

X-DMARC-Failure-Reason: both-fail
X-DMARC-Failure-Detail: dkim-result=fail, spf-result=fail
X-DMARC-Policy-Action: reject
X-DMARC-ARC-Status: none

这些字段在邮件头级别直接标注失败原因，接收方无需解析 XML 格式的 RUF 内容即可获取关键信息。

三、DMARCbis 中配置 RUF 的示例

; DMARCbis RUF 配置示例
v=DMARC1; p=reject; fo=1;
rua=mailto:rua@example.com;
ruf=mailto:ruf@example.com!summary;
; !summary 参数表示只需要摘要（不含原始邮件内容）

注意 !summary 参数是 DMARCbis 新引入的 ruf URI 扩展语法。类似地：

• !summary — 仅发送邮件头摘要和失败元数据
• !full — 发送包含完整原始邮件内容的报告（谨慎使用）
• !headers — 发送完整邮件头但不包含正文和附件

四、RUF 与隐私合规（GDPR/PIPL）

原 RFC 7489 的 RUF 设计在 GDPR 生效后实际上已无法广泛使用——发送未经授权的个人通信内容到第三方地址明显违反数据最小化原则。DMARCbis 的修订使 RUF 重新变得合规：

• 默认不包含原始邮件内容，仅发送认证失败元数据
• 接收方需要对 RUF 数据进行适当的去标识化处理
• 报告发送前应进行数据泄露风险评估

五、部署建议

1. 如果之前因为隐私顾虑没有启用 ruf，现在可以试用 !summary 模式
2. 从 fo=1 开始监控，确认报告量在可接受范围内再调整
3. 确保 ruf 接收地址支持 AFRF 格式解析
4. 定期审查 RUF 报告内容，确保没有泄露敏感信息