Re: [Exim] error response rate limiting vs. overloaded syste…

On Sun, 6 Jul 2003, Greg A. Woods wrote:

> You've missed the key point: "and so that the errant client can't come
> right back at you with another attempt to cause the same error."

"can't"? They most certainly *can*.

Multiprogramming isn't exactly a new idea. If you're so right that an
inactive connection on your mail server is such a tiny use of
resources, which I'm prepared to believe, then presumably the inactive
connection at the spammer's end is also such a tiny use of resources
that they can just carry on and open another dozen - or hundred -
insecure proxies at the same time, and carry on down their list of
addresses?

> If on average the majority of your connections result in errors
> (e.g. the 75% from my well-studied sample machine), and assuming your
> base OS is well designed and implemented, then you could increase the
> maximum number of allowed connections by as much as an order of
> magnitude and still not suffer at all.

And in what way does that not apply to the spammers also? Indeed they
seem to have the use of a semi-infinite number of open proxies to
leverage their action.

When I saw a spammer connecting to our mail server at approx 20 minute
intervals, and churning their way down about three dozen addresses per
call, irrespective of the fact that our mailer was saying, in effect,
"5xx go away you're an open proxy" to every request they made, and
leaving our log full of nuisance rejection entries, I thought it would
be a nice idea to slow them down. In fact, I slowed them down to 4
minutes per RCPT request, i.e a couple of hours per call, but they
still made a fresh connection after about 20 minutes, and another
after 20 minutes again, and at the end of the day they had still
churned their way down the same number of addresses as before, just
that they'd used several simultaneous connections (via different open
proxies) to do it. So we ended up with some half-dozen calls, from
different open proxies - but on looking at the log, evidently coming
from the same prime cause - all churning their way slowly down their
list of addresses, and all getting our 5xx go away responses.

Trying to drop the call was even worse - they'd come right back and
repeat the same addresses over and over and over.

OK, that's just one example. Maybe you think it was atypical.

> You can't go on forever this way of course, because eventually you will
> run out of some OS resource, but in reality you don't have to. I don't
> know if there's some formula based on the size and type of your user
> base or not, but if you have a good feel for the requirements of your
> user base and if you watch your logs and system performance for a trial
> period, it's not hard at all to tune this value such that you don't
> exceed the physical limits of your machine.

I'm not disputing that, but my real worry is whether it's really
achieving anything - since, as you say yourself, the inactive TCP
connection uses very little resource, so presumably it causes the
spammer no more distress that it causes oneself? Indeed less distress
to them, since most of them are using someone else's computers to do
their work.