Philip Hazel writes:
> On Mon, 19 Apr 1999, david sims wrote:
>
> > woohoo! it's working! I finally figured out that I had to make two
> > changes in config.h.defaults:
> >
> > #define DELIVER_IN_BUFFER_SIZE 512 /* was set to 8192 */
> > #define DELIVER_OUT_BUFFER_SIZE 512 /* was set to 8192 */
> >
> > Then I recompiled, and my mail started going out to mail.earthlink.net
> > again.
>
> My goodness. That seems extremely odd. The first of those specifies the
> size of the buffer Exim uses to read the message off its spool. I can't
> believe that can have any effect. The second is the size of buffer it
> uses when actually write()-ing the message down the TCP/IP connection. I
> guess that could affect the size of packet used. Maybe with large
> buffers it is splitting up into multiple packets and the other end isn't
> handling these right? As far as I know, nobody else has ever reported a
> problem with the default settings.
I haven't followed the thread but these symptoms smell like an
all-too-common problem where some firewall or router between him and
his destination wrongly drops all ICMP packets. This breaks the
"Path MTU discovery" system used by most modern TCP implementations
and causes symptoms where small packets get through but large ones
don't. Users normally see it in terms of "when I ftp small files I
can download them but when I try to get large files the connection
hangs". What's happening is that the client sends larger and larger
packets with the "Don't Fragment" bit set so that, when the maximum
MTU is reached, it'll get back an "ICMP Frag Needed" packet and thus
know the optimum MTU. If some idiot has configured a firewall or
router wrongly and drops all ICMP on the floor then the "ICMP Frag
Needed" never arrives and the client thinks the packet has just
been a random drop and keeps resending.
--Malcolm
--
Malcolm Beattie <mbeattie@???>
Unix Systems Programmer
Oxford University Computing Services
--
*** Exim information can be found at
http://www.exim.org/ ***
