RFC 6377《DKIM 与邮件列表》中文译本

IETF · RFC 6377 · 最佳当前实践（Best Current Practice，BCP 167）· 2011 年 9 月

摘要

域名密钥识别邮件（DomainKeys Identified Mail，DKIM）允许一个管理管理域（ADministrative Management Domain，ADMD）为某条消息承担一定的责任。基于 DKIM 的部署经验，本文档为在包含邮件列表管理器（Mailing List Manager，MLM）的场景中使用 DKIM 提供指引。

1. 引言

域名密钥识别邮件 [DKIM] 允许一个管理管理域（ADMD）为一条 [MAIL] 消息承担某种责任。承担该责任的可以是作者（Author）所属的机构、一个运营中的中继（邮件传输代理，即 MTA），或者它们的某个代理方。责任的声明是通过一个密码学签名来做出的。消息从作者到收件人的传输过程要经过若干中继，这些中继通常不会对消息内容作实质性改动，因而能够保持 DKIM 签名的有效性。

与中继不同，还存在一类中间方（intermediary），例如邮件列表管理器（MLM），它们会主动接收（take delivery of）消息、重新格式化，然后再重新投递（repost），这一过程往往会使 DKIM 签名失效。本文档的目标是探讨在包含中间方的场景中如何使用 DKIM，并基于已积累的经验推荐最佳当前实践。将要讨论的问题包括：

• 在什么情况下，作者或其所在机构对发往邮件列表的邮件施加 DKIM 签名是可取的？
• 让 MLM 验证并使用 DKIM 标识符，在权衡上有哪些利弊？
• 让 MLM 在重新投递消息之前移除已有的 DKIM 签名，在权衡上有哪些利弊？
• 让 MLM 添加自己的 DKIM 签名，在权衡上有哪些利弊？

这些都是开放性问题，可能并不存在确定的答案。然而，基于 [DKIM] 原始版本发布以来的经验及其逐步部署的过程，仍有一些值得参考的观点和一些推荐的做法。

总体而言，就 DKIM 而言 MLM 可分为两类：参与型（participating）与非参与型（non-participating）。由于每一类在处理或产生 DKIM 已签名消息（或二者兼有）时都有各自的问题，本文档将它们分别置于不同章节讨论。

应对 MLM 最好的通用建议是：由 MLM 本身、或由 MLM 所在域中的某个 MTA，对其转发的每一条消息施加自己的 DKIM 签名；同时，接收端的评估方（assessor）在作出评估时应把 MLM 的域签名纳入考虑。（参见第 5 节，特别是第 5.2 节。）

考虑到这一做法并非总是可行或切合实际，也考虑到它可能并不总是充分的，本文档提供了更多的指引。

1.1. 背景

DKIM 签名允许电子邮件体系结构（参见 [EMAIL-ARCH]）中的某个代理方，在消息经过某个中继时，为其附加一个经过验证的域级标识符，从而对该消息作出责任声明。虽然这不是唯一的可能，但最常见的做法是：在消息经由边界邮件传输代理（MTA）离开一个管理管理域（ADMD）、进入开放 Internet 时施加签名。

如果消息中被某个哈希所覆盖的部分发生了改动，DKIM 签名的验证就会失败。而 MLM 通常会修改消息，以提供其所服务的那个邮件列表所特有的信息。常见的修改类型在第 3.3 节中枚举与描述。但要注意，各 MLM 的行为差异很大，而且往往允许订阅者自行选择某些行为。此外，MTA 也可能作出独立于 MLM 之外的改动。

DKIM 签名规范 [DKIM] 有意排斥了这样一种观念：把签名域（DKIM 签名中的 "d=" 标签）与消息中的任何其他标识符绑定起来；任何处理该消息的 ADMD 都可以对它签名，无论消息的来源或作者域为何。特别地，DKIM 并未为「"d=" 标签的内容与某个值（例如 RFC5322.From 字段中的域名）相匹配」这一情形定义任何含义；反过来，当二者不匹配时，签名也不会因此就有什么明显的价值折损。既然任何 DKIM 签名都仅仅是某个 ADMD 对「某种」责任的声明，那么由 MLM 添加的 DKIM 签名，其含义并不比带有任何其他 "d=" 值的签名更多或更少。

1.2. 基础设施中的 MLM

MLM 是一个自治的代理方，它接收一条消息，并可以将其作为一条新消息重新投递，或者把它与其他消息聚合成摘要（digest）发送给列表成员（参见 [EMAIL-ARCH] 第 5.3 节）。然而，这类消息（在非摘要的情形下）的 RFC5322.From 字段通常与原始消息相同，且收件人会认为该消息「来自」原作者而非 MLM，这就在「重新投递的消息由谁负责、其自治性如何」上造成了混淆。这对 DKIM 的使用具有重要影响。

第 3.3 节描述了 MLM 通常会做、并会导致签名被破坏的一些操作，这些操作降低了 DKIM 的感知价值。

此外，尽管存在若干专门针对 MLM 行为的已发布标准（例如 [MAIL]、[LIST-ID] 与 [LIST-URLS]），它们的采纳程度充其量只能说是参差不齐。因此，规定在 MLM 场景下如何使用 DKIM 的努力必须是渐进式的，并且以实际价值为导向。

某些 MLM 行为已经根深蒂固，可以认为它们对 DKIM 签名有效性的影响阻碍了 DKIM 的更广泛采用。尽管如此，这些行为并不违反标准。因此，本备忘录为所有相关方规定了实践做法，并把对 MLM 自身所要求的改动定义为尽可能小的最小集合。

消息上的 DKIM 签名表达了签名域对该消息承担的某种责任。本文档所要处理的一个开放问题是：在消息经过邮件列表、并且可能已被、也可能未被破坏其有效性之后，收件方的评估模块可以以何种方式使用该签名。本文档还考察了签名有效性可能是如何被破坏的。

