We continue to accumulate logs, and the databases grow in size. We can send and receive e-mails in the network (a T1 with a firewall), but we are unable to receive outside e-mails, although we can send. Since we accumulate logs daily, the implication is that the mail comes in, but is not accessible via Outlook (the queue is empty). The system was working fine, and there have been no changes made in the last two years. The domain host was contacted, and a non-technical person responded with, "It's us, not them."
So, that said, I would start by doing some tests from outside your corporate network. For all intents and purposes, this could be a home machine connected to the Internet over a cable modem or similar. For the purposes of this discussion, I'll call your SMTP domain "company.com."
First, launch a command prompt and use NSLookup to check the public DNS record associated with your domain. See the following example:
> set query=mx
company.com MX preference = 10, mail exchanger = aslan.company.com
Note that the first thing I did was use the SET command to scope the query to return only Mail Exchanger records. I then ran the query against the SearchExchange.com domain. I see that one MX record is listed, aslan.company.com. I also note that the record returned is "non-authoritative" since I'm pointing to my local ISP's server.
Now find the authoritative server:
> set query=ns
Company.com nameserver = caspian.narnia.com
caspian.narnia.com internet address = 126.96.36.199
At this point, just double-check the MX record held on the authoritative server to confirm it is also listed as aslan.company.com. You can do this using the same set of commands I used earlier. If there is a discrepancy, go to the hosting provider that looks after your public DNS record, and ask it why it made a change to your MX record.
Assuming there is no discrepancy, try telnetting to port 25 of the server listed in the MX record.
>telnet aslan.company.com 25
This pops you into a telnet session, and should display some sort of SMTP banner similar to the following:
220 aslan.company.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.211 read
y at Wed, 21 Sep 2005 19:15:48 -0700
If, for some reason, you don't manage to establish a telnet session, then this is where your problem lies. The server that 'the world' thinks is your public mail gateway is not, in fact, accepting connections on port 25, which is the port used for SMTP traffic. This is bad. (It is sort of like not having a mailbox out front of your house -- nowhere to put the mail!) This could be caused by server a misconfiguration or a firewall somewhere between the outside world and your mail gateway.
If you did manage to connect to the server, the next step is to issue telnet commands manually to send yourself a test message. The steps to accomplish this are outlined in Microsoft Knowledge Base article 153119, XFOR: Telnet to port 25 to test SMTP communication.
(I actually recommend that *anyone* who regularly works with Microsoft Exchange memorizes and practices the steps required to send a message via telnet. It's pretty simple to learn and this is an invaluable skill when it comes to troubleshooting.)
At this stage, it's quite likely that you'll get an error during the process of trying to send an inbound message. In that case, you need to take the specific error message (i.e., "relaying denied," etc.) and troubleshoot further from there. The server you're connected to (either your server or your ISP's, depending on your set up) is misconfigured.
I suspect that, by now, you have found your problem, and are well on the way to determining root cause. Once you have resolved the issue, you should be able to send yourself a message through the telnet session, just to confirm things are working.
If all of this still doesn't solve your issue, try using the Message Tracking Center to see where the message is going in your environment. Let me know how it goes, and if you have further questions!
Do you have comments on this Ask the Expert Q&A? Let us know.
Related information from SearchExchange.com:
This was first published in November 2005