非官方中文译本声明：本页为 IETF RFC 6647《Email Greylisting: An Applicability Statement for SMTP》 的非官方中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布、不受版权限制；依据 BCP 78，本译本为署名翻译作品，译文力求忠实但不构成官方版本，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc6647。

RFC 6647《邮件灰名单（Greylisting）应用》中文译本

IETF · RFC 6647 · 标准跟踪（Standards Track）· 2012 年 6 月

摘要

本文档描述邮件灰名单（greylisting）这一技艺，即把「对未知邮件客户端临时提供降级服务」作为一种反滥用机制的做法。

灰名单是一种成熟的机制，被认为是当前反滥用邮件过滤系统技术储备中不可或缺的一环。

1. 引言

处理邮件滥用问题时，人们更倾向采用的技术是明确识别出「好的行为体」与「坏的行为体」，并分别给予差异显著的服务质量。但在某些情况下，某个行为体并不具备已知的声誉；这就为「先提供降级服务，直至有依据提供更好的服务」提供了正当理由。后一种做法即被称为「灰名单」（greylisting）。广义上，该术语指的是在一段时间内（通常以分钟或数小时计）对未知或可疑来源所作的任何服务降级。狭义上，该术语指的是针对来自此类来源的流量返回 SMTP 临时失败应答码。这一基本概念存在多种多样的实现方式，因此可以预见地，其术语使用也出现了一些模糊之处。

在缺少一种既完美又零成本的滥用检测机制的情况下，当下的现实要求是：每套过滤系统都需综合运用一系列技术手段。这些手段在成本、有效性以及所针对的滥用手法类型上各不相同。

灰名单恰好属于成本低廉、介入时机靠前（就其在 SMTP 时序中的应用位置而言）的技术，并且出人意料地至今仍然有效。确实有一些垃圾邮件软件（spamware）会绕开这一技术，但更多的并不会。

互联网上如潮水般涌来的垃圾邮件，其技术精巧程度差异极大。灰名单可用于清除其中数量庞大、手法简单却影响显著的那一部分流量。

本备忘录记录常见的灰名单技术，并讨论其收益与代价。它同时定义了相关术语，以便对这些技术作出清晰的区分与讨论。

业界存在一种混淆，把灰名单与「因任何原因返回 SMTP 临时失败」混为一谈。本备忘录的目的之一也是澄清这种混淆。

1.1. 背景

多年以来，大量垃圾邮件都是通过专门编写的软件（即「垃圾邮件软件」，spamware）发送的，这类软件只支持功能受限的 SMTP。特别是，此类软件在收到 SMTP 临时失败后并不会执行重传尝试。也就是说，如果垃圾邮件软件无法投递某封邮件，它只会转向其地址列表中的下一个地址，因为在发送垃圾邮件这件事上，数量远比可靠性重要。灰名单正是利用了这一点：对来自不熟悉来源的邮件返回「瞬时（软）失败」（4xx）[SMTP] 错误码予以拒绝。灰名单的另一种应用是延迟来自新出现 IP 地址的邮件，其原理在于：如果它是一个垃圾邮件源，那么等到它重试时，它多半已经出现在某个待过滤来源列表中，邮件也就不会被接受。

关于灰名单的早期描述与实现，可参见 [SAUCE] 与 [PUREMAGIC]。

1.2. 定义

1.2.1. 关键词

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

1.2.2. 邮件体系结构术语

读者需要熟悉 [MAIL]、[EMAIL-ARCH] 与 [SMTP] 中所讨论的材料和术语。

2. 灰名单的类型

灰名单主要在 SMTP 会话的某个阶段执行。系统会使用一组关于客户端侧 SMTP 服务器的属性，来评估是否实施灰名单。最简单的情形下，这个属性就是客户端的 IP 地址，而评估内容则是它此前是否近期连接过。也可以采用更复杂的属性组合与更精细的评估方式。以下讨论涵盖最常见的若干组合，并以读者了解 [SMTP]、其命令，以及信封（envelope）与内容（content）之间的区别为前提。

2.1. 连接级灰名单