请注意，本文档中凡讨论到 MLM 执行 DKIM 签名验证或作者域签名实践（[ADSP]）策略验证之处，实际实现中该验证工作可能是由 MTA 或附属于 MTA 的某个代理完成的，其结果再通过某个此处未加规定的可信通道传递。关于这一点的讨论参见 [AUTH-RESULTS]。本文档并不偏好这些代理的某种特定组织方式；出于叙述简洁的考虑，文中只是笼统地说「由 MLM 本身完成这项工作」。

1.3. 反馈环路与其他双边协议

反馈环路（Feedback Loop，FBL）是双方之间为交换滥用报告而达成的一种双边协议。典型情形是：发送方向某个接收站点注册，以便从该站点接收针对来自该发送方的邮件的滥用报告。

FBL 报告地址（即接收 FBL 报告的地址）是这一双边注册的组成部分。有些 FBL 要求注册方使用 DKIM。

更多讨论参见第 6 节。

FBL 通常采用 [ARF] 或 [IODEF] 格式。

1.4. 文档范围与目标

本文档针对上述问题展开讨论，以改进 DKIM 与 MLM 之间各种可能交互的处理方式。总体上，倾向于把行为上的改动施加于签名方（Signer）与验证方（Verifier），而不是施加于 MLM。

在可能的情况下，本文档对 MLM 的讨论在概念上与 MTA 相解耦，尽管在具体实现中二者有时集成得非常紧密。这样做是为了强调 MLM 的服务与职责在功能上独立于 MTA 的服务与职责。

本文档的一部分内容探讨了签名方、验证方与 MLM 在常规做法上可能作出的改变。所建议的这些增强在性质上很大程度上是预测性的，它们考虑了当前的电子邮件基础设施、DKIM 在获得更广泛部署后所能提供的能力，以及工作组的共识。这些建议并不建立在大量的实现历史之上，其有效性、性能与安全特性也尚未被充分探究。

2. 定义

2.1. 关键词

本文档中的关键词 "MUST"（必须）、"MUST NOT"（不得）、"REQUIRED"（需要）、"SHALL"（应）、"SHALL NOT"（不应）、"SHOULD"（应当）、"SHOULD NOT"（不应）、"RECOMMENDED"（推荐）、"NOT RECOMMENDED"（不推荐）、"MAY"（可以）和 "OPTIONAL"（可选）应按照 [KEYWORDS] 中的描述进行解释。

2.2. 消息传递术语

关于当前消息传递体系结构的总体描述，以及本文档中所用各类术语的定义，参见 [EMAIL-ARCH]。

2.3. DKIM 相关参考资料

建议读者熟悉核心规范文档 [DKIM] 与 [ADSP]，以及 DKIM 的主要教程性文档 [DKIM-OVERVIEW] 与 [DKIM-DEPLOYMENT]。

2.4. 「DKIM 友好」（'DKIM-Friendly'）

术语「DKIM 友好」用于描述这样一类邮件中间方：它在处理消息时，不会对消息作出任何会导致「输入时有效的 [DKIM] 签名在输出时验证失败」的改动。

MTA 与 MLM 的许多被视为对用户有帮助的特性，往往具有使 DKIM 签名无法通过验证的副作用。这些特性不符合上述称号。

2.5. 消息流（Message Streams）

「消息流」标识的是源自某个 ADMD 之内、在意图、来源和/或用途上彼此不同的一组消息，并以某种方式对它们进行划分（例如在 DKIM 语境下通过改变 "d=" 标签的取值），使这些消息既保持与用户的关联，又在验证方或接收方的评估与处理层面彼此区分开来。

一个很好的例子是：由公司员工产生的用户邮件，相对于来自自动化系统的运营类或事务类邮件，或者营销与销售活动邮件。针对每一类都可以施加不同的发送策略，或者可能希望让它们彼此隔离（例如，某次营销活动被大量垃圾邮件过滤器举报，可能导致营销流的声誉下降，而不会自动殃及事务流或用户流）。

3. 邮件列表与 DKIM

有必要对不同风格的中间方、它们的典型实现方式，以及它们在具备 DKIM 意识的环境中所产生的影响，作出一些区分。

3.1. 角色与现实

在与 DKIM 相关的各项活动中，消息传输过程涉及若干关键角色。其中大多数已在 [EMAIL-ARCH] 中定义，此处重述以便快速查阅。

• 作者（Author）：提供待发送消息内容的代理方。作者把内容交付给发起方（Originator），从而开启消息通往其预期最终收件人的旅程。作者可以是使用 MUA（邮件用户代理）的人，也可以是可能发送邮件的自动化进程（例如 Unix 系统的 "cron" 工具）。
• 发起方（Originator）：从作者处接受消息、确保其符合 [MAIL] 等相关标准，然后把它发往目的地的代理方。它通常被称为邮件提交代理（Mail Submission Agent，MSA）。
• 签名方（Signer）：在消息前往其最终目的地的途中，为其附加一个或多个 DKIM 签名的任何代理方。通常在位于作者 ADMD 与公共 Internet 之间的那个 MTA 上运行着一个签名方。发起方和/或作者也可能是签名方。
• 验证方（Verifier）：执行 DKIM 签名验证的任何代理方。通常在位于公共 Internet 与接收方 ADMD 之间的那个 MTA 上运行着一个验证方。请注意，任何处理已签名消息的代理方都可以执行验证；本文档只考虑在 MLM 或在接收方处的这一动作及其结果。该代理方可以基于验证结果作出过滤决策。
• 接收方（Receiver）：作为消息最后一跳传输中继、并向消息收件人执行最终投递的代理方。基于验证方所得结果的过滤决策可以由接收方来实施。验证方与接收方可以是同一个代理方。接收方有时与邮件投递代理（MDA）相同，或与之耦合。

在简单的用户对用户邮件场景中，这些角色相当直观。然而，当有人向某个列表发信、邮件随后被中继给该列表的全部订阅者时，这些角色对一般用户来说往往就不那么清晰了，因为某个具体的代理方可能同时担任多个重要但彼此可分的角色。上述定义旨在使有关机制的讨论更为精确。

