翻译披露：本页为对 IETF RFC 9091《Experimental Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Extension for Public Suffix Domains》 的中文翻译，原文著作权归 IETF/原作者所有，内容以人类原始 RFC 为准。本译本由 ztpop.net 整理，仅供学习参考；RFC 受 BCP 78 与 IETF 信托法律条款约束，译本保留原文编号与结构，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc9091。

RFC 9091：面向公共后缀域的实验性 DMARC 扩展（PSD DMARC）

IETF · RFC 9091 · 实验性（Experimental） · S. Kitterman（fTLD Registry Services）、T. Wicinski（编辑） · 2021 年 7 月

摘要

基于域名的消息鉴别、报告与一致性（DMARC，定义于 RFC 7489）允许一个掌控域名的组织表达域名级的策略与偏好，用于消息验证、处置与报告，邮件接收组织可藉此改进邮件处理。

DMARC 区分了一个名称中属于公共后缀域（Public Suffix Domain，PSD）的部分，其下创建组织域（Organizational Domain）名称。基本 DMARC 能力允许组织域指定适用于其子域的策略，但并未将该能力赋予 PSD。本文档描述了对 DMARC 的一项扩展，以完整启用 PSD 的 DMARC 功能。

DMARC 的某些实现对 PSD 视为不符合 DMARC 强制执行的资格。本规范处理这一情形。

本备忘录的状态

本文档并非互联网标准跟踪规范；其发布供审查、实验性实现与评估之用。

本文档为互联网社区定义了一项实验性协议。本文档是互联网工程任务组（IETF）的产物，代表 IETF 社区的共识，已经过公开评审，并由互联网工程指导组（IESG）批准发布。并非所有经 IESG 批准的文档都能成为任何级别的互联网标准；参见 RFC 7841 第 2 节。

关于本文档当前状态、任何勘误，以及如何就其提供反馈的信息，可在 https://www.rfc-editor.org/info/rfc9091 获取。

版权声明

本文档受 BCP 78 以及 IETF 信托的《IETF 文档相关法律规定》（https://trustee.ietf.org/license-info）约束，以本文档发布之日生效的版本为准。请仔细审阅这些文档，因为它们描述了您就本文档所享有的权利与限制。从本文档中提取的代码组件必须包含《信托法律条款》第 4.e 节所述的简化 BSD 许可证文本，并依简化 BSD 许可证所述"按原样"提供，不附带任何担保。

1. 引言

DMARC [RFC7489] 提供了一种向邮件接收方发布组织策略信息的机制。DMARC 允许针对单个域名、以及针对一个组织内的组织域及其子域，指定策略。

为确定被评估消息的组织域（从而确定去何处查找策略声明），DMARC 借助一份公共后缀列表。其处理过程见 DMARC 规范 [RFC7489] 第 3.2 节。当前最常用的公共后缀列表由 Mozilla 基金会维护，发布于 <https://publicsuffix.org>。

在基本 DMARC 模型中，公共后缀域（PSD）不是组织域，因此不受 DMARC 处理约束。在 DMARC 中，域名分为三类：组织域、组织域的子域，或 PSD。PSD 只能为自己发布 DMARC 策略，而不能为其下任何子域发布。在某些情况下，这一限制使得非存在的组织级域名的滥用成为可能，并妨碍了对邮件中域名滥用的识别。

本文档对 DMARC 规范 [RFC7489] 指定了实验性更新，试图缓解此类滥用。

1.1. 示例

作为一个例子，设想一个顶级域（TLD）".example"，其下有为政府用途与商业用途而设的公共子域（".gov.example" 与 ".com.example"）。此类 PSD 结构的维护者会在列表中为这两个子域各加一条记录，表明它们是 PSD，其下可以注册组织域。进一步假设在 ".gov.example" 内注册了一个名为 "tax.gov.example" 的合法域名。

利用电子邮件通常未经认证的天然特性，常有恶意活动冒充该组织，使用外形相似的（"近亲"）域名，如 "t4x.gov.example"。此类域名并未注册。

在 ".gov.example" 这个公共后缀下，已强制要求使用 DMARC，于是 "gov.example" 发布了如下 DMARC DNS 记录：

