Author: W B Hacker Date: To: exim users Subject: Re: [exim] SMTP connection lost
David Woodhouse wrote: > On Thu, 2010-08-12 at 21:17 -0400, W B Hacker wrote:
>> Grep the list archives. ISTR an issue two or more years ago wherein some (many?)
>> broadband providers were - in essence - 'stealing' bytes for one overhead reason
>> or another, AND ICMP was now-and-then firewalled (or ignored?), so the hosts
>> could not negotiate a mutually useful MTU size - at least for anything that
>> needed a full MTU (HELO and other basic 'handshakes' would not, but headers
>> probably would, 'DATA' almost always would do...).
>>
>> Not (exclusively) an Exim issue - it's 'sub-optimal' configuration of the
>> underlying TCP/IP...
>
> I wouldn't describe that as 'sub-optimal' -- even with the quotes. It's
> broken, plain and simple.
ACK. And probably still is .. (a high-roller apart-hotel on the Peak in Hong Kong).
Solution for the client involved was to use our webmail interface for the
portion of their year resident there.
That approach is probably no use at all to the OP, however..
>
> If ICMP is filtered and you can't ping the host you're trying to
> communicate with, then all bets are off. Thinks might *look* like they
> work at first glance, but they're quite likely to be broken.
>
> If you're trying to diagnose any kind of network issue and ICMP is not
> getting through, then fix that before attempting to do *anything* else.
>
> (It *is* possible to filter only certain types of ICMP, so connectivity
> is only mildly broken and TCP connections actually work OK. But most
> people clueless enough to filter ICMP at all are also clueless enough to
> get that wrong.)
>
ACK - and the point to keep in mind is that it was(is?) the broadband provider -
connectivity or in-building distribution/firewalling - not the server
operator(s) that are doing the damage in this and several similar cases.
That said, it is also a (hopefully) rare situation wherein an MTA is being run
on such facilities.