On 4 Mar 2004 at 13:22, Edgar Lovecraft wrote about
"Re: [Exim] Re: Bagle, unqualified H":
| Fred Viles wrote:
| ..[snip]...
| >
| > 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...
| >
| No ambiguity here, the manual is quite clear that smtp_recieve_timeout is
| for all forms of SMTP input.
That could just mean batch as well as TCP, and "SMTP reception" could
mean "receiving a message via SMTP" as opposed to "reading a
character from TCP". Also, it defines "SMTP input" as "SMTP command"
or "SMTP data line". Is a command *response* one of those?
In any case, a review of the source shows you are right.
smtp_receive_timeout is applied to every read from the socket,
regardless of context. So it can be set no shorter than the longest
delay you want to be able to accomodate. Too bad...
| This is what an OOTB sendmail installation has for timeouts, I used to
| tweak these back when I used sendmail all the time, and I for one would
| like (not absolutly neccesary) to be able to tweak these in exim, some
| we already can, others we cannot.
|...
I hadn't given the topic of timeouts any consideration before now.
But now that I have I agree that timeout handling seems to be a
weakness in exim (at least as of 4.22). IMO there should be some
higher level knobs.
I don't think there needs to be as many as sendmail has, but as it
stands there is effectively no limit on how long a malicious sender
can tie up an exim socket. They get a fresh five minute timeout
*per* *byte*. The smtp_receive_timeout knob seems pretty useless to
me, since it has to be set reasonably high for interoperability.
Philip, have you been reading this thread? What do you think?
- Fred