_dmarc.gov.example. IN TXT ( "v=DMARC1; p=reject;"
                             "rua=mailto:dmc@dmarc.svc.gov.example" )

这条 DMARC 记录为来自 @gov.example 的邮件提供了策略与报告去向。类似地，"tax.gov.example" 会拥有一条 DMARC 记录，为来自 @tax.gov.example 地址的邮件指定策略。然而，由于 DMARC 当前在组织域层级发现并应用策略的方式，非存在的组织域 @t4x.gov.example 并不、也无法落入某条 DMARC 策略之下。

防御性地注册 "tax" 的所有变体并非可扩展的策略。因此，本规范的目标在于增强 DMARC 发现方法，使接收到此类消息的代理能够确定在 "gov.example" 处存在一个相关策略——而这一点被当前 DMARC 规范所排除。

1.2. 讨论

本文档对 [RFC7489] 提供了一项简单的扩展，使公共后缀域（PSD）的运营者能够：

在 PSD 层级表达策略，覆盖所有未显式发布 DMARC 记录的组织域；
扩展 DMARC 策略查询功能，以检测并处理此类策略；
描述此类策略的接收方反馈；
提供控制机制，以缓解与此扩展相关的潜在隐私考量。

本文档还提供了一个新的 DMARC 标签，用于指示针对非存在子域所请求的处理策略。此标签专门用以支持 PSD DMARC 的分阶段部署，但预计在更一般情形下也有用处。对于声称来自不存在域名的邮件，不期望的拒收风险，显著低于来自存在域名的邮件，因此请求严厉策略处理（例如 reject）的运行风险更低。

作为一项额外收益，PSD DMARC 扩展澄清了既有要求。基于 [RFC7489] 的要求，对于精确域名匹配，DMARC 应当在组织层之上发挥作用（即，如果为 "example" 发布了 DMARC 记录，那么来自 example@example 的邮件应当受 DMARC 处理）。测试表明，这一点在不同实现中并未一致地得到应用。

有两种类型的公共后缀运营者（PSO）适合并有理由使用本扩展：

品牌型 PSD（例如 ".google"）：这些域名实质上如 [RFC7489] 所讨论的组织域。它们掌控该树下的所有子域。它们实质上是私有域名，却被列在当前的公共后缀列表中；出于 DMARC 目的被当作公共域名处理。它们需要与 DMARC 组织域相同的保护，但当前无法从 DMARC 受益。
要求使用 DMARC 的多组织 PSD（例如 ".bank"）：由于使用此 PSD 的既有组织域拥有自己的 DMARC 策略，本扩展适用的对象是那些不存在的域名。该扩展使 DMARC 的品牌保护收益扩展到整个 PSD，包括已注册组织的近亲域名。

由于 DMARC 的设计与互联网邮件架构 [RFC5598] 的特性，DMARC 部署存在互操作性问题。这些问题在《域名级消息鉴别、报告与一致性（DMARC）与间接邮件流之间的互操作性问题》[RFC7960] 中讨论。这些问题通常不适用于 PSD，因为它们（例如上文的 ".gov.example"）通常不发送邮件。

2. 术语与定义

本节定义文档其余部分使用的术语。

2.1. 本文档使用的约定

本文档中的关键词"MUST"（必须）、"MUST NOT"（不得）、"REQUIRED"（需要）、"SHALL"（应）、"SHALL NOT"（不应）、"SHOULD"（应当）、"SHOULD NOT"（不应当）、"RECOMMENDED"（推荐）、"NOT RECOMMENDED"（不推荐）、"MAY"（可以）与"OPTIONAL"（可选），当且仅当它们以此处所示全大写形式出现时，依 BCP 14 [RFC2119] [RFC8174] 解释。

2.2. 公共后缀域（PSD）

