Re: SM - Data Transfer failed

Question asked by Hemen Shah - 7/15/2015 at 11:37 PM

Unanswered

Hi,

I am using SM 14.x entp and off lately got few complaints that mails are sent but not received by the recipient, on further check in logs i do see the mail transaction but "data transfer failed" below one of log, can someone advise here where could be the issue.

[2015.07.15] 07:26:27 [ISP IP][52902308] rsp: 220 xxx.mailserver.com
[2015.07.15] 07:26:27 [ISP IP][52902308] connected at 7/15/2015 7:26:27 AM
[2015.07.15] 07:26:27 [ISP IP][52902308] cmd: EHLO MYCOMP
[2015.07.15] 07:26:27 [ISP IP][52902308] rsp: 250-xxx.mailserver.com Hello [ISP IP]250-SIZE 26214400250-AUTH LOGIN CRAM-MD5250-STARTTLS250-8BITMIME250 OK
[2015.07.15] 07:26:28 [ISP IP][52902308] cmd: AUTH LOGIN
[2015.07.15] 07:26:28 [ISP IP][52902308] rsp: 334 VXNlcm5hbWU6
[2015.07.15] 07:26:28 [ISP IP][52902308] Authenticating as sender@domain.com
[2015.07.15] 07:26:28 [ISP IP][52902308] rsp: 334 UGFzc3dvcmQ6
[2015.07.15] 07:26:28 [ISP IP][52902308] rsp: 235 Authentication successful
[2015.07.15] 07:26:28 [ISP IP][52902308] Authenticated as sender@domain.com
[2015.07.15] 07:26:29 [ISP IP][52902308] cmd: MAIL FROM: <sender@domain.com>
[2015.07.15] 07:26:29 [ISP IP][52902308] rsp: 250 OK <sender@domain.com> Sender ok
[2015.07.15] 07:26:29 [ISP IP][52902308] cmd: RCPT TO: <recipient@domain.com>
[2015.07.15] 07:26:29 [ISP IP][52902308] rsp: 250 OK <recipient@domain.com> Recipient ok
[2015.07.15] 07:26:30 [ISP IP][52902308] cmd: RCPT TO: <recipient-1@domain.com>
[2015.07.15] 07:26:30 [ISP IP][52902308] rsp: 250 OK <recipient-1@domain.com> Recipient ok
[2015.07.15] 07:26:34 [ISP IP][52902308] cmd: RSET
[2015.07.15] 07:26:34 [ISP IP][52902308] rsp: 250 OK
[2015.07.15] 07:26:44 [ISP IP][52902308] cmd: RSET
[2015.07.15] 07:26:44 [ISP IP][52902308] rsp: 250 OK
[2015.07.15] 07:26:47 [ISP IP][52902308] cmd: MAIL FROM: <sender@domain.com>
[2015.07.15] 07:26:47 [ISP IP][52902308] rsp: 250 OK <sender@domain.com> Sender ok
[2015.07.15] 07:26:47 [ISP IP][52902308] cmd: RCPT TO: <recipient@domain.com>
[2015.07.15] 07:26:47 [ISP IP][52902308] rsp: 250 OK <recipient@domain.com> Recipient ok
[2015.07.15] 07:26:50 [ISP IP][52902308] cmd: RCPT TO: <recipient-1@domain.com>
[2015.07.15] 07:26:50 [ISP IP][52902308] rsp: 250 OK <recipient-1@domain.com> Recipient ok
[2015.07.15] 07:26:50 [ISP IP][52902308] cmd: DATA
[2015.07.15] 07:26:50 [ISP IP][52902308] rsp: 354 Start mail input; end with <CRLF>.<CRLF>
[2015.07.15] 07:30:02 [ISP IP][52902308] rsp: 421 Command timeout, closing transmission channel
[2015.07.15] 07:30:02 [ISP IP][52902308] data transfer failed.
[2015.07.15] 07:30:02 [ISP IP][52902308] disconnected at 7/15/2015 7:30:02 AM

Thanks in advance

58 Replies

Reply to Thread

Hemen Shah Replied

7/16/2015 at 7:14 AM

would appreciate some advise here....what does "data transfer failed" means ! ..log posted in first post.

thanks in advance.

Employee Replied

7/16/2015 at 7:37 AM

Employee Post

Hemen, you will receive a "data transfer failed" message if something errant has happened during the data transfer portion of a SMTP session. The most likely case if that zero bytes were received in the data transfer which will end processing that particular message.

Hemen Shah Replied

7/16/2015 at 7:47 AM

Hi Robert,
I dont think this is the case as this is happening randomly, same email if i refwd gets delivered too, i have been experiencing this after recent SM14 update, what could be the other reason,

while am writing to you got a complaint that mail sent but recipient has not received and when i checked log there is mail transaction with data transfer failed and with couple of domains which are getting used from different locations

Employee Replied

7/16/2015 at 8:22 AM

Employee Post