3.2. 邮件列表的类型

常见的 MLM 实现模式有四种：

• 别名式（aliasing）：别名式 MLM（参见 [EMAIL-ARCH] 第 5.1 节）在再分发时不对消息本身作任何改动；任何修改都仅限于对 [SMTP] 信封收件人列表（RCPT 命令）的改动。除了添加 [MAIL] 追踪信头字段之外，消息头与消息体完全不发生变化。这类 MLM 的输出被视为作者原始消息传输过程的延续。此类 MLM 的一个例子是直接在 MTA 中展开的地址，例如用于中继运营类或其他仅限内部的消息的本地系统管理员列表。另可参见 [SMTP] 第 3.9.2 节。
• 重发式（resending）：重发式 MLM（参见 [EMAIL-ARCH] 第 5.2 与 5.3 节）可能会对消息作出改动。这类 MLM 的输出被视为一条新消息；在重新投递该消息之前，原始消息的投递已经完成。此类消息常被重新格式化，例如加入列表特有的信头字段或其他属性，以便利列表订阅者之间的讨论。
• 创作式（authoring）：创作式 MLM 自行创作所发送的内容并发起其传输，而不是基于先前收到的一条或多条消息。就 [EMAIL-ARCH] 而言，它并不是「中介方（mediator）」，因为消息由它发起；但在创作完成之后，它的消息处理与投递行为在其他方面确实符合 MLM 范式。通常不会产生回复；即便有回复，回复也是发给某个特定收件人，而不是回到列表的全体收件人。例子包括电子报（newsletter）与批量营销邮件。
• 摘要式（digesting）：重发式 MLM 的一种特例，它发送单独一条消息，其中聚合了近期向该 MLM 提交的若干投稿；这条消息可能是 [MIME] 类型为 "multipart/digest" 的消息（参见 [MIME-TYPES]）。这显然是一条新消息，但其中可能包含一系列原始消息，而这些原始消息本身可能是经过 DKIM 签名的。

在本文档的余下部分中，我们区分与以下 SMTP 事务相对应的两个相关步骤：

• MLM 输入（MLM Input）：发起消息的用户是作者；发起方 ADMD 是发起方与签名方；MLM 的 ADMD 是验证方；MLM 的输入功能是接收方。
• MLM 输出（MLM Output）：MLM（发送其对原始用户消息所重构的副本）是作者；MLM 的 ADMD 是发起方与签名方；列表每个订阅者所在的 ADMD 是验证方；每个订阅者是接收方。

本文档的大部分内容聚焦于重发式 MLM，因为它在运营上与 DKIM 的冲突最为直接。

把 MLM 的整体运作剖分为这两个彼此不同的阶段，使得与 MLM 相关的 DKIM 特有问题得以被隔离出来并以合乎逻辑的方式加以处理。核心问题在于：MLM 对消息的重新封装与重新投递，实际上是在构造一条全新的消息；就此而言，MLM 是在向电子邮件生态中引入新内容——它消费掉作者那份消息，并创建属于自己的消息。以这种方式来看待时，MLM 及其 ADMD 的双重角色就变得清晰了。

与这些活动有关的一些问题，在 [MAIL] 第 3.6.4 节与 [EMAIL-ARCH] 第 3.4.1 节中有所讨论。

3.3. 当前 MLM 对签名的影响

如上所述，别名式 MLM 不会影响任何既有签名；创作式 MLM 始终是在创作新内容，因此从来不存在既有签名。然而，重发式 MLM 通常所作的改动会影响 RFC5322.Subject 信头字段、会添加某些列表特有的信头字段，和/或会修改消息体。下面讨论这些改动各自对 DKIM 验证的影响。

• 主题标签（Subject tags）：MLM 的一项流行特性是对 RFC5322.Subject 字段「打标签」，即在该字段内容之前加上列表名称作为前缀，例如对名为 "example" 的列表加上 "[example]"。通过添加列表特有的前缀或后缀来改动新投稿的 RFC5322.Subject 字段，若创建签名时该信头字段被纳入了哈希，就会使签名方的签名失效。[DKIM] 第 5.5 节把 RFC5322.Subject 列为应当被覆盖的字段之一，因为它含有对用户可见的重要文本；因此，对于任何作出此类改动的列表，这都会是一个问题。
• 列表特有的信头字段：有些列表会添加用于列表管理功能的信头字段，例如 [LIST-ID] 与 [LIST-URLS] 中定义的字段，或 [MAIL] 中定义的 "Resent-" 系列字段。典型的 MUA 不太可能在原始消息中包含这类字段，而且 DKIM 总体上对信头字段的添加具有韧性（参见 [DKIM] 第 3.5 节中关于 "h=" 标签的说明）。因此，这一点不被视为问题。
• 其他信头字段：有些列表会添加或替换诸如 "Reply-To" 或 "Sender" 之类的信头字段，以表明该消息是在邮件列表的语境中发送的，从而标识出该列表（"Sender"），并使用户的任何回复都发往列表（"Reply-To"）。如果这些字段原本就存在于原始消息中，那么其中一个或多个有可能已被纳入签名哈希，于是这些签名将被破坏。
• 轻微的消息体改动：有些列表会在每条消息前面或后面加上几行文字，以提醒订阅者关于订阅事宜的管理 URL、列表政策等。对消息体的改动会改变 DKIM 验证方计算出的消息体哈希，因此这类改动会使任何覆盖了消息体相应部分的既有签名无法通过验证。[DKIM] 提供了限制消息体哈希所覆盖长度的能力，使得追加的文本不至于干扰签名验证，但这样做有安全方面的影响。
• 重大的消息体改动：有些 MLM 在准备再分发消息时会对消息体作出更实质的改动，例如添加、删除、重排或重新格式化 [MIME] 部件，把 HTML 消息「压平」为纯文本，或在 HTML 消息内部插入页眉或页脚。这些改动中的大多数乃至全部都会使 DKIM 签名失效。
• MIME 部件移除：某些具备 MIME 意识的 MLM 会从投稿中移除较大的 MIME 部件并以 URL 取而代之，以缩小消息分发形态的体积，并防止无意间自动投递恶意软件。除了在生成 DKIM 签名时施加了消息体长度限制的某些情形之外，签名都会被破坏。

