跳到主要内容

6. 策略

DMARC policy 由 Domain Owner 发布, 并由 Mail Receiver 应用.

Domain Owner 通过向其一个或多个域添加 DNS TXT 记录 (见 Section 6.1) 来宣告这些域参与 DMARC. 这样做时, Domain Owner 会就声称来自其某个域的消息的处置, 以及关于这些消息的反馈提供, 向 Mail Receiver 提出具体请求.

Domain Owner 可以选择不参与 Mail Receiver 的 DMARC 评估. 在这种情况下, Domain Owner 只需拒绝宣告参与这些方案. 例如, 如果对于给定 Author Domain, 路径授权检查的结果不应作为整体 DMARC 结果的一部分来考虑, 则 Domain Owner 不发布能够产生 SPF pass 结果的 SPF policy 记录.

实现 DMARC 机制的 Mail Receiver 在消息未通过 DMARC 测试时, SHOULD 尽最大努力遵循 Domain Owner 发布的 DMARC policy. 由于电子邮件流可能很复杂 (例如因为转发, 既有 RFC5322.From 域伪造服务等), Mail Receiver MAY 在消息处理期间偏离 Domain Owner 发布的策略, 并 SHOULD 通过反馈报告向 Domain Owner 提供偏离这一事实及原因, 尤其是使用聚合报告的 "PolicyOverride" 功能 (见 Section 7.2).

6.1. DMARC Policy Record​

Domain Owner 的 DMARC 偏好存储为名为 "_dmarc" 的子域中的 DNS TXT 记录. 例如, "example.com" 的 Domain Owner 会在 "_dmarc.example.com" 的 TXT 记录中发布 DMARC 偏好. 类似地, 希望查询 RFC5322.From 域为 "example.com" 的邮件相关 DMARC 偏好的 Mail Receiver, 会向 DNS 发起针对 "_dmarc.example.com" 子域的 TXT 查询. 下文将通过 DNS 定位到的 DMARC 偏好数据称为 "DMARC record".

DMARC 对 Domain Name Service 的使用, 由 DMARC 对域名的使用以及它所执行查询的性质所驱动. 查询需求与 DNS 相匹配, 用于获取简单的参数化信息. 它使用一种已确立的信息存储方法, 将信息与目标域名关联, 即限制在 DMARC 上下文中的独立 TXT 记录. 使用 DNS 作为查询服务的好处是可以复用极为成熟的运营, 管理和维护基础设施, 而无需创建新的基础设施.

按照 [DNS], 一个 TXT 记录可以包含多个 "character-string" 对象. 在这种情况下, 执行 DMARC 评估的模块 MUST 按顺序将这些对象连接起来, 并将结果作为单个字符串解析.

6.2. DMARC URIs​

[URI] 定义了用于标识资源的通用语法. DMARC 机制使用该语法作为 Domain Owner 指定两种受支持报告类型目的地的格式.

指定此类 URI 的位置 (见 Section 6.3) 允许提供一个 URI 列表. 报告通常会按照 Domain Owner 提供的顺序发送到每个列出的 URI. Receiver MAY 对其发送报告的 URI 数量施加限制, 但 MUST 支持至少发送到两个 URI 的能力. URI 列表以逗号分隔 (ASCII 0x2C).

每个 URI 可以关联一个可发送到该 URI 的最大报告大小. 这是通过在分隔逗号或终止分号之前追加一个感叹号 (ASCII 0x21), 后接最大大小指示来实现的.

因此, DMARC URI 是一个 URI, 其中任何逗号或感叹号都按 [URI] 进行百分号编码, 后跟一个 OPTIONAL 感叹号和最大大小规范, 并且如果列表中还有其他报告 URI, 则后跟一个逗号和下一个 URI.

例如, URI "mailto:[email protected]!50m" 将请求通过电子邮件向 "[email protected]" 发送报告, 前提是报告载荷不超过 50 MB.

正式定义见 Section 6.4.

6.3. General Record Format​

DMARC record 遵循 DKIM [DKIM] 中为基于 DNS 的密钥记录定义的可扩展 "tag-value" 语法.

