2.1. SMTP Transaction Delays

As it turns out, one of the more effective ways of stopping spam is by imposing transaction delays during an inbound SMTP dialogue. This is a primitive form of teergrubing, see: http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html

Most spam and nearly all e-mail borne virii are delivered directly to your server by way of specialized SMTP client software, optimized for sending out large amounts of mail in a very short time. Such clients are commonly known as Ratware.

In order to accomplish this task, ratware authors commonly take a few shortcuts that, ahem, "diverge" a bit from the RFC 2821 specification. One of the intrinsic traits of ratware is that it is notoriously impatient, especially with slow-responding mail servers. They may issue the HELO or EHLO command before the server has presented the initial SMTP banner, and/or try to pipeline several SMTP commands before the server has advertised the PIPELINING capability.

Certain Mail Transport Agents (such as Exim) automatically treat such SMTP protocol violations as synchronization errors, and immediately drop the incoming connection. If you happen to be using such an MTA, you may already see a lot of entries to this effect in your log files. In fact, chances are that if you perform any time-consuming checks (such as DNS checks) prior to presenting the initial SMTP banner, such errors will occur frequently, as ratware clients simply do not take the time to wait for your server to come alive (Things to do, people to spam).

We can help along by imposing additional delays. For instance, you may decide to wait:

• 20 seconds before presenting the initial SMTP banner,

• 20 seconds after the Hello (EHLO or HELO) greeting,

• 20 seconds, after the MAIL FROM: command, and

• 20 seconds after each RCPT TO: command.

Where did 20 seconds come from, you ask. Why not a minute? Or several minutes? After all, RFC 2821 mandates that the sending host (client) should wait up to several minutes for every SMTP response. The issue is that some receiving hosts, particularly those that use Exim, may perform Sender Callout Verification in response to incoming mail delivery attempts. If you or one of your users send mail to such a host, it will contact the Mail Exchanger (MX host) for your domain and start an SMTP dialogue in order to validate the sender address. The default timeout of such Sender Callout Verifications is 30 seconds - if you impose delays this long, the peer's sender callout verification would fail, and in turn the original mail delivery from you/your user might be rejected (usually with a temporary failure, which means the message delivery will be retried for 5 days or so before the mail is finally returned to the sender).

In other words, 20 seconds is about as long as you can stall before you start interfering with legitimate mail deliveries.

If you do not like imposing such delays on every SMTP transaction (say, you have a very busy site and are low on machine resources), you may choose to use "selective" transaction delays. In this case, you could impose the delay:

• If there is a problem with the peer's DNS information (see DNS checks).

• After detecting some sign of trouble during the SMTP transaction (see SMTP checks).

• Only in the highest-numbered MX host in your DNS zone, i.e. the mail exchanger with the last priority. Often, Ratware specifically target these hosts, whereas legitimate MTAs will try the lower-numbered MX hosts first.

In fact, selective transaction delays may be a good way to incorporate some less conclusive checks that we will discuss in the following sections. You probably do not wish to reject the mail outright based the results from e.g. the SPEWS blacklist, but on the other hand, it may provide a strong enough indication of trouble that you can at least impose transaction delays. After all, legitimate mail deliveries are not affected, other than being subjected to a slight delay.

Conversely, if you find conclusive evidence of spamming (e.g. by way of certain SMTP checks), and your server can afford it, you may choose to impose an extended delay, e.g. 15 minutes or so, before finally rejecting the delivery [1]. This is for little or no benefit other than slowing down the spammer a little bit in their quest to reach as many people as possible before DNS blacklists and other collaborative network checks catch up. In other words, pure altruism on your side. :-)

In my own case, selective transaction delays and the resulting SMTP synchronization errors account for nearly 50% of rejected incoming delivery attempts. This roughly translates into saying that nearly 50% of incoming junk mail is stopped by SMTP transaction delays alone.

See also What happens when spammers adapt....