Hemen, the preceding 421 Command timeout message means there is some sort of error occurring between the client and the server. Typically, a 400 error means to try again. Is message being delivering after the next retry? Does it always fail? Are you only getting a 421, or do you see any other error code?

Hemen Shah Replied

7/16/2015 at 11:39 PM

I am getting only error 421 wherever there is data tranfer failed, also if this happens with one customer then can be understood some internet related issue or anything between client-server but this is happening with all customers randomly and getting frequent now from past -12 days.

Joe Wolf Replied

7/17/2015 at 6:22 AM

You're probably trying to send a large message and the recipients SMTP server has a 240 timeout. Either your server, their server, or a combination of the two are not fast enough to transfer the message before the timeout period expires.

Thanks, -Joe

Hemen Shah Replied

7/17/2015 at 1:25 PM

Hi Joe, this is also ruled out, mails sent are pretty small just normal text, and as said this is happening with couple of my customers.
I doubt if this has to do with ISP but even tried with changing smtp port to 587

Hemen Shah Replied

7/18/2015 at 4:55 AM

Any further clue here..i am still facing issue wherein mails are not getting delivered and same shows as "data transfer failed" in the logs, also its been noticed that while outlook sync also it is getting timed out so not sure is this related to TIME OUT issue with the ISP.

I have temporary increased the timeout in SMTP IN to 240 and SMTP OUT to 120 to check if this is the issue but doesnt look like so far.

any further guesses here...

Thanks

Bruce Barnes Replied

7/18/2015 at 5:39 AM

Sounds like either a network error, between your MX server, and the receiving MX server, or

a misconfiguration on the part of one of your servers.

We're glad to assist in troubleshooting, but you'll have to share the address and domain info before anyone can assist you further.

You can also try to send a test message from the originating account to mailtest@unlicktheinbox.com, but that requires a PAID subscription.

You can also do a tracert between your SmarterMail server and the receiving MX server, and note any non-responses or excessively high node times, but you'll have to report those directly to the responsible engineering team, and they'll probably ignore you if you're not their customer.

Running and maintaining MX servers is not plug and play: the service requires constant monitoring and periodic maintenance because of all the changing rules and standards.

Alternatively, you can open a ticket with SmarterMail, or pay someone to troubleshoot the issue.

Remember, with the exception of SmarterTools PAID STAFF, we're all volunteers.

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

Hemen Shah Replied

7/20/2015 at 7:23 AM

Hi Robert, by anyways can this be related to autodiscover or my upgrading this to enterprise version and any setting which i have missed, all issues am facing is after upgrading to enterprise version, also had huge debate with ISP and they too say nothing on their side pertaining to SMTP timeout changes etc, this is really killing me and i dont mind opening up a ticket but this needs urgent attention if an be resolved online.

smartermail Replied

7/20/2015 at 7:38 AM

Hi Hemen,

This is not only you, we are also facing the same issue and from last 5 days ticket is going on with their support and still waiting for resolution. Happening between local domains also.

smartermail Replied

7/20/2015 at 7:48 AM

We thought that issue with server related hence we have migrated our server to another location (On new brand Server with higher configuration), still we are facing the same issue. One thing is common between you and us that we are using SM Enterprise version.

smartermail Replied

7/20/2015 at 7:59 AM

Bruce, you are saying do tracert, telnet, ping etc. Its not only remote mail issue, happening between local SM domains and domain's mail ids also. We have ongoing ticket with SM support staff but still didn't get any resolution from their side. Migrated the server to another country but problem still persist.

Also want to inform you, the issue with not particular ISP, this is happening with all customers randomly and getting frequent now.

Hemen Shah Replied

7/20/2015 at 8:20 AM

I have faced multiple issues in which this is major post migration to enterprise version,
Would request SM team to look into this and comment asap.

Bruce Barnes Replied

7/20/2015 at 9:31 AM

post your actual logs and/or server information and we can test externally.

Given what you've posted, and the fact that nothing anyone suggests seems to work for you, there's not much we can do unless you give us your server information or open a ticket with SmarterTools.

Hemen Shah Replied

7/20/2015 at 10:11 AM

Have you received any update ? or i too am going ahead and opening ticket with SM

Hemen Shah Replied

7/20/2015 at 12:42 PM

Ticket is already opened with SM, lets see what they have to revert.

smartermail Replied

7/20/2015 at 12:54 PM

Its 1:30 AM at our timezone and we were waiting for their reply only and what a good response we got after 5 days:

Its network issue, update your clients to use webmail instead of mail client and check they are facing issue or not.

Whereas we provided all the evidences / logs that, we are getting issue from multiple IPs / ISPs, migrated the server to other country to check server's network card issue but they are not taking issue seriously and responded as above.

smartermail Replied

7/20/2015 at 12:57 PM

We have already ticket with ST and the following is their reply:

"I have read over the ticket and see the issue is related to the network and not SmarterMail. I understand you are having this same issue when you send internal but according to the logs you are using a SMTP client which would then go though your network. To test this send to the same internal domains but only use the web interface. When using the web interface only you will see the the emails are delivered."

