跳到主要内容

4. 验证外部目标

可以为不同 reports 指定不在发出请求的 Domain Owner 权限范围内的 destinations. 这允许不运行 mail servers 的 domains 请求 reports, 并让 reports 发送到能够接收和处理它们的位置.

如果没有检查, 恶意行为者就可以发布一个 DMARC Policy Record, 请求将 reports 发送到 victim address, 然后向大量 destinations 发送大量会同时未通过 DKIM 和 SPF checks 的邮件. victim 随后会被不需要的 reports 淹没. 因此, 本文包含了一个 verification mechanism.

当 Mail Receiver 在 DNS 中发现 DMARC Policy Record, 且发现该 record 所在的 Organizational Domain 不同于 "rua" tag 中指定的 [RFC3986] authority component 的 host part 所属 Organizational Domain 时, MUST 执行以下 verification steps:

  1. 提取 URI authority component 的 host portion. 将其称为 "destination host", 因为它指代 Report Receiver.

  2. 前置字符串 "_report._dmarc".

  3. 前置检索 policy 的 domain name, 如有需要, 先转换为 A-label [RFC5890].

  4. 如果构造出的 name 长度超过 DNS limits, 则无法对 external reporting relationship 做出肯定判定. 停止.

  5. 在构造出的 name 处查询 DNS TXT record. 如果此请求的结果是某种 temporary DNS error, 例如 timeout, Mail Receiver MAY 选择临时失败 delivery, 以便稍后重复 verification test.

  6. 对返回的每条 record, 将结果解析为一系列 "tag=value" pairs, 即与 DMARC Policy Record 相同的总体格式. 参见 [RFC9989] Section 4.7. 特别是, "v=DMARC1" tag 是 mandatory, 并且 MUST 出现在列表首位. 丢弃任何未通过此测试的 record. 末尾的 ";" 是 optional.

  7. 如果结果中没有通过基本解析的 TXT resource records, 则无法对 external reporting relationship 做出肯定判定. 停止.

  8. 如果解析后集合中至少保留一条 TXT resource record, 则 external reporting arrangement 已由 Report Consumer 授权.

  9. 如果因此发现 "rua" tag, 则用此 record 中找到的值替换从 domain 的 DMARC Policy Record 中提取的相应值. 这允许 Report Consumer override report destination. 但是, 为防止 loops 或 indirect abuse, overriding URI MUST 使用第一步中的同一 destination host.

例如, 如果 "blue.example.com" 的 DMARC Policy Record 包含 "rua=mailto:[email protected]", 从后者提取的 Organizational Domain host ("red.example.net") 与 "blue.example.com" 不匹配, 因此会执行此过程. 随后发出对 "blue.example.com._report._dmarc.red.example.net" 的 TXT query. 如果返回的单个 reply 包含 "v=DMARC1" tag, 则确认二者之间的关系. 此外, 如有需要, "red.example.net" 有机会 override "blue.example.com" 请求的 report destination.

如果上述 algorithm 未能确认 external reporting 已由 Report Consumer 授权, 生成 report 的 Mail Receiver MUST 忽略该 URI. 此外, 如果确认 record 包含的 URI 之 host 又不同于发布该 override 的 domain, 则生成 report 的 Mail Receiver MUST NOT 向原始 URI 或 override URI 生成 report. Report Consumer 如果希望接收其他 domains 的 reports, 就在其 DNS 中发布此类 record.

愿意接收任何 domain 的 reports 的 Report Consumer 可以使用 wildcard DNS record. 例如, 位于 "*._report._dmarc.example.com" 的 TXT resource record 只要至少包含 "v=DMARC1", 就确认 example.com 愿意为任何 domain 接收 DMARC reports.

如果 Report Consumer 被 volume 压垮, 它可以简单地移除确认 DNS record. 但是, 由于 positive caching, 更改最长可能需要该 record 的 Time to Live (TTL) 才会生效.

如果 DNS query length 过长, 即上文 Step 4 的情况, Domain Owner 可能需要考虑使用更短的 domain name, 或与可能允许更短 DNS label 的另一方协调.

最后于 更新