Hi, On Mit, 2002-03-27 at 08:03, [EMAIL PROTECTED] 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 -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
