On Mon, 8 Feb 1999, Evan Leibovitch wrote:
> > > unexpected disconnection while reading SMTP data (header) from
> > > smtp2.globalserve.net [209.90.128.7]
> >
> > > Is there *anything* I can do at my end to help this? I already have
> > >
> > > smtp_receive_timeout = 15m
> >
> > Unexpected disconnection is not a timeout (as seen by your host). It
> > means the connection has been closed.
>
> Understood. What is being told to me is that there may be something that
> exim is sending (or not sending) that is causing this to happen.
>
> Someone who is trying to help me fix this is suggesting the possibility
> that exim may be too slow at performing some kind of lookup or
> verification, and that the other side is timing out because of this delay.
Well, according to your log, this is happening during the DATA part of
the transfer. Exim is simply sucking data, looking for a line that
contains just "." which is the terminator. So it really isn't doing much
processing. When it gets that "." it might indeed do some lookups, if
you have header verification set, but the log shows that it is still
trying to read the header data, so it hasn't got that far. What it has
seen so far is a valid SMTP transaction, up to the DATA command, to
which it has sent a "3xx" response.
So, the problem has to be one of:
(a) the 3xx response never reached the sender, so it times out waiting
for it, and on doing so, just closes the connection without sending
anything else down it.
(b) the sender got the 3xx response, but was unable to send the data
for some reason (disc error, program fell over, power cut...)
(c) the sender got the 3xx response, and started sending the data, but
the data got lost. If it was a short message, the entire thing might
have fitted into a single packet, so the sender might be waiting for
the response to "." and time out when it doesn't get it.
(d) the sender got the 3xx response and sent the data, but the message
was corrupted so that Exim doesn't recognize the end of it. This seems
unlikely, since Exim is still in the header-reading phase.
(e) The sender is using pipelining, so it sends off MAIL FROM, RCPT
TO, and DATA all in one go, and then waits for the responses to arrive
back. Exim takes too long to respond (this could be because of
lookups) so it times out on one of them.
(f) No doubt there are other possiblities...
> Is there a level of debugging that will help me figure out the point in an
> SMTP handshake at which the connection is broken? I've had debug set at 9
> but there still isn't sufficient info to help me here.
I would have expected 9 to include all the transaction information.
However, it is clear from the log that the problem is happening in the
data-reading phase.
Can you not get in touch with the postmaster of the sending host and ask
for information about what the problem looks like from their end?
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
--
*** Exim information can be found at
http://www.exim.org/ ***
