3.1. 聚合报告
聚合报告 (Aggregate Reports) 提供认证结果 (authentication results), 纠正措施, 以及 Domain Owner policy 对 mail streams 影响的洞察. 每个 DMARC Policy Domain MUST 生成单独的 report. 一个 report MUST 只包含一个 DMARC Policy Domain 和一个 policy configuration 的数据.
3.1.1. XML 文件内容说明
这些报告的格式由 Appendix A 中的 XML Schema Definition (XSD) 定义. XSD 包括下列某些元素的可能取值. 这些值大多具有与 [RFC9989] 相关联的定义.
以下各节也描述了该格式. 每一节都描述 XML 层级结构中一组同级元素. 每个表都指明其在层级结构中的位置.
如果文档不匹配指定格式, document evaluator SHOULD 丢弃该 report. evaluator MAY 选择尝试利用其中部分数据. 但是, 如果格式存在疑问, 数据本身也可能存在问题. report evaluator MAY 选择联系 report generator, 以便告知其 report 格式存在问题.
列 "#" 指定一个元素可以出现多少次, 这有时称为 multiplicity. 可能的值如下:
O: OPTIONAL, 零个或一个元素
R: REQUIRED, 正好一个元素
*: OPTIONAL, 零个或多个元素
+: REQUIRED, 一个或多个元素
某些元素包含面向人类的文本, 并支持一个可选的 "lang" 属性, 其值表示内容所用语言. 默认值为 "en". 支持该可选属性的元素会在以下表格的内容说明开头标记为 "[@lang]".
3.1.1.1. XML 根元素
DMARC aggregate feedback reports 的根元素为 "feedback", 其 XML namespace 设置为 DMARC namespace.
| Element name | # | Content |
|---|---|---|
| feedback | R | 第一级元素. 参见 Section 3.1.1.2 |
Table 1: XML 根元素
3.1.1.2. 第一级元素
本表中的元素 MUST 按所列顺序出现.
| Element name | # | Content |
|---|---|---|
| version | O | MUST 具有值 1.0. |
| report_metadata | R | Report generator metadata. 参见 Section 3.1.1.3. |
| policy_published | R | receiving system 观察到的 DMARC policy configuration. 参见 Section 3.1.1.5. |
| extension | O | 支持未来扩展性. 参见 Section 3.1.1.6. |
| record | + | 来自 report generator 的 feedback 记录. 参见 Section 3.1.1.7. |
Table 2: 聚合反馈报告的第一级元素
MUST 至少存在一个 "record" 元素. 这些元素包含数据, 表明某些 IP addresses 被观察到为 Author Domain 向 receiving system 投递了消息. 对于每个被报告的 IP address, 至少会有一个 "record" 元素.
3.1.1.3. 报告生成器元数据
| Element name | # | Content |
|---|---|---|
| org_name | R | Reporting Organization 的名称. |
| R | 联系 Reporting Organization 时使用的联系人. | |
| extra_contact_info | O | [@lang] 附加联系详情. |
| report_id | R | 唯一的 Report-ID. 参见 Section 3.5.1. |
| date_range | R | 报告周期. 参见 Section 3.1.1.4. |
| error | O | [@lang] 处理 DMARC Policy Record 时遇到的错误消息. 参见 Section 3.1.5. |
| generator | O | report generator 的名称和版本. 这可以帮助 Report Consumer 找到报告 bug 的位置. |
Table 3: 报告生成器元数据
3.1.1.4. "date_range" 元素的内容
此元素描述以 UTC 定义的时间范围, 即该 report 的 reporting period.
| Element name | # | Content |
|---|---|---|
| begin | R | reporting period 的开始. |
| end | R | reporting period 的结束. |
Table 4: "date_range" 元素的内容
- "begin" 和 "end" 包含自 epoch 以来的秒数.
"begin" 和 "end" 元素用于表示 reporting period, 而不是 reporting period 中观察到的第一条或最后一条消息. 生成 reports 时, 这些 reporting periods SHOULD NOT 重叠. 通常, reporting period 会覆盖单个 UTC 日, 从 0000UTC 开始.
3.1.1.5. "policy_published" 元素的内容
此元素提供为 Author Domain 发布的 DMARC Policy Record 信息. 从 "p" 开始的元素包含所应用 DMARC policy 的发现值或默认值.
未指定的 tags 使用其默认值.
| Element name | # | Content |
|---|---|---|
| domain | R | DMARC Policy Domain. |
| discovery_method | O | evaluation 期间用于发现 DMARC Policy Record 的方法. |
| p | R | Domain Owner Assessment Policy. |
| sp | O | Domain Owner Assessment Policy. |
| np | O | Domain Owner Assessment Policy. |
| fo | O | failure reporting options 的值. |
| adkim | O | DKIM Identifier Alignment 模式. |
| aspf | O | SPF Identifier Alignment 模式. |
| testing | O | "t" tag 的值. |
Table 5: "policy_published" 元素的内容
-
"discovery_method" 可以具有值 "psl" 或 "treewalk". 其中 "psl" 是 [RFC7489] 中的方法, "treewalk" 在 [RFC9989] 中描述.
-
上述许多项目 (p, sp 等) 在 [RFC9989] 中定义.
3.1.1.6. "extension" 元素的内容
使用 extensions 可能会导致在此处添加元素. 这些元素 MUST 具有 namespace.
| Element name | # | Content |
|---|---|---|
<any namespaced element> | * | 由 extension 定义的文件级元素. |
Table 6: "extension" 元素的内容
- "
<any namespaced element>": 在 XML 根元素中声明的相关 extension namespace 中的零个或多个元素.
3.1.1.7. "record" 元素的内容
report MUST 包含一条或多条 records, 说明哪些 IP addresses 被观察到为 Author Domain 向 receiving system 投递了消息. 对于每个被报告的 IP address, 至少会有一个 "record" 元素.
此元素包含 receiving system 针对给定消息集合评估的全部 authentication results.
可以指定不限数量的 "record" 元素.
使用 extensions 可能导致在 record 末尾添加其他元素. 此类元素 MUST 具有 namespace.
每个 tuple 对应一条 record (IP, result, authentication identifiers).
本表中的元素 MUST 按所列顺序出现.
| Element name | # | Content |
|---|---|---|
| row | R | 参见 Section 3.1.1.8. |
| identifiers | R | 用于对给定 "row" 应用 policy 的数据. 参见 Section 3.1.1.10. |
| auth_results | R | 与认证关联于此 sending IP address 的消息相关的数据. 参见 Section 3.1.1.11. |
<any namespaced element> | * | 由 extension 定义的 record 级元素. |
Table 7: "record" 元素的内容
3.1.1.8. "row" 元素的内容
"row" 元素包含连接系统的详情, 以及在所评估 policy 的特定组合下从该系统收到的邮件消息数量.
| Element name | # | Content |
|---|---|---|
| source_ip | R | 连接 IP address. IPv4address 或 IPv6address, 如 [RFC3986] Section 3.2.2 所定义. |
| count | R | 已应用 "policy_evaluated" 的消息数量. |
| policy_evaluated | R | 应用于匹配消息的 DMARC disposition. 参见 Section 3.1.1.9. |
Table 8: "row" 元素的内容
3.1.1.9. "policy_evaluated" 元素的内容
此元素描述应用 DMARC policy 的结果. 如果 alignment 失败, 且所应用的 policy 与 DMARC Policy Domain 配置的 policy 不匹配, 则 MUST 包含 "reason" 元素.
本表中的元素 MUST 按所列顺序出现.
| Element name | # | Content |
|---|---|---|
| disposition | R | 应用 DMARC policy 的结果. |
| dkim | R | DKIM DMARC Identifier Alignment test 的结果. |
| spf | R | SPF DMARC Identifier Alignment test 的结果. |
| reason | * | Policy override reason. 参见 Section 3.1.1.14. |
Table 9: "policy_evaluated" 元素的内容
-
"spf" 和 "dkim" MUST 是与 DMARC 相关的已评估值, 而不是 receiver 在 override policy 时可能使用的值.
-
"reason" 元素用于包含 reporter 可能希望加入的任何说明, 解释为什么 "disposition" policy 与 "policy_published" 不匹配, 例如 local policy override.
3.1.1.10. "identifiers" 元素的内容
| Element name | # | Content |
|---|---|---|
| header_from | R | 消息中的 RFC5322.From domain. |
| envelope_from | O | SPF check 所应用的 RFC5321.MailFrom domain. |
| envelope_to | O | 消息中的 RFC5321.RcptTo domain. |
Table 10: "identifiers" 元素的内容
- 如果消息具有 null reverse-path, "envelope_from" MAY 存在但为空. 参见 [RFC5321] Section 4.5.5.
3.1.1.11. "auth_results" 元素的内容
此元素包含 DKIM 和 SPF results, 不按 DMARC 进行解释.
如果尝试验证任何 DKIM signature, 结果 MUST 包含在 report 中. 但应保持合理数量. 对大量 signatures 的处理见下文 Section 3.1.3.
本表中的元素 MUST 按所列顺序出现.
| Element name | # | Content |
|---|---|---|
| dkim | * | DKIM authentication result. 参见 Section 3.1.1.12. |
| spf | O | SPF authentication result. 参见 Section 3.1.1.13. |
Table 11: "auth_results" 元素的内容
3.1.1.12. "dkim" 元素的内容
| Element name | # | Content |
|---|---|---|
| domain | R | validation 期间使用的 domain, 即 signature 中的 "d=" tag. |
| selector | R | validation 期间使用的 selector, 即 signature 中的 "s=" tag. |
| result | R | DKIM verification result. 见下文. |
| human_result | O | [@lang] 与 evaluation failures 相关的, 提供给 Domain Owner 的更具描述性的信息. |
Table 12: "dkim" 元素的内容
- "result" 是 lowercase string, 其值为 [RFC8601] Section 2.7.1 中定义的 results 之一.
3.1.1.13. "spf" 元素的内容
DMARC 中只使用 "MAIL FROM" identity. 参见 [RFC7208] Section 2.4.
| Element name | # | Content |
|---|---|---|
| domain | R | validation 期间使用的 domain. |
| scope | O | validation 期间使用的 domain 来源. |
| result | R | SPF verification result. 见下文. |
| human_result | O | [@lang] 与 evaluation failures 相关的, 提供给 Domain Owner 的更具描述性的信息. |
Table 13: "spf" 元素的内容
-
"scope" 元素唯一有效值为 "mfrom".
-
"result" 是 lowercase string, 其值为 [RFC8601] Section 2.7.2 中定义的 results 之一.
3.1.1.14. "reason" 元素的内容
policy override reason 由预定义的 override type 和 free-text comment 组成. 参见 Section 3.1.6.
| Element name | # | Content |
|---|---|---|
| type | R | DMARC policy 被 overridden 的原因. |
| comment | O | [@lang] 可用时提供更多详情. |
Table 14: "reason" 元素的内容
3.1.2. 报告中的域处理
同一个 report 中 MUST 只有一个 DMARC Policy Domain, 但可以有多个 RFC5322.From domains. 每个 RFC5322.From domain 都会在 report 中创建自己的 "record". 考虑有三个 domains 存在需要报告的 traffic volume: example.com, foo.example.com, 以及 bar.example.com. example.com 和 bar.example.com 会有显式的 DMARC Policy Records, 且 policies 不同. foo.example.com 没有显式的 DMARC Policy Record, 因此它将依赖为 example.com 描述的 policy. 对于一个 report period, 现在会有两个 reports.
第一个 report 将用于 bar.example.com, 并且只包含一个对应 bar.example.com 的 "record". 第二个 report 将用于 example.com, 并且包含多个 "record" 元素, 一个用于 example.com, 一个用于 foo.example.com. 扩展而言, 也包括其他同样没有显式 DMARC Policy Record 的 subdomains 的 "record" 元素.
3.1.3. 聚合报告中的 DKIM 签名
在单个消息中, 可能存在多个 DKIM signatures. 当对消息执行 validation 时, 某些 signatures 可能 pass, 另一些则可能不 pass. 由于这些 signatures 与 DMARC 相关, 尤其与 aggregate reporting 相关, reporters 可能不清楚应在 report 中包含哪些 DKIM signatures. 无论结果如何, signatures 都可能帮助 report ingester 判断消息来源. 但是, 对于包含哪些 signatures 存在优先顺序.
-
与 RFC5322.From domain 严格 alignment 并通过 DKIM 的 signature
-
与 RFC5322.From domain 宽松 alignment 并通过 DKIM 的 signature
-
任何其他通过的 DKIM signatures
-
未通过的 DKIM signatures
对于给定 "row", report SHOULD 按优先级递减顺序包含不超过 100 个 signatures.
3.1.4. 聚合报告中的唯一标识符
在 report 正文, subject 等位置, 有几处会指定 unique identifier. 对每个 report 而言, 这些 unique identifiers 应保持一致. 如下所示, 读者会看到 "Report-ID" 和 "unique-id". 这些是在使用时 MUST 相同的字段.
3.1.5. Error 元素
以下是 "error" 元素中所含信息的一些示例:
-
DMARC Policy Record evaluation errors, 例如无效的 "rua", "sp" 等.
-
给定位置存在多个 DMARC Policy Records.
请注意, "error" 元素是 unbounded string, 但不应包含极大的正文. 应提供足够信息, 帮助 Domain Owner 理解其 authentication 或 DMARC Policy Record 中的某些问题.
3.1.6. Policy Override Reason
"reason" 元素表示对 DMARC policy 的 override, 由必需的 "type" 元素和可选的 "comment" 元素组成. "type" 元素 MUST 具有下列预定义值之一. "comment" 元素是 unbounded string, 用于提供更多详情.
policy override type 的可能值:
"local_policy": Mail Receiver 的 local policy 使该消息免于适用 Domain Owner 请求的 policy action.
"mailing_list": local heuristics 判定该消息经由 mailing list 到达, 因此不预期原始消息的 authentication 成功.
"other": 发生了此列表中其他条目未涵盖的某种 policy exception. 可在 "comment" 元素中找到更多详情.
"policy_test_mode": 由于 DMARC Policy Record 中 testing mode ("t" tag), 该消息免于应用 policy.
"trusted_forwarder": 根据将该消息关联到本地维护的已知且受信任 forwarders 列表的其他证据, 可预期 message authentication failure.