全局互联网域名系统（DNS）记载于众多 RFC 中。它定义了一棵以根"."开头的名称树，其下紧邻的是顶级域名，如 ".com" 与 ".us"。域名结构由一棵名称树组成，其中每个名称由一串以句点分隔的"标签"（词）构成。树的根简称为"."。互联网社区整体通过本工作之外的流程与政策，在这棵树上选择一些点，用以注册由独立组织"拥有"的域名。现实例子有 ".com"、".org"、".us" 与 ".gov.uk"。发生此类注册的名称称为"公共后缀域（PSD）"，一次注册由注册者选定的一个标签加上所希望的 PSD 构成。例如 "ietf.org" 是一个已注册域名，而 ".org" 是其 PSD。

2.3. 组织域

"组织域"一词定义于 [RFC7489] 第 3.2 节。

2.4. 最长 PSD

最长 PSD 是去掉一个标签后的组织域，即 DNS 名称树中组织域的紧邻父节点。

2.5. 公共后缀运营者（PSO）

公共后缀运营者是在一个 PSD 内管理运维、特别是该域名及其之下名称所发布 DNS 记录的组织。

2.6. PSO 管控的域名

PSO 管控的域名是 DNS 中由 PSO 管理、不可用作组织域的名称。PSO 管控的域名可能含有一个（例如 ".com"）或多个（例如 ".co.uk"）名称组件，取决于 PSD 政策。

2.7. 非存在的域名

就 DMARC 而言，非存在的域名是指对 A、AAAA 与 MX 记录返回 NXDOMAIN 或 NODATA 响应的域名。此定义比 [RFC8020] 中的更宽泛。

3. 对 DMARC 要求的 PSD DMARC 更新

为参与本实验，实现应当按以下各小节解释 [RFC7489]。

3.1. 一般性更新

对"域名拥有者（Domain Owners）"的引用同样适用于 PSO。

3.2. 第 6.3 节（"通用记录格式"）中的变更

本节新增如下段落，并在 "fo" 之后新增一个标签：

|  np:  针对非存在子域请求的邮件接收方策略（纯文本；可选）。
|     指明接收方应域名拥有者请求执行的策略。它仅适用于被查询
|     域名的非存在子域，而不适用于既存的子域或域名本身。其
|     语法与下文定义的 "p" 标签相同。若 "np" 标签缺省，则对
|     非存在子域必须应用由 "sp" 标签（若 "sp" 标签存在）指定的
|     策略，或由 "p" 标签（若 "sp" 标签缺省）指定的策略。注意：
|     由于 [RFC7489] 第 6.6.3 节描述的 DMARC 策略发现机制的作用，
|     "np" 对于发布在组织域子域与 PSD 上的 DMARC 记录将被忽略。

DMARC 中的下列标签定义被更新：

p：原句"策略适用于被查询的域名及其子域，除非使用 "sp" 标签显式描述了子域策略"修改为"策略适用于被查询的域名及其子域，除非使用 "sp" 或 "np" 标签显式描述了子域策略"。

sp：原句"若缺省，子域必须应用由 "p" 标签指定的策略"修改为"若 "sp" 标签缺省且 "np" 标签缺省或不适用，则子域必须应用由 "p" 标签指定的策略"。

3.3. 第 6.4 节（"形式化定义"）中的变更

DMARC 的 ABNF [RFC5234] 更新为包含一个新的定义 "dmarc-nprequest"：

             dmarc-nprequest =  "np" *WSP "=" *WSP
                 ( "none" / "quarantine" / "reject" )

"dmarc-record" 定义更新为包含如下内容：

dmarc-record    = dmarc-version dmarc-sep
              [dmarc-request]
              [dmarc-sep dmarc-srequest]
              [dmarc-sep dmarc-auri]
              [dmarc-sep dmarc-furi]
              [dmarc-sep dmarc-adkim]
              [dmarc-sep dmarc-aspf]
              [dmarc-sep dmarc-ainterval]
              [dmarc-sep dmarc-fo]
              [dmarc-sep dmarc-rfmt]
              [dmarc-sep dmarc-percent]
              [dmarc-sep]
              [dmarc-sep dmarc-nprequest]
              ; dmarc-version 与 dmarc-request 之外的组件
              ; 可以任意顺序出现

3.4. 第 6.5 节（"域名拥有者动作"）中的变更

除 DMARC 域名拥有者动作外，要求使用 DMARC 并参与 PSD DMARC 的 PSO 应当将该信息提供给接收方。本文档是实现此目的的一项实验性机制；参见附录 B 中的描述。