连接级灰名单决定是否接受来自「新」[SMTP] 客户端的 TCP 连接。在客户端与服务器通信的这一时点上，接收服务器所知的唯一信息就是入站 IP 地址。当然，该地址通常（但并非总是）可以转换为一个主机名。

灰名单在此处的典型应用是：保存一份已见过的 SMTP 客户端 IP 地址和/或主机名（合称「源」，sources）的记录。这样一个数据库充当已知发送方的缓存，其中的记录可能会、也可能不会在一段时间后过期。如果某个源不在数据库中，或者该源的记录尚未达到某个要求的最小存续时长（例如自首次连接尝试起满 30 分钟），服务器就会执行以下动作之一，以邀请对方稍后重试：

在基本的「已知/未知」策略之上，有一种有用的变体：把灰名单限定于那些出现在「已知与不良行为体相关联的 IP 地址列表」中的地址。较简单的策略会影响所有新连接（包括来自良好行为体的连接），而这种受限策略只对已经具有负面声誉的站点施加灰名单动作。

2.2. SMTP HELO/EHLO 灰名单

HELO/EHLO 灰名单针对的是 SMTP 会话中的第一个命令动词。它包含一个单一的必需参数，该参数本应包含客户端的完全限定主机名或其字面 IP 地址。

在该阶段实现的灰名单会保存「源与 HELO/EHLO 参数相配对」的记录。如果该元组此前未被记录过，或者记录虽存在但尚未达到某个配置的最小存续时长，它就会对直至 SMTP 会话结束前的所有命令返回 4yz SMTP 应答。

2.3. SMTP MAIL 灰名单

MAIL 命令灰名单针对的是 SMTP 会话中发起一笔新事务的那个命令动词。它至少包含一个必需参数，用以指明由客户端中继给服务器的那封邮件的回信地址（RFC5321.MailFrom）。

在该阶段实现的灰名单会保存「源与回信地址相配对」的记录。如果该元组此前未被记录过，或者记录虽存在但尚未满足某个配置的最小存续时长，它就会在本次 SMTP 会话的剩余部分中对所有命令返回 4yz SMTP 应答。

2.4. SMTP RCPT 灰名单

RCPT 灰名单针对的是 SMTP 会话中指定一笔邮件事务预期收件人的那个命令动词。它至少包含一个必需参数，用以指明由客户端中继给服务器的那封邮件的某个预期收件人的邮件地址。

在该阶段实现的灰名单会保存这样一类元组的记录：把所提供的收件人地址与以下各项的任意组合相结合：

如果所选的元组未在数据库中找到，或者记录虽存在但尚未达到某个配置的最小存续时长，实施灰名单的邮件传输代理（MTA）[EMAIL-ARCH] 就会在本次 SMTP 会话的剩余部分中对所有命令返回 4yz SMTP 应答。

请注意，涉及第一个有效 RCPT 的元组匹配往往就足以正确识别出一次重试，后续检查可以省略。

2.5. SMTP DATA 灰名单

DATA 灰名单针对的是 SMTP 会话中传输实际邮件内容（相对于其信封细节而言）的那个命令动词。

这类灰名单可以在 SMTP 时序中的两个位置执行：

  1. 在收到 DATA 命令时，因为在该时点整个信封都已接收完毕（即所有 MAIL 与 RCPT 命令均已发出）；或者
  2. 在 DATA 命令完成时，即在终止邮件正文传输的那个 "." 之后，因为在该时点可以对邮件执行摘要计算或其他分析。

一些实现之所以在此处做过滤，是因为存在这样的客户端：它们除 DATA 之外根本懒得检查其他命令的 SMTP 应答码。因此，在 SMTP 会话的该时点增加灰名单能力是有用的。

在该时点可以采用众多灰名单策略。所有这些策略都会保存元组记录，这些元组以某种方式组合 SMTP 事务的各个部分，包括：

（上述列表中的最后四项只可能在 DATA 结束时进行，而不能在收到 DATA 命令时进行。）

