反击式过滤器
2003年8月
（本文最初以讨论过滤开始。该讨论的扩展版本现在作为独立文章So Far, So Good存在。） 通过让贝叶斯垃圾邮件过滤器访问链接查看另一端的内容，我们可能能够提高其准确性。death2spam的Richard Jowsey现在在边界情况下这样做，并报告说效果很好。
为什么只在边界情况下这样做？为什么只访问一次？
正如我在过滤器会杀死垃圾邮件吗？中提到的，访问垃圾邮件中的所有URL会产生一个有趣的副作用。如果流行的邮件客户端这样做是为了过滤垃圾邮件，垃圾邮件发送者的服务器将遭受严重打击。我越想越觉得这是个好主意。这不仅仅是有趣；很难想象还有比这更完美的针对垃圾邮件发送者的反击。
所以我建议那些从事垃圾邮件过滤器工作的人添加一个"惩罚"模式，如果开启，它会访问可疑垃圾邮件中的每个URL n次，其中n可以由用户设置。[1]
正如许多人指出的，当前邮件系统的问题之一是它太被动了。它只是按照你的指示行事。到目前为止，所有修复这个问题的建议似乎都涉及新的协议。这个建议不会。
如果被广泛使用，自动访问的垃圾邮件过滤器会使邮件系统产生反弹。垃圾邮件的巨大数量，到目前为止一直对垃圾邮件发送者有利，现在会反过来伤害他们，就像树枝反弹到他们脸上。自动访问的垃圾邮件过滤器会提高垃圾邮件发送者的成本，降低他们的销售额：他们的带宽使用会飙升，他们的服务器会在负载下崩溃，这会使它们对可能响应垃圾邮件的人不可用。
每小时发送一百万封邮件，你的服务器就会每小时收到一百万次访问。
当然，如果任何URL是"网络臭虫"，它们会向垃圾邮件发送者表明邮件被打开了，可能会导致更多垃圾邮件。（然而，它们也会使"打开率"变得毫无意义，从而剥夺垃圾邮件发送者的宝贵信息。）当然，有些链接会是退订链接。净效应可能是垃圾邮件减少。我们需要确保这只针对可疑的垃圾邮件。一般来说，发送给数百万人的任何URL都可能是垃圾邮件URL，所以提交每封邮件中的每个http请求在几乎所有情况下都能正常工作。但有一些情况不是这样：例如，Yahoo Mail和Hotmail等免费邮件服务发送的邮件底部的URL。
为了保护这些网站并防止滥用，自动访问应该与垃圾广告网站的黑名单相结合。只有黑名单上的网站才会被爬取，而网站只有在经过人工检查后才会被列入黑名单。垃圾邮件的生命周期至少有几个小时，所以应该能够及时更新这样的列表以干扰推广新网站的垃圾邮件。[2]
高容量的自动访问只对高带宽连接的用户实用，但这样的人足够多，足以给垃圾邮件发送者造成严重麻烦。事实上，这个解决方案巧妙地反映了问题本身。垃圾邮件的问题在于，为了接触到少数容易上当的人，垃圾邮件发送者向所有人发送邮件。不容易上当的收件人只是附带损害。但不容易上当的大多数人无法停止收到垃圾邮件，除非他们能够阻止（或威胁阻止）容易上当的人回应它。自动访问的垃圾邮件过滤器为他们提供了这样做的方法。
这能杀死垃圾邮件吗？不完全是。最大的垃圾邮件发送者可能能够保护他们的服务器免受自动访问过滤器的攻击。然而，对他们来说最简单和最便宜的方法是在他们的邮件中包含有效的退订链接。这对小规模垃圾邮件发送者和雇用垃圾邮件发送者推广的"合法"网站来说都是必要的。所以如果自动访问过滤器变得普遍，它们会变成自动退订过滤器。
在这种情况下，垃圾邮件会像操作系统崩溃、病毒和弹窗一样，成为只影响那些懒得使用正确软件的人的瘟疫之一。
注释
[1] 自动访问的过滤器必须跟踪重定向，在某些情况下（例如一个只说"点击这里"的页面）应该跟踪多个级别的链接。还要确保http请求与流行Web浏览器的请求无法区分，包括顺序和引用者。
如果响应在x时间内没有返回，默认为相当高的垃圾邮件概率。
与其让n保持恒定，不如让它成为提到该网站的垃圾邮件数量的函数。这将为滥用和事故提供额外的保护层。
[2] 本文的原始版本使用"白名单"而不是"黑名单"。尽管它们的工作方式像黑名单，但我更喜欢称它们为白名单，因为这可能使它们不太容易受到法律攻击。但这似乎只是让读者感到困惑。
应该有多个黑名单。单一故障点容易受到攻击和滥用。
[6] 我不假装已经想出了这个方案的所有细节。我不能声称确定它会有效。（在实践之前谁能确定呢？）幸运的是，与需要新协议的解决方案不同，这个方案可以在问题的子集上测试。为什么不尝试在，比如说，以A开头的域名上使用FFB？如果垃圾邮件发送者开始避免这样的域名，我们就知道我们正在获胜，我们可以一次一个字母地向下滚动字母表的其余部分。
感谢Brian Burton、Bill Yerazunis、Dan Giffin、Eric Raymond和Richard Jowsey阅读了这篇文章的草稿。
英文版：paulgraham.com/ffb.html｜中文版：HiJiangChuan.com/paulgraham/025-filters-that-fight-back
更新记录：
- 2024-12-27 HiJiangChuan 初稿翻译，术语待验证；