3. Terminology and Definitions (术语和定义)
本节定义了文档其余部分中使用的术语。
本文档中的关键词"必须 (MUST)"、"不得 (MUST NOT)"、"要求 (REQUIRED)"、"应当 (SHALL)"、"不应 (SHALL NOT)"、"应该 (SHOULD)"、"不应该 (SHOULD NOT)"、"推荐 (RECOMMENDED)"、"可以 (MAY)" 和"可选 (OPTIONAL)" 应按 [KEYWORDS] 中所述进行解释。
鼓励读者熟悉 [EMAIL-ARCH] 的内容。特别是，该文档定义了消息传递基础设施中的各种角色，这些角色在各种上下文中可能显示为相同或分离。例如，域所有者可以通过 DMARC 所基于的消息传递安全机制，将作为域所有者发送邮件的能力委托给具有另一个角色的第三方。本文档不涉及此类角色之间的区别; 鼓励读者在继续之前熟悉该材料。
还使用以下术语:
Authenticated Identifiers (认证标识符): 使用认证技术验证的域级别标识符称为"认证标识符"。有关支持的机制的详细信息，请参见第 4.1 节。
Author Domain (作者域): 从 RFC5322.From 字段中提取的表面作者的域名。
Domain Owner (域所有者): 拥有 DNS 域的实体或组织。这里的术语"拥有"表示被引用的实体或组织持有该 DNS 域的注册。域所有者的范围从复杂的、全球分布的组织，到代表非技术客户工作的服务提供商，再到负责维护个人域的个人。本规范使用此术语类似于 [EMAIL-ARCH] 中定义的管理管理域 (Administrative Management Domain)。它还可以指委托方，例如报告接收方，当这些委托方在其直接管理域之外时。
Identifier Alignment (标识符对齐): 当 RFC5322.From 地址中的域与 SPF 或 DKIM (或两者) 验证的域匹配时，它具有标识符对齐。
Mail Receiver (邮件接收方): 接收和处理电子邮件的实体或组织。邮件接收方运营一个或多个面向互联网的邮件传输代理 (MTAs)。
Organizational Domain (组织域): 向域名注册商注册的域。在缺乏更准确方法的情况下，使用启发式方法来确定这一点，因为注册的域名并不总是简单地是顶级 DNS 域加上一个组件 (例如，"example.com"，其中"com"是顶级域)。组织域通过应用第 3.2 节中的算法来确定。
Report Receiver (报告接收方): 从实施本文档中描述的报告机制的另一个运营商接收报告的运营商。这样的运营商可能正在接收关于其自己的消息的报告，或关于与另一个运营商相关的消息的报告。此术语统称适用于接收和处理这些报告的系统组件以及运营它们的组织。
3.1. Identifier Alignment (标识符对齐)
电子邮件认证技术认证单个消息的各种 (且不同的) 方面。例如，[DKIM] 认证为消息附加签名的域，而 [SPF] 可以认证出现在 [SMTP] 的 RFC5321.MailFrom (MAIL FROM) 部分中的域，或 RFC5321.EHLO/HELO 域，或两者。这些可能是不同的域，并且它们通常对最终用户不可见。
DMARC 通过要求 RFC5322.From 域与认证标识符匹配 (对齐) 来认证 RFC5322.From 域的使用。选择 RFC5322.From 域作为 DMARC 机制的中心标识，因为它是必需的消息头字段，因此保证存在于符合要求的消息中，并且大多数邮件用户代理 (MUAs) 将 RFC5322.From 字段表示为消息的发起者，并向最终用户呈现此头字段内容的部分或全部。
因此，此字段是最终用户用来识别消息来源的字段，因此是滥用的主要目标。许多高知名度的电子邮件来源，例如电子邮件服务提供商，要求发送代理在生成电子邮件之前必须经过认证。因此，对于这些邮箱，本文档中描述的机制为接收方最终用户提供了强有力的证据，证明消息确实是由他们与该邮箱关联的代理发起的，如果最终用户知道已提供这些各种保护。
在此上下文中的域名应按照 [DNS-CASE] 以不区分大小写的方式进行比较。
重要的是要注意，对于根据 [MAIL] 无效的消息，特别是具有格式错误、缺失或重复的 RFC5322.From 字段的消息，标识符对齐不能发生，因为在这种情况下没有可靠的方法来确定适用于消息的 DMARC 策略。因此，DMARC 操作的前提是输入是有效的 RFC5322 消息对象，并且处理此类不符合要求的情况超出了本规范的范围。关于这一点的进一步讨论可以在第 6.6.1 节中找到。
DMARC 作为输入的每个底层认证技术在成功时都会产生认证域作为其输出。从 DMARC 的角度来看，每个都可以在"严格 (strict)" 模式或"宽松 (relaxed)" 模式下操作。如果域所有者希望邮件接收方仅将 DMARC 处理应用于具有与这些机制将验证的域完全匹配的 RFC5322.From 域的消息，则通常会选择严格模式。当运营商还希望影响具有已验证域的子域的消息流时，可以使用宽松模式。
3.1.1. DKIM-Authenticated Identifiers (DKIM 认证标识符)
DMARC 允许基于 DKIM 认证结果的标识符对齐为严格或宽松。(请注意，这些与 DKIM 的"简单 (simple)" 和"宽松 (relaxed)" 规范化模式无关。)
在宽松模式下，[DKIM] 认证的签名域 (从签名中"d="标签的值获取) 和 RFC5322.From 域的组织域都必须相等，标识符才被视为对齐。在严格模式下，只有两个完全限定域名 (FQDNs) 之间的完全匹配才被认为产生标识符对齐。
为了说明，在宽松模式下，如果经过验证的 DKIM 签名成功验证了"d="域为"example.com"，并且 RFC5322.From 地址为"[email protected]"，则 DKIM "d="域和 RFC5322.From 域被认为是"对齐的"。在严格模式下，此测试将失败，因为"d="域与地址的 FQDN 不完全匹配。
但是，带有"d=com"值的 DKIM 签名永远不会允许"对齐"结果，因为"com"应该出现在所有公共后缀列表中 (参见附录 A.6.1)，因此不能是组织域。
需要标识符对齐是因为消息可以带有来自任何域的有效签名，包括邮件列表使用的域甚至恶意行为者的域。因此，仅仅带有有效签名不足以推断作者域的真实性。
请注意，单个电子邮件可以包含多个 DKIM 签名，如果任何 DKIM 签名对齐并验证，则被认为是 DMARC "通过 (pass)"。
3.1.2. SPF-Authenticated Identifiers (SPF 认证标识符)
DMARC 允许基于 SPF 认证结果的标识符对齐为严格或宽松。
在宽松模式下，[SPF] 认证的域和 RFC5322.From 域必须具有相同的组织域。在严格模式下，只有完全的 DNS 域匹配才被认为产生标识符对齐。
请注意，RFC5321.HELO 标识通常不在 DMARC 的上下文中使用 (除非需要"伪造"否则为空的反向路径)，即使根据 [SPF] 的"纯 SPF" 实现会检查该标识符。
例如，如果消息通过 SPF 检查，RFC5321.MailFrom 域为"cbg.bounces.example.com"，并且 RFC5322.From 字段的地址部分包含"[email protected]"，则认证的 RFC5321.MailFrom 域标识符和 RFC5322.From 域在宽松模式下被认为是"对齐的"，但在严格模式下则不是。
3.1.3. Alignment and Extension Technologies (对齐和扩展技术)
如果将来 DMARC 扩展为包括使用其他认证机制，则扩展将需要允许提取域标识符，以便可以验证与 RFC5322.From 域的对齐。
3.2. Organizational Domain (组织域)
使用以下算法确定组织域:
-
获取"公共后缀"列表，即为注册保留的 DNS 域名列表。一些国家顶级域 (TLDs) 制定了特定的注册要求，例如，英国将公司注册放在".co.uk"下; 其他 TLD (如".com") 出现在 IANA 顶级 DNS 域注册表中。公共后缀列表是所有这些的并集。附录 A.6.1 包含有关获取公共后缀列表的一些讨论。
-
将主题 DNS 域名分解为"n"个有序标签的集合。从右到左对这些标签进行编号; 例如，对于"example.com"，"com"将是标签 1，"example"将是标签 2。
-
在公共后缀列表中搜索与主题 DNS 域中找到的最大标签数匹配的名称。将该数字设为"x"。
-
使用从公共后缀列表中匹配的名称构造一个新的 DNS 域名，并在其前面加上主题域的"x+1"标签。这个新名称就是组织域。
因此，由于"com"是 IANA 注册的 TLD，主题域"a.b.c.d.example.com"将具有组织域"example.com"。
确定后缀的过程目前是启发式的。不能保证任何列表都是准确或最新的。