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.
| X-SCL |
Confidence Level (%) |
| 1 |
52.68 |
| 2 |
57.43 |
| 3 |
63.87 |
| 4 |
67.41 |
| 5 |
82.82 |
| 6 |
90.50 |
| 7 |
94.72 |
| 8 |
97.82 |
| 9 |
99.58 |
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:
| Gateway Action |
NoAction |
|
| Gateway SCL |
8 |
In this case this is not relevant, but 8 would be my starting value for any other gateway action setting. |
| Junk Email SCL |
4 |
Emails with SCL values between 0 and 4 will go straight to the inbox. All the rest goes to the Junk Email folders. |
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:
- Valid emails ending in the Junk Email folder (false positives).
- 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
WinDeveloper IMF Tune