据称目前仍有一些运行中的邮件列表实际上是由人工列表管理员手动运作的，其准备消息以供分发的工作方式，可能包含上述改动，甚至还包含其他改动。

总体而言，如果 MLM 的开发者与运营者没有整体上转向更加 DKIM 友好的做法，那么 MLM 的订阅者就不能指望「在消息被 MLM 处理之前所施加的签名」在投递到接收方时仍然有效。由于总体的开发与部署惯性，这样的演进在短期内并不被看好。此外，即便某个 MLM 目前会原样传递消息、从而使作者签名得以通过验证，该 MLM 的一次配置改动或软件升级也可能使情况不再如此。

4. 非参与型 MLM

本节讨论向不具备 DKIM 意识的 MLM 发送、或经由其转发 DKIM 已签名邮件时所涉及的问题。具体来说，[DKIM] 与 [AUTH-RESULTS] 所引入的信头字段对这类 MLM 不具有任何特殊含义。

4.1. 与作者相关的签名

在理想化的世界中，如果作者知道消息所发往的 MLM 是一个非参与型的重发式 MLM，那么在决定是否向该列表发送已签名消息时，作者需要谨慎行事。MLM 可能作出某项改动，使作者的签名失效，却又不在再分发之前将其移除。于是，列表收件人收到的消息看似来自作者，却带有一个无法通过验证的 DKIM 签名。某些邮件过滤软件会错误地对含有验证失败的 DKIM 签名的消息予以惩罚。这可能造成作者无法控制的不利后果。（关于这一点的更多讨论见下文。）如果存在实施签名策略（例如 [ADSP]）的接收方，且作者发布了任何形式的严格策略——即要求接收方拒收或以其他严厉方式处置不合规消息的策略——这一问题就会被进一步放大。

对于确实发布了严格 ADSP 策略的域，发起站点应当（SHOULD）为「个人」邮件使用一个独立的消息流（参见第 2.5 节），例如一个用于签名的作者子域——一个不同于其他邮件流所用域的子域。这使得各个消息流能够发展出各自独立的声誉，并且可以对那些不经过邮件列表、或者干脆完全不签名的邮件流施加更严格的策略（包括 ADSP）。

然而，所有这一切都以对基础设施的某种理解水平为前提，而这种理解水平预计并不普遍。因此，随着 DKIM 获得更广泛的采用，站点管理员将有责任去考虑：如何为希望参与邮件列表的用户提供支持。

总体而言，更严格的实践与策略，很可能只对那些受发起机构端到端控制程度最高的邮件流才会奏效。这通常不包括经由 MLM 的邮件。因此，希望采用 ADSP "discardable"（可丢弃）设置的站点管理员应当（SHOULD）把值得如此处置的受控邮件流，与其他受控程度较低的邮件流（例如经过 MLM 的个人邮件）分离开来。（另参见下文第 5.7 节。）

4.2. 接收方处的验证结果

没有可靠的办法判定某封邮件是经由非参与型 MLM 到达的。其用户订阅了非参与型 MLM 的站点应当（SHOULD）确保这类用户邮件流不受严格的 DKIM 相关处置策略的约束。

4.3. 接收方处的处置选择

如第 4.1 节所述，为了把某些邮件从「应通过签名验证」的预期中豁免出来，接收方 ADMD 需要登记非参与型列表，并确认邮件确实经由它们传输。然而，这种做法需要过多的工作量，即便如此也很可能并不可靠。因此，它不是一个可扩展的解决方案。

把验证失败当作具有某种特殊含义来对待，是对 DKIM 签名基本规范 [DKIM] 的违反。超出该规范范围的唯一有效且已标准化的依据，是特定的 ADSP 指示。

使用诸如 [ADSP] "discardable" 之类的限制性域策略带来了额外的挑战。在这种情况下，当消息未被签名或签名已无法通过验证时，策略要求丢弃该消息。策略中并没有为「可能已被 MLM 改动过的消息」设置例外，也不存在可靠的办法来识别此类邮件。因此，参与各方应当（SHOULD）遵从该策略并拒绝放行该消息。

4.4. 「包裹」一个非参与型 MLM

为一个原本非参与的 MLM 增加 DKIM 支持的一种办法，是把该 MLM「包裹」起来，实质上就是把它置于其他具备 DKIM 意识、可提供部分 DKIM 服务的组件（例如 MTA）之间。举例来说，运营该非参与型 MLM 的 ADMD 可以让自己的 DKIM 验证方对来自列表订阅者的消息进行处理，代表该 MLM 落实第 5 节的部分特性与建议；而接收 MLM 输出的 MTA 或 MSA 也可以为 MLM 所在的域添加一个 DKIM 签名。

5. 参与型 MLM

本节讨论 DKIM 已签名邮件经由具备 DKIM 意识的 MLM 传输时所涉及的问题。

5.1. 总则

仅仅添加新信头字段的改动（例如 [LIST-ID]、[LIST-URLS] 与 [MAIL] 所规定的那些字段），通常对参与 DKIM 的电子邮件基础设施最为友好。MLM 添加这些字段不会影响任何既有的 DKIM 签名，除非这些字段原本就已存在并被某个签名的哈希所覆盖，或者某个签名是专门为禁止添加这些字段而创建的（参见 [DKIM] 第 3.5 节中关于 "h=" 的说明）。

然而，在消息体上添加页眉与页脚的做法很常见，而且无论哪个标准组织出台什么文档，预计这种做法都不会消退。这类改动会使「消息体哈希覆盖整条消息」的签名失效。因此，接下来的各节还会讨论并建议其他处理方案。

