I discovered this problem on inbound mail, but it is more likely to affect others who use SmarterMail Smtp out to the Internet whether from your main server or an outbound gateway. For outbound traffic, the problem may occur but be undetected. You can quickly check to see if it has occurred by searching your Delivery logs for "timed out"
Most systems perform all email filtering while the SMTP session is open. Knowing this, RFC 5321 says that transmitting systems should wait up to 5 minutes after "Rcpt To" for receiving systems to perform recipient verification, and should wait up to 10 minutes after End-of-Data for receiving systems to perform email acceptability checks. The SmarterMail default setting for SMTP Out timeout is only 60 seconds. That value seems like it should be plenty, but I found that it is not..
If the receiving system takes longer than then timeout period, SmarterMail disconnect, waits a while, and tries again. This can cause several problems:
- If the receiving system executes faster on the retry, the minimum harm is that the message is delayed.
- If the receiving system fails to abandon the disconnected message, the user receives a copy for every retry.
- If the processing time at the receiving system is consistently bad on every retry, the attempt will be repeated until the max retry limit is reached, typically in 48 hours, and the user receives a delivery failure notice.
In short, there is no benefit from abandoning a slow connection, and many disadvantages.
This came to light on my inbound traffic. My first spam filter is running SmarterMail Free, which of course does nearly all of its spam filtering after the SMTP session is closed. Systems that send to me will never see a slow response after End-of-Data. That system evaluates the message and then relays it to a commercial spam filtering appliance, which does all of its filtering while the SMTP session is open.
For reasons that are still being investigated, the appliance is sometimes taking longer than 60 seconds to process a message, so I was seeing timeouts. The appliance also fails to detect the disconnected, so it delivers the message after every attempt. I saw one example with 7 retires before it delivered successfully. Increasing the SMTP Out timeout solved the problem.
No transmission is taking anything close to 10 minutes, but I have set my system to that high value because there seems to be no benefit from using anything less.
I suggest that the SmarterMail default for new installs should be set to 600 to match the RFC. I suggest that everyone reading this check their logs and bump up the timeout parameter.