In above case the SMTP will not comes up in case because we will not use the mail client so this answer is worthless.

Employee Replied

7/20/2015 at 3:01 PM

Employee Post

Hemen, in the mailConfig.xml can you find the entry for <enablePerformanceCounters> and set it to False. You will need to stop your service, make a copy of the mailConfig.xml file, make the modification, and restart the server. There have been reported incidents in the past related to performance counters.

smartermail Replied

7/21/2015 at 12:28 AM

Hi Robert,

Made the changes in mailconfig.xml, restarted the service but problem still persist.

smartermail Replied

7/21/2015 at 2:06 AM

Robert, is it possible for you that you can have a look on ongoing ticket which we have with ST support. Its with same mail id which I am using here.

smartermail Replied

7/21/2015 at 4:37 AM

Robert,

In logs one thing we observers that one of mail id trying to send same mail multiple times to his client on same domain and for same mail id but SM sometimes showed the genuine error and sometime not (Showed only data transfer failed without any reason):

rsp: 552 Message size exceeds maximum allowed size of 37748736. Closing transmission channel.

and sometimes its just showing data transfer failed without the reason.

It seems to us that these are genuine data transfer failed because of some reasons but somewhere SM is failing to provide the reason of data transfer failed, which should be there and after that it should bounce the mail to client. For example, both the data transfer messages are as follows:

First Data Transfer Failed
--------------
12:32:04 [ISP IP][40485556] rsp: 220 Server_Name
12:32:04 [ISP IP][40485556] connected at 21-07-2015 12:32:04
12:32:04 [ISP IP][40485556] cmd: EHLO [Local IP]
12:32:04 [ISP IP][40485556] rsp: 250-Server_Name Hello [ISP IP]250-SIZE 37748736250-AUTH LOGIN CRAM-MD5250-8BITMIME250 OK
12:32:04 [ISP IP][40485556] cmd: AUTH CRAM-MD5
12:32:04 [ISP IP][40485556] rsp: 334 PDE5OTY1MTMxLjYzNTczMDc4NzI0OTAzNDAwMUB2Z2wuZG5zcmFja3MuY29tPg==
12:32:04 [ISP IP][40485556] Authenticating as mailid@yourdomain.com
12:32:04 [ISP IP][40485556] rsp: 235 Authentication successful
12:32:04 [ISP IP][40485556] Authenticated as mailid@yourdomain.com
12:32:04 [ISP IP][40485556] cmd: MAIL FROM:<mailid@yourdomain.com>
12:32:04 [ISP IP][40485556] rsp: 250 OK <mailid@yourdomain.com> Sender ok
12:32:05 [ISP IP][40485556] cmd: RCPT TO:<mailid1@yourdomain.com>
12:32:05 [ISP IP][40485556] rsp: 250 OK <mailid1@yourdomain.com> Recipient ok
12:32:05 [ISP IP][40485556] cmd: DATA
12:32:14 [ISP IP][40485556] rsp: 354 Start mail input; end with <CRLF>.<CRLF>
12:49:30 [ISP IP][40485556] rsp: 421 Command timeout, closing transmission channel
12:49:30 [ISP IP][40485556] data transfer failed.
12:49:30 [ISP IP][40485556] disconnected at 21-07-2015 12:49:30
--------------

Second Data Transfer Failed
--------------
16:47:41 [ISP IP][43651429] rsp: 220 Server_Name
16:47:41 [ISP IP][43651429] connected at 21-07-2015 16:47:41
16:47:41 [ISP IP][43651429] cmd: EHLO [Local IP]
16:47:41 [ISP IP][43651429] rsp: 250-Server_Name Hello [ISP IP]250-SIZE 37748736250-AUTH LOGIN CRAM-MD5250-8BITMIME250 OK
16:47:41 [ISP IP][43651429] cmd: AUTH CRAM-MD5
16:47:41 [ISP IP][43651429] rsp: 334 PDE5MzIzMTM3MC42MzU3MzA5NDA2MTcwNDQxNTNAdmdsLmRuc3JhY2tzLmNvbT4=
16:47:41 [ISP IP][43651429] Authenticating as mailid@yourdomain.com
16:47:41 [ISP IP][43651429] rsp: 235 Authentication successful
16:47:41 [ISP IP][43651429] Authenticated as mailid@yourdomain.com
16:47:42 [ISP IP][43651429] cmd: MAIL FROM:<mailid@yourdomain.com>
16:47:42 [ISP IP][43651429] rsp: 250 OK <mailid@yourdomain.com> Sender ok
16:47:42 [ISP IP][43651429] cmd: RCPT TO:<mailid1@yourdomain.com>
16:47:42 [ISP IP][43651429] rsp: 250 OK <mailid1@yourdomain.com> Recipient ok
16:47:44 [ISP IP][43651429] cmd: DATA
16:47:53 [ISP IP][43651429] rsp: 354 Start mail input; end with <CRLF>.<CRLF>
16:50:25 [ISP IP][43651429] data transfer failed.
16:50:25 [ISP IP][43651429] rsp: 552 Message size exceeds maximum allowed size of 37748736. Closing transmission channel.
16:50:25 [ISP IP][43651429] disconnected at 21-07-2015 16:50:25
--------------

