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
.
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....