Re: [Exim] Delay 220 greeting to reduce spam?

On Tue, 1 Jun 2004, Edgar Lovecraft wrote:

> Mike Bacher wrote:
> >
> > Is there a way to make exim delay giving the initial 220 greeting for an
> > arbitrary amount of time (say, 40 seconds or so)? The idea is that most
> > spamware will give up after 30 seconds (most are quite impatient from
> > what I've read) and move on to the next host. Others that have
> > implemented it on their MTAs have seen good results with this method.
[...]
> However, you should note that there is a bunch of MTA software whos
> developers seem to think that 30 sec is long enough to wait, and they drop
> the connection if they have not seen the greeting by then.

I don't know about delays before the initial greeting, but we've been
having reasonable results from running a delay in the course of the
RCPT TO stage.

What we're doing is to collect various indications of a suspicious
sending MTA which are not in themselves bad enough to cause us to
reject outright (lack of bothway DNS lookup; use of an unqualified
string in the HELO greeting; IP listed as a dialup in dnsRBLs etc.);
and then we throw a delay. This gets rid of a fair proportion of
viruses, as well as some proportion of spam, and at relatively low
cost compared with proceeding to the spamassassin stage.

Most bona fide mails are unaffected by this behaviour, since they
don't trigger any of the above reasons for suspicion. The procedure
brought good results and I'm not aware of genuine mail being affected.
At the time I introduced it, I did some rough and ready statistics to
see which of the various indicators of suspicion were worth including
in the test, and which weren't; but the selection can easily be
reconfigured in the ACL.

> I did have good success with various delays, but I finally turned
> them off as I got tired of educating other MTA admins that the RFC's
> recomend 5 minutes :P

It's fair comment that this is only a recommendation by the RFC and in
no way mandatory. But a delay which is somewhat over 60sec (while
still being well short of 5mins) at the RCPT TO stage seems to be OK;
if your sender is giving up at 30-40sec then they would seem to be
unreasonably impatient!

Now sure, if this technique became widespread then the spammers would
have to respond by simply raising their timeouts, and then we'd need
to look for some different solution. But for the time being, the
procedure seems to be doing a reasonable job for us. But optimised by
the fact that if the offering MTA doesn't raise our suspicions, we
don't try the delay (we hope for our various other blended defences to
keep the nasties out).

good luck

[I should stress the usual warning that one should NOT insert
deliberate delays at the DATA phase.]