On 4 Mar 2004 at 11:09, Chris Edwards wrote about
"Re: [Exim] Re: Bagle, unqualified H":
| 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.
|
| It too am confused about sending and receiving here.
|
| The above implies a mercury sending client wouldn't wait for your (exim?)
| server imposing a 90s delay.
That's right. It timed out sooner than that. An important point: I
believe the timeout is a configurable option in Mercury/32, so what I
was observing was just how DH chose to configure the server for a
mailing list I am on. I don't know what the timeout defaults to
OOTB.
The problem is that a single option sets *all* timeouts. There is no
capability to set shorter timeouts where they are needed to minimize
DDoS attacks that use up socket resources, and longer ones where they
are needed for interoperability.
That's what made me look into the situation with exim.
smtp_receive_timeout *sounds* like it may be appropriately selective,
but I'm not sure. So far, seems like nobody else is either...
| | 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, with no practical benefit.
|
| But this implies a mercury server won't be willing to wait for its
| clients.
|
| How long does DH think a server _should_ wait, if it wishes to avoid
| "trivial DDoS" ?
DH commented that he was considering reducing the timeout on the list
server to 20 seconds. He is of the opinion that more and more mail
servers will implement similarly reduced timeouts. His opinion may
be colored by the fact that he was the victim of a substantial DDoS
attack recently...
BTW, an example the type of DDoS attack David was talking about is
that each zombie simply opens a connection to the target server and
never sends a command. Rinse and repeat when the target server
closes the socket. If the recipient holds each socket open for five
minutes, it would be very easy for the attacker's army of zombies to
consume all the available sockets (and/or process slots) on the
target machine.
- Fred