Hemen Shah Replied

7/21/2015 at 4:55 AM

Smartermail, i havent tried the mailconfig thing yet, also note that Robert has advised to restart the server post this changes, if you are able to reboot the server at this time then request to do the same and update, i am unable to try this and will take next couple of hours.

smartermail Replied

7/21/2015 at 5:04 AM

Hemen, Seems to me he mistakenly wrote the server restart. Only service restart required which I have already did. See above, he started the sentence to stop the service.

Hemen Shah Replied

7/21/2015 at 1:03 PM

Hi,
I checked this on our side and data transfer failed cases are not genuine bounces, i am getting all with command 421, i am awaiting further update from SM team.

smartermail Replied

7/22/2015 at 1:28 AM

http://www.tweakservers.com/421-command-timeout/

The above forum suggested to change the network card's MTU value on server. But its our live server so we can't take risk of it. Robert, kindly suggest your views on it.

Hemen Shah Replied

7/22/2015 at 11:59 PM

One thing i found here is, our SM server has MTU set to 1500 wherein the user sending has MTU set to 1492 in their internet modem-router, can this be the reason to mails not getting delivered and getting failed with command 421 "data transfer failed" ?

If so i wonder how many of customer using different ISP facing this all of sudden !!

will try to speak to client and validate this and try to update settings in their router to default MTU 0 which takes 1500 and matches with server side, as dont wanna disturb server side setting which has been running since long, also if doesnt work out then would try to replace the network card at server side to give a shot.

Comments pls...

Thanks

Bruce Barnes Replied

7/23/2015 at 2:48 AM

EDITED for formatting and spelling [for whatever reason, Android 5.0 does not play well in this editor!]

The MTU setting is a great catch on your part.

A similar case drove us crazy back in 1976, right after Comcast re-branded as Xfinity, and their engineers figured out that they could puck up almost 10,000 data transfer hours per day by initially negotiating the Comcast MX server to remote MX server speeds at an MTU of 1492, switching to an MTU of 1500 when the actual data exchange began.

We had a bandwidth provider who's core routers were incapable of handling MTU changes on the fly, and they could not compensate for the higher MTU speeds, so every Comcast MX transfer failed - driving me crazy, and almost costing me a large customer.

Long story short: we dumped our bandwidth provider for one who could handle the MTU speeds, and simultaneously cut our costs by 80%, while, at the same time, picking up a 500% increase in our network connectivity.

Do NOT cut you MTU speed on your end, it's an issue on your customer's side.

If they own the router, they will either have to get a firmware upgrade or replace the device.

If their internet provider owns the equipment, the internet provider will have to upgrade or replace it.

smartermail Replied

7/23/2015 at 3:11 AM

Hi Bruce,

Understood, but if you check the above logs which I have provided are not from one network / ISP. To how many ISPs you can update the same and how many are able to do this.

The SM application itself have to handle this in order to resolve this issue as other mail servers are handling.

We never faced the same issue with other mail service provider then why its only with SM.

Hemen Shah Replied

7/23/2015 at 3:31 AM

Hi Bruce,

To short here does MTU count has to be 100% match or user side (ISP) should have less or equal to mail server side MTU count.

As of now i have updated MTU to 0 (default 1500) for one of customer who is using Dlink-2750U which is a adsl2+router

Am gonna monitor if this customer faces the same issue.

Bruce Barnes Replied

7/23/2015 at 7:31 AM

Here are some MTU facts:

Since moving to our current bandwidth provider, we have had ZERO issues with MTU sizes.
SmarterMail's code has nothing to do with the MTU size.

From past experience, I can state that SmarterMail will handle any of the MTU sizes it encounters, from the original Windows XP MTU size of 576 bytes, to the new standard size of 1500 bytes,

The minimum value an MTU size can be set to is 68, but such a small size would be extremely impractical and only be used in very slow communications channels.
IPV4 Systems MAY use Path MTU Discovery to find the actual path MTU.

Path MTU Discovery (PMTUD) is a standardized technique in computer networking for determining the maximum transmission unit (MTU) size on the network path between two Internet Protocol (IP) hosts, usually with the goal of avoiding IP fragmentation. PMTUD was originally intended for routers in Internet Protocol Version 4 (IPv4). However, all modern operating systems use it on endpoints.
In IPv6, MTU Discovery has been explicitly delegated to the end points of a communications session
We have NO issues with SmarterMail's capability to handle any size MTU that is thrown at it.
Most MTU issues are caused by older operating systems, improperly configured network interface adapters, unpatched routers, or routers which are not capable of larger MTU sizes.
Some residential providers still limit MTU size capabilities in their systems.

Having said that, here are some facts which cannot be ignored:

The maximum transmission unit (MTU) size is controlled by the mtu mtu_size switch of the ifconfig command. 

