Note: This article makes references to WinDeveloper IMF Tune, an application that was available as freeware at the time of writing. IMF Tune is today a commercial product.

The Intelligent Message Filter IMF, is one of the anti-spam products with the least configuration settings I ever came across. It boils down to four settings, Gateway SCL, Gateway Action, Junk Email SCL, and enabling of IMF per SMTP virtual server. The lack of options may easily give the impression that the configuration is trivial.

Recently, a client for whom I was developing some software, installed IMF. He came across the most common problem in setting it up. What values should the SCL settings have? This question led me to develop a new freeware application, WinDeveloper IMF Tune, that helped him getting the settings right. So today I would like to discuss the use of this application with the hope that it can be of benefit to many others.

What's an SCL by the way? The SCL rating is a value from 0 to 9 assigned to emails as a classification of their likelihood of being spam. 0 indicates lowest probability whereas 9 indicates near certainty of the email being spam. Values in between indicate a varying degree of certainty.

Given the SCL value, an administrator is expected to decide what to do with the email. Emails with ratings at the lower range of SCL values are typically permitted to go through as valid email. High SCL ratings enable Administrators to be brave and take drastic actions such as delete, reject or archive. Values in between typically require emails to be deposited to the Junk Email folder for verification by the end-recipient. So effectively our goal is that of identifying these three SCL value ranges. Getting them wrong may lead to many valid emails ending in the Junk Email folder. Getting them totally wrong (and some do!!) may lead to loss of valuable emails.

Quick IMF Configuration Tour

Before delving deeper into SCLs, let's have a very quick look at the IMF configuration to make sure everyone is in sync. The main IMF configuration settings are available from:

<Organization> | Global Settings | Message Delivery <properties> | Intelligent Message Filtering <property sheet>

Here you will find Gateway SCL, Gateway Action and Junk Email SCL. The Gateway settings are used to filter emails scoring very high SCLs. At this end one can configure IMF to reject, delete or archive emails. The Junk Email SCL identifies the emails that should be deposited to the Junk Email folder. Obviously this is set to a lower value than the Gateway SCL. Note that there is a typo in the IMF configuration. The text "Move messages with an SCL rating greater than or equal to:" should read "Move messages with an SCL rating greater than:". Combining these two SCL values we end up with three buckets for email classification as depicted below:

Enabling of IMF per virtual server is done from:

<Organization> | Servers | <Exchange Server> | Protocols | SMTP | 'Intelligent Message Filtering'

What does the SCL really mean?

The first point to make clear is the fact that the SCL range between 0 and 9 is not linear. Let's rephrase this. Do SCL values such as 4 or 5 indicate 50:50 chance of an email being spam? Does it mean that half of these emails are spam and half ham? The answer is no. Such linearity would make large part of the SCL values useless.

Using IMF Archiving feature it is possible to get an idea how the level of certainty changes from one SCL value to another. To compile this table I just looked at a few sample emails between SCL1 and SCL 9, hence the values are purely indicative to illustrate this point.

As already said these values are purely indicative but it is clear that anyone rejecting/deleting/archiving emails with SCL lower than 7 is looking for trouble. Also values up to 3 or 4 can cause quite a large number of false positives.

Did I already say these values are purely indicative? This means that in practice one has to see IMF in action to see the real meaning of SCL values. My aim so far was to block anyone (see the newsgroups) from doing crazy stuff. What we need is to start off with some reasonable SCL values and fine tune our settings by checking what is being filtered.

Initial SCL settings

Putting myself in the position of an administrator deploying IMF for the first time this is how I would start the configuration settings:

Starting with no gateway action is wise. It is first best to build your confidence in IMF before giving it the trust to remove emails. This is of course true for any other application as well. Once configuration is done make sure to enable IMF per virtual SMTP server as shown previously.

Next we need to check which emails are ending in the Junk Email folder and which in the Inbox. Note that for the Junk Email folder to be active, must be enabled through Outlook 2003: Tools | Options | Preferences | Junk E-mail... or through OWA: Options | 'Privacy and Junk E-mail Prevention'.

WinDeveloper IMF Tune freeware

It is now time to verify how well our initial SCL settings are doing. There are two things to check:

1. Valid emails ending in the Junk Email folder (false positives).
2. Spam remaining unfiltered ending in the recipient Inbox (false negatives).

To do this we need to identify the SCL ratings for mails with false results. This information is not readily available unless a tool such as WinDeveloper IMF Tune is used. IMF Tune processes all emails whose SCL score is larger than the Junk Email SCL. It then prefixes their subject with the SCL score as shown below.

IMF Tune now enables us to look into the Junk Email folder and see how each of the individual emails is being classified. The subject prefix enables us to sort all emails by SCL which is very useful.

Let's say a number of false positives are identified with SCL 5. The next step would be to determine what would happen if we were to raise the Junk Email SCL level to 5. Naturally this will cause all emails with rating of 5 or less to remain unfiltered. So it is best to determine how many false negatives will this cause. Sorting emails by SCL rating will enable us to visualize this. If a good number of emails with SCL 5 are valid then one should certainly raise this level. On the other hand if this is a small percentage it might be best to leave it as is. This decision can only be taken by analyzing real live data.

IMF Tune is not configurable. It reads the IMF configuration every 5 minutes and adjusts which emails to process accordingly. Hence on changing the IMF configuration, for a short while, you may end up with some missing SCL prefixes at the Junk Email folder or some SCL prefixes at the Inbox. To avoid this restart the IIS Admin service, otherwise just be patient for a few minutes.

IMF Tune only processes Junk Email. The subject is clearly an important piece of information which is best left alone for legitimate emails. So IMF Tune is most useful when analyzing false positives. If a significant amount of spam is reaching your Inbox then you may of course lower the Junk Email SCL. You may then use IMF Tune to analyze the result of this change.

Determining the Gateway SCL settings is another area where IMF Tune comes handy. We started our IMF setup with no gateway action. Now that the system has been running for some time it is good to look at the emails being assigned high SCL values such as 8 and 9. Most organizations are unlikely to get false positives at this level. If you feel enough confident in IMF SCL ratings at this end, then you may want to switch to archiving or even something more drastic like delete or reject.

To conclude this, my client is currently using archiving as Gateway Action, 8 for Gateway SCL and 5 for Junk Email SCL. He is also using another commercial Anti-spam product. I didn't discuss the ramifications of this but in effect it means that these settings are specific to his particular setup. I hope you will find WinDeveloper IMF Tune helpful and make sure to grab your copy by following the link at the references section. I will be happy to hear your feedback through the www.windeveloper.com contact form.

References