> > If enough of their mail bounces, they'll fix it.
>
> That's easily said, but we're currently struggling with a different
> problem (Cisco pix MTU munging) where we're being accused of being
> the ONLY site that cannot send mail to them. So although there is
> even documentary evidence that they are the ones at fault, they don't
> seem interested in fixing it.
Sounds like our sonic wall problem (I haven't verified it's sonic wall, but
I'm pretty sure it is). We can't send email to some domains (aol is one I
think) through this thing. It *DOES* connect and *DOES* write the message
(according to exim -v -M ...) but it never completes after exim says it's
ending the message with final dot.
I'm now seeing the opposite, but it's odd. a 17k email will come through
but a 117k email won't. I've noticed this from some relays. Videotron.ca
comes to mine and critical path.
> My point in posting here was really to address the general issue of
> "if enough mail bounces, they'll fix it" - but if anyone knows a
> really effective solution to this specific problem, we'd be interested
> to have it. I'm sure I once found a page that showed how to set a
> pessimistic MTU for all destinations, but such general breakage of
> one's IP protocol stack isn't really an attractive approach.
Me too. I've been trying to tell them to "remove sonic wall from the
picture" just long enough to test this. They are headstong and won't do
this.
> Several previous threads on the mailing list have addressed this
> problem ("timeout at data close" being the typical observed symptoms)
Exactly.
> but I don't see a comfortable solution that could be applied by the
> other party. I recently hypothesised that using /sbin/route to set a
> host route with a specific MSS might do the trick - and funnily enough
> it did seem to achieve the desired effect at the time, but we've been
> unable to reproduce the success since.
What about incoming email?
--
Lab tests show that use of micro$oft causes cancer in lab animals
