Security Advisor

Message Hygiene -- Microsoft Style: Part I

Keep your inboxes clean of spam and viruses with some new tools and enhancements in Exchange 2003.

• By Joern Wettern
• 01/01/2006

Microsoft has always provided basic tools to help Exchange administrators keep their e-mail clean (often referred to as message hygiene). Recently, though, Microsoft has enhanced Exchange’s existing features and added new capabilities. It is also offering new products to help you keep users’ inboxes free of spam and viruses. The result is a set of tools that should help you keep unwanted mail out of your network. (All the Exchange features I will describe here are in Exchange 2003. If you’re using a different version, keep in mind that some of this might not apply.)

This is the first of two columns on using Microsoft’s tools for message hygiene. This month, I’ll show you how to block unwanted messages as they arrive and assess the effective-ness of these methods. Next month, I’ll show you how to use Microsoft’s tools to filter messages based on content analysis. I’ll also assess the effectiveness of using all these methods together.

Filtering -- Your First Line of Defense
The more unwanted messages you can block before they’re processed by your mail server, the better off you’ll be. Using a combination of filtering techniques -- connection filtering, sender filtering and recipient filtering -- I’m able to block more than 90 percent of spam attempts on my mail server. Let’s take a look at what each of those methods do and how you can use them.

Connection filtering is based on rejecting connections from mail servers that are about to send you spam or viruses. That may sound straightforward, but how can you identify these servers? You could assemble a list over time, but that would be tedious and probably not too effective. Fortunately, there’s an easier way.

Exchange 2003 supports real time black lists (RBLs). These are also called real time block lists. Groups that maintain RBLs do the work of tracking and classifying e-mail servers for you. Categories they watch include servers that are known to have sent spam, insecurely configured servers that could be used by spammers, and IP addresses assigned by large ISPs to dial-up users (mail from such a dial-up address is more likely to come from a home user’s computer that has been compromised by malware than a legitimate mail server).

Figure 1. You’ll need to choose which RBLs you’ll be using and how they’re configured.

There are other categories as well, and they all have one thing in common -- they let Exchange and other mail servers do a database lookup to see if the IP address of a computer sending you mail is on one or more blacklists. If it is, Exchange immediately sends an SMTP status code 550. That’s its way of saying, “Go away, I don’t want to talk to you.” The connection is ended before the message is ever sent. You can fine-tune connection filtering by telling Exchange to always reject mail from specific IP addresses and to always accept mail from others. (See the sidebar “Getting Started with RBLs” for more information about how to use RBLs in Exchange.)

Sender filtering helps you identify and isolate the source of unwelcome e-mail. You’ll discover that some spam or mail-based worms originate from specific senders or domains. You can then configure Exchange to immediately drop the connection when any blacklisted mail server tries to send you a message. This may be useful in a few cases, but it’s generally not effective in blocking a significant portion of unwanted e-mails.

Recipient filtering is a much more effective technique. After all, you can clearly identify valid e-mail addresses within your organization and Exchange can automatically reject any mail sent to non-existent users. A lot of spammers send to commonly used names ([email protected], for example) or randomly chosen addresses. They figure this will result in at least a few of these addresses being valid. Configuring Exchange to block e-mail addressed to invalid addresses can effectively block a large amount of spam.

You can easily configure recipient filtering by selecting one check box. Before you do this, though, make sure you’ve considered all the implications. First, by blocking mail addressed to invalid addresses you also block messages that simply have a misspelled address. Do you really want to reject such messages or do you want to accept them and sort through them later?

Figure 2. Enable connection filtering to help filter out potential spam based on the sending server.

The second potential problem is that by accepting messages for valid recipients and blocking attempts to invalid addresses, you inadvertently help the spammers discover valid addresses simply by attempting to send mail to millions of different combinations and observing the results. When you configure address verification there is unfortunately no way to prevent spammers from “mining” your address list for valid addresses.

You can, however, make such mining attempts impractical by “tar pitting.” Just as a real tar pit would slow down anything trapped within, Exchange can delay responses to attempts to send a message to a non-existent recipient. If you configured a 60 second delay, it would take a spammer years to send enough connection attempts to successfully mine valid addresses. You can configure tar pitting via a registry setting. Learn more about how it works and how to enable it by reviewing Knowledge Base article 842851.

Sender Verification
The different methods of filtering e-mail before the message is actually sent can be effective, but they still let through enough spam and virus-infected mail to constitute a serious threat. Since spammers frequently use fake addresses in the sender field of e-mail, verifying a sender would seem to be an effective filtering technique. Unfortunately, the SMTP protocol used to send messages between mail servers was never designed to perform that type of verification, and there is no universal system for signing e-mail.

Microsoft and a group of other vendors have been promoting the Sender ID Framework, which partially solves this problem. Sender ID can’t verify an e-mail sender, but it can verify that the mail server is indeed from the sender’s domain. For example, if your mail server receives a message from [email protected], it can verify that the mail server at the other end is really one of Microsoft’s mail servers.

Verifying the legitimacy of the sending server also helps to guard against phishing attacks. Phishing involves sending e-mail designed to look like it comes from a bank or another trusted source. The recipient is directed to a Web site to verify his or her user name and password. While the Web site looks as legitimate as the e-mail, it’s really run by criminals to record passwords they can use to empty people’s bank accounts. If you can determine whether or not an e-mail from [email protected] really comes from Mega Savings Bank, you can block a large percentage of phishing attempts.

The effectiveness of Sender ID ultimately depends on organizations creating DNS records to list their authorized mail servers. Relatively few have done so at this point, and it’s unclear how widespread acceptance will be. Because of this, Sender ID isn’t yet an effective tool to filter all e-mail. However, even today it helps mail servers assign different levels of trust.

If the Sender ID matches, when an e-mail arrives from a server listed in the Sender ID domain record, it is most likely legitimate. It will be delivered unless it matches other spam criteria.

If the Sender ID doesn’t match, an e-mail from a server not listed on the SenderID domain record is highly suspect. In most cases, e-mail like this is spam.

Often, Sender ID simply doesn’t exist. Most e-mail falls into this category because most organizations haven’t configured a Sender ID setting on their DNS servers. Your mail server shouldn’t treat such e-mail as spam. Instead it should evaluate it further to determine whether or not it meets other spam characteristics.

Because most organizations haven’t implemented Sender ID, it’s not very effective against spam or phishing today. This could change as it becomes more widespread and more organizations configure their DNS servers to list legitimate mail servers. It does help your mail server detect a small number of spam and phishing e-mails, so it still makes sense to use this filtering method as well, especially since it is quick and easy to configure.

The first step in configuring Sender ID is to set up the required DNS record for your organization. If you’re using Exchange 2003 with Service Pack 2, you can also configure your mail server to check the Sender ID of incoming messages. The best starting point to learn more about this is Microsoft’s Sender ID Framework page.

Keep an Eye on the Content
These methods of filtering e-mail based on where it comes from and to whom it’s addressed can block the vast majority of spam. However, to catch the rest of it, you’ll have to use tools to scan the content of each e-mail message.

Microsoft’s Intelligent Message Filter for Exchange and the Outlook Junk Mail Filter have been around for a while, but only recently has Microsoft enhanced them. Microsoft also recently acquired Sybari, a company that developed anti-virus and anti-spam solutions for Exchange.

Next month, you’ll learn how you can combine all of these tools and techniques for comprehensive e-mail hygiene. In the meantime, I encourage you to send me e-mail with any questions or comments. I’ll do my best to let it through.