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

On Thu, 4 Mar 2004, Fred Viles wrote:

> | - 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.
>
> So your point is that as long as any DDoS vulnerability exists, it
> doesn't matter how many of them there are?

Let's not get carried away with that kind of rhetoric, please.

The fact is - merely by operating a mail server, one exposes oneself
to possible DDoS attacks of various kinds. What we're discussing here
however is a matter of scale.

You already concede, I think, that an offering MTA is going to need to
be willing to wait some tens of seconds for a response if it's to be
successful as an MTA. The RFC, as we know, recommends that it should
be willing to wait 300 seconds - I'm not trying to spin the delay out
to even a half of that.

As I see it, there's only a modest factor between our bargaining
positions.

> | > 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".
>
> I have apparently not made myself clear.
>
> The timeouts that carry the DDos risk without a corresponding benefit
> are not the ones your trick takes advantage of.

Then maybe you want to talk about the benefits of decoupling the
timeout settings for different phases of the protocol?

> They are the timeouts on a receiving server waiting for a next
> command from a sending server.

Well, I'm talking, as it seems you are aware, about the sending
server's timeouts on waiting for a response from the receiving server.
In particular, at the RCPT stage.

Based on experience of manual checks against remote MTAs, I'm quite
accustomed to seeing delays of several tens of seconds at this stage,
even when the outcome is successful. Seems to me that someone who
attempted to run an MTA with a limit set to 20seconds (a value that
was mentioned elsewhere on this thread) would be responsible for a
massive rate of temporary failures and unproductive retries even of
bona fide requests - which itself would be an abuse of the system.

best regards