Topic '[Servers] strange b2b email behavior' in forum 'Networking' - dslreports.com

Re: [Servers] strange b2b email behavior

Thu, 11 Oct 2012 22:14:02 EDT

HELLFIRE posted : Glad you got it all sorted out in the end mr_boodog

My bill will be coming to you via registered mail :D

Regards

Re: [Servers] strange b2b email behavior

Fri, 05 Oct 2012 14:21:30 EDT

mr_boodog posted : You are correct, we have had no other connectivity issues, that same email server sends messages to many different servers.

Today we spent considerable time with the receiving server in question. They went through turning off all spam, all firewall, and we still couldn't send anything larger than 250k. Smaller files went fine, but anything larger (which could be a regular 1-5mb pdf) failed.

What we finally found is that my smtp server and their receiving host (Smartermail) were not negotiating properly. I changed smtp smarthost on my end, and everything flowed into their server. You were right on in one of your statements that it really looks like an application issue.

They are looking into possible bugs in that particular email server software and normal smtp gateway.

Pretty bizarre, but at least we have pinpointed the issue.

Thanks again, close this ugly case up!

Re: [Servers] strange b2b email behavior

Fri, 05 Oct 2012 13:03:28 EDT

HELLFIRE posted : Something else I was thinking about, exactly what kind of files are you sending that would need 3 - 5 MBs in size?

Email is email, but something about sending that big a file via email even in this day and age just gives
me the willies; could you get a more reliable transmission method, like S/FTP and/or a fileshare service, or
possibly compress the size down further?

Just putting it out there as an option.

Regards

Re: [Servers] strange b2b email behavior

Fri, 05 Oct 2012 12:56:31 EDT

HELLFIRE posted :

said by mr_boodog:

However, from inside the network where I sit, it reports needing fragmentation all the way down to 500. I take it that my network's MTU at the perimeter is always limited to 500? Is that too small for transmitting larger files? It doesn't seem optimal.

Is the traceroute you originally gave from the network where you are trying to send the email from?
Thats why I suggested trying the ping / Don'TFrag test there along each visible hop towards 75.103.97.26
to see WHERE you might be getting this small MTU problem.

Short of you being on some VERY legacy WAN links, MTU in this day and age is rarely a problem, and endhosts
should be able to figure out if they have to fragment or not.

You haven't seen any other WAN connectivity problems OTHER than this email problem, right mr_boodog?
The only other symptom I've seen with MTU problems is intermittent page loads over xDSL, but like I
said, I've rarely seen MTU problems in my time working on networks.

Happy to help, let us know if you get anywhere.

Regards

Re: [Servers] strange b2b email behavior

Thu, 04 Oct 2012 16:59:49 EDT

mr_boodog posted : HF,

Thanks for taking a look at the scenario. I did search on the undeliverable message, but nothing really stuck out as far as fixes. Again, I our server is sending messages all around the country, large attachments and all. Only when a receiving server has size limits or some kind of blocking have I received undelivered messages.

All other facts just seem to say that their server is not able to respond in a timely manner to our smtp traffic. Then when one packet is discarded, the entire set has to be retried.

Smaller text messages get through, and even a few of the ones with attachments. But more than likely they come back undeliverable.

You tested pinging with different buffer sizes. From home, I have tried 2 different ISPs with two different results, about 1428, and 1228. However, from inside the network where I sit, it reports needing fragmentation all the way down to 500. I take it that my network's MTU at the perimeter is always limited to 500? Is that too small for transmitting larger files? It doesn't seem optimal.

I guess that still doesn't fly because we are sending smtp traffic to many different hosts.

I completely concur about it being on their end, and possibly application level problem. Arggggh!

Again, I appreciate your time in checking it out.

Re: [Servers] strange b2b email behavior

Thu, 04 Oct 2012 13:37:31 EDT

HELLFIRE posted :

said by mr_boodog:

Their IT is saying it has to be our ISP, our SMTP server, or our firewall configuration.

Ahh, the cry of the "it's not my fault" type. Sorry, Agent Orange reaction to my time on the desk flaring up...

said by mr_boodog:

After 4 hours of retries, the mailer-daemon sends me this:
Undeliverable:subject
4.4.2 X-Proprietary; lost connection with mail.indlube.com[75.103.97.26] while sending message body#SMTP#

Did you try plugging that or any other output into Google or Microsoft, just for s**ts and giggles? Anything come back?

said by mr_boodog:

Is this some sort of MTU problem between the server and router hops?

Doubtful, if other stuff is getting through, but not mails with attachments 3-5MB in size, I'd lean more to
an application size problem. The reall B***H of the problem is proving it to these guys.

I can replicate your ping problem with 1492byte packets / DF but I couldn't with 1300, 1200, or 1000byte packets.