针对这种不兼容性，一种可能的缓解办法是使用 "l=" 标签来限定 DKIM 消息体哈希所覆盖的消息体范围，但这对 [MIME] 消息并不可行；而且它还有安全方面的考虑（参见 [DKIM] 第 3.5 节）。因此，不鼓励使用它。

MLM 运营者常常会在外发消息中加入列表特有的策略表述（例如参与规则、小广告等）。除了 [LIST-URLS] 已支持的内容之外，目前尚无提议用于传递此类 MLM 一般运营细节的信头字段。这类信息通常以页脚文本的形式附加在消息体之后，或以页眉文本的形式置于原始消息体之前。推荐（RECOMMENDED）的做法是：定期向列表自动发送邮件，以提醒订阅者列表政策。同样推荐（RECOMMENDED）使用标准的信头字段而非消息体改动来表达列表的运营参数。这些定期邮件当然会显得重复，但正因为每次内容大体相同，如有需要它们可以很容易地被过滤掉。

5.2. DKIM 作者域签名实践（ADSP）

ADSP 带来了一项特殊的挑战。发布 "discardable" 策略的作者域对邮件列表的使用施加了非常严格的限制，实质上把该域的用户限定为只能使用由别名式 MLM 运营的列表；任何 MLM 只要改动来自该域的消息或移除其签名，就会使该消息遭到验证方或接收方的严厉处置。重发式 MLM 应当（SHOULD）直接拒收来自「其域发布了此类策略」的作者的任何邮件，因为这些消息很可能会被任何具备 ADSP 意识的收件方丢弃或拒收。另参见第 5.3 节中的讨论。

在未强制执行对 "discardable" 邮件的此类拒收、并且此类邮件到达了一个执行 ADSP 检查且检查失败的验证方时，该消息应当（SHOULD）被丢弃（即在 [SMTP] 层面接受该消息，但不投递而将其丢弃），或者通过返回 5xx 错误码予以拒收。对于后一种情况，关于如何以可能有意义的方式执行拒收，可在第 5.11 节中找到一些建议。

作出这些建议的理由，用一个例子来说明最为清楚。假设如下情形：

• 用户 U1 与 U2 都是列表 L 的订阅者；
• U1 位于一个使用 ADSP 通告 "discardable" 策略的 ADMD 之内；
• L 在重发之前会改动投稿，其改动方式会使 U1 的 ADMD 所添加的 DKIM 签名失效；
• U2 的 ADMD 在边界处通过发出 SMTP 错误码来强制执行 ADSP；并且
• L 被配置为移除那些邮件持续退信的订阅者。

由此可以推出：U1 向 L 的一次投稿会被 U2 收到，但由于 DKIM 签名验证失败，U2 的 ADMD 会依据 ADSP 协议拒收它。该拒收被 L 收到，于是 L 便把 U2 从列表中移除。

另参见 [ADSP] 附录 B.5 中的进一步讨论。

5.3. 订阅

在订阅时，具备 ADSP 意识的 MLM 应当（SHOULD）检查新订阅者所在域是否发布了 ADSP 记录。如果该策略指定为 "discardable"，MLM 应当（SHOULD）不允许此次订阅，或者给出警告：由于该订阅者所属 ADMD 所发布的策略，其向该邮件列表的投稿可能无法投递给某些收件人。

当然，此类策略记录也可能是在订阅之后才创建的，因此这并不是一个普适的解决方案。MLM 实现可以（MAY）定期检查其订阅者并在检测到此类策略时发出警告，或者干脆在每次投稿时检查。

5.4. ADSP 相关建议的例外情形

如果某个 ADMD 与另一个 ADMD 之间已建立某种带外（out-of-band）信任协议，使得一方所施加的 Authentication-Results 字段能被另一方信任，那么上述关于 MLM 在 ADSP 方面的运营建议就不再适用；因为在这种情况下，即便收到消息时并不存在有效的作者签名，也仍然可以确定是否能够推断出曾存在过这样一个签名。

举例来说，假设域 example.com 与 example.net 之间有明确协议，彼此信任对方的认证断言。现在考虑这样一条消息：其 RFC5322.From 域为 "example.org"，并带有同一域所作的有效 DKIM 签名，它到达了由 example.com 运营的一个邮件列表。在评估时，example.com 验证了该签名，并添加了一个 [AUTH-RESULTS] 字段来表明这一点。然而，该 MLM 同时也对消息体作了改动，使该签名失效。随后 MLM 使用 DKIM 对修改后的消息重新签名，并把它发送给列表订阅者，其中一位订阅者在 example.net。

该消息到达 example.net 时，example.org 的 DKIM 签名已不再有效，因此 ADSP 通常会判定失败。但 example.net 信任 example.com 的 Authentication-Results 字段所作的断言——即曾存在一个来自 example.org 的有效签名——因此这次 ADSP 失败可以被忽略。

5.5. 与作者相关的签名

一项重要的考虑是：作者极少能对 MLM 的管理施加任何直接影响。具体来说，中间方的行为（例如某个 MLM 在过滤垃圾邮件方面不够细致，或在处理退订请求方面不够勤勉）可能引发收件人投诉，而这些投诉会反过来落到那些看上去应对该消息负责的代理方身上——在这里就是通过 RFC5322.From 字段中的地址所指向的作者。将来，当 DKIM 签名的输出（即签名域）被用作声誉模块的输入时，人们可能会希望把自己的声誉与「向 MLM 发信所带来的未知结果」隔离开来。在这种情况下，作者应当（SHOULD）专门创建一个消息流，用于在向 MLM 发送流量时生成 DKIM 签名。

这一建议可以推广为更一般的形式：属于事务性的、或总体上具有端到端性质、不太可能被 MLM 或用户四处转发的邮件，应当（SHOULD）使用一个不同于「服务于更多样化用途的邮件流」的消息流标识符来签名。

5.6. MLM 处的验证结果

