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

Alan J. Flavell wrote:
>
> 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.

I could have clarified here a touch...
Delays during the initial greeting and delays during the response to the
HELO/EHLO command are the ones that were problomatic when the delay was
over 29 seconds (very impatient in my opinion).
As Alan notes, delays during the MAIL FROM, and RCPT TO commands generally
did not cause problems for most 'real' MTA software.

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

This is what I was doing as well, and still do, only I moved away from
forced delays, and have changed most 'drops' to 'denys' in the acl
systems. For my particular circumstances this works better. As does
moving nearly all of the acl deny/drop statements to the RCPT and DATA
acls.

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

Yes I agree, I have things set to give 'prefered service' to those hosts
that have not spammed me, and that have verifyiable information at all
stages of the transaction.

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

Agreed! They could at least wait 90 seconds :p

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

I strongly agree here :)

--

--EAL--