摘要

  • RFC 9990 将聚合报告定义为接收端在一个报告期内提供的 XML 观察：它包含所观察到的策略、源 IP 记录、计数和认证结果。
  • 外部 rua 目的地的 DNS 确认只说明 Report Consumer 同意接收该报告关系；它不证明报告完整、真实或足以触发封禁等高影响措施。

最容易被忽略的是报告的视角。RFC 9990 规定，policy_published 是接收系统所观察到的 DMARC 策略配置；每个 record 说明某些 IP 地址被看到向该接收系统投递了代表 Author Domain 的邮件。这里的“观察到”和“该系统”不是无关紧要的措辞，而是这份证据的边界。

因此，报告能回答一些很有价值的问题。它可能暴露未登记的群发服务、已失效的 DKIM 签名、迁移后遗漏的发送源，或值得核查的异常量。它不能回答所有接收者看到了什么，不能说明哪一个人写了邮件，也不能证明来源有欺骗意图。一个接收端的计数不是互联网总量；一个处置结果也不是所有接收端必须接受的判决。

这一区别在仪表盘里尤其容易消失。团队把某行里的大计数、reject 或一次策略覆盖压缩为“风险已确认”，然后把该标签接到供应商限制、账户处理或邮件策略变更。这样的行动在有其他证据时或许合理，但不是 RFC 9990 已经替他们作出的决定。协议传递了可比较的观察，不传递制裁权。

报告期不是首尾消息之间的完整档案

该 RFC 对文件结构很具体：报告必须有生成者元数据、policy_published 和至少一个 record；元数据含有报告标识以及 UTC 时间范围。规范特别说，开始和结束时间标的是报告期，不是该期中第一封和最后一封被观察到的邮件。报告期通常是一整天 UTC，也不应相互重叠。

这使得“没有出现”与“从未发生”不能互换。窗口内未见到某个来源，不证明它没有发送；窗口内出现一个来源，也不证明其他接收端见到相同模式。auth_results 中的 DKIM 和 SPF 结果按 RFC 9990 的表述，对 DMARC 而言仍是未解释的结果。策略覆盖原因同样只是接收端为何覆盖其策略的记录，并非对发件人的身份、动机或责任的认定。

把报告转化为行动前，应与本地可控制的事实对照：授权发送源目录、DNS 与密钥历史、投递日志、供应商变更记录、转发路径，以及其他独立接收端的重复观察。原始文件、文件哈希、解析后的字段和仪表盘推导出的分数应分别保存。任何“高风险”结论都是本地系统新增的推理，必须有自己的负责人和可复核依据。

确认接收的目的地，并没有接管后续决定

域名所有者可以通过 rua 请求报告送达的地址。若该地址在组织域名之外，RFC 9990 要求 Mail Receiver 执行外部目的地验证：按规定构造 DNS 名称，查询确认记录；若无法形成肯定判断，接收端必须忽略该 URI。这样可以防止攻击者把报告导向受害者，再通过大量失败邮件让许多接收端替自己制造反射流量。

确认记录的含义很窄：这个 Report Consumer 愿意为这段报告关系接收报告。它不决定谁能查看报告，不规定保留多久，不许可转交给下游方，也不授权将记录与其他数据库结合后采取制裁。RFC 9990 还提醒，向第三方发送报告可能受到 Mail Receiver 隐私政策或使用条款的限制；聚合报告不含个人邮箱地址、个人 IP 地址和邮件内容，却仍可能让接收方分析域级流量。

所以 DNS 之外还需要一份明确的治理清单：每个外部目的地允许接收哪些政策域、目的为何、谁负责、哪些角色可访问、可以做何种变换、保留与删除期限、是否允许再传递、出现事件由谁处理。DNS 记录应与这份清单相互核对，但它不能替代清单。

对齐的报告邮件、可解析的 XML、可信内容是三道不同的关

聚合数据通过邮件中的 XML 附件发送，通常使用 GZIP。RFC 9990 要求承载反馈数据的邮件流自身符合 DMARC 并获得对齐的 pass，以降低 Report Consumer 处理伪造报告的风险；文件名和 Report-ID 也帮助处理重复发送。

这些措施并不使报告中的每个断言为真。规范明确警告，攻击者可以伪造聚合数据、大量提交以影响政策或平台架构决定；畸形报告还能对解压器或 XML 解析器实施 zip bomb、XML bomb 等资源耗尽攻击。一份文件即便看似从熟悉的地方到达正确地址，也可能是虚假、不完整或危险的输入。

接收链路的第一项工作应是验证和隔离，而不是改策略：在解压前后限制字节数，约束 XML 复杂度，按预期模式校验，把原始件放进受限存储。格式有疑问时，RFC 9990 允许评估者丢弃或暂存报告，并与生成方协作。解析成功不等于证据可靠；证据可靠也不等于高影响处置已经正当。

RFC 9989 给出了同样克制的政策背景：依邮件发送节奏不同，域名所有者可能需要消费聚合报告数月，才有把握所有邮件均已正确认证，而 p 的选择取决于其自身需要。聚合报告为本地决策累积材料，绝不替代该决策。

编辑解释：受限的共同层

这是一种编辑解释，而非 IETF 要求：共同格式、可验证路由与反射防护足以支持互操作，无须由格式建立一个管理他人邮件政策的中央权威。链路必须拆开记录：哪一个接收端观察到，哪个验证器接受了，谁决定改变政策，以及改变后究竟发生了什么。