The most common MTU sizes are 

 * 1500 bytes (standard-size Ethernet frames), and; 
 * 9000 bytes (jumbo Ethernet frames). 

Configuring an adapter which supports jumbo frames to use jumbo frames can increase network throughput and reduce CPU load, but only if the network supports jumbo frames.

All devices (routers, switches, hubs, etc) which are directly connected to an adapter which supports jumbo frames must also support jumbo frames.

To see the MTU size in use on the server on which SmarterMail is installed, open a command window and run the command:

netsh int ipv4 show int

The results returned will look something like this:

C:\Users\REDACTED>

netsh int ipv4 show int

Idx     Met         MTU          State                Name
--- ---------- ---------- ------------ ---------------------------
1          50 4294967295 connected     Loopback Pseudo-Interface 1
13          10        1500 connected     Ethernet
12           5        1500 disconnected Ethernet 2

Note that if any of the Ethernet cards have an MTU value of 1500, then they have either been modified or there is a problem with the driver for the card. HP has some well-known issues with MTU sizes because of Server 2012 drivers.

C:\Users\REDACTED>

Note that the LOOPBACK will always have a non-valid MTU size, but all Ethernet cards should have an MTU of 1500 to properly function with the rest of the Internet world.

Here is an excellent Technet article on the issues of MTU size in Server 2012:

http://blogs.technet.com/b/askpfeplat/archive/2014/12/01/psa-incorrect-mtu-size-causes-connectivity-issues-with-windows-server-2012-and-windows-server-2012-r2.aspx

smartermail Replied

7/23/2015 at 8:23 AM

Hi Bruce,

Thanks for your explanation on this. Really appreciated.

Right now we have Windows 2012 Server and have MTU value 1500 for both the network cards. Find the following result:

Idx Met MTU State Name
--- ---------- ---------- ------------ ---------------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
12 20 1500 connected Ethernet
13 10 1500 connected Ethernet 2

So in case MTU is 1500 then there should be not an issue with network card but still we are facing the issue.

Kindly Note: Before this server we had Windows 2008 R2 Server and was facing the same issue there also.

Can you kindly suggest.

Bruce Barnes Replied

7/23/2015 at 8:49 AM

Thanks for supplying the test results. Those are important benchmarks.

The next thing I would do is a TRACERT to the MX server(s) you are having (a) problem(s) with. Had you posted the information in the logs, I could do that from our end, but, since you redacted it, I cannot.

REMEMBER: all initial negotiations are done in PLAIN TEXT - TLS is NOT NEGOTIATED until a connection is established, so everything that is transmitted during negotiations is viewable to anyone. So it is not really necessary to redact such information when posting logs as the non-disclosure of such information generally slows down the ability of those of use who respond to such issues to test and respond.

so, from a COMMAND prompt, do TRACERT MAIL.DOMAIN.TLD and see what routers are non-responsive.

The next thing you can do is to use an MTU checker.

You can download a command line MTU checker from http://www.elifulkerson.com/projects/mturoute.php and follow their instructions.

Since your cards are set to the MTU size of 1500, use 1500 as your MTU packet size and test to the problem MX server or IP address.

smartermail Replied

7/23/2015 at 10:05 PM

Bruce, Thanks for your detailed reply on this. Actually the main issue is between the local mail ids on same domain which exist on SM Server.

See the following logs:

12:32:04 [ISP IP][40485556] rsp: 220 Server_Name
12:32:04 [ISP IP][40485556] connected at 21-07-2015 12:32:04
12:32:04 [ISP IP][40485556] cmd: EHLO [Local IP]
12:32:04 [ISP IP][40485556] rsp: 250-Server_Name Hello [ISP IP]250-SIZE 37748736250-AUTH LOGIN CRAM-MD5250-8BITMIME250 OK
12:32:04 [ISP IP][40485556] cmd: AUTH CRAM-MD5
12:32:04 [ISP IP][40485556] rsp: 334 PDE5OTY1MTMxLjYzNTczMDc4NzI0OTAzNDAwMUB2Z2wuZG5zcmFja3MuY29tPg==
12:32:04 [ISP IP][40485556] Authenticating as mailid@yourdomain.com
12:32:04 [ISP IP][40485556] rsp: 235 Authentication successful
12:32:04 [ISP IP][40485556] Authenticated as mailid@yourdomain.com
12:32:04 [ISP IP][40485556] cmd: MAIL FROM:<mailid@yourdomain.com>
12:32:04 [ISP IP][40485556] rsp: 250 OK <mailid@yourdomain.com> Sender ok
12:32:05 [ISP IP][40485556] cmd: RCPT TO:<mailid1@yourdomain.com>
12:32:05 [ISP IP][40485556] rsp: 250 OK <mailid1@yourdomain.com> Recipient ok
12:32:05 [ISP IP][40485556] cmd: DATA
12:32:14 [ISP IP][40485556] rsp: 354 Start mail input; end with <CRLF>.<CRLF>
12:49:30 [ISP IP][40485556] rsp: 421 Command timeout, closing transmission channel
12:49:30 [ISP IP][40485556] data transfer failed.
12:49:30 [ISP IP][40485556] disconnected at 21-07-2015 12:49:30

