SMTP data timeout (message abandoned)

[WSWD]

Anybody ever encounter the dreaded "SMTP data timeout (message abandoned)" error?  It's happening on a CentOS 6 server with cPanel, and I can't figure it out for the life of me.  I had the cPanel support folks have a looksie around for good measure and they said everything looks great.

There doesn't seem to be any rhyme or reason to why it's happening.  Some emails come through and some emails don't.  The datacenter said there isn't anything happening on their end that would cause this.  Changing the EXIM timeout from the cPanel default (165s) to 5m or even 10m does nothing.  It's really bizarre, to be honest, and something I haven't seen before. 

Don't really know when it crept up, as I hadn't noticed any emails missing until a few weeks ago, when I didn't get an invoice for a VPS I have over at Ramnode.  They looked into it, as I thought it might have been some issue on their end.  The invoice never came through, the emails for their support tickets never came through.  Then literally a day or two later, emails started working for them again.

I'm soooo confused...

 

[cloudcone]

Did you try the following command

/scripts/upcp --force

It will force update cPanel to the latest build (it can fix these sorts of random errors) and it can take a lot of time to update as well

 

[wlanboy]

Any viruscan, rbl (spamhaus, spamcop) in place of your sendmail/postfix configuration?

Was my - long searched - cause for delayed/timout email errors on a really slow vps. Go through your email chain to find the one causing the deplay.

 

[TheLinuxBug]

From just a quick search it looks like this is a know issue and their is a cPanel KB for it: https://forums.cpanel.net/threads/what-causes-smtp-data-timeout-message-abandoned.355462/

This is explained in the Exim documentation:It means that there was a timeout while Exim was reading the contents of a message on an incoming SMTP connection. That is, it had successfully accepted a MAIL command, one or more RCPT commands, and a DATA command, and was in the process of reading the data itself. The length of timeout is controlled by the smtp_receive_timeout option.
If you get this error regularly, the cause may be incorrect handling of large packets by a router or firewall. The maximum size of a packet is restricted on some links; routers should split packets that are larger. There is a feature called “path MTU discovery” that enables a sender to discover the maximum packet size over an entire path (multiple Internet links). This can be broken by misconfigured firewalls and routers. There is a good explanation athttp://www.netheaven.com/pmtu.html. Reducing the MTU on your local network can sometimes work round this problem. See Q0017 (3) for further discussion.

[SIZE=14.6666669845581px]From this description it seems like you are probably getting some bots which are connecting, sending a few commands (likely verifying there is a valid user there) and then breaking the connection abnormally instead of shutting the connection down with the correct commands.  This in turn results in the error you were seeing, [/SIZE]"SMTP data timeout (message abandoned)".  The other possibility, if you can confirm the connections where this is happening is actually valid client connections and not a spammer/attack then it seems like with you have your MTU set to high for the other end to handle or your node is doing enough PPS that its occasionally having issues and dropping the connection.

I would vote for it being some type of botnet attack, unless you are specifically seeing the issue with known customers connections.

my 2 cents.

Cheers!