Managing whitelists and blocklists for Exchange Server environmentsWritten by Paul Cunningham on January 16, 2009
Most organisations that have deployed an email anti-spam solution will at some stage encounter a situation in which a false positive (legitimate email blocked as spam) or a false negative (spam email allowed to pass through) causes a problem for their business.
False positives can affect important business emails and can have a very high cost to the organisation if the email was time sensitive. False negatives can have a similar impact on the business by annoying or offending end users who receive unwanted spam. Both situations can also erode the confidence the end users have in the organisation’s email system.
To combat these issues many organisations configure whitelists or blocklists on their anti-spam systems.
What is a Whitelist?
A whitelist is a list of known safe email senders. Whitelists can be made up of IP addresses, domain names, or email addresses. In most cases businesses will choose to whitelist domain names of highly trusted customers or suppliers, or email addresses that are the source of critical emails.
As a real world example in one customer I worked with the email address that was the sender of voicemail attachments from the external voicemail system was whitelisted to ensure that the anti-spam system never blocked a voicemail message as a false positive.
Whitelists carry some risks. For example some domains such as hotmail.com, ebay.com, and paypal.com are frequently forged by spammers sending commercial spam or phishing emails. If ebay.com was whitelisted it would cause eBay phishing scams to pass through the anti-spam system to end users.
What is a Blocklist?
A blocklist (also sometimes called a blacklist) is the opposite of a whitelist. Blocklists can also be made up of IP addresses, domain names, and email addresses. Businesses will choose to blocklist domains or email addresses that are found to always be the source of spam yet sometimes slip through the anti-spam system as a false negative.
In some customer environments I have worked in, the email administrators have chosen to block entire top level domains such as .ru (Russia) and .tw (Taiwan) because the company did no business with anyone in those countries yet constantly received spam, viruses, and phishing emails from those domains.
Blocklists carry some risks as well. For example even though hotmail.com is often used by spammers blocking the entire hotmail.com domain would prevent any customers or legitimate senders who utilise Hotmail from emailing your business.
How does Exchange Server 2007 manage Whitelists and Blocklists?
Exchange Server 2007 can apply whitelists and blocklists on Edge Transport servers and Hub Transport servers that have the Exchange Server 2007 Anti-Spam components installed.
Whitelists are configured in two places. Whitelisted IP addresses (or the IP Allow List) are handled by the Connection Filter agent but are not configured at the organisation level. Instead they are configured on the Edge Transport or Hub Transport servers. Typically the IP address whitelist is configured on any Transport server that accepts email from the internet.
Whitelisted domains and email addresses are configured on the Content Filtering agent at the organisation level.
Blocklists are also configured in two places. Blocklisted IP addresses (or IP Block Lists) are similar to whitelists in that they are configured on the individual Transport servers where appropriate.
Blocklisted domains and email addresses are configured on the Sender Filtering agent at the organisation level.
Exchange Server 2007 Safelist Aggregation
Although whitelists and blocklists can be managed at the Exchange organisation and server level there is an additional level of configuration that can be applied.
Outlook clients from version 2003 onwards contain Junk Email controls including the ability to specify safe senders and safe recipients. This safelist information is stored in the user mailbox and can be optionally pushed to the Active Directory user object.
The Exchange administrator can enable Safelist Aggregation on the Exchange servers, which aggregates all of the safelist information stored in user objects into one list that Transport servers can apply to the entire organisation. In short this means that if user John added the email address email@example.com to his safelist, the Transport server’s Content Filtering agent would consider emails sent by firstname.lastname@example.org to be trusted and pass them through to the recipients within the organisation.
Disadvantages of Exchange 2007 Safelist Aggregation
Although Safelist Aggregation may help reduce the number of false positives it carries some disadvantages.
Firstly the default configuration of the Update-Safelist cmdlet on the Exchange servers includes both safe senders and safe recipients data, even though safe recipients data is ignored by the Content Filtering agent. This can lead to unnecessary replication traffic and storage bloat on the Transport servers.
Also the update process is cumbersome and requires a scheduled task be created on the Exchange server to run the Update-Safelist cmdlet. There is no functionality within the Exchange management tools to create or manage this schedule.
Finally the default configuration of the Update-Safelist cmdlet includes domain names that end users have marked as safe. For example, John may have intended to add email@example.com to his safelist but instead added @hotmail.com as a safe domain. When this information is aggregated to the Transport servers any spam emails from forged @hotmail.com email addresses will not be blocked by the Content Filtering agent.
Alternatives to Exchange Server 2007 whitelists and blocklists
Despite the value of whitelists and blocklists they can become an administrative burden over time as they are manually managed by the Exchange administrators. Even though the Exchange Server 2007 Safelist Aggregation feature seeks to alleviate some of this burden it also carries disadvantages and risks.
Dedicated third party email anti-spam solutions feature similar whitelist and blocklist capabilities but present them in a more effective and manageable way. When considering an anti-spam solution that will provide these capabilities you should look for products that allow end users to participate in the whitelist and blocklist process but also permit administrators full control of the organisation-wide whitelist and blocklist behaviour.