跳到主要内容

3. 术语和定义

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

本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" 和 "OPTIONAL" 应按 [KEYWORDS] 中的说明解释.

建议读者熟悉 [EMAIL-ARCH] 的内容. 特别是, 该文档定义了消息基础设施中的各种角色, 这些角色在不同上下文中可能表现为相同实体或不同实体. 例如, Domain Owner 可以通过 DMARC 所基于的消息安全机制, 将以 Domain Owner 身份发送邮件的能力委托给承担另一角色的第三方. 本文档不讨论这些角色之间的区别; 建议读者在继续阅读前熟悉该材料.

本文档还使用以下术语:

Authenticated Identifiers: 使用认证技术验证的域级标识符称为 "Authenticated Identifiers". 有关支持机制的详细信息, 见 Section 4.1.

Author Domain: 从 RFC5322.From 字段提取的表观作者的域名.

Domain Owner: 拥有某个 DNS 域的实体或组织. 此处的 "owns" 表示所指实体或组织持有该 DNS 域的注册. Domain Owner 的范围可以从复杂的全球分布式组织, 到代表非技术客户工作的服务提供商, 再到负责维护个人域的个人. 本规范使用该术语, 其含义类似于 [EMAIL-ARCH] 中定义的 Administrative Management Domain. 当 Report Receiver 等委托方位于其直接管理域之外时, 该术语也可以指这些委托方.

Identifier Alignment: 当 RFC5322.From 地址中的域与 SPF 或 DKIM (或二者) 验证的域匹配时, 即具有 Identifier Alignment.

Mail Receiver: 接收并处理电子邮件的实体或组织. Mail Receiver 运行一个或多个面向 Internet 的 Mail Transport Agent (MTA).

Organizational Domain: 在域名注册商处注册的域. 在缺少更准确方法的情况下, 使用启发式方法来确定它, 因为注册域名并不总是简单地等于一个顶级 DNS 域加一个组成部分 (例如 "example.com", 其中 "com" 是顶级域). Organizational Domain 通过应用 Section 3.2 中的算法来确定.

Report Receiver: 从另一个实现本文档所述报告机制的运营者接收报告的运营者. 此类运营者可能接收关于其自身消息的报告, 也可能接收关于另一个运营者相关消息的报告. 该术语整体适用于接收并处理这些报告的系统组件, 以及运行这些组件的组织.

3.1. Identifier Alignment​

电子邮件认证技术会认证单个消息的不同 (且彼此差异较大的) 方面. 例如, [DKIM] 认证为消息附加签名的域, 而 [SPF] 可以认证 [SMTP] 中 RFC5321.MailFrom (MAIL FROM) 部分出现的域, 或 RFC5321.EHLO/HELO 域, 或二者. 这些可能是不同的域, 并且通常对最终用户不可见.

DMARC 通过要求 RFC5322.From 域与某个 Authenticated Identifier 匹配 (即 alignment), 来认证 RFC5322.From 域的使用. RFC5322.From 域被选为 DMARC 机制的中心身份, 是因为它是必需的消息头字段, 因此保证会出现在合规消息中, 并且大多数 Mail User Agent (MUA) 会把 RFC5322.From 字段表示为消息的发起者, 并向最终用户呈现该头字段的部分或全部内容.

因此, 该字段是最终用户用于识别消息来源的字段, 也因此成为滥用的主要目标. 许多高知名度的电子邮件来源, 例如电子邮件服务提供商, 要求发送代理在生成电子邮件之前完成认证. 因此, 对于这些邮箱, 如果最终用户知道已经提供了这些保护, 本文档描述的机制会向收件最终用户提供强有力的证据, 表明该消息确实由其与该邮箱关联的代理发起.

在此上下文中, 域名应按 [DNS-CASE] 以大小写不敏感方式比较.

需要注意, 对不符合 [MAIL] 的消息无法发生 Identifier Alignment, 特别是 RFC5322.From 字段格式错误, 缺失或重复的消息, 因为在这种情况下无法可靠地确定适用于该消息的 DMARC policy. 因此, DMARC 操作以输入是有效 RFC5322 消息对象为前提, 对此类不合规情况的处理超出本规范范围. Section 6.6.1 中对此有进一步讨论.

DMARC 作为输入的每一种底层认证技术在成功时都会输出已认证域. 从 DMARC 的角度看, 每一种都可以在 "strict" 模式或 "relaxed" 模式下运行. 如果 Domain Owner 希望 Mail Receiver 仅对带有 RFC5322.From 域且该域与这些机制将验证的域完全匹配的消息应用 DMARC 处理, 通常会选择 strict 模式. 当运营者还希望影响带有已验证域的子域的消息流时, 可以使用 relaxed 模式.

