428 lines
9.1 KiB
HTML
428 lines
9.1 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>SMTP Transaction Delays</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
REL="HOME"
|
|
TITLE="Spam Filtering for Mail Exchangers"
|
|
HREF="index.html"><LINK
|
|
REL="UP"
|
|
TITLE="Techniques"
|
|
HREF="techniques.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="Techniques"
|
|
HREF="techniques.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="DNS Checks"
|
|
HREF="dnschecks.html"></HEAD
|
|
><BODY
|
|
CLASS="section"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>Spam Filtering for Mail Exchangers: </TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="techniques.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
>Chapter 2. Techniques</TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="dnschecks.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><H1
|
|
CLASS="section"
|
|
><A
|
|
NAME="smtpdelays"
|
|
></A
|
|
>2.1. SMTP Transaction Delays</H1
|
|
><P
|
|
> 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
|
|
<EM
|
|
>teergrubing</EM
|
|
>, see: <A
|
|
HREF="http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html"
|
|
TARGET="_top"
|
|
>http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html</A
|
|
>
|
|
</P
|
|
><P
|
|
> 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
|
|
<A
|
|
HREF="gloss.html#ratware"
|
|
><I
|
|
CLASS="glossterm"
|
|
>Ratware</I
|
|
></A
|
|
>.
|
|
</P
|
|
><P
|
|
> In order to accomplish this task, ratware authors commonly take
|
|
a few shortcuts that, ahem, <SPAN
|
|
CLASS="QUOTE"
|
|
>"diverge"</SPAN
|
|
> 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
|
|
<B
|
|
CLASS="command"
|
|
>HELO</B
|
|
> or <B
|
|
CLASS="command"
|
|
>EHLO</B
|
|
> command
|
|
before the server has presented the initial SMTP banner, and/or
|
|
try to pipeline several SMTP commands before the server has
|
|
advertised the <B
|
|
CLASS="command"
|
|
>PIPELINING</B
|
|
> capability.
|
|
</P
|
|
><P
|
|
> Certain <A
|
|
HREF="gloss.html#mta"
|
|
><I
|
|
CLASS="glossterm"
|
|
>Mail Transport Agent</I
|
|
></A
|
|
>s (such as Exim) automatically
|
|
treat such SMTP protocol violations as
|
|
<EM
|
|
>synchronization errors</EM
|
|
>, 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
|
|
<A
|
|
HREF="dnschecks.html"
|
|
>DNS checks</A
|
|
>) 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).
|
|
</P
|
|
><P
|
|
> We can help along by imposing additional delays. For instance,
|
|
you may decide to wait:
|
|
</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
> 20 seconds before presenting the initial SMTP banner,
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> 20 seconds after the Hello (<B
|
|
CLASS="command"
|
|
>EHLO</B
|
|
> or
|
|
<B
|
|
CLASS="command"
|
|
>HELO</B
|
|
>) greeting,
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> 20 seconds, after the <B
|
|
CLASS="command"
|
|
>MAIL FROM:</B
|
|
>
|
|
command, and
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> 20 seconds after each <B
|
|
CLASS="command"
|
|
>RCPT TO:</B
|
|
> command.
|
|
</P
|
|
></LI
|
|
></UL
|
|
><P
|
|
> 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 <A
|
|
HREF="smtpchecks.html#callback"
|
|
>Sender Callout Verification</A
|
|
> in
|
|
response to incoming mail delivery attempts. If you or one of
|
|
your users send mail to such a host, it will contact the <A
|
|
HREF="gloss.html#mx"
|
|
><I
|
|
CLASS="glossterm"
|
|
>Mail Exchanger</I
|
|
></A
|
|
> (MX host) for your domain and start an SMTP
|
|
dialogue in order to validate the sender address. The default
|
|
timeout of such <A
|
|
HREF="smtpchecks.html#callback"
|
|
>Sender Callout Verification</A
|
|
>s 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).
|
|
</P
|
|
><P
|
|
> In other words, 20 seconds is about as long as you can stall
|
|
before you start interfering with legitimate mail deliveries.
|
|
</P
|
|
><P
|
|
> 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
|
|
<SPAN
|
|
CLASS="QUOTE"
|
|
>"selective"</SPAN
|
|
> transaction delays. In this case, you
|
|
could impose the delay:
|
|
</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
> If there is a problem with the peer's DNS information (see
|
|
<A
|
|
HREF="dnschecks.html"
|
|
>DNS checks</A
|
|
>).
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> After detecting some sign of trouble during the SMTP
|
|
transaction (see <A
|
|
HREF="smtpchecks.html"
|
|
>SMTP checks</A
|
|
>).
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> Only in the highest-numbered MX host in your DNS zone,
|
|
i.e. the mail exchanger with the last priority. Often,
|
|
<A
|
|
HREF="gloss.html#ratware"
|
|
><I
|
|
CLASS="glossterm"
|
|
>Ratware</I
|
|
></A
|
|
> specifically target these hosts,
|
|
whereas legitimate MTAs will try the lower-numbered MX hosts
|
|
first.
|
|
</P
|
|
></LI
|
|
></UL
|
|
><P
|
|
> 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 <A
|
|
HREF="dnschecks.html#dnsbl"
|
|
>blacklist</A
|
|
>, 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.
|
|
</P
|
|
><P
|
|
> Conversely, if you find conclusive evidence of spamming (e.g. by
|
|
way of certain <A
|
|
HREF="smtpchecks.html"
|
|
>SMTP checks</A
|
|
>), 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
|
|
<A
|
|
NAME="AEN632"
|
|
HREF="#FTN.AEN632"
|
|
><SPAN
|
|
CLASS="footnote"
|
|
>[1]</SPAN
|
|
></A
|
|
>.
|
|
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. :-)
|
|
</P
|
|
><P
|
|
> 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.
|
|
</P
|
|
><P
|
|
> See also <A
|
|
HREF="qanda.html#qanda-adapt"
|
|
><EM
|
|
>What happens when
|
|
spammers adapt...</EM
|
|
></A
|
|
>.
|
|
</P
|
|
></DIV
|
|
><H3
|
|
CLASS="FOOTNOTES"
|
|
>Notes</H3
|
|
><TABLE
|
|
BORDER="0"
|
|
CLASS="FOOTNOTES"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="5%"
|
|
><A
|
|
NAME="FTN.AEN632"
|
|
HREF="smtpdelays.html#AEN632"
|
|
><SPAN
|
|
CLASS="footnote"
|
|
>[1]</SPAN
|
|
></A
|
|
></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="95%"
|
|
><P
|
|
> Beware that while you are holding up an incoming SMTP
|
|
delivery, you are also holding up a TCP socket on your
|
|
server, as well as memory and other server resources. If
|
|
your server is generally busy, imposing SMTP transaction
|
|
delays will make you more vulnerable to Denial-of-Service
|
|
attacks. A more <SPAN
|
|
CLASS="QUOTE"
|
|
>"scalable"</SPAN
|
|
> option may be to
|
|
drop the connection once you have conclusive evidence that
|
|
the sender is a ratware client.
|
|
</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="techniques.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="dnschecks.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>Techniques</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="techniques.html"
|
|
ACCESSKEY="U"
|
|
>Up</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>DNS Checks</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |