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
Ask anyone who manages a corporate e-mail system what keeps them busy at work
and awake at night. Their first answer is sure to be viruses and spam. Keeping
these nasty intrusions out of your network and out of users’ inboxes can be
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 (firstname.lastname@example.org, 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
Base article 842851.
Started with RBLs
The biggest challenge you’ll
face when configuring Exchange to use RBLs is identifying
legitimate lists that work. Some RBLs are overly aggressive,
which can block legitimate mail. Others aren’t updated
often enough, and a mail server listed by mistake may not
be promptly removed.
Do some research when deciding which RBLs to use to see how
widely used it is and what sort of reputation it has. It also
makes sense to frequently review which e-mails the RBL blocks,
at least at the beginning, to ensure that no legitimate e-mail
is being blocked. Good candidates to evaluate are some of
the free or donation-based lists that have been around for
-- The Open Relay Database.
-- This has multiple lists that cover separate categories.
-- This is one of the more aggressive lists.
Once you have chosen your list or lists, here’s what
you’ll need to do:
- In Exchange, under Global Settings, display the Properties
of Message Delivery.
- On the Connection Filtering tab, enter the RBL you want
to use. You’ll need to enter a display name, and a
DNS suffix specific to the RBL and a return status code.
The RBL’s Web site should list both of these values.
- It’s a good idea to include a custom message that
your mail server will return to indicate why an e-mail was
blocked. This message can point to the RBL’s Web site
or prompt a sender to direct any questions to an e-mail
address that you have exempted from filtering on the Connection
- Enable each SMTP virtual server to apply the settings
you configured. To do this, display the Properties dialog
box of the virtual server, click the Advanced button, select
the address that the server uses and then click the Edit
On the Identification dialog box, which is shown in Figure
2, enable Apply Connection Filter. -- J.W.
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@example.com, 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 firstname.lastname@example.org 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.