>> [...]
>> Snooping the traffic makes me think something odd is going on.  It
>> looks a bit like the won't-frag disease, the problem outlined in
>> RFC2923 section 2.1, but it's not that simple.
> this is exactly the symptom with path MTU discovery problem

Yes, but I find that implausible in this case; see below.

> provider mailbox
>   |
> some router	<--- bad guy
>   |
> DSL entrypoint
>   | smaller MTU
> DSL exitpoint
>   |
> your client

I find this implausible because the top four points would be the same
if I were using the provider-provided software on Wintel - and anything
that broke mail fetching for that crowd would be fixed approximately
instantly.  (However, the provider's mailhost *does* appear to be
trying to do PMTU-D; the packets I do see have DF set.)

I have it fixed in a functional sense.  I have been completely
unsuccessful at finding out what's happening to the missing packets;
however, setting net.inet.tcp.mss_ifmtu=1 with sysctl makes the symptom
vanish.  Looking at before-and-after tcpdump output leads me to suspect
that the mailhost is paying attention to the advertised MSS but isn't
correctly handling PMTU-D right if the advertised MSS is higher than
the actual path MSS.  Unfortunately I have no way of sniffing anywhere
along the path except between the DSL box and my border host, or I
would be trying to see if that _were_ the problem, as outlined in
RFC2923.

I'm considering adding a sysctl to put a cap on advertised TCP MSS
values regardless of interface MTUs; I can't see any way at present to
make it advertise a value less than that appropriate for the outgoing
interface's MTU.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B