The SMTP log error “421 Command Timeout” appear to have been happening randomly on some SmarterMail mail server (including the latest SmarterMail 8.x edition). We have done some extensive troubleshooting today on one of our client’s mail server and it turns out that the issue is coming from the network interface on the server side itself and has nothing to be done with SmarterMail.
Commonly, you will see the following in your SmarterMail SMTP log :
01:35:53 [220.127.116.11] cmd: MAIL From:<firstname.lastname@example.org> SIZE=2873 01:35:53 [18.104.22.168] rsp: 250 OK <email@example.com> Sender ok 01:35:53 [22.214.171.124] cmd: RCPT To:<firstname.lastname@example.org> 01:35:53 [126.96.36.199] rsp: 250 OK <email@example.com> Recipient ok 01:35:53 [188.8.131.52] cmd: DATA 01:35:53 [184.108.40.206] rsp: 354 Start mail input; end with <CRLF>.<CRLF> 01:38:54 [220.127.116.11] rsp: 421 Command timeout, closing transmission channel 01:38:54 [18.104.22.168] data transfer failed. 01:38:54 [22.214.171.124] disconnected at 11/10/2011 1:38:54 AM
You will notice that after the 354 command, there’s a delay of 3 minutes before the 421 timeout is being logged for all the 421 cases you may found in your SMTP log. There was a Troubleshooting 421 Command Timeout thread in SmarterTools forum which one of the SmarterTools support suggested the cause may be coming from the RBL DNS Antispam checks. We have tried disabling the checks and resending those mails and it does not looks to be helping as well.
At the end we have tried changing the MTU size of the network connection on the server from the default value of 1500 to 1480 and it does looks to fix the problems. We then tried to re-enable the RBL DNS Antispam check as well and the mail transaction goes through.
To change the MTU size on your Windows 2008 server, run the following command as the administrator :
netsh interface ipv4 set subinterface “Local Area Connection” mtu=1480 store=persistent
** Replace Local Area Connection to the actual naming of your network interface name. It would require a reboot on the server but we tested the mails goes through without reboot as well – which is nice!
If this fixes your issues, share with us or otherwise let us know what you have done differently to resolve the issue.