如果所选的元组未在数据库中找到，或者记录虽存在但尚未达到某个配置的最小存续时长，实施灰名单的 MTA 就会在本次 SMTP 会话的剩余部分中对所有命令返回 4yz SMTP 应答。

2.6. 额外的启发式规则

既然灰名单的目标是针对垃圾邮件发送者，那么随之而来的是：若能在 SMTP 语境中超越「此前未曾见过」这一简单概念来识别垃圾邮件软件，将是很理想的。一种更具针对性的做法，还可以在其筛选中纳入如下启发式规则：

2.7. 例外

大多数灰名单系统都提供例外机制，允许指定豁免于灰名单检查的 IP 地址、IP 地址的无类域间路由（CIDR）[CIDR] 地址块、主机名或域名，从而使其 SMTP 客户端会话不受此类干预的影响。

可能适合被列入灰名单例外的候选对象包括：已知其重试模式不会被视为合法的那些发送方，以及发信频率极低、以至于会在数据库中过期老化的那些发送方。在这两种情形下，实施灰名单的站点都已知该被豁免的源并非滥用者。除此之外，典型的非滥用发送方会在第一次正常重试时进入例外列表，并永久留在其中。

人们也可以使用一个列出已知良好主机的 [DNSBL] 作为灰名单的例外集合。

3. 收益与代价

上述任何一种技术最显而易见的收益在于：在没有此前投递尝试记录的情况下，垃圾邮件软件通常不会重试，因而更不容易得逞。

实施灰名单最显而易见的害处，则是对合法邮件强加了延迟。一些流行的 MTA 在投递尝试失败后一小时甚至更久才会重试，当邮件投递具有时效性时，这可能造成代价高昂的延迟。更糟糕的是，某些合法 MTA 根本不重试。（不过请注意，按照 [SMTP] 第 2.1 节，不重试的客户端并不具备完整的 SMTP 能力。客户端并不知道、也无权知道所返回的临时失败状态码的原因；可能是灰名单在起作用，也可能是服务器端的本地资源问题所致。因此，客户端需要具备重试能力，才能被认为功能完整。）

针对这一「误判」（false positive）问题的反驳意见是：电子邮件从来都是一种「尽力而为」（best-effort）的机制；因此，与处理海量垃圾邮件的代价相比，这种代价终究是低的。尽管如此，此类延迟的实际影响仍可能相当显著，例如会改变邮件列表中多方讨论的语气或节奏。

当客户端经历任何形式的重新配置时（尤其是网络重新编址），所存储的关于 SMTP 客户端历史的缓存信息，对那些已被列入接受名单的合法客户端就不再起作用。在灰名单实现看来，这些客户端再次成为未知者，也将再次遭受延迟。

另一项显而易见的代价来自所需的数据库。它必须足够大以保存必要的历史记录，也必须足够快以避免服务器运行中出现过度的低效。首要的考量是数据库中记录的最大存续时长。如果记录过早老化淘汰，那么那些确实按 [SMTP] 重试的主机即便行为良好，也会周期性地遭受灰名单；如果记录经过过长的时间才老化淘汰，那么最终发起新一轮攻势的垃圾邮件软件将不会以这种方式被识别为「未知」，也就不会被要求重试。

假定已知的友好发送方会被手工配置为灰名单检查的例外，那么最终会达到一种稳定状态：其中唯一被延迟的邮件，来自从未发过邮件的 IP 地址。经验表明，绝大多数邮件都来自已成形的例外列表中的位置，因此在一段「训练期」之后，实际受影响的邮件只占很小的比例。这一训练期也可以用如下方式取代：处理一份邮件流量的历史数据，把绝大多数流量所来自的 IP 地址加入例外列表。

基于实际邮件内容（即 DATA 之后）实施灰名单，其代价比其他任何替代方案都要高得多：既包括接收并临时存储一份完整邮件正文（其体量可能相当可观）所需的资源，也包括对该内容所做的任何处理。因此，这类方法在会话期间会带来更高的开销，故而并非典型做法。

4. 非预期后果

4.1. 非预期的邮件投递失败