Here mailid@yourdomain.com and mailid1@yourdomain.com is on same domain on our SM Server so MX can't be issue here.

Kindly suggest.

smartermail Replied

7/23/2015 at 10:08 PM

Hemen, Request you, kindly share the results.

Hemen Shah Replied

7/23/2015 at 11:52 PM

Hi,

I have discussed this at length at my data centre devops, as per them MTU set to 1500 is default for current server systems with OS 2008/2012 and they dont recommend any changes to MTU be it server side or user side, normally user side modems/routers using DSL Broadband will have MTU set to 1492 or 0 which is default for 1500
So i dont think this has to do something with server side network as these settings has been there over the years and update is done at only SM software with new version updated etc.

I had analysed yesterday's SMTP log and found 31 connections with "data transfer failed" i checked these IPs and all are from different ISPs and geographies, so i dont take that all of sudden they have issue with their outlook software or network or modem etc that too at same time.

From SM side team is still working on my box and they are running wireshark for capturing realtime logs and analysis, they have got something for which they have developed custom build which i will be installing once by peak time gets over and then further analysis on this, am sure this will be cracked in another day or two.

will keep all posted.

Thanks

Hemen Shah Replied

7/23/2015 at 11:55 PM

smartermail Replied

7/24/2015 at 12:15 AM

Hemen,

They did all the tests with my server also i.e. wireshark capture and I got very ridiculous reply from them (Sorry to use this word here). They provided all the instances which were not related with this data transfer failed where as I have provided all the logs to them server access etc.

Further yesterday I got reply,

"For troubleshooting purposes only we would like to provide you a SmarterMail professional key for a few days to see if you receive the 421 response. This is a suggestion by the developers based on some information. Please let me know and I will send you a professional key."

I said our client is using Archiving and Shared Global Address List so today they said

"The professional will stop the archive and address book syncing. So we will not try that but please find out what the MTU length is. Please see the post from Hemen at July 22 11:59 and then the reply from Bruce.

Where as we have already provided the reply on this thread to you and Bruce but they didn't check the same and passed one more day which they are doing from almost last one week.

Today is Friday and its their last working day of week. If today we didn't get any satisfied answer from their side then we have to wait almost for 3 days.

Further its happening with local mail ids also so its not related with MX also for which Bruce suggested today in his last reply.

I am also sure that this issue is not related with MTU as Bruce and Microsoft forum both confirmed that we have MTU in right way on server for our network card. The issue seems with SM only and they are not accepting it.

Regarding Custom Build they still not suggested us for it.

Hemen Shah Replied

7/24/2015 at 1:01 AM

Now they got this issue from another user (thats me) so they have digged deep and found something for which they did custom build and to do further analysis, either something to do with ENTP version or builds after June'15, i dont know if others would be facing this issue as there is no bounce back for such error and it is completely based on user complaint or unless someone digs the log the checks this, if any customer sending high volume of mails but few misses due to this then customer might complaint back or may be not instead he would reforward the mail quickly to get their job done.

Bruce Barnes Replied

7/24/2015 at 7:24 AM

Anything which is set to an MTU of 1492 will FAIL data with an MTU size of 1500, if the device is not capable of MTU auto-resizing on-the-fly.

Bruce Barnes Replied

7/24/2015 at 7:30 AM

If this is happening with local domains, then this might be DNS related.

Since you have refused to provide any domain, MX or IP information, it is impossible to test this externally for you.

Again, I remind you that we are volunteers, and can only do so much. If you expect further assistance, please provide the following:

The SENDING DOMAIN
The RECEIVING DOMAIN
The FULLY QUALIFIED DOMAIN NAME of the SmarterMail SERVER
The IP PUBLIC, STATIC, IP ADDRESS of the SmarterMail SERVER.

By providing this information, those of us who are attempting to assist you will be able to validate the DNS settings, HOST records, and rDNS records of the domains and e-mail in question.

We will also be able to see who the ISP that provides the interconnection is and tell whether they are RESIDENTIAL or BUSINESS class circuits, IP addresses and services.

failure to respond to that request will mean I will no longer be able to provide you with any assistance.

If you desire further assistance, you need to provide legitimate information for us to work with.

Hemen Shah Replied

7/24/2015 at 1:36 PM

MTU of 1492 is default size of DSL broadband, today i have checked this in atleast 23 different dsl routers in our premises different offices, some are of cisco, dlink, tp-link, netgear, on the other side servers with OS 2008/2012 have network cards with MTU 1500 default so i rule out this part, to say again i have faced this precisely after upgrading to enterprise version or around 2 weeks back so may be after June'15 SM update, till then from so many years it was perfectly fine with same MTU.

Hemen Shah Replied

7/24/2015 at 1:38 PM

Hi Bruce,

