Sorry for the delay in getting back to this assignment note - if you didn't read the first part you can read it here.
Previously: In order to eliminate Microsoft Exchange server idiosyncracies I ran a pure SMTP (client) to SMTP (server) test with the same (bad) results that Stefan had reported. This test although it failed, did narrow down the problem, indicating that the error, most likely, was not within the Microsoft Exchange server and originated at the client site.
Check to make sure that our domain is not blacklisted.
I went to http://www.anti-abuse.org/multi-rbl-check/ and ran a quick check on our company domain name and the external (internet) email server name both of which came up okay. So the company is not on a general blacklist. I also checked the AT&T blacklist site in case the client used AT&T as their ISP - we were also clean there. Stefan gave me a contact number at the client site which got me to their help-desk. After explaining the situation a couple of times to the folks on the help-desk who promised to open a ticket. I finally got a telephone call back two hours later, from their email administrator. The administrator insisted that they did NOT have any filtering rules or blocks setup against our domain and insisted that they did not subscribe to any Blacklist services that may for some reason have our domain (or IP address) listed. I faxed the admin the output of my tests including the test showing that the port was being closed by a server/firewall/router on their network as soon as we tried to establish a connection. I asked the admin to look into their configuration anyway, perhaps check with their network admins and to get back to me, meanwhile I went back to the drawing board.
Check for DNS, MX record, or mail server configuration problems
I went over to http://www.mxtoolbox.com and ran checks against OUR mail server and MX records verifying that everything on our side looked okay. I then ran the same tests on the client mail server, mail.bigcmailsrvr.com to verify that there are no obvious problems (from an email client perspective) on their end.
Not an open relay.
5.242 seconds - Warning on Transaction time
Dig a little deeper
Okay, the client's IT guys are none too responsive and from my side it is increasingly looking like it is their problem – I guess since its not their users that are complaining it is a very low priority problem. Meanwhile, the CFO on my end is now getting annoyed because his contracts are not getting through to the client – I managed to get that pushed off for a bit by having them faxed but this had better get resolved soon now that it's escalating. I'm going to have to dig a little deeper (pun intended). The MXTOOLBOX site has all of the tools needed to continue the tests (in the old days you would have needed a DIG client, PING, Traceroute just to name a few. I used the MX Lookup tool to get a peek into the clients mail server configuration:
Interesting, the client actually has five mail servers configured. The SMTP test link makes it easy to quickly test each mail server right from the web page to verify that they are working and that led to the following result:
The client site has five mail servers defined but one of them does not respond. The server with the pref 700 entry is a dummy entry is this a mistake? a failure in their infrastructure or something else? - Time to call the client tech support people back and get some answers.
Note: The IP Addresses, domain and other names have been changed to protect guilty and innocent alike - if you want to follow along with the tools then I suggest that you use your own servers - the results may even surprise you.