On 2 Mar 2004 at 12:04, Alan J. Flavell wrote about
"[Exim] Re: Bagle, unqualified HELO,":
|...
| (snip technique of delaying RCPT response in certain cases)
|
| As I said yesterday, the delay should probably be larger than 60s, but
| comfortably less than the 300s limit mentioned by the RFC.
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, with no practical benefit.
That led me to think about reducing the smtp_receive_timeout value in
exim.
But from its description, I'm not sure whether it only applies to
receiving SMTP sessions or whether it would also affect waiting for
replies to commands in a sending session. The name and wording seems
to imply the former, but it is somewhat ambiguous.
If it applies to waiting for replies as well as commands, setting it
to a lower value could affect interoperability. Does anyone know for
sure?
- Fred
