RFC 5617《DKIM 作者域签名规范（ADSP）》中文导读

IETF · RFC 5617 · 发布时为标准跟踪（Proposed Standard）· 现状：Historic（历史）· 2009 年 8 月

诚实披露：本页为 IETF RFC 的人类翻译版本，依 IETF Trust 条款可自由再制与翻译；译本由 AI 基于人类权威文献辅助整理生成，非人类原创，仅供学习参考。

本页按 RFC 5617《DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)》 原文章节顺序梳理规范要点，并非逐字全文翻译；任何规范性判断均以英文原文为准。原文由 IETF 发布并适用 BCP 78 与 IETF Trust 法律条款，英文原文见 rfc-editor.org/rfc/rfc5617.txt。

状态提示：RFC 编辑器对本文档记录的当前状态为 Historic（历史），发布时的状态为 Proposed Standard。阅读时请把它当作理解域级策略声明演进脉络的历史文献，而非当前部署依据。

摘要

RFC 5617 定义 ADSP（Author Domain Signing Practices，作者域签名规范）。原文摘要说明：DKIM 为邮件定义了域级认证框架，用于验证邮件来源与内容；本文档规定一种辅助机制，帮助评估那些未带有作者地址所用域的 DKIM 签名的邮件；它定义了一条记录，可以对外声明某个域是否对其出站邮件签名，以及其他主机如何访问该记录。

1. 问题背景（原文第 1 节）

原文第 1 节的推理链条是：DKIM 让签名域可以对“把邮件引入邮件流”这件事声明责任，收件方通过查询签名域取得公钥来验签。但互联网的历史遗留决定了并非所有邮件都会被签名，缺少签名本身并不能先验地判定为伪造；在部署早期，多数邮件很可能仍未签名。

然而某些域可能决定对其全部出站邮件签名（原文举的动机是保护其品牌名称），这类域会希望能把这一事实向其他主机公告——这正是 ADSP 要解决的问题。原文把实现本规范的主机所发起的这种询问称为一次“作者域签名规范检查”。

2. 关键术语（原文第 2 节）

3. 运作概览与四种结果（原文第 3 节）

第 3 节说明：域所有者通过 DNS 之类的查询机制发布 ADSP 信息，主机可对作者地址所属的域执行查询。若一封邮件有多个作者地址，应当（SHOULD）对每个地址独立执行 ADSP 查询；如何合并多个查询结果，本文档不作规定。

适用范围（第 3.1 节）：ADSP 绑定 DNS，因此只适用于具备相应 DNS 记录（A、AAAA 和／或 MX，表明该域可能用于邮件）的作者域。原文特别提醒：攻击者可能刻意使用范围之外的域名来绕开某组织的 ADSP 策略声明，检查器实现应对超出 ADSP 范围的作者域返回恰当的错误结果。

第 3.1 节还明确一条容易被误解的边界：ADSP 适用于具体的域，而不是域的子树。例如作者地址为 user@domain.example 时，作者域是 domain.example，适用的 ADSP 记录位于 _adsp._domainkey.domain.example；而子域地址 user@sub.domain.example 对应的是位于 _adsp._domainkey.sub.domain.example 的另一条记录。ADSP 不在父域与子域之间建立任何关联。

可获得的信息（第 3.2 节）：邮件无任何有效签名时，ADSP 结果与该邮件直接相关；邮件已带作者域签名时，ADSP 对该域不再提供额外收益（因为该邮件必然满足该域可能声明的任何 ADSP）；邮件带有作者域签名以外的有效签名时，收件方可同时利用签名与 ADSP 结果做评估。

四种结果（第 3.3 节）：对某个作者地址的 ADSP 查询产生以下四者之一——该域邮件可能带也可能不带作者域签名（域存在于 DNS 但未找到 ADSP 记录时的默认值）；该域所有邮件均带作者域签名；该域所有邮件均带作者域签名且可丢弃；该域超出适用范围（域在 DNS 中不存在）。此外，若 DNS 查询发生临时故障，ADSP 查询可能在不产生任何结果的情况下终止。

4. DNS 记录与语法（原文第 4.1–4.2 节）

第 4.1 节规定 ADSP 记录使用 DNS TXT 资源记录类型发布，RDATA 为文本格式，采用 DKIM 规范中的“标签=值列表”（Tag=Value List）语法，但改用空白（WSP）而非折叠空白（FWS）。不符合该语法或不符合各标签语法的记录，就 ADSP 而言必须（MUST）被忽略（等同于 NODATA 结果），但可以通过日志机制记录告警。若 RDATA 含多个字符串，各字符串在逻辑上直接拼接、其间无分隔符。

第 4.1 节还明确：域必须不（MUST NOT）发布带通配符名字的 ADSP 记录。

第 4.2.1 节规定记录语法：每条 ADSP 记录必须以出站签名实践标签开头，即记录的前四个字符为小写 “dkim”，随后是可选空白与 “=”。无法识别的标签必须被忽略。dkim= 为必填的纯文本标签，取值含义如下：

原文补充：其他任何取值都按 unknown 处理。对应的 ABNF 规则为：

adsp-dkim-tag = %x64.6b.69.6d *WSP "=" *WSP
                ("unknown" / "all" / "discardable" /
                 x-adsp-dkim-tag)

5. 查询流程（原文第 4.3 节）