灰名单有几种失效模式值得考虑。例如，设想一封发往 user@example.com 的邮件。example.com 域由两台接收邮件服务器提供服务，一台叫 mail1.example.com，另一台叫 mail2.example.com。在第一次投递尝试时，mail1.example.com 对该客户端实施了灰名单，于是客户端把该邮件放入其出站队列以待稍后重试。之后当重试发生时，mail2.example.com 被选中来完成投递——要么是因为 mail1.example.com 不可用，要么是因为轮询式（round-robin）的 [DNS] 求值产生了这一结果。然而，这两台 example.com 主机并不共享灰名单数据库，因此第二台主机再次拒绝了这次尝试。这样一来，虽然 example.com 本意是通过部署两台服务器来提升其邮件吞吐能力，实际上却放大了灰名单所引入的合法邮件延迟问题。

与此类似，设想一个拥有多台出站 MTA 且共享同一队列的站点。在第一次向 example.com 发起出站投递尝试时，该尝试被施加了灰名单。在稍后的重试中，选中了另一台出站 MTA，这意味着 example.com 看到的是一个不同的源，于是同一封邮件再次遭遇灰名单。使用 [DHCP] 也会产生同样的效果——出站 MTA 的 IP 地址在两次尝试之间发生了变化。

对于执行 DATA 级灰名单的系统而言，如果邮件的任何部分自第一次尝试以来发生了变化，那么所构造出的元组就可能与第一次尝试时的元组不同，于是该次投递再次被施加灰名单。某些 MTA 确实会在提交时重新组织邮件的部分内容，这会使每次尝试之间产生可见的差异。

一台很少向某个特定目的地发信的主机，可能无法在接收服务器的数据库中保持「已知」状态，因而尽管它可能是合法发送方，其邮件仍会有很高比例遭到灰名单。

所有这些以及其他类似情形，都可能导致灰名单被多次不当地施加于合法 MTA，从而造成投递的长时间延迟，或最终把邮件退回给发件人。其他副作用还包括：一组有先后次序的相关邮件出现乱序投递。

诸如 [NAT] 之类的地址转换技术，会使彼此不同的 MTA 看起来都来自同一个共用 IP 地址。这可能导致灰名单只对来自该共享 IP 地址的第一次连接尝试生效，也就意味着此后首次连接的其他 MTA 将被排除在灰名单所提供的防护之外。

4.2. 非预期的 SMTP 客户端失效

部署灰名单时，还需要考虑非典型的 SMTP 客户端行为。

有些客户端在很长时间内都不会重投邮件。流行的开源 MTA 会在邮件收到临时失败消息时实施逐次递增的退避时间，和/或降低超大邮件的队列优先级。这意味着，对于实现此类方案的 MTA，灰名单会引入更多的延迟，而这种延迟可能大到成为用户的困扰。

有些客户端根本不重投邮件，这违反了 [SMTP]。这意味着，对于此前未曾见过的源、信封或邮件，无论尝试投递的是哪个客户端，灰名单都会立刻导致彻底的投递失败，本质上是把合法邮件与垃圾邮件同等对待。

如果某个灰名单方案要求数据库记录必须达到一定的存续时长，而不仅仅是检测该记录是否存在于数据库中，同时客户端的重试计划又过于激进，那么该客户端就可能在灰名单所施加的限制之外，另行受到 MTA 的速率限制。

有些 SMTP 实现犯了把所有错误码都当作致命错误的错误，这与 [SMTP] 相悖；也就是说，4yz 应答被当作 5yz 应答处理，邮件被作为不可投递而退回给发件人。这可能导致诸如「因被误认为是拒收而被无意中从邮件列表中移除」之类的后果。

有些客户端会把邮件专有的细节编码进 [SMTP] MAIL 命令的地址参数中。如果这样做导致该参数在多次重试尝试之间发生变化，灰名单实现就可能把它看作一次新的投递而非一次重试，从而不予放行。在这类情形下，邮件将永远无法送达，并会在重试超时到期后退回给发件人。

遭遇灰名单的客户端可能会转向目的域的有序 [DNS] MX 记录集中的下一台主机，并重新尝试投递。这本身带来若干需要考虑之处：

