2.1. SMTP 事务延迟

事实证明，阻止垃圾邮件的更有效方法之一是在入站 SMTP 对话期间施加事务延迟。这是一种原始形式的 teergrubing，请参阅：http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html

大多数垃圾邮件和几乎所有通过电子邮件传播的病毒都是通过专门的 SMTP 客户端软件直接传递到您的服务器的，这些软件经过优化，可以在很短的时间内发送大量邮件。此类客户端通常被称为 恶意邮件发送软件。

为了完成这项任务，恶意邮件发送软件的作者通常会走一些捷径，这些捷径，嗯，“偏离” 了 RFC 2821 规范。恶意邮件发送软件的一个内在特征是它非常没有耐心，尤其是在响应缓慢的邮件服务器面前。他们可能会在服务器显示初始 SMTP banner 之前发出 HELO 或 EHLO 命令，和/或在服务器通告 PIPELINING 功能之前尝试 pipeline 多个 SMTP 命令。

某些 邮件传输代理（例如 Exim）会自动将此类 SMTP 协议违规视为同步错误，并立即断开传入连接。如果您碰巧正在使用这样的 MTA，您可能已经在日志文件中看到了许多与此相关的条目。事实上，如果您在显示初始 SMTP banner 之前执行任何耗时的检查（例如 DNS 检查），则很可能会频繁发生此类错误，因为恶意邮件发送软件客户端根本不会花时间等待您的服务器启动（要做的事情，要发送垃圾邮件的人）。

我们可以通过施加额外的延迟来提供帮助。例如，您可以决定等待

• 20 秒，然后再显示初始 SMTP banner，

• Hello（EHLO 或 HELO）问候后 20 秒，

• MAIL FROM: 命令后 20 秒，以及

• 每个 RCPT TO: 命令后 20 秒。

您可能会问，20 秒是从哪里来的？为什么不是一分钟？或者几分钟？毕竟，RFC 2821 规定发送主机（客户端）应等待长达几分钟才能获得每个 SMTP 响应。问题是一些接收主机，特别是那些使用 Exim 的主机，可能会执行 发件人回叫验证 以响应传入的邮件传递尝试。如果您或您的用户之一向这样的主机发送邮件，它将联系您域的 邮件交换器（MX 主机）并启动 SMTP 对话，以验证发件人地址。此类 发件人回叫验证 的默认超时时间为 30 秒 - 如果您施加如此长的延迟，则对等方的发件人回叫验证将失败，反过来，来自您/您的用户的原始邮件传递可能会被拒绝（通常是临时故障，这意味着邮件传递将重试大约 5 天，然后邮件最终退回给发件人）。

换句话说，20 秒是您可以在开始干扰合法邮件传递之前可以拖延的最长时间。

如果您不喜欢对每个 SMTP 事务都施加此类延迟（例如，您的站点非常繁忙且机器资源不足），您可以选择使用 “选择性” 事务延迟。在这种情况下，您可以施加延迟

• 如果对等方的 DNS 信息存在问题（请参阅 DNS 检查）。

• 在 SMTP 事务期间检测到一些问题迹象后（请参阅 SMTP 检查）。

• 仅在您的 DNS 区域中编号最高的 MX 主机中，即优先级最低的邮件交换器。通常，恶意邮件发送软件 专门针对这些主机，而合法的 MTA 将首先尝试编号较低的 MX 主机。

事实上，选择性事务延迟可能是结合我们将在以下部分讨论的一些不太确定的检查的好方法。您可能不希望完全根据例如 SPEWS 黑名单 的结果拒绝邮件，但另一方面，它可能提供足够强烈的麻烦迹象，至少您可以施加事务延迟。毕竟，合法的邮件传递不受影响，只是会受到轻微的延迟。

相反，如果您发现垃圾邮件的决定性证据（例如，通过某些 SMTP 检查），并且您的服务器可以承受，您可以选择施加更长的延迟，例如 15 分钟左右，然后在最终拒绝传递 [1]。这几乎没有任何好处，除了稍微减慢垃圾邮件发送者在 DNS 黑名单和其他协作网络检查赶上之前尽可能多地接触到人的速度。换句话说，纯粹是您的利他主义。 :-)

就我个人而言，选择性事务延迟和由此产生的 SMTP 同步错误占被拒绝的入站传递尝试的近 50%。这大致意味着，仅通过 SMTP 事务延迟就阻止了近 50% 的入站垃圾邮件。

另请参阅 当垃圾邮件发送者适应时会发生什么...。