第 4.3 节要求主机产生的结果在语义上必须等价于按顺序执行下列步骤；实践中可并行执行以提升性能，但实现应当（SHOULD）避免不必要的 DNS 查询。该节把“有效 ADSP 记录”定义为语法与语义都正确、既匹配 tag-list 的 ABNF 又以有效 dkim 标签开头的记录。

第一步：判定域范围。检查器必须判断给定作者域是否在 ADSP 适用范围内，并对范围之外的作者域返回恰当错误。主机必须对作者域（不加前缀）执行一次 DNS 查询——查询类型不限，因为该步骤只用于确定域本身是否存在于 DNS。若结果表明作者域不存在于 DNS（即 NXDOMAIN，rcode=3），算法必须终止并给出“域超出范围”的错误。原文特别提醒：rcode=0 但无记录（NODATA）与 NXDOMAIN 不是一回事。原文的非规范性讨论指出，MX 是该用途的合理选择，因为它被认为是邮件用域最常见的记录类型，其结果比否定结果更易缓存。

若域确实存在，检查器可以（MAY）做更充分的核验（如 RFC 5321 第 5 节所述）；若这些检查表明该作者域并不为邮件而存在（例如既无 MX 也无 A、AAAA 记录），检查器应当（SHOULD）终止并给出“超出范围”的错误。

第二步：取回具名 ADSP 记录。主机必须查询作者域加 _adsp._domainkey. 前缀（注意末尾的点）对应的 TXT 记录。若结果为 NOERROR（rcode=0）且答案是单条有效 ADSP 记录，则采用该记录，算法终止。若结果为 NXDOMAIN 或 NOERROR 且零条记录，则不存在 ADSP 记录。若查询返回多于一条记录，或返回一条并非有效 ADSP 记录的记录，则 ADSP 结果未定义。若查询返回 SERVFAIL（rcode=2），算法终止且不返回结果；可能的处置包括将邮件入队或返回表示临时失败的 SMTP 错误。

6. Authentication-Results 结果码（原文第 5.4 节）

第 5.4 节为认证方法 dkim-adsp 登记了一组结果码，各自含义如下：

7. 安全考量（原文第 6 节）

第 6 节开宗明义：ADSP 的安全考量主要与恶意发件人试图把自己伪装成无权代其发信的作者有关，其目的通常是欺诈收件人或被冒名的作者。

威胁模型（第 6.1 节）：原文指出邮件滥用常利用合法作者在收件人中的名称认知度，在 From: 头字段中使用该作者的域名；并且由于许多邮件客户端（MUA）并不显示作者的邮件地址，对于这种未授权使用域名的行为在多大程度上造成收件人受骗、以及消除它是否会产生显著效果，并无实证证据。第 6.1 节同时说明，堵住这一潜在利用点可能便于收件侧过滤引擎做某些优化处理，因为它可以在域名的 From: 用法确属授权时维持更高置信度的判断。

第 6.1 节还有两条重要限制：其一，ADSP 不产生任何收益、实际上也不产生任何效果，除非有外部系统对其判定采取行动——或在投递过程中区别对待该邮件，或向最终收件人展示某种指示；这类系统超出本规范范围。其二，ADSP 检查器可能对每个被声称的作者域执行多次 DNS 查询，而这些查询由可能属于欺诈邮件的头字段中的域名驱动，因此合法的 ADSP 检查器可能沦为针对欺诈邮件中所出现域名的流量放大攻击的参与者。

DNS 考量（第 6.2 节）：攻击者可能攻击 DNS 基础设施以伪造 ADSP 记录来影响收件方决策，但这类攻击者更可能在更高层面下手（例如劫持 A 或 MX 记录查询以截获本应发往目标域的流量）；这些 DNS 安全问题由 DNSSEC 应对。该节并强调，由于 ADSP 运行在既有邮件体系框架内，无 ADSP 记录时的默认结论是“该域并非对其所有邮件签名”，因此 ADSP 客户端把 SERVFAIL 之类的 DNS 故障与其他 DNS 错误区分开来十分重要。

DNS 通配符（第 6.3 节）：位于被检查域同级或其上层的 DNS 通配符会干扰第 4.3 节中的范围判定。例如 *.domain.example 的通配符记录会让 foo.domain.example 之类的所有子域都“存在”。原文因此建议：打算积极使用 ADSP（发布 unknown 以外实践）的域应避免在其层级中使用通配符；并规定使用 unknown 以外实践的域应当不（SHOULD NOT）发布通配符记录。原文解释了根因：_adsp._domainkey. 前缀既不允许发布只覆盖 ADSP 记录而不覆盖非 ADSP 记录的通配符，也不允许发布只覆盖非 ADSP 记录而不覆盖 ADSP 记录的通配符。

作者域签名的不当施加（第 6.4 节）：在一种 DKIM 用法中，域会对流经其系统的邮件签名。由于任何域名与作者域相同的签名按定义就是作者域签名，因此若邮件的作者域恰为签名者自身的域、而该邮件又未知是否满足该域对作者域签名的标准，对其签名是不明智的。原文举出的一个用例是：域在施加 Authentication-Results 头字段之后又施加此类签名。规避办法也由原文给出——要么不施加可能被误认为作者域签名的签名，要么改用其他域（例如作者域的子域）的签名。

8. 术语英文对照

参考链接

参考：https://www.rfc-editor.org/rfc/rfc5617.txt