Can't receive email from certain domains with Exchange 2003.

Question

I have recently ran into a problem with my Exchange 2003 server. I can not receive emails from certain domains. There is only 2 domain names in particular (only one user from each domain has tried sending emails to our domain).

I have turned of filters to test if it was a filtering issue to no avail. I have also looked in the message tracking logs but notice NO emails from either domain when the sender said that they have sent us multiple test emails. I can telnet into the server and get appropriate EHLO and HELO responses, we aren't blacklisted and everything else looks right.

I was wondering if anybody had any suggestions as to what I can check next or look into. If I have forgotten crucial information sorry about that, let me know and I will post more info. Thanks in advance.

Answer 1

I'm assuming that you're receiving email directly from the Internet via an MX record that refers to your Exchange Server computer (based on your statements re: using TELNET to run SMTP "by hand"). If you have any anti-spam / anti-virus filtering in place you owe it to yourself to double / triple check this before you start complaining to third-party sysadmins.

Having said that, the best place to troubleshoot this, next, would be on the sender's end. If you can't get traction from them to monitor their outbound email flow then you could try to capture traffic on your end but it's likely you're going to have a gigantic haystack to comb through.

The senders should be looking for SMTP protocol logs or whatever their email system has equivalent to Exchange "Message Tracking" (/var/log/mail.log, etc) to find out how their server dispositioned a failing message (which the sending user should be able help them identify in their logs). Assuming they are "losing" the message, blocking by policy, etc, it's silly that their servers aren't sending an NDR back to the sending user. Black-holing outbound email is never the answer. (Sending NDRs on inbound email, arguably, may not be such a great idea. Yeah, yeah-- I know that several RFC's say you should... >sigh<)

If the senders can't help you then your only hope is, very probably, to capture traffic at your border and attempt to identify connection attempts (or the lack thereof) from their outbound server. Assuming you can get somebody to send a message on command (say, during a telephone call) and assuming their outbound server infrastructure doesn't take a long time to process the message you should be able to capture an SMTP conversation with the sender's server (or nothing, if it's never getting to you).

Truth be told this really isn't your problem, from a technical perspective. Unfortunately, users and management don't understand the "wild west" nature of Internet email and frequently see it as a reliable form of communication. When reality proves otherwise they often blame the closest email sysadmin, rather than accepting that, not unlike postal mail, it's not a reliable system.

Answer 2

This is a problem which can go wrong at three places:

1. The sender. Does the mail server at the senders site actually work?
2. The receiver. In other words: you
3. A lot of places in between.

For 1) you obviously need the help the the person who manages the mail at the senders site. Not much you can actually do except ask them if they are blocking specific mails (e.g. blocking all mail over a certain size and that person if sending you huge iso files)

2) The receiver: Well, you seem to have checked most things on your end point. And you receive all other mails (well, bar one other sender). The only thing left to check is if you receive your mail directly or via a third party.

3) If the senders mail server does not contact your mail server directly but uses an indirect route then you have a few additional places where things can go wrong. All outside your control.

Personally I ran into a similar problem when spammers started to put their spams in PDF files. All or mail was received via a spam filtering agency and they decided that all PDFs where not suspect. Those mails got quaranteed and the final recipient got a once per week mail stating that he had quaranteed mails. (The once per week setting was explicitly set by the user and promptly forgotten). Something similar could be the case.

Answer 3

Uh, what you need to do is tell the mail admins at these domains (and your users, if applicable) that you can only deliver mail that actually arrives. If it doesn't arrive at your systems, there's nothing you can do about it, period.

I've had this "problem" foisted on me dozens of times as a Domino or Exchange admin and the answer is always the same. The problem's on the sender's end (and have I ever seen some retarded ones of that nature) or somewhere in between you and them. Either way, it's out of your control and there's not a thing you can do about it.

"Hey, [other mail admin], your shit's broken. Fix it" comes screaming to mind as the canned response I'd love to give every time this comes up.

Answer 4

is this happening to all mail from the specific domains? If you contact their IT, what IP addresses will they send from?

If they are always failing they should have a notification of the failure and why. Have them forward the failure to your public mail account so you can see the rejection notice.

You can verify if a connection was even attempted in the IIS logs there is an SMTP log. Turn up the logging level if need be. Look for their IP.

This can also be a firewall issue on your side. If you can, try to see if you can look through logs. Make sure you have the latest updates.

I have also seen poor ineternet connections cause this issue. Perform a continous ping for 10 minutes to your ISP or some otehr site that won't mind the test. High latency or failed packets means you need to talk to your ISP about the line.

Lastly, if you have the resources set up a SPAM filtering linux server. A VM running on another machine that forwards email to your Exchange server will be good. If it still happens, then you know it's not your mail server, and you get an extra layer of filtering...

Answer 5

Try the telnet test on each of your MX records. I've previously come across a similar situation which turned out to be caused by a combination of the sending system always using a lower priority MX record and a system which only accepted deliveries on the primary. The secondaries simply swallowed the messages without passing them on nor bouncing them back.

In that particular instance the defective system was MessageLabs, which is a Symantec owned spam filtering service, the operators of which claimed that their system acted that way because, and I quote, "only spammers every use the secondaries". The only solution available to me was to eliminate all but the primary MX record, as the customer wished to continue to use MessageLabs for filtering.

Answer 6

The Message Tracking log is useful only for emails that make it to Exchange, and more specifically, for emails that are delivered to the Information Store. Emails that are blocked by Recipient or Sender filtering are not going to show up in the Message Tracking log, but they will show up in the SMTP log. You need to enable logging on the SMTP service on the Exchange server as that's the "entry" point for emails arriving at your Exchange server. Emails that are blocked by Connection filtering will not show up in the SMTP log so you need to enable logging on your firewall or router as that's the "entry" point for emails arriving at your network. If there are no entries in the Message Tracking log, the SMTP log, or your firewall/router log then you can be confident that the emails in question are not arriving at your network and/or your Exchange server.

Next you need to make sure your public DNS is correct and that your NS, MX and associated A record(s) are correct and are resolving correctly. If there's a misconfiguration in your DNS then that's a potential failure point for external email servers trying to send email to your domains. If there are problems with your public DNS, that's your problem and you need to fix it.

If the aforementioned logs show no entries and your public DNS is configured and working correctly then, and only then, can you say with certainty that the problem is not on your end.