灰名单 概念由 Evan Harris 在一份白皮书中提出,网址为:http://projects.puremagic.com/greylisting/。
与SMTP 事务延迟类似,灰名单是一种简单但非常有效的机制,可以剔除通过Ratware传递的消息。其理念是确定消息的发送者和接收者之间是否存在先前的关系。对于大多数合法的邮件,这种关系是存在的,并且投递会正常进行。
另一方面,如果不存在先前的关系,则投递会被临时拒绝(使用 451 SMTP 响应)。合法的 MTA 会相应地处理此响应,并在稍后重试投递[1]。相比之下,ratware 要么会立即重复投递尝试,要么干脆放弃并转移到其地址列表中的下一个目标。
来自投递尝试的三条信息(称为三元组)用于唯一标识发送者和接收者之间的关系
如果投递尝试被临时拒绝,则此三元组会被缓存。它会在给定的时间段内(通常为 1 小时)保持在灰名单中,之后会被列入白名单,并且新的投递尝试将会成功。如果在给定的超时时间(通常为 4 小时)之前没有新的投递尝试发生,则该三元组将从缓存中过期。
如果白名单中的三元组在很长一段时间内(至少一个月,以考虑每月账单之类的)未被看到,则它会过期。这可以防止列表无限增长。
这些超时时间取自 Evan Harris 的原始灰名单白皮书(或者我们应该说,嗯,“灰皮书”?)。有些人发现,在灰名单三元组过期之前可能需要更长的超时时间,因为某些 ISP(例如 earthlink.net)仅每 6 小时或类似时间重试投递一次。[2]
如果您运行多个入站邮件交换器,并且每个交换器都维护自己的灰名单缓存,那么
从给定发件人到您的用户的首次投递理论上可能会延迟最多N倍的初始 1 小时延迟,其中N是邮件交换器的数量。这是因为消息很可能会在与最初发出 451 响应的服务器不同的服务器上重试。在最坏的情况下,发送主机可能不会在 4 小时内,或在灰名单三元组过期之前,重新尝试投递到第一个交换器,从而导致投递尝试一遍又一遍地被拒绝,直到发送者放弃(通常在 4 天左右之后)。
实际上,这种情况不太可能发生。如果投递尝试暂时失败,则发送主机通常会立即使用不同的 MX 重试投递。因此,在一小时后,这些 MX 主机中的任何一个都将接受该消息。
即使三元组已在您的一个 MX 中列入白名单,如果下一个具有相同三元组的消息被传递到不同的 MX,它仍将被列入灰名单。
由于这些原因,您可能希望实施一种解决方案,其中灰名单三元组的数据库在您的入站邮件交换器之间共享。但是,由于托管此数据库的机器将成为单点故障,因此您必须在该机器宕机时采取明智的措施(例如,接受所有投递)。或者您可以使用数据库复制技术,并让 SMTP 服务器回退到其中一个复制服务器进行查找。
根据我自己的经验,灰名单 能够去除大约 90% 的独特垃圾邮件投递,在 应用了先前描述的大部分 SMTP 检查 之后!如果您将灰名单用作第一道防线,它可能会捕获更高比例的入站垃圾邮件。
相反,这种技术几乎不会导致 误报。所有主要的 邮件传输代理 都会在临时故障后执行投递重试,其方式最终将导致投递成功。
灰名单的缺点是,来自过去没有向特定收件人发送过电子邮件的人的合法邮件会受到一小时的延迟(如果您运行多个 MX 主机,则可能延迟数小时)。
另请参阅 当垃圾邮件发送者适应时会发生什么...。
[1] | 尽管很少见,但一些“合法”批量邮件发送者,例如groups.yahoo.com,不会重试临时失败的投递。 Evan Harris 编制了此类发送者的列表,适用于列入白名单:http://cvs.puremagic.com/viewcvs/greylisting/schema/whitelist_ip.txt?view=markup。 |
[2] | 大型站点通常使用多台服务器来处理外发邮件。例如,一台服务器或服务器池可能用于立即投递。如果第一次投递尝试失败,则邮件将移交给已针对大型队列进行调整的备用服务器。因此,来自此类站点的,前两次投递尝试都会失败。 |