Dealing with spam in Exchange 2007
It’s vital to keep control of spam. Not only does it reduce productivity by distracting staff, it also brings the risk of malware – either as a payload in a message or as a link to a site that’s ready to deposit software on your clients’ PCs. It’s also a prime source of phishing attacks, where messages try to get people to divulge login details for finance sites. Business bank accounts are a common target for phishers, as they often contain more funds than a personal account.
Your clients trust you to protect their businesses, and their mail server is one of the first lines of defence. While you can help them invest in border protection tools or cloud-based malware and spam filters, there are also the tools built into common mailservers like Exchange, tools which can be surprisingly effective. There are also the tools that can plug in to a mail server, adding to its security and helping you manage the torrent of spam and malware.
Exchange 2003 introduced a basic set of anti-spam tools in the shape of the Intelligent Message Filter. It worked well enough, though you had to use tools like IMF Companion and IMF Archive Manager to deal with quarantined messages (the original Web sites for both applications are now gone, but you should be able to find download links to copies). The filter rules were also only updated irregularly, and you had to shut the server down to install any updates. You could use anti-spam blacklists to improve detection, but there was no real way of tracking just how effective this was.
Microsoft reworked things with Exchange 2007. IMF became part of the new Content Filtering tools built into the mail server, and detection rules were updated a lot more regularly – and could be applied through Windows Update without you having to shut down and restart the whole Exchange server. While the initial release of Exchange 2007 left you to use PowerShell to implement and manage Content Filtering, things were improved with the release of SP1. Now you can use wizards and the Exchange Management Console to set up and manage Exchange 2007’s anti-spam tools – though you’ll still need to use PowerShell to handle more complex tasks, including managing whitelists.
Content Filtering still uses the Spam Confidence Level (SCL) ratings used in Exchange 2003 to categorise spam, so you can use the same levels for acceptance, quarantine and rejection with Exchange 2007 that you’re familiar with in Exchange 2003.Exchange 2007 also changes the way suspicious messages are quarantined, requiring a new Quarantine mailbox (and an appropriate Active Directory user). There’s a half-finished feel to this new approach, as it can be hard to view and manage quarantined messages – especially from inside Outlook. Managing multiple Outlook profiles can be a complex task. Luckily there’s an acceptable, and extremely portable, alternative in the shape of Outlook Web Access.
Setting up Exchange 2007 anti-spam
Getting Exchange 2007’s anti-spam tools online should be part of your initial set-up process. Once it’s installed you’ll need to open the Exchange Management Shell and run one of the bundled PowerShell scripts. Change directory to c:\Program Files\Microsoft\Exchange Server\Scripts and run install-AntispamAgents.ps1 to enable the Content Filtering tools. Make sure you use the Exchange Management Shell, not the standard PowerShell console, as it loads the appropriate libraries automatically, ready for your scripts to run.
Once you’ve installed the anti-spam agents you’ll need to restart the Exchange transport service. In the Exchange Management Shell type restart-Service MSExchangeTransport to quickly bring the Content Filter online. Switch to the Exchange Management Console, and open the Organization Configuration view. You’ll see a new Anti-spam tab in the Hub Transport section, and this is where you can enable and tune the various spam detection tools used by the Content Filter. The Content Filtering rules are the first port of call, and these let you define what happens to messages that have been identified as spam. You’re able to delete, reject or quarantine messages – delivering quarantined messages to a special mailbox.
Automatically deleting messages that are identified as spam is a risky approach, and we’d recommend just rejecting messages that have the maximum SCL score. This will send an appropriate bounce message, so legitimate senders will be able to tell that their messages are being detected as spam. There’s little need to worry about spammers seeing any bounce messages – the spambots they use won’t have legitimate email addresses. The only person it will inconvenience is anyone whose legitimate email address is used as the reply-to address for spam (a ‘joe job’).
The bigger issue is handling mail that may or may not be spam. That’s where Exchange’s quarantine mailbox comes in. As noted, you need some workarounds to manage it effectively. First you need to create a Quarantine mailbox account, by creating a new Active Directory user (‘quarantine’ is a good name) and giving them a mailbox. If you’re working with a large number of users, Microsoft recommends creating a separate mailbox database for this user. With the mailbox and user in place you can then using the Content Filtering dialog box in the Anti-spam tab to set a SCL for automatically quarantining messages, giving it the fully qualified SMTP email address for the quarantine mailbox.
The default anti-spam tools in Exchange 2007 are effective enough to allow you to set a quarantine SCL score of 6, leaving Outlook’s junk email filter to handle anything that gets through. Once messages have been filtered you can use Outlook or Outlook Web Access to manage the quarantine folder. Setting up multiple Outlook profiles to handle the quarantine user and mailbox isn’t particularly easy – and it’s not really practical when you’re working with several clients. Instead, just log on with Outlook Web Access using the quarantine user’s password, and you’ll be able to triage the quarantine mailbox, using the Send Again function in OWA to send falsely-identified messages to their correct destination (as long as you’re using Internet Explorer). Regular false positives can be whitelisted using some PowerShell to add domains to a list of addresses that will always be accepted.
You can improve on the tools used to identify spam messages by subscribing to a real-time block list inside Exchange 2007. Set the IP Block List Providers properties with the DNS details of the RBL you plan to use. One of the best is Spamhaus’ blended list which includes known spam domains as well as the IP addresses of PCs that are currently sending spam. Use zen.spamhaus.org to subscribe your clients’ Exchange servers to this list. There are other properties you can set to manage the SCL rules used by Exchange – including identifying messages sent through open proxies, messages with SenderID set, messages with blank sender fields in their headers, and senders who are also sending messages to non-existent users at a site. One interesting option is the ability to use a whitelisting service, which provides a list of DNS addresses of sites known not to send spam. You need to keep your clients’ content filters up to date to get the most from Exchange’s built-in anti-spam tools. Updates are published at least weekly, so make sure to regularly check Windows Update on your clients’ servers to install any pending filter updates; you don’t even have to reboot Exchange
to get the updates.
Using third-party anti-spam tools
Exchange 2007’s anti-spam tools are adequate, but they’re only part of securing an Exchange server. To really lock down a network requires a layered approach, adding a mix of tools to your clients’ networks – from additional software and services to appliances that take load away from busy servers.
One quick option is to use the tools provided by Cloudmark. You’re probably familiar with the Outlook plug-in, which adds tools for reporting and managing spam. The database Cloudmark has built from the reports sent back by the Outlook toolbar acts as a huge early warning radar system that can track the arrival of new waves of spam – and quickly pass that information to the system’s subscribers. If you’re using the server-side tools, messages are compared with the network’s spam signatures, and then filtered appropriately. It takes less than 30 minutes for the Cloudmark network to generate a new signature for each new spam message – that’s enough time to significantly reduce the risk of spam (and spam-vectored malware) from getting into your clients’ mailboxes. Cloudmark operates on a subscription basis and a 75-user one-year licence costs $1,599.
Microsoft provides additional security tools in its Forefront Security For Exchange Server. This is a powerful tool that adds anti-virus and anti-spam using up to five different scan engines at once. If a piece of malware gets through one scanner, it’s more than likely to be stopped by another. The system will also keep running while the engines download and install updates, with just one engine going offline for updates at a time. A set of heuristics also add to the anti-spam features of Exchange, helping identify spam messages before a signature gets pushed to the Exchange content filters, and Forefront also enables access to Microsoft’s DNS whitelist services.
One alternative to software anti-spam solutions simplifies things considerably in small and medium-sized installations: anti-spam appliances. These are usually a piece of network equipment (or in some cases some additional software on a firewall). Once it’s connected to the network you set up DNS (or NAT) rules to treat the appliance as your client’s SMTP server. It will then pre-filter messages before they arrive on the mail server.
You can simplify things even further by looking at the cloud as a solution to the spam problem. Services like MessageLabs provide managed email services that filter email before it even reaches your clients’ systems. All you need to do is manage the DNS for your clients so that MessageLabs become the main mail exchange record, meaning any mail sent to them will pass through the MessageLabs servers first.