Hi,
I have been dealing with this for several months now, and I am running out of ideas...

Company-A has an internal mailserver working as expected.

Company-B has itīs mail service hosted by its ISP (ISP-B).

EMails from Company-A can not be delivered to the mailserver of ISP-B .(meaning that I know of at least 3 domains hosted by ISP-B to whom mail canīt be delivered).

I can not establish a telnet connection from Company-A to ISP-Bīs smtp server, from any of the systems on c-Aīs LAN.
It either times out of stays forever waiting for the connection to initiate.
I can do it from 3rd party IPs of diff ISPs.
I canīt find someone else using c-Aīs ISP to run a test.
-

No explanation about why I canīt telnet to the smtp is given.

ISP-B dismisses the issue by simply claiming there are no blockings in his side that could be causing this.
-

All sorts of tests and verification were made in Company-A, and everything looks good. This includes online tests, RBL checks, rDNS, etc. etc.

All I can think of at this stage, is that ISP-B is blocking us, be it by our IP, IP block, or because of some particular hardware/software combination they might have (re: http://support.microsoft.com/kb/895857). No answers received about that either.
-

My very last idea is to spoof the IP address and see what happens if we were on a different IP / IP block ????.
All I need is to find out if the telnet session is prompted properly or even prompted at all...

Suggestions greatly appreciated!
Thanks in advance.

October 18th, 2006, 04:59 PM

SirDice

You can forget about spoofing a TCP connection across the Internet. Blind spoofing is hard enough to do in a lab environment..

Solve the issue.. Use a sniffer to see what's actually going out and getting back..

Can you connect to any other port besides 25?

One thing I can think of is NAT.. The packets at Company-A aren't NAT'ted and Company-A is using RFC-1918 addresses (private address ranges).. Meaning the packets arive at ISP-B with a non Internet routable source address. Using a sniffer on Company-A's Internet connection will show this..

October 18th, 2006, 05:01 PM

Opus00

I assume since you stated Company-A has an internal email server it means you are behind a firewall and possibley using NAT. Have you tried to change your NAT'd address to another in your netblock range. Maybe they blocked just the IP and not the whole range.

I also recall having a similar issue which turned out to be some sort of DNS conflict(difficult to recall exactly since it was years ago) but it had something to do with the DNS name resolving to a different IP or the IP resolving to a different name and the server rejecting the connection since their was no valid A/MX record. I'll try and go back and see if i can get the exact information and will post if i do fully recall it. Sorry for the ambiguity

October 18th, 2006, 07:34 PM

siko9

Quote:

Can you connect to any other port besides 25?

I had scanned it when the issue began and there were some other ports available I think.

Quote:

Use a sniffer to see what's actually going out and getting back..

If I read this correctly, I get nothing after the third packet, wich should be the serverīs response. I DO get a response on packet 4 sniffing from an external location.
I did this from a work station, I would like to avoid messing (even more) with the mailserver because of this.

Quote:

Meaning the packets arive at ISP-B with a non Internet routable source address. Using a sniffer on Company-A's Internet connection will show this..

Company-A has no known issues with any other server. Then again, the same goes for ISP-B.
I sniffed Company-A connection with a non-related mailserver, but donīt know what I whould look at to detect problems with the routable source address??

Quote:

Have you tried to change your NAT'd address to another in your netblock range. Maybe they blocked just the IP and not the whole range.

If you mean the public IP, I havenīt change it, and it would be kinda too disruptive only to find out the problem is at netblock level.
If you mean the internal IP, I have made tests from several systemas in the LAN and they all fail in the same manner.

Quote:

it had something to do with the DNS name resolving to a different IP or the IP resolving to a different name and the server rejecting the connection since their was no valid A/MX record.

We (two ISPs, online tools and me) canīt detect any obvious mis-configurations about DNS, rDNS, etc.
Both ends seem to be resolving fine.

TIA.

October 18th, 2006, 07:43 PM

SirDice

Quote:

Originally Posted by siko9

If I read this correctly, I get nothing after the third packet, wich should be the server&#180;s response. I DO get a response on packet 4 sniffing from an external location.
I did this from a work station, I would like to avoid messing (even more) with the mailserver because of this.

Sniff the traffic at company-A's Internet connection, preferably before and after the firewall.. You need to see the TCP three-way handshake:

A ------SYN-----> B
A <--SYN/ACK-- B
A ------ACK-----> B

Basic TCP/IP stuff.. Forget about DNS etc.. Start troubleshooting the basics. If this works, it means you're able to make a connection and nothing is blocking the traffic at the IP level.

I changed the DNS server used in Comp-A workstation (from Comp-Aīs ISP) for the ones of a different provider and the tracerouteīs results are the same.

I did that on-the-fly, no rebooting, cause I am doing that remotely and canīt risk loosing acces to taht terminal. It still seems valid though, since name resolution didnīt work with the "alternative" DNS.