Skip to main content

7. DMARC Feedback (DMARC 反馈)

以反馈的形式向域所有者提供邮件接收方如何实施和执行 DMARC 机制的可见性，对于建立和维护准确的认证部署至关重要。当域所有者能够看到他们的策略和实践产生的效果时，他们会更愿意也更能够使用隔离和拒绝策略。

7.1. Verifying External Destinations (验证外部目的地)​

可以为不同的报告指定在发出请求的域所有者权限之外的目的地。这允许不运营邮件服务器的域请求报告并将它们发送到能够接收和处理它们的地方。

如果不进行检查，这将允许恶意行为者发布一个 DMARC 策略记录，请求将报告发送到受害者地址，然后向各种目的地发送大量未通过 DKIM 和 SPF 检查的邮件; 受害者反过来将被大量不需要的报告淹没。因此，包含了一个验证机制。

当邮件接收方在 DNS 中发现 DMARC 策略，并且发现该记录的组织域与"rua"或"ruf"标签中指定的 [URI] 的权限组件的主机部分的组织域不相同时，需要执行以下验证步骤:

  1. 提取 URI 权限组件的主机部分。将其称为"目的地主机"。

  2. 在目的地主机前面加上字符串"_report._dmarc"以构造用于查询的 DNS 域名。

  3. 对构造的名称发出 DNS A 或 AAAA RRset 查询。如果查询返回有效的 ANSWER 响应，则结果是与目的地主机对应的 IP 地址列表。

  4. 使用第 3.2 节中描述的方法解析目的地主机的组织域。

  5. 如果从中检索策略的域与目的地主机的组织域相同，则邮件接收方应该 (SHOULD) 发送请求的报告。否则，邮件接收方不得 (MUST NOT) 发送报告。

  6. 如果在执行上述验证后未获得结果，则邮件接收方不得 (MUST NOT) 发送报告。

7.2. Aggregate Reports (聚合报告)​

DMARC 聚合反馈报告旨在为域所有者提供来自邮件接收方的认证结果和合规性的精确洞察。聚合报告作为 XML 文档 [XML] 使用下面指定的格式发送。

聚合报告包含的数据不是特别敏感。但是，它们可以暴露有关域的基础设施和邮件流的信息。第 9 节讨论隐私考虑。

7.2.1. Report Format (报告格式)​

报告格式如下:

聚合反馈报告的 XML 架构在附录 C 中定义。聚合报告必须 (MUST) 按照此架构格式化。

以下是聚合报告的示例:

<?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>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>72.150.241.94</source_ip>
      <count>2</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>fail</result>
        <human_result>fail (body has been altered)</human_result>
      </dkim>
      <dkim>
        <domain>example.net</domain>
        <result>pass</result>
        <human_result></human_result>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

7.2.2. Aggregate Report Data Elements (聚合报告数据元素)​

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

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

  • policy_published: 在报告期间对域有效的 DMARC 策略。

  • record: 包含与特定消息组相关的数据。单个报告中可能存在多个记录元素。

  • row: 关于消息的数据，包括源 IP、消息计数和策略评估结果。

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

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

7.3. Failure Reports (失败报告)​

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

失败报告通常在所有底层认证机制都未能产生符合 DMARC 的结果时发送。但是，域所有者可以使用第 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) 对其进行编辑以保护用户隐私。

Last updated on