灰名单仍然是防止垃圾邮件的有效方法吗?

neu*_*242 52 email-server smtp spam greylisting

我在我的服务器上使用灰名单已经很多年了,但我不知道现在它有多有效。

在 2012 年对抗垃圾邮件还有好处吗?

或者典型的垃圾邮件发送者 MTA 现在是否能够重新发送列入灰名单的电子邮件?

Mad*_*ter 55

我上次在今年 7 月(2012 年)定量地研究了这一点。7 月份,我的邮件服务器收到了大约 46,000 次投递邮件;其中,大约 1,750 个返回并被灰名单允许通过(并通过了有效的发件人域、SPF 和其他一些非基于内容的测试)。其中,大约另外 1,500 个被我的基于内容的过滤过滤了。

假设那 44,250 封电子邮件是垃圾邮件(因为它们无法通过灰名单,我认为这是一个合理的假设),如果不是灰名单,我的基于内容的过滤将不得不处理 46,000 封邮件而不是 1,750 封。

基于内容的过滤负载增加 25 倍将需要我拥有更强大的 CPU 和更多的内存。由于额外的功耗(可能还有服务器的大小),这反过来又会增加我的每月托管成本。

简而言之,我最后一次计算时,是的,作为完整垃圾邮件过滤系统的一部分,灰名单仍然非常非常有意义。在过去的几周里,我为客户激活了它,所有人都对基于内容的过滤系统负载的减少感到非常满意。