C:\Documents and Settings\XXXXX>ping 75.103.97.26 -l 1492 -f Pinging 75.103.97.26 with 1492 bytes of data: Packet needs to be fragmented but DF set.Packet needs to be fragmented but DF set.Packet needs to be fragmented but DF set.Packet needs to be fragmented but DF set. Ping statistics for 75.103.97.26:    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), C:\Documents and Settings\XXXXX>ping 75.103.97.26 -l 1300 -f Pinging 75.103.97.26 with 1300 bytes of data: Reply from 75.103.97.26: bytes=1300 time=96ms TTL=115Reply from 75.103.97.26: bytes=1300 time=95ms TTL=115Reply from 75.103.97.26: bytes=1300 time=93ms TTL=115Reply from 75.103.97.26: bytes=1300 time=93ms TTL=115 Ping statistics for 75.103.97.26:    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds:    Minimum = 93ms, Maximum = 96ms, Average = 94ms C:\Documents and Settings\XXXXX>ping 75.103.97.26 -l 1200 -f Pinging 75.103.97.26 with 1200 bytes of data: Reply from 75.103.97.26: bytes=1200 time=96ms TTL=115Reply from 75.103.97.26: bytes=1200 time=106ms TTL=115Reply from 75.103.97.26: bytes=1200 time=96ms TTL=115Reply from 75.103.97.26: bytes=1200 time=92ms TTL=115 Ping statistics for 75.103.97.26:    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds:    Minimum = 92ms, Maximum = 106ms, Average = 97ms C:\Documents and Settings\XXXXX>ping 75.103.97.26 -l 1000 -f Pinging 75.103.97.26 with 1000 bytes of data: Reply from 75.103.97.26: bytes=1000 time=101ms TTL=115Reply from 75.103.97.26: bytes=1000 time=93ms TTL=115Reply from 75.103.97.26: bytes=1000 time=98ms TTL=115Reply from 75.103.97.26: bytes=1000 time=96ms TTL=115 Ping statistics for 75.103.97.26:    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds:    Minimum = 93ms, Maximum = 101ms, Average = 97ms C:\Documents and Settings\XXXXX>ping 75.103.97.26 -l 500 -f Pinging 75.103.97.26 with 500 bytes of data: Reply from 75.103.97.26: bytes=500 time=92ms TTL=115Reply from 75.103.97.26: bytes=500 time=95ms TTL=115Reply from 75.103.97.26: bytes=500 time=93ms TTL=115Reply from 75.103.97.26: bytes=500 time=91ms TTL=115 Ping statistics for 75.103.97.26:    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds:    Minimum = 91ms, Maximum = 95ms, Average = 92ms

1472bytes also seems to be a pretty happy middle ground as well; another reason why I doubt your MTU theory.

C:\Documents and Settings\XXXXX>ping 75.103.97.26 -l 1472 -f Pinging 75.103.97.26 with 1472 bytes of data: Reply from 75.103.97.26: bytes=1472 time=95ms TTL=115Reply from 75.103.97.26: bytes=1472 time=93ms TTL=115Reply from 75.103.97.26: bytes=1472 time=93ms TTL=115Reply from 75.103.97.26: bytes=1472 time=93ms TTL=115 Ping statistics for 75.103.97.26:    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds:    Minimum = 93ms, Maximum = 95ms, Average = 93ms

Short of getting a sniffer on 75.103.97.26's side, there's no way to tell if fragmentation is the problem or not,
so I wouldn't bother trying to prove a negative.

Another test you can do is to do the pings / DF test on each hop towards 75.103.97.26. I don't know what's
on their backend -- loadbalancer, DNS redirect, multiple datacenters, etc -- but that should rule the network
path up to whatever 75.103.97.26 is physically.

I'm not up on the latest troubleshooting from an application / email server side, maybe someone else can chime
in. At the very least would be the obvious test of sending a 5MB email to these jokers while on the phone live with
their "IT guys" and asking "okay, did it hit your end?"

My 00000010bits

Regards

[Servers] strange b2b email behavior

Wed, 03 Oct 2012 16:47:35 EDT

mr_boodog posted : Here's a situation that has a bunch of us stumped:

We are experiencing sporadic email delivery failures from our internal Exch2010 server to just one business customer who has a cloud based Windows server using something called SmarterMail. Many times the failures are due to sending attachments 3-5mb. Usually plain text emails are successful.

We have not seen any failure to any other business or customer. I can send much bigger files to my outside email addresses. I have never received an undeliverable notice(unless I mistyped address).

They claim they are not having issues receiving mail from anyone else. I successfully sent them large attachments using my gmail account. We sent many tests from my server; they actually did get a couple of 3mb files, but most of time, emails with attachments failed.

No spam or other type of filters appear to be the problem, as while monitoring it shows the transfer beginning, and then finishing before it even hits their spam.

Their IT is saying it has to be our ISP, our SMTP server, or our firewall configuration. All I see is very high values in a tracert to their address. I tried pinging using -l 1492 -f, fails. 1300 failed. 1200 failed 1000 failed. With 500 I got the ping to work.

We have fiber internet with 40-60Mbs consistently.

After 4 hours of retries, the mailer-daemon sends me this:
Undeliverable:subject
4.4.2 X-Proprietary; lost connection with mail.indlube.com[75.103.97.26] while sending message body#SMTP#

There is other info, but just original headers.

Here is the bottom part of the tracert:

4 2 ms 2 ms 2 ms fp133.ips.paulbunyan.net [205.149.159.133]
5 4 ms 4 ms 4 ms fg29.ips.paulbunyan.net [205.149.150.29]
6 8 ms 8 ms 8 ms te-4-3.car2.minneapolis1.level3.net [4.59.66.13]

7 178 ms 212 ms 201 ms ae-11-11.car1.minneapolis1.level3.net [4.69.136.
101]
8 18 ms 21 ms 24 ms ae-4-4.ebr1.chicago1.level3.net [4.69.136.106]
9 17 ms 24 ms 24 ms ae-6-6.ebr1.chicago2.level3.net [4.69.140.190]
10 * 17 ms 21 ms ae-1-51.edge4.chicago3.level3.net [4.69.138.134]

11 32 ms 17 ms 17 ms chp-brdr-03.inet.qwest.net [63.146.27.17]
12 * * * Request timed out.
13 70 ms 74 ms 74 ms 63.148.218.166
14 73 ms 69 ms 69 ms 216.197.122.66
15 70 ms 69 ms 70 ms 216.119.120.118
16 71 ms 72 ms 70 ms mail.ilcorail.net [75.103.97.26]

Trace complete.

Is this some sort of MTU problem between the server and router hops?

Sorry so darn long winded...just hitting dead ends here.
Jeff