------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1386
Todd Lyons <tlyons@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tlyons@???
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #1 from Todd Lyons <tlyons@???> 2013-09-21 16:33:34 ---
You almost certainly are sending to a site and pMTUD (path MTU Discover) is
broken between the two of you. Typically this means that one or the other side
is blocking all ICMP instead of just the few types of ICMP that are bad or leak
information. Less typical (never in my experience) is that it's somewhere
in-between. It has always been a firewall on one end or the other.
Fortunately for you, *nix provides a simple tool which can discover the MTU of
a path, but only if ICMP is functioning properly from end to end.
tracepath -n tar.get.ip.address
Go to
http://packetlife.net/blog/2008/aug/18/path-mtu-discovery/ for more info,
which shows a sample session where it starts at the system default (1500) and
then "discovers" the maximum packet size that can be passed.
You can also have a remote site do pMTU testing for both you and the place you
are trying to send to:
http://wand.net.nz/pmtud/ Sometimes, third party views
of the situation will do more to tell you what is going on than you testing
from your site.
In the end, this is not an exim problem, but a networking problem. Exim
properly detected that it did not receive the 250 OK from the remote site.
Whether this is due to the ICMP packet coming back from that remote site to
indicate reduced MTU getting dropped (most likely by your firewall), or if it's
due to the remote side simply hanging and never responding, either way, Exim
timed out and closed things down on your side, and queued the message for retry
later.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