编辑:我注意到我还没有回答关于它是否随着时间的推移变得不那么有效的问题。当我在 2006 年底打开它时,我当时估计它可以过滤掉大约 95% 的垃圾邮件。1,750 占 46,000 的比例约为 4%,因此我的数据表明,在那段时间内它并没有变得不那么有效。

  • 有趣,但我不能直接比较,因为原则上我不会使用任何 RBL 作为收货的明线测试;我只将它们用作 spamassassin 分数的贡献者。我自己经常使用 RBL,出于完全虚假的原因,将我自己的邮件操作委托给其他人的理由。但是,如果我们假设所有这些 XBL 拒绝都来自即发即弃的僵尸网络,那么如果您像我一样首先列入灰名单,您会看到与我相当的百分比。 (7认同)
  • 我认为在您的特定情况下定量地看待这一点很有意义。我刚刚查了一下,我的邮件服务器看到了非常不同的数字:8 月和 9 月的总数,460214 5xx 拒绝,12331 4xx 拒绝和 22665 接受。因此,4.6% 的垃圾邮件被接受,只有 2.6% 的垃圾邮件(最多)被灰名单阻止。5xx 拒绝率由 8.4% 的未知用户和 >90% 的 RBL 主导。(我什至不运行极端激进的 RBL。绝大多数 RBL 块是 [XBL](http://www.spamhaus.org/xbl/)。)再说一次,RBL 捕获的流量永远不会成功到灰名单。 (3认同)
  • 正是我正在寻找的那种答案。谢谢! (2认同)

Chr*_* K. 11

2019 年更新:有条件的灰名单是最好的权衡

在繁忙的邮件服务器上长时间对所有邮件使用灰名单后,我停止了这样做。它不必要地延迟了火腿邮件。这对于带有帐户激活链接的邮件尤其烦人。它会给您需要列入白名单的云邮件程序带来严重问题(详情见下面的答案)。在将所有邮件传递给垃圾邮件过滤器之前将它们列入灰名单的另一个缺点是,学习型垃圾邮件过滤器错过了了解灰名单过滤掉的所有简单垃圾邮件的机会。

我现在没有将所有邮件列入灰名单,而是使用垃圾邮件过滤器(rspamd,我强烈推荐它),它只将垃圾邮件分数介于清除垃圾邮件和清除垃圾邮件之间的邮件列入灰名单。这样,火腿邮件几乎不会延迟。另一方面,当服务器第二次尝试时,进入灰名单的垃圾邮件通常会被检测为垃圾邮件,因为到那时,垃圾邮件通常在黑名单(RBL、URIBL)和模糊过滤器中已知,因此会获得更高的分数。

所以我建议将不清楚是垃圾邮件还是火腿的邮件列入灰名单。时间确实可以帮助垃圾邮件过滤器找出不清楚的情况。

2018 年的原始答案:

我一直是灰名单的忠实粉丝。由于这些原因:

  • 它不仅标记垃圾邮件,还会阻止它。
  • 在德国用作服务提供商是合法的(不像在收到后删除垃圾邮件)
  • 它简单而有效。
  • 它增加了垃圾邮件发送者的负担,而不是您的接收邮件服务器。因此,即使垃圾邮件发送者可能通过您的灰名单,您也迫使他们的机器更加努力地工作,因此他们总共可以发送更少的垃圾邮件。
  • 与基于 IP 的 RBL 等不同,它几乎不会阻止合法邮件。
  • 它引入了延迟,但您可以将频繁联系人的客户端(发送服务器)列入白名单,并将真正需要电子邮件的收件人列入白名单,延迟时间最短。请记住,直接在您的所有邮件上使用 Spamassasin 之类的垃圾邮件过滤器(没有灰名单)也会导致合法邮件的延迟:某些垃圾邮件发送者向您的服务器发送太多邮件,以至于垃圾邮件过滤器过载。因此,它将向进一步传入邮件的发送服务器发送一个临时故障(例如 451)。这会导致与灰名单相同的效果,即邮件延迟,但白名单并不那么容易。当然,您可以使用云垃圾邮件过滤器,该过滤器可根据垃圾邮件发送者的能力进行扩展,但这可能会更昂贵。
  • 需要有限的维护或不需要维护。没有需要随时间更新和更改的黑名单。没有需要更新的基于模式的规则。

但不幸的是,在我的统计数据中,我看到今年,灰名单变得越来越不有效。延迟消息的数量确实相当快地接近灰名单消息的数量,这意味着被阻止的垃圾邮件数量正在减少。

在过去一年(365 天)中,55% 的灰名单消息最终通过灰名单,即 45% 被阻止。

邮报统计年

邮报统计年

请注意,此图表包含一个时间范围,其中由于 mailgraph 的配置错误而未计算灰名单消息,仅计算延迟消息。这意味着这个计算有点高估了延迟的消息,实际上更多的邮件被阻止了。

上个月,64% 被延迟,只有 36% 被阻止。

邮报统计月

邮报统计月

在上周,75% 被延迟,只有 25% 被阻止。

邮报统计周

邮报统计周

此外,查看被阻止的消息总量:本月,灰名单阻止了 4411 条消息,但 Amavisd(spamassasin)阻止了 22763 条消息。这意味着只有 16% 的垃圾邮件被灰名单阻止,其余的都被 amavisd 阻止。

此外,越来越多的云发送提供商从数百个 IP 地址发送。他们尝试从另一个 IP 进行每次传输尝试。因此,灰名单可能会阻止这些邮件甚至几天。因此,您需要将所有“好”邮件提供商列入白名单。这引入了新的维护工作。

我一直是灰名单的忠实粉丝,但遗憾的是,我发现它的效果越来越差,我想我很快就会禁用它,因为它开始只会不必要地延迟 14% 的邮件,而不会阻止大量垃圾邮件.

误导性统计

我(和你)的统计数据中被阻止的邮件数量也可能在很大程度上具有误导性。让我们来看一封来自尚未列入白名单的大型云邮件提供商(如 Microsoft 的 *.outbound.protection.outlook.com)的电子邮件。第一次尝试失败。第二次和第三次传输尝试来自另外两个服务器 (IP),因此再次失败,因为三元组不匹配。现在第四次尝试再次来自第一台服务器并成功。这将计为 1 条延迟传输和 4 条列入灰名单的消息。我上面的计算表明 1/4=25% 的灰名单消息被延迟,3/4=75% 被阻止。但实际上,没有一条消息被阻止。现在我们将这些邮件提供商的服务器列入白名单,这样它们就不会再被列入灰名单。将会发生的情况是,灰名单消息的数量将比延迟消息的数量下降得更多。这意味着我们计算的被阻止消息的数量将会减少。但被阻止的消息较少是不正确的。

事实上,我自 2017 年 2 月以来所做的就是将越来越多的云邮件提供商添加到白名单中,以解决因灰名单而导致的长时间延迟问题。这可以解释(部分?),为什么我计算的被阻止邮件的数量会迅速下降。所以也许,我一直认为灰名单会阻止大量垃圾邮件,但被阻止的垃圾邮件数量一直要少得多,只是计算错误。所以在解释你的统计数据时要小心。


Gry*_*ius 8

垃圾邮件机器人通常仍然不进行消息排队,但其中一些只是将垃圾邮件发送给每个收件人两次,并延迟几分钟以阻止灰名单。此外,如今,来自垃圾邮件机器人的垃圾邮件不再是真正的问题,来自被盗雅虎帐户等的垃圾邮件更难捕获。

从这个角度来看,灰名单并不像以前那样有效。结合其他反垃圾邮件技术,它仍然可以提供帮助,例如,如果您的域经常处于垃圾邮件活动的“第一批”中,灰名单可以帮助将消息延迟足够长的时间,以便域/IP 黑名单赶上,因此如果垃圾邮件会在第一次连接尝试时通过您的过滤器,它可能会在第二次尝试时被检测到。


Pau*_*ear 5

作为一个切线问题,我不喜欢在无法衡量其有效性的情况下部署像灰名单这样的技术。在 Debian 上,使用 postfix 作为 MTA 和 postgrey 作为灰名单策略引擎,你可以apt-get install mailgraph得到一个简单的接受和拒绝邮件的图表。Mailgraph 有点老派,完全独立,但它有效,其数据或技术可以轻松集成到更复杂的现代监控系统中。


归档时间:

查看次数:

11552 次

最近记录:

5 年,9 月 前