1
Data transfer failed
Problem reported by Manuel - October 16, 2015 at 12:49 AM
Submitted
Hello,
I have SmarterMail Enterprise 14.2.5704 on Windows Server 2008 R2.
I find many many of this errors on SMTP logs:
 
rsp: 421 Command timeout, closing transmission channel
data transfer failed
 
for example:
 
09:40:52 [x.x.x.x][54990147] rsp: 354 Start mail input; end with <CRLF>.<CRLF>
09:42:54 [x.x.x.x][54990147] rsp: 421 Command timeout, closing transmission channel
09:42:54 [x.x.x.x][54990147] data transfer failed. 
 
 
I have try to change MTU value from 1500 to 1480, but problem persist.
The problem is extremely serious because the SmarterMail server rejects the email in many cases.
I try to check firewall logs, but not find problem or error.
 
Can you help me to understand the problem ?
 
Tnx
Manuel

7 Replies

Reply to Thread
0
Bruce Barnes Replied
October 16, 2015 at 3:44 AM
Is your ISP nlocking port 25 for cloent to MX server data transfer? If so, you'll have to setup port 587 for client SMTP use.
Bruce Barnes
ChicagoNetTech Inc

Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting
0
Bruce Barnes Replied
October 16, 2015 at 5:25 AM
Blocking port 25. Many large ISPs now block data between clients and MX servers when the data uses port 25.
 
They do this in such a manner that MX to MX SERVER traffic flows without being blocked, but client to MX server traffic is blocked. That is why the IETF made it mandatory for ISPs to open port 587 which is now the alternative SMTP port for CLIENT to MX server data transfer.
 
You may also have a situation where there is a core router in the path, between your client and the MZ server which cannot auto-resize MTU packet sizes.
 
This has become a very frequent issue, and is very hard to both diagnose and resolve, because neither you, nor the receiving MTA are responsible for the failing device, and most transport providers won't even begin to acknowledge equipment problems brought to their attention by "outsiders."
 
On-the-fly MTU size changes are very frequently employed, by the likes of Comcast, and other providers who initiate a connection at an MTU of 1492, and then, after the handshakes and protocols are established, bump the MTU up to 1500 to complete the data transmission.
 
Given the volume of e-mail data large ISPs handle in a single day, they can "squeeze" the equivalent of several additional hours of bandwidth time into a circuit by jumping to the higher MTU after establishing the connection.
 
Unfortunately, many legacy routers have issues with the MTU size bumps, as do some NIC cards, and even some legacy software and firewalls. Google for MTU checking software, and run some tests to check the data route. The results may prove eye opening.
 
You should also make certain port 587 is properly setup and bound in SmarterMail, and have your POP, SMTP, IMAP and DELIVERY LOGS all set to detailed, keeping them for at least six months so you can go back and check new issues against old traffic to spot trouble patterns.
 
(We keep all of our detailed logs at least 60 months).
 
EDIT NOTE:  Spelling corrected and reformatted.  Originally posted via browser on Android device.
Bruce Barnes
ChicagoNetTech Inc

Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting
0
Manuel Replied
October 20, 2015 at 3:20 AM
Hello,
the problem is server->server, not client->server.
 
This error It happens many times during the day.
The problem is extremely serious because the SmarterMail server rejects the email in many cases.
 
 
Manuel
0
Bruce Barnes Replied
October 20, 2015 at 6:21 AM
Many large ISPs employ MTU size changes during server-to-server transactions.
 
Unless your SmarterMail installation is corrupted, this is not a SmarterMail issue, its a problem with the equipment somewhere between your SmarterMail server and those MX servers which are loosing connectivity with you.
 
Download an MTU checker and run some teats from the box your SmarterMail is installed on and the sender, or receiver, who keeps disconnecting.
Bruce Barnes
ChicagoNetTech Inc

Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting
0
Manuel Replied
October 20, 2015 at 11:24 PM
Hello Bruce,
I am not expert with the MTU.
How exactly should I do to make some tests?
0
Manuel Replied
October 23, 2015 at 2:51 AM
Hello,
my problem persist and is very very important for me to find and resolve the problem.
Many clients migrated from another provider to my, now have this problem, and with the previous provider not.
 
I did some tests, and it seems that the problem of data transfer failed happen only when there is an email attachment. 
If the attachment is not there, the email is accepted/delivered to my server.
I tried to send the same e-mail with another ip and providers, and the email arrives.
 
This seems to rule out a problem of my servers, system operation and firewall, right?
 
We are 100% sure that is not a problem/issue of SmarterMail?
I'm receiving constant calls and complaints of customers who do not receive email for this problem, I have to find a solution soon.
 
In one case, the source IP is in the same provider and datacenter of my server, and this is very very strange.
 
I opened a ticket with SmarterMail support, but all your help and advice would be valuable.
 
Manuel
0
Bruce Barnes Replied
October 25, 2015 at 4:16 AM
Just to clarify, I am not a SmarterTools employee, but a SmarterTools product specialist who volunteers my time in these forums.
 
Given the complexity of MTU issues, anyone experiencing such issues should seriously consider hiring a tech to do the troubleshooting or opening a ticket with SmarterTools.
 
Checking for MTU issues involves both your local network, your ISP (internet service/bandwidth provider), the path between you and the MX server which is failing communications, and the other server owner's ISP.
 
MTU connectivity issues are not easily resolved and can, as it did for us on one occasion, take weeks, to resolve.  The cause of MTU, and other connectivity issues, can be one, or more, of any of the following:
  • bad local NIC card
  • bad driver in server
  • bad local router
  • bad local modem
  • bad core router or firewall at your ISP's network
  • bad core router or firewall between you and the remote location you are having issues connecting with
  • bad core router or firewall at remote MX server's ISP
  • bad driver at remote server
  • bad NIC card at remote location
  • a bad cable at any point in the network between you and the remote location.
 
Wireshark is a good place to start, but is only one of a handful of tools which will be required to do full troubleshooting of an MTU issue.
 
There are several references to MTU checkers in this Google search:
 
Bruce Barnes
ChicagoNetTech Inc

Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting

Reply to Thread