[TriLUG] Email issues

[Brad Jorsch]

On Fri, Feb 02, 2007 at 10:15:34PM -0500, S B wrote:
> 
> Is it possible I have the ECN bit set, so the destination feels entitled to 
> drop the packets (for some reason) ?

Before the bit was assigned to ECN, it was reserved and
supposed-to-be-zero. Some old hardware/software decided that meant they
could drop everything that had the bit set.

On fairly modern Linux kernels, /proc/sys/net/ipv4/tcp_ecn should let
you toggle it on and off.

> (1) traceroute takes 10 hops to get to the shared hosting provider boundary 
> and then no responses (just 20 loads of  " * * * ").
> This is true for the shared server that had the SMTP/HTTP  problem, *and* 
> the one that didn't have the problem.

Does tcptraceroute do the same thing? A tcptraceroute to port 80 has a
better chance of getting through than a standard traceroute.

> 2) If I ping the shared servers, the one with the SMTP/HTTP problem doesN'T 
> respond but with server without the SMTP/HTTP problem *does* respond.
> 
> 3) If I telnet to port 25 (SMTP) on the shared servers, again the one with 
> the SMTP/HTTP problem doesN'T respond but with server without the SMTP/HTTP 
> problem *does* respond.
>
> If I repeat step (1) (2) and (3) from my Roadrunner home connection, both 
> shared hosting servers respond correctly !

Something somewhere is definately filtering the packets. Without access
to the machine with the problem, i'm not sure how to determine where the
problem might be though. I'd want to use tcpdump (if possible) to see if
the packets are getting there, check the firewall rules to see if
there's anything stupid there, and try connections (especially
tcptraceroutes) in the opposite direction to see if the blocking is in
both directions or just one.

How different are the paths from the two sources to the shared hosting
provider boundary? If they end up the same going into the boundary, it'd
be a good guess that it's something in their network or on the
destination box itself.