Thank you for the information.... The change has been made and we will
keep an eye on it to see the result.
On Mon, 2003-09-01 at 04:04, Philip Hazel wrote:
> On Sat, 30 Aug 2003, Stephen Malenshek wrote:
>
> > Over the past week I have been getting ALOT of calls of clients trying
> > to send e-mail to our SMTP servers, which are both running the same
> > configuration, that the connection to the SMTP server is timing out. I
> > the logs on our side, we are seeing the error of 'incomplete transaction
> > (RSET)' on SOME of them. I really have not found a good reason why this
> > is occuring, so obviously I can not figure out how to correct this. I
> > know that this probably can be caused by a wealth of different things,
> > but the strange thing is it is not happening to everyone, and not even
> > in specific areas. Please let me know your thought on what might be
> > causing this. I know I have not included much specific information,
> > because I really do not know what to include. All I do know is I have
> > to get this resolved quickly, I have lost at least 30-40 users this week
> > because of this specific problem. Thanks in advance.
>
> This is just one possibility:
>
> A problem with certain Windows clients was identified and discussed on
> this list last week. It was concerned with the "Nagle algorithm" feature
> of TCP/IP protocol implementations. I happened to be updating the FAQ
> last week, and this is what I added to it:
>
> Q0088: The Windows mailer SENDFILE.EXE somethings hangs while trying to send a
> message to Exim 4, and eventually times out. It worked flawlessly with
> Exim 3. What has changed?
>
> A0088: Exim 4 sets an obscure TCP/IP parameter called TCP_NODELAY. This
> disables the "Nagle algorithm" for the TCP/IP transmission. The Nagle
> algorithm can improve network performance in interactive situations such
> as a human typing at a keyboard, by buffering up outgoing data until the
> previous packet has been acknowledged, and thereby reducing the number
> of packets used. This is not relevant for mail transmission, which
> mostly consists of quite large blocks of data; setting TCP_NODELAY
> should improve performance.
>
> However, it seems that some Windows clients do not function correctly if
> the server turns off the Nagle algorithm. Unfortunately, in the current
> Exim release (4.22), there is no way to change this other than to patch
> the source code. A single line of code in the \(daemon.c)\ module has to
> be removed. Future releases of Exim may provide an option.
>
> Here are further details from the Jonathan Hunter who diagnosed this
> problem, and posted this to the list:
>
> - The Windows mail application in question appears to be somewhat badly
> written, it opens the network socket and immediately sends its HELO without
> waiting for Exim's "220 ESMTP" message.
>
> - When TCP_NODELAY is not enabled (the line of code in question is commented
> out), the Exim server sends "220 ESMTP", waits for an ACK, sends "250
> Hello", then accepts the client's MAIL FROM: command. All goes OK from then
> on.
>
> - When TCP_NODELAY *is* enabled (i.e. Nagle algorithm disabled), the Exim
> server sends "220 ESMTP" and then sends "250 Hello" without waiting for an
> ACK. An ACK for the "220 ESMTP" message then comes in from the Windows
> client, but nothing else arrives after that. It is as if Windows has ignored
> the "250 Hello" message or doesn't want to send an ACK for it.
>
> I am not sure where to point the finger of blame (Windows 2000? The mail
> sending application? The Linux TCP stack??) but either way removing
> TCP_NODELAY got the mail flowing again for us.