3.5. 第 6.6.1 节（"提取作者域名"）中的变更

DMARC 的经验表明，某些实现在接收方提取的域名（来自 RFC5322.From 域名）出现在接收方使用的公共后缀列表上时，会短路处理消息，绕过 DMARC 策略应用。这抵消了本规范正在创建的能力。因此，向 DMARC 规范 [RFC7489] 第 6.6.1 节追加如下段落：

|  注意：出现在公共后缀列表上的域名，并不免除 DMARC 策略应用
|  与报告。

3.6. 第 6.6.3 节（"策略发现"）中的变更

在第 3 步与第 4 步之间新增一步：

|  3A. 若集合现已为空，且组织域的最长 PSD（[RFC9091] 第 2.4 节）
|      是接收方已确定为可用于 PSD DMARC 的（基于 [RFC9091] 附录 B
|      所述的某个 DMARC PSD 注册表示例中的数据），则邮件接收方
|      必须查询 DNS，以在组织域的 RFC5322.From 域名所在位置改用
|      最长 PSD 匹配的那个 DNS 域名查询 DMARC TXT 记录（若不同）。
|      返回一个可能为空的结果集合。

例如，对于组织域为 "example.compute.cloudcompany.com.example" 的消息，PSD DMARC 查询将使用 "compute.cloudcompany.com.example" 作为最长 PSD。接收方会检查该 PSD 是否列于 DMARC PSD 注册表，若是，则在 "_dmarc.compute.cloudcompany.com.example" 处执行策略查找。

注：由于 PSD 策略查询位于组织域策略查询之后，PSD 策略不会用于已发布 DMARC 策略的组织域。具体而言，当某个组织域拒绝提供时，这不是一种提供反馈地址（RUA/RUF）的机制。

3.7. 第 7 节（"DMARC 反馈"）中的变更

本节新增如下段落：

|  PSD DMARC 的运行说明：对于 PSO，针对非存在域名的反馈正如对
|  组织级 DMARC 运营者一样，是值得要且有用的。关于 PSD DMARC
|  隐私考量的讨论见 [RFC9091] 第 4 节。

4. 隐私考量

这些隐私考量基于 [RFC6973] 的要求发展而来。此外，[RFC7489] 的隐私考量适用于本文档描述的机制。为参与本实验，实现应当知悉本节描述的隐私考量。若本实验成功，本节应作为"反馈泄漏"并入"隐私考量"一节。

向 PSO 提供反馈报告，在某些情况下会导致信息从某个组织泄漏到 PSO。这种泄漏可能被用作普遍性监视计划的一部分（见 [RFC7624]）。大致有三种情形需要考虑：

单组织 PSD（例如 ".google"）：基于 PSD DMARC 的 RUA 与 RUF 报告可能包含与该组织所管理实体相关邮件的信息。由于 PSO 与组织域拥有者同为一方，无论是常规域名还是非存在域名的报告，都不会因 PSD DMARC 带来额外隐私风险。
要求使用 DMARC 的多组织 PSD（例如 ".bank"）：基于 PSD DMARC 的报告只会针对那些未在组织或主机层级发布 DMARC 策略的域名生成。对于确实发布了所需 DMARC 策略记录的域名，将使用组织（或主机）的反馈报告地址（RUA 与 RUF）。这些 PSD 中反馈泄漏的唯一直接风险，来自那些不符合 PSD 政策的组织域；关于非存在近亲域名的数据会被发往 PSO。
不强制要求使用 DMARC 的多组织 PSD（例如 ".com"）：此类 PSD 中尚未部署 DMARC 的组织域面临的隐私风险是显著的。对于非 DMARC 的组织域，所有 DMARC 反馈都会被导向 PSO。PSD DMARC 是选择退出（opt out，通过在组织域层级发布 DMARC 记录），而不是选择加入（opt in），而后者本应是更理想的特性。这意味着任何非 DMARC 的组织域都会将其反馈报告重定向到 PSO。此类报告的内容，尤其对于既存域名，是隐私敏感的。