The thing is scenarios are quite weird, i would send my mx ip on private msg and would not like to share it here, if you ask me sending/receiving domain then there is scenario where domain A > B mails sent successfully and another transaction of same domain A > B with same IP has error "data transfer failed" i have such 31 connections for which i can send you the log file if needed.
SM team has installed custom build which is detail debug log which can give further insight once i get similar instances today post installation.

Bruce Barnes Replied

7/24/2015 at 4:32 PM

And an MTU of 1492 will NOT work with devices which do not auto-renegotiate. This appears to be the issue with those devices which are not connecting with your SmarterMail installation.

This is NOT a SmarterMail issue. The issue is, most likely, with the accounts and/or customers who are having delivery issues.

Trust me, I worked on this same situation with a major account a few years back. It drove me nuts, and it was all because of one of the devices used by one of my vendors who refused to do any upgrades.

We terminated the vendor and moved to a different provider for that particular connection and everything was fine after that.

Bruce Barnes Replied

7/24/2015 at 4:34 PM

You need to pay someone to go into your server and do testing from within there.

Based refusing to provide the requested information, you are completely inhibiting the ability to troubleshoot this further from an external point of view.

Please pay for a ticket with SmarterMail, or hire a tech to troubleshoot your situation.

Hemen Shah Replied

7/25/2015 at 4:08 AM

Hi,
It has been already paid to SM and thats why they are working on the same with custom build or myself and further trouble shooting.

Hemen Shah Replied

7/27/2015 at 12:21 AM

Hi Smartermail, any luck at your end, i am still facing issue even with custom build and have sent connection logs with data transfer failed cases to SM team.

smartermail Replied

7/28/2015 at 12:45 AM

Hemen, have you got the solution.

Hemen Shah Replied

7/29/2015 at 7:26 AM

I am posting one of the response received from SM team, again my submission here is there can be network issue with all the users that too same point of time or within few days, this is random to all and not pertaining to specific domain/user,

IP given in the log is of user -ISP and is dynamic ip

Thank you for providing us with this. We parsed through the logs and noticed that every data transfer failed message is the result of the remote server failing to send the appropriate information and commends to your server.

Please review the attached two files. You'll see that in the entries with data transfer failed, we've included the last data received on the network level. I've included an example below:

01:03:21 [103.251.48.144][66140022] rsp: 220 MAIL.SERVER.COM

01:03:21 [103.251.48.144][66140022] connected at 7/27/2015 1:03:21 AM

01:03:21 [103.251.48.144][66140022] cmd: EHLO user-sender

01:03:21 [103.251.48.144][66140022] rsp: 250-MAIL.SERVER.COM Hello [103.251.48.144]250-SIZE 26214400250-AUTH LOGIN CRAM-MD5250-STARTTLS250-8BITMIME250 OK

01:03:29 [103.251.48.144][66140022] cmd: AUTH LOGIN

01:03:29 [103.251.48.144][66140022] rsp: 334 VXNlcm5hbWU6

01:03:30 [103.251.48.144][66140022] Authenticating as sender@domain.com

01:03:30 [103.251.48.144][66140022] rsp: 334 UGFzc3dvcmQ6

01:03:31 [103.251.48.144][66140022] rsp: 235 Authentication successful

01:03:31 [103.251.48.144][66140022] Authenticated as sender@domain.com

01:03:31 [103.251.48.144][66140022] cmd: MAIL FROM: <sender@domain.com>

01:03:31 [103.251.48.144][66140022] rsp: 250 OK <sender@domain.com> Sender ok

01:03:32 [103.251.48.144][66140022] cmd: RCPT TO: <recipient@gmail.com>

01:03:32 [103.251.48.144][66140022] rsp: 250 OK <recipient@gmail.com> Recipient ok

01:03:32 [103.251.48.144][66140022] cmd: DATA

01:03:37 [103.251.48.144][66140022] rsp: 354 Start mail input; end with <CRLF>.<CRLF>

01:14:23 [103.251.48.144][66140022] data transfer failed.

01:14:23 [103.251.48.144][66140022] last data (932 bytes) received 01:14:23

01:14:23 [103.251.48.144][66140022] last data:

D0fPnvOGVNqfe7k4fHc4hz3kwIYN<CRLF>

7xcUFCQlJ4jFYjMzXvvzno6Ojrq6u/N/57Zs6fKwsHB3d3fpYMfOnX/u6BhgsVh8Lsfc3MrXxzsi<CRLF>

IsLB0ZbLRJf83k+jVdLpevCv+E+BQA/fysrX961zZzN37drVKeml0ZgODsL4oxkpKanV1dU8HsfW<CRLF>

FrVzcCksLJw/37W7u7u1qycnJ+erz/8hDvxj8vGEmpoaHz9fkbVZvxJ5+qTdbaE7yBWLichl0lPJ<CRLF>

SRs3btTSeba23PZ2WXNz84oVKzRaNUgCF+Uq1Arwy2QwZApZcWFxY2NjQEAAKKqUY/GfZ5/t61X0<CRLF>