MLM 通常会尝试对经由其投递的消息进行认证。它们一般通过一种简单（且不安全）的手段来做到这一点：把 RFC5322.From 字段中的邮件地址（或者较少见地，把 RFC5321.MailFrom 参数）与列表订阅登记表进行比对。DKIM 使一种更强的认证形式成为可能：MLM 可以要求使用某个特定 RFC5322.From 地址的消息，同时带有一个具有相应 "d=" 域的 DKIM 签名。这项特性与使用 ADSP 有些相似，区别在于该要求是由 MLM 而非作者所属机构提出的。

（但要注意，这已超出了 DKIM 已成文的语义。此处只是把它作为一种可能可行的增强来介绍。）

如上所述，MLM 可能会对已签名消息执行 DKIM 验证，以试图确认作者的身份。尽管这是一个常见而且直观的结论，但实际上很少有已签名消息会包含作者签名（参见 [ADSP]）。增加此类支持的 MLM 实现者必须考虑到这一点。举例来说，可以把 MLM 设计为能够为某个给定作者维护一份可能的签名域（DKIM 签名的 "d=" 部分）清单，并在验证时判定其中是否有任何一个出现在消息中。这样能提供一种更可靠的认证方法，代价则是必须为订阅者存储一份已授权签名域的映射表，并且要指望它能保持及时更新。

无法通过上述方式完成认证的消息，可以（MAY）被暂留待审（held for moderation）或直接拒收。

这一逻辑可以适用于任何列表操作，而不仅仅是向列表投稿。特别地，这种改进后的认证可以（MAY）适用于通过邮件（而非通过 Web 这类经过认证的交互式通道）发送的订阅、退订和/或订阅者选项变更。

在对投稿上的签名进行验证的情形中，MLM 应当（SHOULD）添加一个 [AUTH-RESULTS] 信头字段，以表明投稿到达 MLM 时所观察到的签名以及评估的结果。下游的代理方是否信任该信头字段的内容，取决于它们对「生成（并且最好是签名了）该信头字段的 ADMD」的运作方式所具有的先验知识。进一步的讨论参见 [AUTH-RESULTS]。

5.7. 签名移除相关的问题

一条带 DKIM 签名到达的消息，意味着在 MLM 输入之前有某个域已对该消息作出了某种责任声明。因此，保留输入侧签名的一个明显好处是：可以保存这一对消息的原始责任声明，使最终消息的接收方有机会在掌握该信息的情况下对消息作出评估。

然而，如果 MLM 被配置为在重新投递之前对消息作出会使原始签名失效的改动，那么推荐（RECOMMENDED）采取进一步措施，以防止已失效的签名到达最终收件人、进而可能触发不应有的过滤动作。（但要注意，这类过滤动作显然是错误的；[DKIM] 明确规定，无效签名应当被视为完全没有签名。）

一种可能的解决方案是：

1. 尝试验证输入消息上存在的所有 DKIM 签名；
2. 应用本地策略来认证作者的身份；
3. 移除所有既有的 [AUTH-RESULTS] 字段（可选）；
4. 向消息添加一个 [AUTH-RESULTS] 信头字段，以表明上述各步的结果；
5. 移除所有先前已被评估过的 DKIM 签名；
6. 附加一个新签名，其哈希覆盖输出侧的整条消息，包括刚刚添加的 Authentication-Results 信头字段（参见第 5.8 节）。

当 MLM 明知自己将要进行的重新格式化在性质上很可能使部分或全部原始签名失效时，移除这些原始签名就显得尤为恰当。这样做可以避免列表订阅者在其作为消息接收方的角色上出现误判（false negative）；虽然 [DKIM] 明确规定无效签名等同于没有签名，但可以预料仍会有一些实现无视这一建议。

MLM 可以在完成对消息的改动之后重新评估既有签名，以判定其中是否有任何签名已失效。这样做的成本会有所降低，因为可以推定所需的公钥已经下载过，并且消息的一个或两个哈希值可以被复用。

依据 [AUTH-RESULTS] 中的讨论，接收方若要对该信头字段的真实性抱有任何信任，就需要对创建该字段的代理方作出先验评估。缺乏这种评估时，接收方无法把该字段解释为有效。因此，消息的最终收件人无法自行验证该消息上作者身份的真实性。不过，如果验证方拿到消息时该字段是消息上唯一的一个，并且验证方明确信任那个把 Authentication-Results 字段纳入其信头哈希的签名方（在此即 MLM），那么验证方就有理由相信该消息上曾存在一个有效的作者签名。

这一点可以推广如下：接收方应当（SHOULD）只考虑这样的 [AUTH-RESULTS] 字段——其 authserv-id 出现在接收方所信任的站点清单中，并且该字段同时被「由同一可信清单中的某个域所添加的 [DKIM] 签名」的信头哈希所覆盖。

由于别名式 MLM 不对消息作任何实质性改动，它无需考虑签名移除的问题，因为原始签名至少应当能够未经修改地到达下一个 MTA。将来基于域的声誉体系有可能更偏好在收到消息时获得更丰富的数据集，若如此，移除签名就是不可取的。

创作式 MLM 对外部投稿者是封闭的，因此这里的大部分讨论在该情形下并不适用。

5.8. MLM 签名

具备 DKIM 意识的重发式 MLM 与创作式 MLM，在分发消息时应当（SHOULD）附加自己的签名。MLM 要为其对所重发的原始消息所作的改动负责，并且应当通过签名来表达这一点。这样做也有助于从可能已建立的各类 FBL 获得反馈，从而使不受欢迎的列表邮件能够触发适当的处置。

MLM 签名很可能会被收件方系统用来识别列表邮件，而且它们给了 MLM 所属 ADMD 一个为该列表本身建立良好声誉的机会。

与任何其他 MLM 一样，进行签名的 MLM 可以自行决定不再分发某条消息，如果该消息的签名情况不符合其自身的本地配置或策略。它也可以选择再分发但不为此类邮件签名。然而，选择性签名是不推荐（NOT RECOMMENDED）的；那样做实质上会从该 MLM 产生两个消息流，一个有签名、一个没有，这会使具备 DKIM 意识的验证方与接收方感到困惑。

