0
Re: SM - Data Transfer failed
Question asked by Hemen Shah - July 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

19 Replies

Reply to Thread
0
Hemen Shah Replied
July 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.
0
Robert Emmett Replied
July 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.  
Robert Emmett
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Hemen Shah Replied
July 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
0
Bruce Barnes Replied
July 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

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
July 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.
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
Robert Emmett Replied
July 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.
Robert Emmett
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
smartermail Replied
July 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
--------------
0
Hemen Shah Replied
July 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
0
Bruce Barnes Replied
July 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.
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
1
Bruce Barnes Replied
July 23, 2015 at 7:31 AM
Here are some MTU facts:
 
  1. Since moving to our current bandwidth provider, we have had ZERO issues with MTU sizes.
     
  2. 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.

     
  3. 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.

     
  4. In IPv6, MTU Discovery has been explicitly delegated to the end points of a communications session
     
  5. We have NO issues with SmarterMail's capability to handle any size MTU that is thrown at it.
     
  6. 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.
     
  7. 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.
 
 
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
July 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.
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
Hemen Shah Replied
July 23, 2015 at 11:55 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
0
smartermail Replied
July 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.
 
1
Bruce Barnes Replied
July 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.
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
July 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.
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
Hemen Shah Replied
July 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. 
0
smartermail Replied
July 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.
0
Bruce Barnes Replied
July 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.
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 23, 2015 at 2:52 AM
Hello,
I have same problem.
 
Refer: http://portal.smartertools.com/community/a87024/data-transfer-failed.aspx

Reply to Thread