3.1.1. DKIM-Authenticated Identifiers​

DMARC 允许基于 DKIM 认证结果的 Identifier Alignment 为 strict 或 relaxed. (注意, 这些与 DKIM 的 "simple" 和 "relaxed" 规范化模式无关.)

在 relaxed 模式下, 如果要认为标识符对齐, 则 [DKIM] 认证的签名域 (取自签名中 "d=" 标签的值) 的 Organizational Domain 与 RFC5322.From 域的 Organizational Domain 必须相等. 在 strict 模式下, 只有两个 Fully Qualified Domain Name (FQDN) 完全匹配时, 才被认为产生 Identifier Alignment.

举例来说, 在 relaxed 模式下, 如果一个已验证的 DKIM 签名使用 "example.com" 作为 "d=" 域成功验证, 且 RFC5322.From 地址是 "[email protected]", 则认为 DKIM "d=" 域和 RFC5322.From 域 "in alignment". 在 strict 模式下, 此测试会失败, 因为 "d=" 域与该地址的 FQDN 并不完全匹配.

然而, 带有 "d=com" 值的 DKIM 签名永远不会允许产生 "in alignment" 结果, 因为 "com" 应出现在所有公共后缀列表中 (见 Appendix A.6.1), 因而不能成为 Organizational Domain.

之所以需要 Identifier Alignment, 是因为消息可以带有来自任意域的有效签名, 包括邮件列表使用的域, 甚至恶意行为者使用的域. 因此, 仅仅带有有效签名不足以推断 Author Domain 的真实性.

注意, 一封电子邮件可以包含多个 DKIM 签名, 如果任一 DKIM 签名对齐并验证通过, 就认为它是 DMARC "pass".

3.1.2. SPF-Authenticated Identifiers​

DMARC 允许基于 SPF 认证结果的 Identifier Alignment 为 strict 或 relaxed.

在 relaxed 模式下, [SPF] 认证的域和 RFC5322.From 域必须具有相同的 Organizational Domain. 在 strict 模式下, 只有 DNS 域完全匹配才被认为产生 Identifier Alignment.

注意, RFC5321.HELO 身份通常不在 DMARC 上下文中使用 (除非需要 "fake" 一个本来为空的 reverse-path), 即使按照 [SPF] 的 "pure SPF" 实现会检查该标识符.

例如, 如果某消息使用 RFC5321.MailFrom 域 "cbg.bounces.example.com" 通过 SPF 检查, 且 RFC5322.From 字段的地址部分包含 "[email protected]", 则在 relaxed 模式下, 认为已认证的 RFC5321.MailFrom 域标识符和 RFC5322.From 域 "in alignment", 但在 strict 模式下并非如此.

3.1.3. Alignment 和扩展技术​

如果未来 DMARC 扩展为包含其他认证机制的使用, 这些扩展将需要允许提取域标识符, 以便验证其与 RFC5322.From 域的 alignment.

3.2. Organizational Domain​

Organizational Domain 使用以下算法确定:

  1. 获取 "public suffix" 列表, 即为注册保留的 DNS 域名列表. 一些国家顶级域 (Top-Level Domain, TLD) 制定了特定注册要求, 例如英国将公司注册置于 ".co.uk" 下; 其他 TLD 如 ".com" 出现在 IANA 顶级 DNS 域注册表中. 公共后缀列表是所有这些内容的并集. Appendix A.6.1 包含关于获取公共后缀列表的一些讨论.

  2. 将主题 DNS 域名拆分为一组 "n" 个有序标签. 从右向左为这些标签编号; 例如, 对于 "example.com", "com" 是标签 1, "example" 是标签 2.

  3. 在公共后缀列表中搜索与主题 DNS 域中最多标签匹配的名称. 设该数量为 "x".

  4. 使用公共后缀列表中匹配到的名称, 并在其前面加上主题域中的第 "x+1" 个标签, 构造一个新的 DNS 域名. 这个新名称就是 Organizational Domain.

因此, 由于 "com" 是 IANA 注册的 TLD, 主题域 "a.b.c.d.example.com" 的 Organizational Domain 将是 "example.com".

确定后缀的过程目前是一种启发式过程. 没有任何列表能保证准确或当前有效.

最后于 更新