PSO 会收到关于非存在域名的反馈，其可能与既存组织域相似。与此类近亲域名相关的反馈，携带与某个真实组织域相关信息的风险较小。为将这一潜在问题最小化，PSD DMARC 反馈必须限于聚合报告（Aggregate Reports）。反馈报告（Feedback Reports）携带更详尽的信息，风险更大。

由于 PSD DMARC 对未参与 DMARC 的多组织 PSD 中的组织域存在固有的隐私与安全风险，任何与多组织 PSD 相关的反馈报告必须限于非存在域名，除非报告者通过查 DMARC PSD 注册表而知 PSO 要求使用 DMARC。

5. 安全考量

本文档不改变 [RFC7489] 与 [RFC7960] 的安全考量。

[RFC7489] 第 12.3 节（"DNS 安全"）所指出问题的风险被 PSD DMARC 放大。特别是，DNS 缓存投毒（或名称链）的后果因一次成功攻击可能有大得多的波及范围而加剧（详见 [RFC3833]）。

[RFC7489] 第 12.5 节（"外部报告地址"）所指出问题的风险被 PSD DMARC 放大。按设计，PSD DMARC 导致将反馈未经请求地报告给组织域之外的实体。这在第 4 节中有更详细的讨论。

6. IANA 考量

IANA 已在"基于域名的消息鉴别、报告与一致性（DMARC）参数"注册表中的"DMARC 标签注册表"新增一个标签。"Status"列定义于 [RFC7489] 第 11.4 节。

新条目如下：

标签名	引用	状态	描述
np	RFC 9091	current	针对非存在子域请求的处理策略

7. 参考性引用

7.1. 规范性引用

[RFC2119] Bradner, S.，《RFCs 中用于指示需求级别的关键词》，BCP 14，RFC 2119，1997 年 3 月。
[RFC5234] Crocker, D., Ed. 与 P. Overell，《语法规范增强型 BNF：ABNF》，STD 68，RFC 5234，2008 年 1 月。
[RFC7489] Kucherawy, M., Ed. 与 E. Zwicky, Ed.，《基于域名的消息鉴别、报告与一致性（DMARC）》，RFC 7489，2015 年 3 月。
[RFC8174] Leiba, B.，《RFC 2119 关键词中大写与小写的歧义》，BCP 14，RFC 8174，2017 年 5 月。

7.2. 资料性引用

[PSD-DMARC]《公共后缀域 DMARC》，<https://psddmarc.org/>。
[RFC3833] Atkins, D. 与 R. Austein，《域名系统（DNS）威胁分析》，RFC 3833，2004 年 8 月。
[RFC5598] Crocker, D.，《互联网邮件架构》，RFC 5598，2009 年 7 月。
[RFC6973] Cooper, A.、Tschofenig, H.、Aboba, B.、Peterson, J.、Morris, J.、Hansen, M. 与 R. Smith，《互联网协议的隐私考量》，RFC 6973，2013 年 7 月。
[RFC7624] Barnes, R.、Schneier, B.、Jennings, C.、Hardie, T.、Trammell, B.、Huitema, C. 与 D. Borkmann，《面对普遍性监视时的机密性：威胁模型与问题陈述》，RFC 7624，2015 年 8 月。
[RFC7960] Martin, F., Ed.、Lear, E., Ed.、Draegen, T., Ed.、Zwicky, E., Ed. 与 K. Andersen, Ed.，《DMARC 与间接邮件流之间的互操作性问题》，RFC 7960，2016 年 9 月。
[RFC8020] Bortzmeyer, S. 与 S. Huque，《NXDOMAIN：其下确实空无一物》，RFC 8020，2016 年 11 月。
[RFC8126] Cotton, M.、Leiba, B. 与 T. Narten，《在 RFC 中撰写 IANA 考量章节的指南》，BCP 26，RFC 8126，2017 年 6 月。

附录 A. PSD DMARC 隐私问题缓解实验

正在进行的实验有三个不同的问题，期望在本文档中得到回答：