有一些应用会连接到 SMTP 服务器，并模拟一笔事务直至发出 RCPT 命令的那一步，以此确认某个地址是否有效。其中一些是合法应用（例如邮件列表服务器），另一些则是试图探明有效地址以便向其投送垃圾邮件的自动化程序（即「目录收割」攻击，directory harvesting）。灰名单会干扰这两类情形，并对前者造成有害影响。

4.3. 地址空间饱和

显然，灰名单并非避免滥用流量的万无一失的方案。那些恰好以足够高的频率发信、从而使其记录不致过期的不良行为体，在第一次之后就永远不会被这一机制拦下。

在这构成担忧的场合，把灰名单与某种声誉服务相结合会是不错的选择——由该声誉服务对那些未被灰名单功能拦截的 IP 地址评估其可能的行为表现。

5. 建议

基于所汇集的经验，推荐（RECOMMENDED）采用以下实践：

  1. 基于由（IP 地址、RFC5321.MailFrom、第一个 RFC5321.RcptTo）构成的元组来实施灰名单。仅使用第一个 RFC5321.RcptTo 就已足够，因为合法 MTA 看起来不会在多次重试之间重新排列收件人顺序。当 IP 地址是按簇（例如 CIDR 地址块）而非精确匹配时（见下文），纳入 RFC5321.MailFrom 可以提高准确性。在一次成功的重试之后，应允许来自该元组中 IP 地址的所有后续 [SMTP] 流量，而不论其信封信息如何。
  2. 设置一个可配置的时间范围：来自被灰名单主机的重试若落在该范围之内则予以采信，落在范围之外则不予理会。该范围需要覆盖常见 MTA 配置的典型重试时间，从而预期一台功能完整的 MTA 会在该范围开始之后、结束之前的某个时刻发起重试。默认范围应当（SHOULD）为 1 分钟至 24 小时。范围之内的重试被允许并可满足灰名单检验，该客户端因而不再可能是垃圾邮件发送方。范围结束之后的重试应当（SHOULD）就灰名单评估而言被视为一封新邮件（即，重置该 IP 地址的「首次见到」时间戳）。有些站点会把该时间范围的下限设得更高，以匹配常见合法 MTA 的重试超时，但这样做看来不太可能带来额外收益。
  3. 为数据库条目设置超时，超时之后即删除那些近期未产生任何流量的 IP 地址的记录。这一步骤的意图在于：万一某个 IP 地址更换了「所有者」，能够对其重新启用灰名单，使该客户端再经历一轮灰名单。默认值应当（SHOULD）至少为一周。
  4. 对于一个管理管理域（ADMD），[DNS] 中列出的所有入站边界 MTA 应当（SHOULD）共享一个共同的灰名单数据库与共同的灰名单策略。这样可以应对「客户端在收到第一个 4yz 应答后转而向另一台服务器重试」的时序，并让所有服务器共享那份已成功重试过的主机名单。
  5. 为了照顾那些拥有出站邮件服务器集群的发送方，灰名单服务器可以（MAY）跟踪由其自行选定大小的 CIDR 地址块（例如 /24），而不是完整的 IPv4 地址。（不过请注意，对于机器分布在不同网络上的集群，这一启发式规则将不奏效。）如果能够确定邮件服务器的域名，也可以（MAY）基于该域名建立类似的归组能力。
  6. 提供手工覆盖能力，用于添加始终绕过检查的特定 IP 地址或网络地址块。确实存在这样的合法发送方：出于种种原因，它们就是无法很好地应对灰名单，而这些原因大多并不与 [SMTP] 相冲突。此外还有一些高度知名的在线实体（例如电子邮件服务提供商），它们必定会重试；因此，对于其中已知的那些，应当（SHOULD）允许其绕过该过滤。
  7. 对于经过认证的客户端主机，ADMD 的提交服务（见 [SUBMISSION]）不应（SHOULD NOT）施加灰名单。对任何经过认证的 ADMD 会话，也不应施加灰名单。这里的认证可以包含 ADMD 认为适当的任何机制，例如已知的内部 IP 地址、协议级的客户端认证等等。

