Main Contents

Microsoft Exchange Un-Intelligent Mail Filter

March 17, 2008

I discovered an annoying problem with Microsoft Exchange Intelligent Mail Filter (IMF) recently. First, IMF works like this: It scans inbound e-mail and if it determines it to be SPAM or UCE of any kind, it will assign it a number from 1 to 9 and add an extra e-mail header to the email. The header looks like this:

 X-MS-Exchange-Organization-SCL: 9

You then have limited options on what you can do with the e-mail. On the server side, you can reject, delete or ignore it based on the number. For example, anything 8 or above, delete it. IMF updates are published regularly and get updated through Microsoft Updates. The same rule engine that runs on the server also can run on the Outlook client.

So what are the problems with it? Primarily, you don’t have much insight into the filter rules. There is no good way you can figure out why an e-mail was rejected, and only limited manipulation of the rules. For the most part what IMF thinks is SPAM is SPAM. You can’t get any usable reports from it, either. There are some performance counters available (look here), so you can extract basic information such as how much UCE it catches and at which SCL levels, but that’s about it. Considering most other SPAM filters available, one must ask, how is this Intelligent?

The problem I recently discovered has to do with Sender ID or Sender Policy Framework (yes, there are differences between the two which I won’t get into here. I’ll use SPF to refer to both). I have a single e-mail server that sends and receives e-mail for multiple domain names. I noticed that others’ Exchange servers were rejecting or dropping some of my e-mails. Investigating further, Exchange was giving my e-mails an SCL (SPAM Confidence Level) of 9. The e-mails didn’t have any obvious indication of being SPAM. I figured out that my e-mail server was in DNS on one domain (e.g. abc.com), and I was sending e-mail from another domain (e.g. def.com). The receiving Exchange servers were performing reverse lookups and they couldn’t match the e-mail domain with the sending server domain. Understandably, this should increase the SCL, but my problem is Microsoft increases it to 9, the highest level possible, regardless of content and other factors. In my opinion that’s excessive, especially when you can’t change this rating. In my other opinion, I think Microsoft is doing this because they are the big backers behind Sender ID. And, the solution to the problem is to add Sender ID vaildation to your domain. After making the necessary adjustments to DNS, IMF no longer tagged it as the worst kind of SPAM possible.

To prevent the issue, using the example above, add a TXT record in DNS for the def.com domain that allows e-mail to come from the abc.com domain, like this:

def.com. IN TXT "v=spf1 mx ptr include:abc.com ~all"

If you want to include other options, such as valid subnet ranges, to validate a safe sender (recommended), do something like this:

def.com. IN TXT "v=spf1 ip4:4.5.6.0/29 ip4:7.8.9.0/24 mx ptr include:abc.com ~all"

For more information, go to http://www.openspf.org/. Here you can find a wizard to help create an SPF record for your domain.

You can test your settings by sending an e-mail to check-auth@verifier.port25.com. You will get an automated reply back that checks various settings, including SPF and Sender ID, among other things.

Filed under: Microsoft, Network, Windows |

Sorry, the comment form is closed at this time.