On 20 Jan 2003, Sean Burford wrote:
> Exim is secondary MX for a Netscape Messaging Server (4.15p7).
> Messaging Server outputs the 550 message and drops the connection
> immediately after any message data line that is longer than 1024
> characters. Exim was then delaying all messages to the server, as per
> the RFC, because it didn't seem to notice the 550 but did notice the
> dropped connection.
If Exim is in the middle of sending a message, it won't be expecting to
receive a 550. That should not be sent until after the client has sent
the terminating "." line. So Exim won't be looking for input; what it
probably sees is a write error when trying to send the next block of
data. As documented in 42.2, this is treated as a host error, which will
indeed delay all messages to that host.
If the server had instead just swallowed the rest of the message and
returned 550 at the correct time, the behaviour would have been
different. It would also have been different if the connection drop
happened after the final '.' - that is treated as a message error.
> My patch for delaying the message that was being sent when the
> connection dropped, rather than the whole queue for that host, is
> attached. A better way to handle this would be to notice the 550 and
> bounce the message, or to have a configurable limit on envelope and data
> line lengths in Exim.
As I pointed out, the 550 is not expected in the middle of a message.
Exim does cope with various kinds of anomalous MTA behaviour, but I'm
afraid I'm not imaginative enough to think of all the weird and
wonderful ways programs can violate the RFCs.
I suppose I could tighten it up to check for input while it is sending
the body of the message, but because of buffering considerations (Exim
sends messages in 8K buffers) I'm not really convinced that this will
actually be of any use.
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
