Author: Alan J. Flavell Date: To: Kevin P. Fleming CC: Exim users list Subject: Re: [Exim] Idea to slow down spammers
On Tue, 29 Apr 2003, Kevin P. Fleming wrote:
> This is already being done, check the list archives for "teergrube".
> There are ACL recipes to get Exim to delay its responses to the sending
> server.
Yes, but all the recipes that I have seen involve delaying for a
period less than 5 minutes, and then sending the response. I don't
know a way of spinning out the response beyond that, or the spammer
will assume the peer is no longer responding and will disconnect.
The classic teergrube works by sending continuation lines at
intervals: that way, you can spin out the response in units of a few
minutes (less than the 5 minute timeout, I mean) for an hour or more.
If there's a way to do that from exim, then I'm afraid I must have
missed it.
OK, sure, if they probe let's say two dozen addresses per invocation,
then delaying 4 minutes on each RCPT will last around an hour and a
half; but a classic teergrube could delay each RCPT TO by an hour or
more, and you could spin out the whole series for a day or more, if
you wanted.
> I have my server set up this way,
Which way, exactly, please?
> and it occasionally keeps a
> spammer connected for nearly ten minutes while try their stupid
> dictionary attacks.
Hmmm, I found that delaying by more than 5 minutes would result in
the peer assuming that we were no longer responding, so they would
disconnect. (Some of them would then go and hassle our secondary MX,
but that's another story...). I suppose I could have missed some
proportion who set their timeout to be longer...?
But as I say, the key to a real teergrube seems to be the ability to
send a response as a series of continuation lines, separated by
delays of a few minutes (less than 5). And I don't know how to do
that with exim.
Another point. The dictionary scanners whose behaviour I had been
watching would still start a fresh series of probes on-schedule (at
intervals of typically 20-30 minutes) even if we were still delaying
our response to their previous series, so I'm a bit concerned that if
we took this too far, we might be setting ourselves up for a
denial-of-service attack.
