Re: [Exim] Re: Bagle, unqualified HELO, time delays

On Wed, 3 Mar 2004, Fred Viles wrote:

> This raises an interesting point. RFC2821 says a 5 minute timeout is
> a SHOULD, not a MUST. It turns out that at least one legitimate MTA
> (Mercury/32) does not wait that long. With a 90 second delay
> introduced, it gave up trying to send.
>
> I've just had an interesting conversation with Mercury/32's author,
> David Harris, about the wisdom of following the RFC timeout
> recommendations. He pointed out that waiting five minutes for
> commands from a sender exposes a receiving MTA to a trivial DDoS
> attack,

I'm not sure that I agree. If an MTA is so easy to compromise with a
DDoS attack, then consider senarios such as this, assuming that the
receiving MTA is applying even minimal checks to the incoming calls:

1. establish multiple calls from IP(s) whose DNS lookup results in a
timeout.

2. assuming that exim's "verify = sender" or equivalent is used (no
callout required!), offer envelope sender address(es) which result in
DNS timeouts.

- and so on. One or more of these strategies will delay the receiving
MTA for perhaps a minute or so. If it can't cope with that, you have
your DDoS already.

> with no practical benefit.

I have to say that shrugging off a nontrivial fraction of spam and, it
now seems, viruses too, seems to me like a "practical benefit". At
the moment it seems that bona fide mail is a dwindling small fraction
of the traffic which our mailer is called upon to deal with, and
anything which results in a low-fat reduction of the unwanted traffic
is good, in my book.

Spamassassin and anti-virus tools are all very well in their way, but
they *do* consume significant computing resources, whereas a process
quietly dozing in the background seems relatively harmless. Every
time our server has broken out in a sweat, it's been clear that what's
keeping it busy are the IMAP sessions from its users - not the SMTP
sessions from remote MTAs.

Don't forget to set a sensible value for smtp_accept_max_per_host

Over and above that, I would mention that an arbitrary sender cannot
simply create these sleeping processes on our MTA at their own behest.
They'd have to get past the various low-fat blacklistings, and fulfil
various other criteria, before we decide to award them the Order of
the Long Wait ;-)

Finally, I did some tests last night and it seems that this particular
engine (i.e Bagle) is always producing a triple of SMTP calls, and
then gives up. The timestamps of this triple are not very accurately
spaced, but from the typical 20-40sec intervals between them, my
explanation of what the engine is doing is that it times out after
perhaps 20 seconds and immediately starts retrying. After trying
three times it gives up.

So, in the present incident it seems that even a delay of 30s is
adequate to shrug it off (although one has to respond to three of them
before they're done). But - as our delays are shrugging off other
kinds of malefactor too - I'm leaving the timeout at its present
setting, which, as I say, is above 60s but well clear of the
RFC-suggested max of 5 minutes. Remember, this is only applied to a
limited category of callers who have not been outright rejected but
have already triggered cause for suspicion. Most bona fide senders
would remain unaffected by it.

Hope that's useful.