第 3.2 节修改策略发现，新增一次 DNS 查询。为确定此查询是否有用，PSD 会就地新增 DMARC 记录并分析 DMARC 报告。若发布 DMARC 记录的 PSD 形成共识、能够收集到有用数据，即为成功。
第 3.2 节为针对非存在子域（DNS NXDOMAIN）新增 "np" 标签。希望测试此点的 PSO 会将该标志加入其 DMARC 记录，并分析 DMARC 报告以评估部署。若各组织发现显式阻断非存在子域是可取的、且这样做能带来附加价值，即为成功。
第 4 节讨论了三种可能因提供反馈而导致信息从组织泄漏的情形。本实验将分析每种情形生成的反馈报告，以确定是否存在信息泄漏。

附录 B. DMARC PSD 注册表示例

为便于围绕数据泄漏缓解开展实验，基于 DNS 的与类 IANA 的注册表示例可在 [PSD-DMARC] 获取。

B.1. DMARC PSD DNS 查询服务

一个独立的样本 DNS 查询服务可在 [PSD-DMARC] 获取。它基于本文档早期草案版本中为一个 IANA 注册表建议的内容开发。该服务的使用方式在 [PSD-DMARC] 中描述。

B.2. DMARC PSD 注册表

[PSD-DMARC] 提供一个类 IANA 的 DMARC 公共后缀域（PSD）注册表，以独立 DNS 查询服务形式提供，其内容如下文描述。其中有一份所列 PSD 的逗号分隔值（CSV）版本，适用于 PSD DMARC 能力软件的构建更新。

正在部署 DMARC 并参与 PSD DMARC 的 PSD，必须在本新注册表中注册其公共后缀域。该要求须以符合 [RFC8126] 专家评审（Expert Review）条款的方式记录。指定专家需确认所提供文档充分描述了 PSD 政策，要求域名拥有者使用 DMARC，或确认所有域名拥有者都与 PSO 同属一个组织。

权威注册表位于：<https://psddmarc.org>

B.3. DMARC PSD PSL 扩展

[PSD-DMARC] 提供一个格式如同公共后缀列表（PSL）的文件，以便于识别 PSD DMARC 参与者。其内容在功能上与类 IANA 注册表相同，只是呈现格式不同。

使用此法时，扩展查询的输入域名应为常规 PSL 查询的输出域名，即组织域。这一替代数据法可能有益，因为 DMARC 实现本就需要能够解析该数据格式，因此应更易实现。

附录 C. 实现

已知有两个可用于测试的 PSD DMARC 实现。

C.1. Authheaders 模块

authheaders Python 模块与命令行工具可从 Python 包索引（Pypi）下载或安装。

它同时支持使用基于 DNS 的查询服务，以及从 [PSD-DMARC] 下载 CSV 注册表文件。

C.2. Zdkimfilter 模块

zdkimfilter 模块是 Courier-MTA 的一个独立附加组件。

它主要用于域名密钥识别邮件（DKIM）签名，也可配置为执行验证、应用 DMARC 策略并发送聚合报告。对于 PSD DMARC，它使用 PSL 扩展列表法，可从 [PSD-DMARC] 获取。

致谢

感谢以下人士为改进本文档所做的贡献（公开与私下皆有）：Kurt Andersen、Seth Blank、Dave Crocker、Heather Diaz、Tim Draegen、Zeke Hendrickson、Andrew Kennedy、John Levine、Dr. Ian Levy、Craig Schwartz、Alessandro Vesely 与 Tim Wicinski。

特别提及 Dave Crocker 想出了这个名称。

作者地址

Scott Kitterman，fTLD Registry Services，Suite 400，600 13th Street, NW，Washington, DC 20005，United States of America。电话：+1 301 325-5475；邮箱：scott@kitterman.com

Tim Wicinski（编辑），Elkins, WV 26241，United States of America。邮箱：tjw.ietf@gmail.com

来源（Source）

本页译自 IETF 人类原始文本，英文原文与权威版本：

RFC 原文（IETF Datatracker）：https://datatracker.ietf.org/doc/html/rfc9091
RFC 原文（RFC Editor）：https://www.rfc-editor.org/rfc/rfc9091
文档状态与勘误：https://www.rfc-editor.org/info/rfc9091

如中文表述与英文原文存在歧义，一律以 ietf.org / rfc-editor.org 英文原文为准。