Difference between revisions of "MTA Timed out while sending message"

(Created page with "{{BC|Certified}} __FORCETOC__ <div class="col-md-12 ibox-content"> =ZimletUtil= {{KB|{{ZC}}|{{ZCS 9.0}}|{{ZCS 8.8}}|{{ZCS 8.7}}|{{ZCS 8.6}}|{{ZCS 8.5}}|{{ZCS 8.0}}|}} {{WIP}}...")
 
Line 2: Line 2:
 
__FORCETOC__
 
__FORCETOC__
 
<div class="col-md-12 ibox-content">
 
<div class="col-md-12 ibox-content">
=ZimletUtil=
+
=MTA Time out while sending data=
 
{{KB|{{ZC}}|{{ZCS 9.0}}|{{ZCS 8.8}}|{{ZCS 8.7}}|{{ZCS 8.6}}|{{ZCS 8.5}}|{{ZCS 8.0}}|}}
 
{{KB|{{ZC}}|{{ZCS 9.0}}|{{ZCS 8.8}}|{{ZCS 8.7}}|{{ZCS 8.6}}|{{ZCS 8.5}}|{{ZCS 8.0}}|}}
 
{{WIP}}
 
{{WIP}}

Revision as of 00:26, 27 July 2021

MTA Time out while sending data

   KB 24332        Last updated on 2021-07-27  




0.00
(0 votes)


Every now and then, mail fails with "timed out while sending end of data -- message may be sent more than once", or with: "lost connection after DATA". Network outages happen, systems crash. There isn't much you can do about it. Usually the problem goes away by itself. However, when you see mail deliveries fail consistently, you may have a different problem: broken path MTU discovery.

Backgound

With the SMTP protocol, the HELO, MAIL FROM and RCPT TO commands and responses are relatively short. When you're talking to sendmail, every command and every response is sent as a separate packet, because sendmail cannot implement ESMTP command pipelining.

The message content, however, is sent as a few datagrams, each datagram typically a kbyte large or even bigger, depending on your local network MTU.

Constant Failures

If mail fails consistently due to a timeout, it may be suspected that the sending machine runs a modern Linux which implements path MTU discovery. That causes the machine to send packets as large as it would send over the LAN, with the IP DON'T FRAGMENT bit set, preventing intermediate routers from fragmenting the packets that are too big for their networks.

Depending on what network path a message follows, some router on the way responds with an ICMP MUST FRAGMENT message saying the packet is too big. Normally, the sending machine will re-send the data after chopping it up into smaller pieces.

Cause

Things break when some router closer to the sending system is dropping such ICMP feedback messages, in a mistaken attempt to protect systems against certain attacks. In that case, the ICMP feedback message never reaches the sending machine, and the connection times out.

This is the same configuration problem that causes trouble with web servers behind a misconfigured packet filter: small images/files are sent intact, large images/files time out because the server does not see the MUST FRAGMENT ICMP feedback messages.

Workaround

Workaround: disable path MTU discovery at the sending machine. Mail will get out, but of course everyone else will still suffer. How to disable path MTU discovery?

ip_no_pmtu_disc is a BOOLEAN parameter, the default value is FALSE (0) on RHEL5 and RHEL6. In order to disable the MTU discovery, you need to turn on the ip_no_pmtu_disc parameter by the following steps.

# echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc

Edit the configure file /etc/sysctl.conf, and add the following line,

#net.ipv4.ip_no_pmtu_disc = 1

Network Issue

The work around is not a fix, however. Find the router that drops the ICMP MUST FRAGMENT messages, and convince the person responsible for it to fix the configuration.
Jump to: navigation, search