Re: Mozilla-0.9.9-1: strange mail problem
Hi,
On Mit, 2002-03-27 at 08:03, joel.soete@freebel.net wrote:
> Last Saterday, I tried to send a simple patch ascii text as an attachment to
> xfce maintainer.
> I waited well an half hour before have to cancel [Delivrering mail] boxe. Sent
> mail again,... no more succes??
> I try severall think (check read right on file, create a new mail,...) and
> finally replaced the text by its compressed (gzip) form and the mail was then
> sent in the few seconds. (the file size was about 10k, compressed 2k)
Found this is in the exim faq [http://www.exim.org/FAQ.html#SEC22],
especially answer C is a common problem:
----------------------------------------------------------------------------
Q0021: Whenever Exim tries to deliver a specific message to a particular
server, it fails, giving the error "Remote end closed connection after
data" or "Broken pipe" or a timeout. What's going on?
A0021: "Broken pipe" is the error you get on some OS when the far end
just drops the connection. The alternative is "connection reset by
peer".
(A) There are some firewalls that fall over on \0 characters in the
mail. Have a look, e.g. with hexdump -c mymail | tail to see if your
mail contains any binary zero characters.
(B) There are broken SMTP servers around that just drop the connection
after the data has been sent if they don't like the message for some
reason (e.g. it is too big) instead of sending a 5xx error code. Have
you tried sending a small message to the same address?
It has been reported that some releases of Novell servers running NIMS
are unable to handle lines longer than 1024 characters, and just close
the connection. This is an example of this behaviour.
(C) If the problem occurs right at the start of the mail, then it could
be a network problem with mishandling of large packets. Many emails are
small and thus appear to propagate correctly, but big emails will
generate big IP datagrams.
There have been problems when something in the middle of the network
mishandles large packets due to IP tunnelling. In a tunnelled link, your
IP datagrams gets wrapped in a larger datagram and sent over a network.
This is how virtual private networks (VPNs), and some ISP transit
circuits work. Since the datagrams going over the tunnel require a
larger packet size, the tunnel needs a bigger maximum transfer unit
(MTU) in the network handling the tunnelled packets. However, MTUs are
often fixed, so the tunnel will try to fragment the packets.
If the systems outside the tunnel are using MTU path discovery, (most
Sun Sparc Solaris machines do by default), and set the DF (don't
fragment) bit because they don't send packets larger than their local
MTU, then ICMP control messages will be sent by the routers at the ends
of the tunnel to tell them to reduce their MTU, since the tunnel can't
fragment the data, and has to throw it away. If this mechanism stops
working, e.g. a firewall blocks ICMP, then your host never knows it has
hit the maximum path MTU, but it has received no ACK on the packet
either, so it continues to resend the same packet and the connection
stalls, eventually timing out.
You can test the link using pings of large packets and see what works:
ping -s host 2048
Try reducing the MTU on the sending host:
ifconfig le0 mtu 1300
Alternatively, you can reduce the size of the buffer Exim uses for SMTP
output by putting something like
DELIVER_OUT_BUFFER_SIZE=512
in your Local/Makefile and rebuilding Exim (the default is 8192).
----------------------------------------------------------------------------
Bye,
Elmar
--
ElmarFasel@web.de
--
To UNSUBSCRIBE, email to debian-testing-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: