RE: [Exim] Read timeout - Socket options changed in Exim 4?

Hi All,

First of all thanks to Philip for responding quickly and courteously; and
apologies to those of you whose MUAs barfed on my original message.

A summary of the problem and solution follows.

> We recently upgraded from Exim 3.32 to 4.22, and since the upgrade we have
> noticed failures with certain clients using a Windows mailer,
SENDFILE.EXE.
>
> The symptoms are that sometimes (but not always!) the client will hang
whilst
> trying to send its message and will eventually time out, having failed to
send
> anything.

Exim v4 sets the TCP_NODELAY socket option by default, whereas Exim v3 does
not. Commenting out this line of code in src/daemon.c "fixed" it, and Exim
v4 now accepts connections from these Windows clients.

I'm still not 100% sure why this is so, but from packet traces the following
was observed:

- 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.

Philip has said he will add this to the FAQ, so hopefully others will be
saved the pain of figuring out the above themselves..

Regards,

Jonathan