进行签名的 MLM 可以添加一个 List-Post: 信头字段（参见 [LIST-URLS]），其中使用的 DNS 域与该 MLM 所添加的 DKIM 签名的 "d=" 标签中所用的域相匹配。验证方或接收方可以据此识别出由 MLM 添加的那个 DKIM 签名。不过这并非必需；一般认为，签名方的声誉将是比这种建议性绑定更为关键的数据点。此外，这种绑定关系并未被任何现行规范文档所承认。

具备 DKIM 意识的重发式 MLM 应当（SHOULD）在消息准备好分发之后（即第 3.2 节所述的 MLM 输出阶段）对整条消息签名。任何其他配置都可能生成无法通过验证的签名。

具备 DKIM 意识的创作式 MLM 则按照 [DKIM] 给出的常规签名指引，为其所发送的邮件签名。

一项值得关注的问题是：让 MLM 对未签名的邮件施加自己的签名，可能会使某些验证方或接收方把该签名解读为赋予了消息内容超出 [DKIM] 所定义范围的权威性或真实性。这个问题超出了 MLM 的范畴，主要涉及 [DKIM] 范围之外的接收侧处理。尽管如此，仍值得在此指出。

5.9. 最终接收站点处的验证结果

总体而言，验证方与接收方应当（SHOULD）把来自 MLM 的已签名消息与任何其他已签名消息同等对待；实际上，要辨别出其中的差异也很困难，因为诸如 [LIST-URLS] 与 [LIST-ID] 之类的规范并未被普遍部署，而且很容易被伪造。

然而，由于作者域通常会不同于 MLM 的签名域，因此可能与 [ADSP] 产生冲突，正如第 4.3 节与第 5.7 节中所讨论的那样，在某个 ADMD 误用了 ADSP 的情形下尤其如此。

5.10. 与 FBL 配合使用

FBL 运营者可能希望针对用户对某条发往列表的消息所作的投诉采取行动。有些 FBL 可能选择基于对相关消息的 DKIM 验证结果来生成反馈报告。此类运营者应当（SHOULD）向每一个「拥有有效签名且已建立 FBL 协议」的域发送报告，因为 DKIM 签名是对该消息承担某种责任的声明。由于作者通常对列表的运作控制有限，这一点使得 MLM 签名更显重要。

MLM 运营者应当（SHOULD）向各大服务提供商的 FBL 进行注册。在 DKIM 的语境下，应当（SHOULD）与 FBL 提供方交换信息，包括 MLM 将使用何种签名域（如果有的话）。

如果 FBL 希望更加具体，它可以（MAY）仅针对这样的 DKIM 签名采取行动：其签名域与 List-Post: 信头字段（或类似字段）中所示的 DNS 域相匹配。

以这种方式使用 FBL 一事，应当（SHOULD）向列表订阅者明确说明。举例来说，如果 MLM 所属 ADMD 的策略是通过退订「看上去是冒犯性消息发送者」的那位用户来处理一条 FBL 记录，那么事先告知订阅者这一点将有助于避免日后的意外。

一条发往 MLM、进而被分发给列表全体收件人的 DKIM 已签名消息，可能会因某种原因引发某位最终收件人的投诉。这可能是某位订阅者认为该消息具有滥用性质或其他不受欢迎之处而发出的真实投诉，也可能是自动化投诉，例如接收方检测到 DKIM 签名失效或其他某种情况。它还可能是敌意行为所导致的投诉，例如常见的情形是：某位列表订阅者在退订时遇到麻烦，随后便开始对该列表的所有投稿发起投诉。这将导致在 FBL 报告的语境下生成一条投诉，并被回送给消息作者。然而，原作者并不参与 MLM 本身的运作，这意味着该 FBL 报告无从据以行动，因而是不受欢迎的。

5.11. 接收方处的处置选择

明确信任来自某个特定 MLM 的签名的收件方，可以（MAY）希望把这种信任延伸到由该 MLM 签名的 [AUTH-RESULTS] 信头字段上。该收件方随后可以（MAY）对消息作进一步处理，使用 Authentication-Results 信头字段中所记录的结果，而不是原作者的 DKIM 签名。这包括可能按照 ADSP 的要求来处理该消息。

接收方应当（SHOULD）忽略或移除所有未经签名的、由外部施加的 Authentication-Results 信头字段，以及那些并非由接收方所能信任的 ADMD 所签名的此类字段。进一步的讨论参见 [AUTH-RESULTS] 第 5 与第 7 节。

在 SMTP 会话期间进行 DKIM 与 ADSP 评估时（这是一种常见的实现方式），代理方可以（MAY）决定在 SMTP 会话中拒收某条消息。若这样做，[SMTP] 规定 550 是正确的响应码。不过，如果该 SMTP 服务器支持 [ENHANCED] 增强状态码，那么更宜使用一个通常不用于「用户未知」（5.1.1）的状态码；因此，应当（SHOULD）使用 5.7.0 状态码。如果执行拒收的 SMTP 服务器支持这一点，它便能够区分「因策略决定而被有意拒收的消息」与「因其他投递问题而被拒收的消息」。特别地，策略性拒收应当（SHOULD）使用上述增强状态码，并在回复的文本部分附以适当的措辞加以传达。那些会自动尝试移除长期存在投递问题的用户（例如删除账户）的 MLM，因此应当（SHOULD）能够检测出策略性拒收与其他投递失败之间的差异，并据此采取相应处置。此外，这样做的 SMTP 服务器如果在回复的文本部分使用恰当的措辞——或许明确地使用 "ADSP" 这一字符串——也将大有裨益，因为这便于在日志中检索相关数据。

上一段的内容不适用于 [ADSP] 的 "discardable" 策略。在投稿未通过该项检查的情形下，接收方或验证方应当（SHOULD）丢弃该消息但返回 SMTP 成功码，即接受该消息但不投递而将其丢弃。对此类邮件采取 SMTP 拒收而非所要求的丢弃动作，弊大于利。