Section 11 为已知 DMARC tag 创建注册表, 并注册本文档定义的初始集合. 只处理本文档或后续扩展中定义并因此加入该注册表的 tag; 未知 tag MUST 被忽略.

以下 tag 作为初始有效 DMARC tag 引入:

adkim: (plain-text; OPTIONAL; default is "r".) 指示 Domain Owner 要求 strict 还是 relaxed DKIM Identifier Alignment 模式. 详见 Section 3.1.1. 有效值如下:

  • r: relaxed mode
  • s: strict mode

aspf: (plain-text; OPTIONAL; default is "r".) 指示 Domain Owner 要求 strict 还是 relaxed SPF Identifier Alignment 模式. 详见 Section 3.1.2. 有效值如下:

  • r: relaxed mode
  • s: strict mode

fo: Failure reporting options (plain-text; OPTIONAL; default is "0") 提供生成失败报告时请求的选项. 报告生成器 MAY 选择遵循所请求的选项. 如果未同时指定 "ruf" tag (见下文), 则此 tag 的内容 MUST 被忽略. 此 tag 的值是一个以冒号分隔的字符列表, 表示如下失败报告选项:

  • 0: 如果所有底层认证机制都未能产生 aligned "pass" 结果, 则生成 DMARC 失败报告.
  • 1: 如果任一底层认证机制产生的结果不是 aligned "pass" 结果, 则生成 DMARC 失败报告.
  • d: 如果消息带有一个评估失败的签名, 则生成 DKIM 失败报告, 无论其 alignment 如何. DKIM 专用报告在 [AFRF-DKIM] 中描述.
  • s: 如果消息未通过 SPF 评估, 则生成 SPF 失败报告, 无论其 alignment 如何. SPF 专用报告在 [AFRF-SPF] 中描述.

p: Requested Mail Receiver policy (plain-text; REQUIRED for policy records). 指示 Receiver 应 Domain Owner 请求执行的策略. 除非使用 "sp" tag 显式描述子域策略, 否则该策略适用于被查询的域及其子域. 此 tag 仅对策略记录是强制的, 对第三方报告记录不是强制的 (见 Section 7.1). 可能的值如下:

  • none: Domain Owner 请求不对消息投递采取特定动作.
  • quarantine: Domain Owner 希望 Mail Receiver 将未通过 DMARC 机制检查的电子邮件视为可疑. 根据 Mail Receiver 的能力, 这可能表示 "place into spam folder", "scrutinize with additional intensity" 和/或 "flag as suspicious".
  • reject: Domain Owner 希望 Mail Receiver 拒绝未通过 DMARC 机制检查的电子邮件. 拒绝 SHOULD 在 SMTP 事务期间发生. 关于 SMTP 拒绝方法及其影响的一些讨论, 见 Section 10.3.

pct: (plain-text integer between 0 and 100, inclusive; OPTIONAL; default is 100). 应应用 DMARC policy 的 Domain Owner 邮件流消息百分比. 然而, 这 MUST NOT 应用于 DMARC 生成的报告, 这些报告都必须无阻碍地发送和接收. "pct" tag 的目的是允许 Domain Owner 逐步推出 DMARC 机制的强制执行.

rf: Format to be used for message-specific failure reports (colon-separated plain-text list of values; OPTIONAL; default is "afrf"). 此 tag 的值是一个或多个报告格式的列表, 由 Domain Owner 请求在消息同时未通过 SPF 和 DKIM 测试时用于报告单个失败的细节. 目前仅定义了 "afrf" ([AFRF] 中定义的 auth-failure 报告类型).

ri: Interval requested between aggregate reports (plain-text 32-bit unsigned integer; OPTIONAL; default is 86400). 指示请求 Receiver 生成聚合报告的间隔不小于所请求的秒数. DMARC 实现 MUST 能够提供每日报告, 并且在被请求时 SHOULD 能够提供每小时报告. 然而, 每日报告之外的任何报告都被理解为按最大努力方式提供.

