Let us examine the error postfix 421 4.4.2 error timeout exceeded. At Bobcares our Server management support services can give you a detailed note on the error.

Postfix Lost connection analysis: 421 4.4.2 host error: Timeout Exceeded

Let us analyze the error for SMTP status code 421 4.4.2 host Error: timeout exceeded. The error refers to network or connection problems between SMTP servers. The symptoms we observe are the Postfix (IMSVA) server is not able to accept all incoming mails. Also, the sender server is starting to have queuing problems.

The lines that follow represent the log from a Sendmail server that is unable to transmit email to Postfix (IMSVA).

user@abcd.com... Connecting to postfix.localdomain via relay...
220 ESMTP
>>> EHLO sendmail.localdomain
250-postfix.localdomain
250-PIPELINING
250-SIZE 31457280
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
>>> MAIL From:<user@company.com> SIZE=4178
250 2.1.0 Ok
>>> RCPT To:<external@abcd2.com>
>>> DATA
250 2.1.5 Ok
354 End data with .
company3.com: Name server timeout
timeout writing message to postfix.com: Broken
pipe user@abcd.com... Deferred
Closing connection to postfix.localdomain.

The easiest method to comprehend these types of issues is to do a network capture while duplicating the problem. This way, we can view all sent packets in real time and evaluate the behavior of both servers.

If feasible, we should record this on both ends to guarantee that the data is accurate. But, if we can only capture on the end, that is OK as well. This is because we will be able to establish whether the problem is on the end or not.

How to perform the capture?

To perform the capture, use the tcpdump command:

tcpdump port 25 –s0 –w capture.cap

Below is a sample from a Postfix Server with postfix 421 4.4.2 error timeout exceeded status code:

No Time Protocol Info
90 2013-10-10 09:56:01.982305 SMTP: C: RCPT TO: - - DATA
91 2013-10-10 09:56:01.999140 SMTP S: 250 2.1.5 OK
92 2013-10-10 09:56:02.040838 TCP 46281 > SMTP [ACK] seq = 110 Ack = 164 win= 5888 Len=0 TSV = 545
93 2013-10-10 09:56:02. 040860 SMTP S: 421 4.4.2 timeout exceeded
94 2013-10-10 09:56:02.041683 TCP 46281 > smtp [ACK] Seq = 110 Ack= 201 Win= 5888 Len =0 TSV 545
865 2013-10-10 09:57:01.994410 SMTP S: 421 4.4.2 timeout exceeded
866 2013-10-10 09:57:01.994751 TCP smtp > 46281 [FIN,ACK] Seq = 256 Ack = 110 Win = 5888 Len = 0
867 2013-10-10 09:57:01.994903 TCP 46281 > Smtp [ACK] Seq= 110 Ack=256 Win= 5888 lEN=0 tsv=545
868 2013-10-10 09:57:02.035107 TCP 46281 > Smtp [ACK] Seq=110 Ack=257 Win=5888 Len=0 TSV=545
1207 2013-10-10 09:57:32.521754 SMTP C: DATA Fragment, 1024 bytes
1208 2013-10-10 09:57:32.521782  TCP smtp > 46281 [RST] Seq = 257 Win= 0 Len = 0

Analyzing the capture, notice that the first column shows the number of packets. So let us go through all of these processes using those numbers as reference.

Process: postfix 421 4.4.2 error timeout exceeded (part1)

90: Sendmail sends both commands simultaneously: RCPT and DATA.

91: Postfix accepts the RCPT command. We are certain of this because the response is 250 2.1.5 OK.

93: Postfix accepts the DATA command. We are certain of this because the response is 354. From this point on, Postfix will wait until Sendmail sends the message body. Notice that this packet took place at 09:56:02 (second Wireshark column “Time”).

94: Sendmail sends a TCP packet with the ACK flag set indicating it has acknowledged the last TCP packet Postfix just sent. This means that both, networking and the TCP session itself are not presenting any problem so far.

(Part2)

865: About one minute later (09:57:01) Postfix timed out because it hasn’t received any information from Sendmail. So it cuts the communication with a status code 421 4.4.2 assuming there may be a network or connectivity problem that doesn’t allow Sendmail to transfer the message.

Also notice that Postfix is set up to wait only for 60 seconds between its last response and the next block of data. This is precisely what we are observing between these two last packets.

866:Postfix has already closed the SMTP session because it received no answer, it sends a TCP packet with the FIN flag set to indicate Sendmail the TCP session should end right away.

867: Sendmail accepts the FIN instruction and responds with the corresponding knowledge which means there’s no network problem between them.

1207: Half a minute later, Sendmail begins the message transfer, but at this point, Postfix no longer has any SMTP opened session to receive information.

1208: Because Postfix had already closed the connection to Sendmail, it now sends an RST packet to indicate Sendmail there is no TCP session open on its side to receive data. Remember that an RST packet is used to indicate one of the parts that is no longer in synchrony with the TCP session and should start a new one if it wants to transmit.

Explanation

This information is more than enough to determine that, even if there is no network problem between these two servers, the postfix 421 4.4.2 error timeout exceeded appeared.

Sendmail has surpassed the timeout limit set by Postfix before concluding something is wrong with the connection. At this time, we can be certain that Postfix is not the issue, but rather Sendmail, which takes at least one and a half minutes to begin message transmission.

Returning to the Sendmail logs, we can see that the “Broken pipe” error is being reported because it is attempting to resolve an IP of another mail server that is not even the one specified in the RCPT command. This implies that there is an active Sendmail policy that is delaying message transmission.

abcd3.com: Name server timeout
timeout writing message to postfix.com: Broken pipe
user@company.com... Deferred
Closing connection to postfix.localdomain.

When we are in this issue, Postfix will log the following line in /var/log/maillog:

timeout after DATA (0 bytes) from unknown[xx.xx.xx.xx]

The optimum approach is, of course, to detect and adjust the filtering/resolution rules on the Sendmail server. But, if this is not feasible, or if the other domain is unwilling to cooperate for whatever reason, we can rely on Postfix configuration settings to remove the postfix 421 4.4.2 error timeout exceeded.

We already know that Sendmail is waiting at least 90 seconds to begin message transmission, so we can set a greater number for the smtpd daemon time out to give Sendmail additional time before ending the connection.

Please keep in mind that these modifications are purely for mitigation and are not being requested because Postfix is the source of the problem. Postfix will not restart its core engine, the planned adjustments will have no effect on the availability of the mail service.

# postconf -e smtpd_timeout=120s
# postfix reload

Where 120s is our proposed value based on the information presented here, so please adjust this value to any delay we have observed on our own capture.

[Need assistance with similar queries? We are here to help]

Conclusion

To conclude we have now learned more about the postfix 421 4.4.2 error timeout exceeded.  And the Torublelshooting steps necessary to remove the error with the support of our Server management support services at Bobcares.