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
GRAFFITI — It's Communication
Riva del Garda (TN), I-38066 – Località Pasina 46
Milano, I-20129 - via Lamberto De Bernardi 1
Verona, I-37134 - via Legnago 126
San Francisco, US-94111 California – 275 Battery St, Suite 2600
website: www.graffiti.it

14 Replies

Reply to Thread
0
Bruce Barnes Replied
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
brucecnt@comcast.net

Phonr: (773) 491-9019
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
Hello Bruce,
what exactly do you mean by "nlocking port 25" ?
GRAFFITI — It's Communication
Riva del Garda (TN), I-38066 – Località Pasina 46
Milano, I-20129 - via Lamberto De Bernardi 1
Verona, I-37134 - via Legnago 126
San Francisco, US-94111 California – 275 Battery St, Suite 2600
website: www.graffiti.it
0
Bruce Barnes Replied
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
brucecnt@comcast.net

Phonr: (773) 491-9019
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
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
GRAFFITI — It's Communication
Riva del Garda (TN), I-38066 – Località Pasina 46
Milano, I-20129 - via Lamberto De Bernardi 1
Verona, I-37134 - via Legnago 126
San Francisco, US-94111 California – 275 Battery St, Suite 2600
website: www.graffiti.it
0
Bruce Barnes Replied
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
brucecnt@comcast.net

Phonr: (773) 491-9019
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
Hello Bruce,
I am not expert with the MTU.
How exactly should I do to make some tests?
GRAFFITI — It's Communication
Riva del Garda (TN), I-38066 – Località Pasina 46
Milano, I-20129 - via Lamberto De Bernardi 1
Verona, I-37134 - via Legnago 126
San Francisco, US-94111 California – 275 Battery St, Suite 2600
website: www.graffiti.it
0
Hemen Shah Replied
Hi Manuel,
Kindly refer below thread i had opened for same issue, tried to convince SM a lot but nothing happened and somehow this was resolved with new updates installed, but it was not concluded wether its ISP or SM

Refer: http://portal.smartertools.com/community/a86639/re-sm-data-transfer-failed.aspx

Thanks
0
Manuel Replied
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
GRAFFITI — It's Communication
Riva del Garda (TN), I-38066 – Località Pasina 46
Milano, I-20129 - via Lamberto De Bernardi 1
Verona, I-37134 - via Legnago 126
San Francisco, US-94111 California – 275 Battery St, Suite 2600
website: www.graffiti.it
0
Hemen Shah Replied
Hi,

Have you received any further upate from SM team on this ? i guess they would be running wireshark on your box for realtime log analysis.

0
Bruce Barnes Replied
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
brucecnt@comcast.net

Phonr: (773) 491-9019
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
Nathan Y Replied
To test the MTU theory try pinging from your smartermail box with the following command:

ping -f -l 1500 <IP address / FQDN>

I would start by pinging your default gateway IP then working out. If you see the following response it means the MTU is less than 1500 and this could be the source of the issue:

'Packet needs to be fragmented but DF set'

As long as your external connectivity is terminated over ethernet (e.g. not using PPPOE which reduces the max MTU due to the overhead of PPPOE) you should be able to send packets of 1500 bytes. In this case it is possible you have inadvertently broken path MTU discovery by blocking the required ICMP types and created a blackhole. More info at...

https://en.wikipedia.org/wiki/Path_MTU_Discovery
0
Manuel Replied
Hi,
I'm try to capture and analyze traffic with whireshark and SmarterTools support.
GRAFFITI — It's Communication
Riva del Garda (TN), I-38066 – Località Pasina 46
Milano, I-20129 - via Lamberto De Bernardi 1
Verona, I-37134 - via Legnago 126
San Francisco, US-94111 California – 275 Battery St, Suite 2600
website: www.graffiti.it
0
Hemen Shah Replied
Hi Manuel,

Have you got any resolution to this issue of data transfer failed ? i have again start receiving few complaints from customer on this same issue.

do let me know thanks
0
Hemen Shah Replied
Hi,

Have you got any resolution to this issue of data transfer failed ? i have again start receiving few complaints from customer on this same issue.

Reply to Thread