跳到主要内容

7. DMARC 反馈

以反馈形式让域所有者 (Domain Owner) 了解邮件接收方 (Mail Receiver) 如何实现和执行 DMARC 机制, 对建立和维护准确的认证部署至关重要. 当域所有者能够看到其策略和实践产生的效果时, 他们更愿意也更有能力使用 quarantine 和 reject 策略.

7.1. 验证外部目的地​

可以为不同报告指定不在提出请求的域所有者权限范围内的目的地. 这样, 不运行邮件服务器的域也可以请求报告, 并让报告发送到能够接收和处理它们的位置.

如果没有检查, 恶意行为者就可以发布一条 DMARC 策略记录, 要求将报告发送到受害者地址, 然后向大量目的地发送同时无法通过 DKIM 和 SPF 检查的大量邮件; 受害者随后会被不需要的报告淹没. 因此, 本机制包含了验证步骤.

当邮件接收方在 DNS 中发现 DMARC 策略, 且发现该记录处的组织域 (Organizational Domain) 与 "rua" 或 "ruf" 标签中指定的 [URI] 的 authority 组件主机部分的组织域不相同时, 应执行以下验证步骤:

  1. 提取 URI 的 authority 组件中的主机部分. 将其称为 "destination host".

  2. 在 destination host 前添加字符串 "_report._dmarc", 以构造用于查询的 DNS 域名.

  3. 对构造出的名称发起 DNS A 或 AAAA RRset 查询. 如果查询返回有效的 ANSWER 响应, 其结果就是与 destination host 对应的 IP 地址列表.

  4. 使用 Section 3.2 中描述的方法解析 destination host 的组织域.

  5. 如果检索到策略的域与 destination host 的组织域相同, 邮件接收方 SHOULD 发送所请求的报告. 否则, 邮件接收方 MUST NOT 发送报告.

  6. 如果执行上述验证后没有得到结果, 邮件接收方 MUST NOT 发送报告.

7.2. 聚合报告​

DMARC 聚合反馈报告 (aggregate feedback report) 旨在让域所有者准确了解邮件接收方给出的认证结果和符合性情况. 聚合报告使用下文指定的格式作为 XML 文档 [XML] 发送.

聚合报告包含的数据通常不是特别敏感. 但是, 它们可能暴露有关域基础设施和邮件流的信息. Section 9 讨论隐私考虑.

7.2.1. 报告格式​

报告格式如下:

聚合反馈报告的 XML schema 在 Appendix C 中定义. 聚合报告 MUST 按照该 schema 格式化.

以下是一个聚合报告示例:

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>mail.receiver.example<org_name>
    <email>[email protected]</email>
    <extra_contact_info>http://mail.receiver.example/dmarc/support<extra_contact_info>
    <report_id>9391651994964116463<report_id>
    <date_range>
      <begin>1335521200</begin>
      <end>1335607599</end>
    <date_range>
  <report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    &lt;sp>none&lt;/sp>
    &lt;pct>100&lt;/pct>
  &lt;policy_published>
  &lt;record>
    &lt;row>
      <source_ip>72.150.241.94</source_ip>
      &lt;count>2&lt;/count>
      &lt;policy_evaluated>
        &lt;disposition>none&lt;/disposition>
        &lt;dkim>fail&lt;/dkim>
        &lt;spf>pass&lt;/spf>
      &lt;policy_evaluated>
    &lt;/row>
    &lt;identifiers>
      <header_from>example.com</header_from>
    &lt;/identifiers>
    &lt;auth_results>
      &lt;dkim>
        &lt;domain>example.com&lt;/domain>
        &lt;result>fail&lt;/result>
        &lt;human_result>fail (body has been altered)&lt;human_result>
      &lt;/dkim>
      &lt;dkim>
        &lt;domain>example.net&lt;/domain>
        &lt;result>pass&lt;/result>
        &lt;human_result>&lt;human_result>
      &lt;/dkim>
      &lt;spf>
        &lt;domain>example.com&lt;/domain>
        &lt;result>pass&lt;/result>
      &lt;/spf>
    &lt;auth_results>
  &lt;/record>
&lt;/feedback>

7.2.2. 聚合报告数据元素​

聚合报告中包含以下元素:

  • report_metadata: 关于报告本身的元数据, 包括报告组织, 日期范围和报告 ID.

  • policy_published: 报告期内该域生效的 DMARC 策略.

  • record: 包含与特定一组消息相关的数据. 单个报告中可以出现多个 record 元素.

  • row: 关于消息的数据, 包括源 IP, 消息数量和策略评估结果.

  • identifiers: 从消息中提取的域级标识符.

  • auth_results: SPF 和 DKIM 认证检查的结果.

7.3. 失败报告​

失败报告 (failure report) 可以提供关于未通过认证检查的单个消息的更详细信息. 这些报告按照 [AFRF] 格式化.

失败报告通常在所有底层认证机制都未能产生符合 DMARC 的结果时发送. 但是, 域所有者可以使用 Section 6.3 中描述的 "fo" 标签请求不同的失败报告选项.

失败报告中包含以下元素:

  • Arrival-Date: 接收消息的日期和时间.

  • Authentication-Results: 消息的认证结果, 包括 SPF 和 DKIM 结果.

  • Delivery-Result: 邮件接收方采取的动作.

  • DKIM-Domain: DKIM "d=" 值.

  • DKIM-Identity: DKIM "i=" 值.

  • DKIM-Selector: DKIM "s=" 值.

  • Reported-Domain: 来自 RFC5322.From 头字段的域.

  • Source-IP: 发起连接的 SMTP 客户端的 IP 地址.

  • SPF-DNS: 从 DNS 检索到的 SPF 记录.

失败报告 SHOULD 在不披露可能对攻击者有用的信息的前提下包含尽可能多的细节. 如果包含消息正文, 则 SHOULD 对其进行删减以保护用户隐私.

最后于 更新