rua: Addresses to which aggregate feedback is to be sent (comma-separated plain-text list of DMARC URIs; OPTIONAL). 一个以逗号分隔的 DMARC URI 列表, 指示应将聚合反馈发送到哪些地址 (DMARC URI 的规范见 Section 6.2). 可以指定任何有效 URI. Mail Receiver MUST 实现对 "mailto:" URI 的支持, 即通过电子邮件发送 DMARC 报告的能力. 如果未提供, Mail Receiver MUST NOT 生成聚合反馈报告. Mail Receiver 不支持的 URI MUST 被忽略. 聚合反馈报告 SHOULD 使用 Section 7.2 中描述的格式.

ruf: Addresses to which message-specific failure information is to be reported (comma-separated plain-text list of DMARC URIs; OPTIONAL). 一个以逗号分隔的 DMARC URI 列表, 指示应将消息专用失败报告发送到哪些地址 (DMARC URI 的规范见 Section 6.2). 如果未提供, Mail Receiver MUST NOT 生成失败报告. Mail Receiver MAY 选择以 [AFRF] 之外的格式发送失败报告.

sp: Requested Mail Receiver policy for all subdomains (plain-text; OPTIONAL). 指示 Receiver 应 Domain Owner 请求执行的策略. 它只适用于被查询域的子域, 不适用于该域本身. 其语法与上面定义的 "p" tag 相同. 如果缺失, 则 "p" tag 指定的策略 MUST 应用于子域.

v: Version (plain-text; REQUIRED). 标识所获取的记录为 DMARC record. 它 MUST 具有 "DMARC1" 值. 此 tag 的值 MUST 出现在 DMARC record 的最前面. 示例: "v=DMARC1; p=none; rua=mailto:[email protected]"

6.4. Formal Definition​

(完整 ABNF 语法请参阅 RFC 7489)

6.5. Domain Owner Actions​

要参与 DMARC, Domain Owner 需要:

  1. 为该域部署 SPF 和/或 DKIM.

  2. 确保 RFC5322.From 域与 SPF 和/或 DKIM 认证的域对齐.

  3. 在 DNS 中发布 DMARC policy.

  4. 监控反馈报告, 并按需调整策略.

6.6. Mail Receiver Actions​

Mail Receiver 通过查询 DNS 中的 DMARC policy 记录, 并将请求的策略应用于 DMARC 评估失败的消息, 来实现 DMARC.

6.6.1. Extract Author Domain​

Mail Receiver 需要从 RFC5322.From 头字段提取域. 要评估的域是 RFC5322.From 字段的域部分.

6.6.2. Determine Handling Policy​

Mail Receiver 通过以下方式确定消息的适当处理策略:

  1. 检查 "_dmarc.{RFC5322.From domain}" 处是否存在策略.
  2. 如果未找到, 应用 Section 3.2 中的算法确定 Organizational Domain, 并检查 "_dmarc.{Organizational Domain}" 处是否存在策略.
  3. 如果仍未找到, Mail Receiver 应用其自身的本地策略.

6.6.3. Policy Discovery​

Domain Owner 可以在其域层次结构中的任意点发布 DMARC policy 记录. Mail Receiver 在 "_dmarc.{domain}" 处查询 DNS 以获取 DMARC TXT 记录. 如果未找到, 则确定 Organizational Domain, 并对 Organizational Domain 重复该查询.

6.6.4. Message Sampling​

"pct" tag 允许 Domain Owner 通过指定只对一定百分比的消息应用策略, 来逐步部署 DMARC. 未被 "pct" 机制选中的消息会被视为 "p" tag 设置为 "none".

6.7. Policy Enforcement Considerations​

Mail Receiver 在强制执行 DMARC policy 时应考虑以下事项:

  1. Mailing Lists: 许多邮件列表会以破坏 DKIM 签名并导致 SPF 检查失败的方式修改消息.

  2. Forwarding: 简单转发不会破坏 DKIM 签名, 但会导致 SPF 检查失败.

  3. Local Policy: Mail Receiver 可以根据本地知识或策略选择覆盖已发布的 DMARC policy.

  4. Reporting: 覆盖策略时, Mail Receiver 应通过聚合报告中的 PolicyOverride 功能报告这一情况.

最后于 更新