对于因灰名单延迟而返回的 4yz 码具体应如何选择，本文档没有特定建议。不过按照 [SMTP]，仅有两种合理选择：若实现希望立即终止连接则用 421，否则用 450。某些客户端有可能对不同的 4yz 码作不同处理，但关于使用 421 相较于其他 4yz 码是否特别有利，尚无数据可循。

对于 SMTP 应答中所包含文本（如果有）的选择，同样没有特定建议。一些实现者主张，表明灰名单正在生效会给垃圾邮件软件一个「何时再试即可投递成功」的提示；另一些人则认为这对垃圾邮件软件无关紧要，因而更可能的受众其实是那些希望弄清自己的邮件为何被延迟的合法发送方。

6. 效果度量

在度量灰名单在某个具体部署中的效果时，以下几种技术较为常见：

7. IPv6 适用性

本备忘录所给出的描述与建议，基于在 IPv4 互联网环境中使用灰名单的多年经验，因此它们显然只适用于 IPv4 部署。

IPv6 地址空间更为庞大，这似乎可能使不良行为体的行为方式出现变化，而这很可能意味着需要改变灰名单的应用细节；它甚至可能使采用灰名单的收益荡然无存。至少，它很可能要求为灰名单算法的各项变量作出不同的具体取值。

此外，一个显而易见的考量是：在 IPv6 环境下，用于存储所见全部 IP 地址记录的数据库，其规模很可能会大得多。

8. 安全考虑

本节讨论与灰名单相关的潜在安全问题。

8.1. 权衡取舍

上文的讨论凸显了这样一个事实：尽管灰名单提供了某些显而易见且有价值的防御能力，但它也可能给合法邮件的投递带来非预期的不利后果。在邮件的及时投递至关重要的场合——尤其是金融、交易或安全相关的应用——需要对此类系统可能造成的后果加以审慎考量。

特定的源可以被豁免于灰名单，但这当然意味着，就访问灰名单系统上的邮箱而言，它们拥有了被提升的权限，而心怀恶意者可能设法利用这一点。

8.2. 数据库

作为任何灰名单系统组成部分而必须维护的数据库，会随着其 SMTP 客户端主机多样性的增长而增长；当然，总体而言，它的大小还取决于针对每次投递尝试所存储元组的性质。即便已有记录老化淘汰策略，这样一个数据库仍可能大到干扰承载它的系统，或至少大到使灰名单服务出现降级。此外，知晓所用灰名单方案的攻击者，可能轮换其控制下的 SMTP 客户端的各项参数，试图把数据库膨胀到造成拒绝服务的地步。

实现者可以考虑配置一项适当的失效策略，以便在数据库遭受攻击或因其他原因不可用时，发生某种在本地可接受的处理行为。

在实践中，这一点并未表现为严重的隐患，因为任何合理的老化策略都能有效抑制数据库的增长。尽管如此，此处仍将其作为一项考量列出，因为在某些环境中的某些实现里，这确实可能成为问题。

9. 参考文献

9.1. 规范性参考文献

9.2. 资料性参考文献

附录 A. 致谢（Acknowledgments）

作者谨此感谢 Mike Adkins、Steve Atkins、Mihai Costea、Derek Diget、Peter J. Holzer、John Levine、Chris Lewis、Jose-Marcio Martins da Cruz、John Klensin、S. Moonesamy、Suresh Ramasubramanian、Mark Risher、Jordan Rosenwald、Gregory Shapiro、Joe Sniderman、Roland Turner 与 Michael Wise 对本备忘录所作的贡献。MAAWG 关于灰名单的多场公开会议（Open Sessions）的各位参与者，也是极有价值的贡献者。

作者地址（Authors' Addresses）

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

Phone: +1 415 946 3800
EMail: superuser@gmail.com

Dave Crocker
Brandenburg InternetWorking
675 Spruce Dr.
Sunnyvale, CA 94086
USA

Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
URI: http://bbiw.net