6. DKIM 报告

随着用于报告 DKIM 验证失败取证细节的机制逐步问世，MLM 将从这些机制的使用中获益。

MLM 应当（SHOULD）应用 DKIM 失败报告机制，作为向签名方反馈 DKIM 基础设施相关问题的一种方法。对于那些把 DKIM 验证用作「对列表配置命令与订阅者投稿进行认证」之机制的 MLM 来说，这一点尤为重要。

7. 安全考虑

本文档提供的是 DKIM 使用方面的建议做法或最佳当前实践，因此并未引入任何需要专门考量的新技术。不过，在实施本文档所述实践时，应当考虑以下安全问题。

7.1. 来自 DKIM 与 ADSP 的安全考虑

读者应视情况熟悉 [DKIM]、[ADSP] 与 [AUTH-RESULTS] 各文档中「安全考虑」章节的内容。

7.2. 中继时的认证结果

第 5 节主张添加 [AUTH-RESULTS] 信头字段，以表明作为 MLM 输入而接收到的消息的认证状态。依据 [AUTH-RESULTS] 第 7.2 节，接收方一般不应在缺乏充分理由（例如与 MLM 所属 ADMD 之间的先验协议）的情况下信任此类数据。

强烈建议此类协议中包含这样一项要求：这些信头字段必须被 MLM 所属 ADMD 添加的 [DKIM] 签名所覆盖。

8. 参考文献

8.1. 规范性参考文献

• [ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine，《域名密钥识别邮件（DKIM）作者域签名实践（ADSP）》，RFC 5617，2009 年 8 月。
• [AUTH-RESULTS] Kucherawy, M.，《用于指示消息认证状态的消息信头字段》，RFC 5451，2009 年 4 月。
• [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.，《域名密钥识别邮件（DKIM）签名》，RFC 6376，2011 年 9 月。
• [EMAIL-ARCH] Crocker, D.，《Internet 邮件体系结构》，RFC 5598，2009 年 7 月。
• [KEYWORDS] Bradner, S.，《在 RFC 中用于指示需求级别的关键词》，BCP 14，RFC 2119，1997 年 3 月。
• [MAIL] Resnick, P., Ed.，《Internet 报文格式》，RFC 5322，2008 年 10 月。

8.2. 资料性参考文献

• [ARF] Shafranovich, Y., Levine, J., and M. Kucherawy，《一种可扩展的邮件反馈报告格式》，RFC 5965，2010 年 8 月。
• [DKIM-DEPLOYMENT] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker，《域名密钥识别邮件（DKIM）的开发、部署与运营》，RFC 5863，2010 年 5 月。
• [DKIM-OVERVIEW] Hansen, T., Crocker, D., and P. Hallam-Baker，《域名密钥识别邮件（DKIM）服务综述》，RFC 5585，2009 年 7 月。
• [ENHANCED] Vaudreuil, G.，《增强型邮件系统状态码》，RFC 3463，2003 年 1 月。
• [IODEF] Danyliw, R., Meijer, J., and Y. Demchenko，《事件对象描述交换格式》，RFC 5070，2007 年 12 月。
• [LIST-ID] Chandhok, R. and G. Wenger，《List-Id：用于标识邮件列表的结构化字段与命名空间》，RFC 2919，2001 年 3 月。
• [LIST-URLS] Neufeld, G. and J. Baer，《将 URL 用作核心邮件列表命令的元语法及其经由消息信头字段的传输》，RFC 2369，1998 年 7 月。
• [MIME] Freed, N. and N. Borenstein，《多用途 Internet 邮件扩展（MIME）第一部分：Internet 报文主体的格式》，RFC 2045，1996 年 11 月。
• [MIME-TYPES] Freed, N. and N. Borenstein，《多用途 Internet 邮件扩展（MIME）第二部分：媒体类型》，RFC 2046，1996 年 11 月。
• [SMTP] Klensin, J.，《简单邮件传输协议》，RFC 5321，2008 年 10 月。

附录 A. 致谢（Acknowledgements）

作者谨向以下各位对本文档的审阅与建设性批评致谢：Serge Aumont、Daniel Black、Dave Crocker、J.D. Falk、Tony Hansen、Eliot Lear、Charles Lindsey、John Levine、Jeff Macdonald、S. Moonesamy、Rolf E. Sonneveld 以及 Alessandro Vesely。

附录 B. 示例场景（Example Scenarios）

本附录描述了若干与 MLM 相关的 DKIM 场景，它们是促成本项工作的部分动因，并给出针对每种场景的推荐解决办法。

B.1. MLM 与 ADSP

问题：

• 作者 ADMD 通告了 "dkim=discardable" 的 ADSP 策略；
• 作者向一个非参与型 MLM 发送 DKIM 已签名邮件，该 MLM 使签名失效；
• 接收方 MTA 在 SMTP 阶段检查 DKIM 与 ADSP，并被配置为拒收 ADSP 失败的邮件，于是拒收了这条消息；
• 上述过程重复若干次之后，MLM 把该接收方退订。

解决办法：除非 MLM 确信自己不会作出任何使 DKIM 签名失效的改动，否则应当拒收来自通告 "discardable" ADSP 策略的域的邮件。

B.2. MLM 与 FBL

问题：

• 订阅者向一个不会使签名失效的非参与型 MLM 发送已签名邮件；
• 某位收件人把该消息举报为垃圾邮件；
• 收件方 ADMD 的 FBL 把报告发给了投稿者而不是列表管理员。

解决办法：MLM 应当为其所发送的邮件签名，并且也可以剥离既有的签名。在能够区分的情况下，FBL 应当向列表运营者而非订阅者报告；否则，FBL 应当向所有持有有效签名的各方报告。

作者地址（Author's Address）

Murray S. Kucherawy
Cloudmark
128 King St., 2nd Floor
San Francisco, CA 94107
USA

Phone: +1 415 946 3800
EMail: msk@cloudmark.com