Data transfer failed

Problem reported by Manuel - 10/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

Bruce Barnes Replied

10/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 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

Manuel Replied

10/16/2015 at 4:40 AM

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

Bruce Barnes Replied

10/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.

Manuel Replied

10/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

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

Bruce Barnes Replied

10/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.

Manuel Replied

10/20/2015 at 11:24 PM

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

Hemen Shah Replied

10/22/2015 at 10:32 AM

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

Manuel Replied

10/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

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

Hemen Shah Replied

10/25/2015 at 12:33 AM

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.

Bruce Barnes Replied

10/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:

https://www.google.com/search?site=&source=hp&q=mtu+checker

Nathan Replied

10/26/2015 at 12:47 PM

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

Manuel Replied

10/27/2015 at 12:47 AM

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

Hemen Shah Replied

1/16/2016 at 1:46 AM

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

Hemen Shah Replied

2/17/2016 at 4:22 AM

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.

Back to Community Threads

Please leave this box unchecked

14 Replies

Reply to Thread

Tags

Related Knowledge Base Articles