dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
4
share rss forum feed

HELLFIRE
Premium
join:2009-11-25
kudos:18

1 recommendation

reply to mr_boodog

Re: [Servers] strange b2b email behavior

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=115
Reply from 75.103.97.26: bytes=1300 time=95ms TTL=115
Reply from 75.103.97.26: bytes=1300 time=93ms TTL=115
Reply 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=115
Reply from 75.103.97.26: bytes=1200 time=106ms TTL=115
Reply from 75.103.97.26: bytes=1200 time=96ms TTL=115
Reply 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=115
Reply from 75.103.97.26: bytes=1000 time=93ms TTL=115
Reply from 75.103.97.26: bytes=1000 time=98ms TTL=115
Reply 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=115
Reply from 75.103.97.26: bytes=500 time=95ms TTL=115
Reply from 75.103.97.26: bytes=500 time=93ms TTL=115
Reply 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=115
Reply from 75.103.97.26: bytes=1472 time=93ms TTL=115
Reply from 75.103.97.26: bytes=1472 time=93ms TTL=115
Reply 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

mr_boodog

join:2008-08-12
55824

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.