Recall Emails sent in error from Outlook Web Access (OWA)

WinDeveloper IMF Tune
WinDeveloper IMF Tune

Email Auto-Whitelisting Pitfalls

Alexander Zammit

Alexander Zammit Photo

Alexander Zammit has been developing server applications for over 15 years. Most of his works involve Exchange integrated applications, including a FAX server, a mail security product and anti-spam products.

  • Published: Jan 27, 2011
  • Category: Anti-Spam
  • Votes: 5.0 out of 5 - 2 Votes
Cast your Vote
Poor Excellent

Auto-Whitelisting is a powerful email hygiene tool. As often happens, power can only be effectively applied if coupled with the necessary control functionality. In today’s article we discuss the hidden traps of sender auto-whitelisting.

Auto-Whitelisting is a powerful email hygiene tool. As often happens, power can only be effectively applied if coupled with the necessary control functionality.

In today's article we discuss the hidden traps of sender auto-whitelisting. I learned about this while working on an auto-whitelisting solution for the Exchange Content Filter/Intelligent Message Filter. However the pitfalls discussed here are inherent to auto-whitelisting, not specific to any particular implementation.

How Sender Auto-Whitelisting Works

Let's quickly describe how sender auto-whitelisting works in most email anti-spam solutions. Such a component is tasked with the automatic discovery of legitimate foreign senders that our organization is interacting with. Once discovered these addresses are whitelisted, and subsequent emails skip filtering.

Once the initial discovery is completed, the only legitimate emails undergoing spam filtering will be those from new contacts. Of course if less legitimate emails are filtered, less legitimate emails risk false classification.

And let's not forget what administrators love best. Automatic means less manual work. Indeed the need for maintaining a manual sender whitelist is greatly reduced.

Someone in sales would probably conclude this article here. But since you are reading this, it is likely you already have some practical questions which we will be discussing next.

How Long Should an Address be Whitelisted?

Foreign contacts can be grouped in two broad categories. There are contacts with which you only exchange emails for a short period of time. For example technical support will often deal with contacts that go dead once the support case is closed. Other contacts might be long term partners and continue to be relevant over time.

Short term contacts are an excellent test for an auto-whitelist. Without an auto-whitelist, these contacts would normally never get whitelisted. Their life span is simply too short for an administrator to be bothered with updating the manual whitelist. On the other hand, if the auto-whitelist is fast to discover new addresses, this email exchange stand to benefit from the automated process.

The discussion on short term contacts leads to the question; how long should emails be retained in the whitelist? Quite obviously once the email exchange is exhausted there is little point in whitelisting the foreign address any further.

Let's look at this from a different angle. Is there any significant benefit in purging dead contacts? Quite obviously with time dead contacts can greatly inflate the whitelist. Technically it is not that difficult to build a whitelist that is capable to efficiently handle a large number of addresses. A more significant problem with dead contacts is the risk for one of these to get infected and start distributing spam or some sort of malware. If the whitelist is filled with hundreds of thousands of dead contacts we are unnecessarily exposing ourselves.

How Do We Purge Dead Contacts?

Once we identify the need for purging dead contacts the HOW question comes next. This is one of those questions where we could get really creative and come up with all kind of complex logic to determine when a contact goes dead.

Otherwise we can go for my preferred type of solution, that of using simple predictable logic. In IMF Tune we keep track of when a foreign address was last discovered. Whenever the address is re-discovered we update its time stamp. In this manner we identify those addresses with which no emails have been exchanged for a long time. An address gets deleted once it reaches a configurable age limit. Long term contacts will get a new lease of live on each re-discovery whereas short term contacts get purged.

Do We Really Want to Whitelist all Foreign Contacts?

As already discussed, auto-whitelisting relies on a discovery process for gathering contact addresses. However should we really whitelist ALL of these? Quite obviously not all contacts are equally important. Some might be absolutely irrelevant to the Organization business.

Personal and other non-work related contacts may be considered as a source of whitelist littering. We can minimize this with the help of a more selective contact discovery process. We can identify which addresses are to be collected by looking at the local user involved in the email exchange.

As an example Support and Sales mailboxes will exchange emails with Organization clients, so we certainly want to whitelist foreign contacts interacting with these mailboxes. However the job of other Organization members might not involve any interaction with external clients. Thus their foreign contacts are unlikely to be of any relevance to the Organization business.

Another important example is the case of mailboxes manned by automated processes. Consider the case where you have a mailbox that sends automated emails to anyone filling some web form. It might be wise to also exclude that from the discovery process.

It's Not Always Possible to Do Everything Automatically

Everyone loves a fully automatic process since little to no maintenance work is required. However, even the smartest auto-whitelisting process may end-up whitelisting the wrong address.

For example a local user might be tricked to start an email exchange with a malicious sender or the case where some contact turns out to be a pest. In all cases it is a must for any auto-whitelist to allow the administrator to go back and exclude specific addresses from being whitelisted.

Final Tips

Implementing sender auto-whitelisting for the Exchange Content Filter/Intelligent Message Filter in IMF Tune v5.6 was an opportunity for me to better appreciate the practical details behind this technology. We developed our solution to effectively counter these shortcomings and to arm the Administrator with the necessary configuration tools to stay in control.

However the bottom line was that the problems being solved were not specific to IMF Tune. Indeed as highlighted in this article most of the problems are inherent to the automated nature of such a process.

So I hope that by sharing this experience you will be in a better position to employ auto-whitelisting no matter which email hygiene tool you are running.

Copyright © 2005 - 2014 All rights reserved. ExchangeInbox.com is not affiliated with Microsoft Corporation