Why is the Intelligent Message Filter not processing emails? This is one of the most recurring questions I receive when supporting IMF. As we shall see, there are various possible causes. These range from incorrect configuration settings, to unsupported usage scenarios, to broken Intelligent Message Filters necessitating a re-install.
What makes you believe IMF is not processing emails?
Are we sure IMF is not processing? Is it because a lot of spam remains unfiltered? Is it because the Junk Email folder is empty? As always the symptoms exhibited may be misleading. Having unfiltered spam is certainly not enough to conclude that IMF is not processing emails.
The performance monitor exposes the heart beat of IMF. Through its counters, SCL assignments may be measured in real time clarifying whether or not IMF is alive. For more details check
Looking at IMF through the Performance Monitor.
If the SCL counters remain unchanged whilst inbound emails are flowing through, then we are certain IMF is not processing. This is the type of scenario I will be discussing today. Otherwise you might be experiencing problems with Junk Email Folder enablement, or maybe it is just a matter of exceedingly high SCL threshold configuration. These are subjects we already discussed in the past in:
Enabling/Disabling the Junk Email Folder and
IMF SCL Configuration - getting it right.
Top Five Reasons for Unprocessed Emails
Here are the top reasons for IMF not to process emails:
- IMF is not Enabled
- Broken IMFv2
- POP3 and non-SMTP email delivery
- Connection Filtering IP Accept List
- Authenticated Connections
The little IMF enablement checkbox still manages to top the chart in this area. Its unintuitive location and the change in enablement interface from IMF v1 to IMF v2 certainly did not help.
Occupying the second spot, are a good number of corrupted Exchange SP2 IMFv2 installations. Unfortunately many still do not read the release notes before installing service packs. To their own expense, these later discover that IMF v1 and IMF v2 cannot be mixed.
Both IMF enablement and the problems with broken IMFv2 installations were discussed in
Troubleshooting IMF v2.
POP3 and non-SMTP email delivery
Next in the chart comes the email delivery protocol. IMF only scans inbound SMTP traffic. This is very often the problem with Small Business Server users. Emails downloaded by the 'Microsoft Connector for POP3 Mailboxes' go through unfiltered.
Configuring Exchange to handle incoming emails directly through SMTP is the most obvious solution. An alternative is to adopt a POP3 to SMTP gateway. This type of solution would still retrieve emails from the service provider using POP3. However the gateway would then deliver emails to Exchange via SMTP. This is different from the connector shipped with SBS which injects emails straight into Exchange.
Connection Filtering IP Accept List
The connection filtering IP accept list provides another window through which emails go through unfiltered. This list identifies trusted hosts whose emails are assumed to be legitimate.
Sometimes the wrong host IP ends up in this list. This often happens in systems where Exchange does not directly handle internet originating email. Instead some other SMTP host relays the traffic, maybe adding content filtering or anti-virus protection in the process.
Entering the relay host IP or subnet address to the IP Accept list, leads IMF to leave all emails unprocessed. For a detailed discussion on how to configure the IP Accept list check
Connection Filtering IP Accept List in Exchange SP2.
Assuming the system was not compromised, an authenticated SMTP connection is established by a trusted host. Thus IMF will also ignore emails delivered over such connections.
Spam will normally enter the network over an anonymous (unauthenticated) connection. This is where anti-spam filtering should take place. Nevertheless if the internet facing SMTP server does not perform anti-spam filtering and relays emails to Exchange over an authenticated connection, a new window for spam delivery is opened.
The standard solution is to filter spam right at the edge where the connections are unauthenticated. Alternatively IMF may be forced to scan these emails with the help of a registry tweak. This leads IMF to scan all emails delivered through an authenticated connection. Thus one must decide whether such a change would put the delivery from other trusted hosts under increased risk of false classification.
Here are the registry key and value required to enable scanning of authenticated connections. The value is of type DWORD. A registry script to set this value is also included here (see downloads section).
Looking at IMF through the Performance Monitor
Enabling/Disabling the Junk Email Folder
IMF SCL Configuration - getting it right
Troubleshooting IMF v2
Connection Filtering IP Accept List in Exchange SP2