Problem with DNS

Hi,

Does the email server connect to the other server if you use the other server's IP address instead of hostname?

- gurutc

Turn logging on on the virtual server then see what the logs say

I cannot connect using the IP address either.

Ok,

It sounds like there may be an access restriction by address that's in place.  Or it may be a firewall on the email server itself.  Are you able to telnet into the email server that's unable to connect to the other one on port 25?

- gurutc

The external firewall device is not blocking anything and the Windows firewall is Off. I am able to telnet to our email server.

Also; I should mention that our email server connects to every other address I tried (yahoo, Hotmail, Comcast), just not this one domain.

Tracert to the IP Address you're trying to connect to, see if there's a routing problem for that.

Chris

Both workstation and server show identical tracerts. This is really starting to bug me.

Tracing route to mail.reedermgt.com [63.229.21.185]
over a maximum of 30 hops:
 
  1     1 ms     1 ms     1 ms  66-224-144-89.atgi.net [66.224.144.89]
  2     3 ms     3 ms     3 ms  172.23.0.53
  3    24 ms    24 ms    24 ms  core0-gi6-0.tiw.eschelon.com [64.42.50.37]
  4    23 ms    23 ms    23 ms  64-42-50-46.atgi.net [64.42.50.46]
  5    26 ms    23 ms    24 ms  209.210.12.29
  6    63 ms    24 ms    24 ms  tg1-1.br01.sttlwawb.integra.net [209.63.114.134]
 
  7    34 ms    23 ms    25 ms  sl-gw12-sea-4-2-2.sprintlink.net [144.223.84.17]
 
  8    23 ms    23 ms    23 ms  sl-bb20-sea-4-0-0.sprintlink.net [144.232.6.121]
 
  9    25 ms    23 ms    23 ms  sea-brdr-01.inet.qwest.net [63.146.26.197]
 10    50 ms    86 ms    24 ms  sea-core-01.inet.qwest.net [205.171.26.81]
 11     *       54 ms    24 ms  tukw-agw1.inet.qwest.net [67.14.4.90]
 12    24 ms    26 ms    24 ms  tukw-dsl-gw24-186.tukw.qwest.net [71.217.184.186]
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 24     *        *        *     Request timed out.
 25     *        *        *     Request timed out.
 26     *        *        *     Request timed out.
 27     *        *        *     Request timed out.
 28     *        *        *     Request timed out.
 29     *        *        *     Request timed out.
 30     *        *        *     Request timed out.

Select allOpen in new window

I recommend checking to see if there is an underlying DNS or MX record issue. Use the following sites to gather a DNS and MX report on the intended mail server site:

MX ToolBox: http://www.mxtoolbox.com
DNS Stuff: http://www.dnsstuff.com
intoDNS: http://www.intodns.com

Well that's quite puzzling. You could try a packet sniffer and see what requests it's sending.

It still leads me to believe it's a Firewall issue, but that we'd expect to see it block SMTP more consistently if it were.

Chris

Unfortunately I spent the better part of my day yesterday on the phone with SonicWall, and the better part of the day before on the phone at Microsoft. So now all I have is the two of them pointing the finger at one another. MS says it the firewall blocking the packets from coming back into our office, and while the firewall is dropping the return packets, SonicWall says its because the packets leaving our windows server (that are accepted by the destination server and returned) are malformed.

I really, really hate computers. Today I will try to update drivers or change hardware. I have been trying to avoid having to take the server down completely because, well its a production server.

OK Problem solved...

Here is the DL

It was an issue with Windows Server 2008, because it ships with "Receive Window Auto-Tuning Level" on by default. (Note: Vista is also on by default) This setting is available in Windows XP, and Server 2003 but is off by default. All this because my SonicWall does not support this TCP flag.

How do you check this you ask?
Run this command: "netsh interface tcp show global" and you will get something like this:
TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State          : enabled
Chimney Offload State               : enabled
Receive Window Auto-Tuning Level    : normal
Add-On Congestion Control Provider  : ctcp
ECN Capability                      : disabled
RFC 1323 Timestamps                 : disabled

So how do you disable this?
Run this command: "netsh interface tcp set autotuninglevel=disabled"
http://forums.technet.microsoft.com/en-US/winserverprint/thread/82c6a5f9-c7d5-4c34-9139-a05fc0706f3b/

This setting is available on windows server 2003, windows xp, vista and windows server 2008. But only on by default with vista and server 08.

See above for solution.

Thanks for trying.

Interesting, thank you for posting back with the final solution.

Thought I'd add a couple more bits in case anyone else bumps into it (now you've identified it).

MS have a test for support of Window Scaling (aka Receive Window Auto-Tuning Level) here (as part of the TCP High Performance test). I hope it works as expected (or doesn't, as appropriate):

http://www.microsoft.com/windows/using/tools/igd/default.mspx

Window Scaling requires the the router / firewall support RFC 1323:

http://www.ietf.org/rfc/rfc1323.txt

There's an incomplete KB Article detailing devices that are known not to support Window Scaling here:

http://support.microsoft.com/kb/934430

I suspect they should be adding Windows 2008 to the "Applies to" section.

Chris