9fXlXb1y4MABvlCwe/fuoKCguLg4EL5SIZ81c9alizlXr+ZrNBoQGvCKw+Oy2ew5rvNA+c13W7Bo<CRLF>

0SLgJNCQmZkpMrMIFAdacIWJiYmBgYHfFN0E16HQNf14u1zE8be0pB35LPTChQvgxuPj4/39PgKR<CRLF>

xiQGPWttLMlv9vDw8PK25/GmXLx40dHREYQ2d+7sp49bbWxs5HK5lZXo4cMmDy8PJkJvfdp648aN<CRLF>

efPmuXnN5XK410tKK2/97Oe3+Jefa/cf3h/wztq0tDSRyKL7ty5ga86bM/39/S1Fwm+/LTqRdKKq<CRLF>

tgrg0BvTpmp1yqKiomOJSadOpUt7Zc5ODqAqBwf1nZ0d3os8dXoVyOdn8cdBfTJQ1qxZswbkClCf<CRLF>

oWFhVVVVd+78qlapcvPyAlau6pR0e7q5y5SyT2M/3R76oUDA7fqtB3grkXSDr7QGvYW5Rf/gIMj2<CRLF>

gcOHQG51OkNbW5v43XdBOZlx6CdPnryUV1Z0vUgolIOcbN60UyhEXvRqJBLJ4iWuKIreqmhZtmzZ<CRLF>

C2mLp6dn3oVckchmEHip17c0PwYVaGaG1NW1gLREH4re

01:14:23 [103.251.48.144][66140022] disconnected at 7/27/2015 1:14:23 AM

It is clear that we are not receiving a <CRLF>.<CRLF> which signifies end of DATA stream, which would then close the connection and deliver the message. Please note that this connection remained open from 01:03:32 to 1:14:23 before reporting the data transfer had failed. So the issue here is why didn't the remote server send your server any further data ? Or alternatively, what had caused the interruption in this connection between your mail server, and the client\remote server.

Please note that the connection remained open during this time period, SmarterMail simply did not receive any further information designating the end of the message and killed off the connection. This is identical to the behavior that was outlined within my previous WireShark captures.

Request to post if anyone is facing such issue

What we're looking at here is an issue on the network level. If we're not receiving the information expected within a timely manner the command timeouts and data transfer failed messages will continue to occur.

Hemen Shah Replied

7/29/2015 at 7:28 AM

not really break through yet, data centre is claiming its more of software issue as even with message size exceeded are data transfer fail cases and no bounce back wherein SM team still claims its network related ..have posted response received from SM team as new post.

smartermail Replied

7/29/2015 at 7:38 AM

Hemen,

I got almost same reply from them. I tried so much but they are not able to understand that this start to happen frequently once we upgraded the SM version to 14.x. This was happening in 13.x also but not too much like its stated in 14.x

Further if the SM server is not able to receive the data from client end then mail should be bounced or the connection gets break at user side specially in case when sending the mail to local domain's user. The mail should not be in Sent Items.

smartermail Replied

7/30/2015 at 1:59 AM

Hemen,

Got the straight reply from SM.

If the client send the Data command and then no additional data after that SmarterMail cannot bound the message. What you are seeing in the logs is the start of the connection leading up to the Data command then SmarterMail logs that is received 0 bits. Since no message data was received there is nothing to bounce.

We have over 15 milling users of SmarterMail and at this time there is only you and one other person who is having this issue and in both cases we see where the client send the data command and does not complete. This is not a SmarterMail issue.

Bruce Barnes Replied

7/30/2015 at 6:05 AM

As I stated back on 24 July, this is probably related to the fact that there is a DNS issue with one, or more, domains.

Given your apparent lack of knowledge about the issues, and the fact that you have, repeatedly, refused to provide the actual names and IP addresses of the sending and receiving domains, the only way you are going to resolve the issue is to pay someone who has a strong working knowledge of DNS, server operating systems, IIS, and SmarterMail to investigate and test in your server.

This will require their having direct access to both the server on which SmarterMail is installed; your SmarterMail installation; and your DNS server(s) - with full administrative level access.

Matt Petty Replied

7/30/2015 at 8:46 AM

Employee Post

I can vouch for Bruce's knowledge of Security and DNS. He is really smart when it comes to that sort of work. It would be worth posting the information he requested so that more eyes can look at the issue.

Matt Petty Senior Software Developer SmarterTools Inc. www.smartertools.com

smartermail Replied

7/31/2015 at 4:24 AM

Hi Bruce,

SM has closed my ticket without the resolution and by stating that its not SM issue.

Is there any way I can directly send the logs to you as its public forum and we can't share clients domain names here.

Bruce Barnes Replied

7/31/2015 at 5:47 AM

Setup an account and open a support ticket at my portal, via the URL shown beloe my last post, ahove, and I'll contact you.

Manuel Replied

10/23/2015 at 2:52 AM

Hello,

I have same problem.

Refer: http://portal.smartertools.com/community/a87024/data-transfer-failed.aspx

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

Back to Community Threads

Please leave this box unchecked