Microsoft is touting Exchange Server 2007 as including major improvements in message content filtering and control; the collective set of antispam and anti-phishing features are now labeled as “message hygiene” functionality. At a high level, Exchange 2007’s message hygiene features look similar in many respects to Exchange Server 2003’s. Like Exchange 2003, Exchange 2007 includes an integrated antispam filter, built-in interfaces for antivirus scanning, and a host of features for message content protection, including the ability to block or drop connections according to the originating IP, the sender name, or the recipient. Exchange 2007 departs from Exchange 2003 by introducing some major new changes that are worth discussing in more detail. Let's take a look at some of those changes, and I'll discuss how they might affect your plans to deploy Exchange 2007.
The Edge Server
Arguably, the biggest difference between Exchange 2003's and Exchange 2007's message hygiene functionality is the introduction of a server role that exists solely for message hygiene. The Edge Transport server (or just “Edge”) role is a separate Exchange role that must be installed on a server that doesn't include any other server roles; the Edge role was designed to provide a separate bastion host for processing inbound email. This strategy makes excellent sense, given that the Edge role was expressly designed to have a minimal attack surface and to be directly exposed to Internet traffic.
Whereas Microsoft recommended against installing Exchange 2003 front-end servers in a network’s perimeter or demilitarized zone (DMZ), with Exchange 2007 Microsoft now explicitly recommends that Edge servers be positioned in just that configuration. Microsoft’s reasoning is that Exchange 2003 front-end servers require several additional ports to be open to the back-end servers, but the Edge server is altogether a different beast. It doesn’t have to be a domain member server (in fact, you can’t install it in a forest that has non-Edge Exchange servers in it), meaning that an attacker who compromises an Edge server can’t easily leverage that compromise into a domain attack. In addition, Exchange 2007 includes an extension to the Windows Security Configuration Wizard (SCW) that automates the process of hardening an Edge server to make it safe for use when directly exposed to the Internet.
The question then arises of how the Edge server can get information about recipients from Active Directory (AD), a necessary step to make filtering based on recipient information work. The answer lies in Active Directory Application Mode (ADAM), a little-used service that allows a server to keep a partial replica of an AD Global Catalog (GC) for a forest that the server doesn't belong to. In this case, the Edge server runs ADAM in conjunction with the new EdgeSync tool, which runs on a Hub Transport server inside the network perimeter. EdgeSync provides a one-way sync of connector data, recipient and sender filtering information, and accepted domains from the hub transport to the Edge role; consequently, you must open three TCP ports (TCP port 25 for SMTP, TCP port 50389 for plain LDAP, and TCP port 50636 for secure LDAP). Interestingly, synchronization happens per AD site, not per server, so you’re not tied to a single Hub Transport server as a bridgehead.
You don’t have to use an Edge server if you don’t want to. The Hub Transport server role can provide some of the same message hygiene capabilities that the Edge server role does. These features are implemented as modules that Microsoft calls agents. However, some significant features (including connection filtering and the address rewriting agent) might be available only on Edge server roles. (As of Exchange 2007 beta 2, you can install the message hygiene agents by using the install-AntiSpamAgents PowerShell script included as part of the Exchange installation, but I don’t know if that will be true of the released version.)
Even if you’re not using an Edge server, you still need to understand the concept of accepted domains. These are the email domains for which your servers should accept mail, whether for direct delivery or relaying. You can think of them as analogous to the SMTP address space definitions from earlier versions of Exchange, but their purpose is somewhat different. When you specify an accepted domain, you’re creating a setting at the Exchange organization level that says the target domain is one of three things: an authoritative domain, an internal relay domain, or an external relay domain.
• An authoritative domain is a domain that your Exchange organization hosts. When you install the first Hub Transport server, the Fully Qualified Domain Name (FQDN) of the forest root will automatically be added as an authoritative receive domain; you’ll have to add other domains if you want to use them.
• An internal relay domain is a domain for which you accept mail for recipients who exist as contacts in your Global Address List (GAL) but don’t have their own mailboxes.
• An external relay domain is a domain in which you accept messages and send them to a separate server for routing and delivery.
You can specify additional domains on a Hub Transport server, which will synchronize them to your Edge servers as part of the normal EdgeSync process. If you fail to specify a domain, the Edge or Hub Transport server will reject mail sent to that domain.
Connection filtering has largely the same feature set it did in Exchange 2003, but the implementation is completely different. The Connection Filter agent runs on an Edge Transport server, and it filters (or more precisely, drops) connections according to the originating IP address: if a connection is on a list of IP addresses that should be allowed or blocked, or on an IP list provider that you specify, the filter will take the appropriate action. Connection filtering is on by default for unauthenticated messages, which is a useful change. Another very useful addition is the existence of commands that test the IP block and allow list providers you specify to verify that queries to the list providers are working properly.
Sender and Recipient Filtering
Sender and recipient filtering behave much the same in Exchange 2007 as they did in Exchange 2003, although they're now implemented as agents that run on the Edge or Hub Transport servers. One major difference is that in Exchange 2003, individual users’ Safe Sender Lists were local to their mailbox, and thus to their mailbox server. Exchange 2007 introduces the ability to aggregate safe sender information and push it to the Edge server. Because mail arriving from safe senders is flagged as safe, it’s exempted from further content checks. Sender filtering can either block senders with a nondelivery report (NDR) or accept the message and increase its spam confidence level (SCL). In another Exchange 2007 change, recipient filtering is applied only to mail sent to domains that are specified as authenticated; this helps prevent accidental rejections of legitimate mail. Because the MAIL FROM SMTP header that sender filtering uses can be spoofed, Microsoft recommends that you use the Sender Filter agent only in conjunction with the Sender ID agent.
Speaking of Sender ID, Exchange 2007 fully supports it, with the same basic options as Exchange 2003 includes (see "Want to Tick Off Spammers? Try Sender ID," April 2006, InstantDoc ID 49313 for more about Exchange 2003’s implementation). You can use the set-SenderIDConfig task in Exchange Management Shell to exclude individual recipients and domains from Sender ID checking, but you can’t currently exclude recipients and domains from the Exchange Management Console.
One very welcome new feature is an Edge agent that filters attachments. You can filter according to filename, file extension, or MIME type, and you can choose what to do with messages that contain a blocked attachment: block the message and its attachment (in which case the sender gets an NDR), strip the attachment but allow the message, or silently delete the message and the attachment. The Exchange Help file points out clearly that stripped or blocked attachments can’t be recovered, so you shouldn’t plan on using the Attachment Filtering agent as a quarantine mechanism. You must configure the Attachment Filtering agent with the Exchange Management Shell, and you must configure it on every Edge or Hub Transport server on which you want filtering to take place; the filtering settings are per-server.
Another brand-new Exchange 2007 feature is support for sender reputation. You can think of this feature as a persistent rating for senders that takes into account factors that indicate how likely a given sender is to be legitimate. This reputation data is persisted, so that a given sender’s bad deeds over time will gradually bump up the sender’s Sender Reputation Level (SRL) from 0 to 9. An SRL of 0 means the sender is guaranteed to be legitimate, while an SRL of 9 indicates a near-certain probability that the sender is a spammer. All previously unseen senders start with an SRL of 0, and the agent starts calculating SRL levels as soon as 20 messages from that sender have arrived.
The Exchange Sender Reputation agent bases its calculation of a reputation on the accuracy of reverse DNS data for a given sender, whether the sender server appears to be an open proxy, the correctness of its EHLO or HELO header, and the SCL ratings of previous messages from the same sender.
Here’s the best part: You can set your own SRL threshold. When a sender hits your threshold, the Sender Reputation agent asks the Sender Filtering agent to add the sender to the blocked senders list for a temporary period. Senders whose IP addresses appear on Microsoft’s own SRL blocked senders list are automatically added to your SRL blocked senders list when the agent updates its configuration data each day.
The Content Filter Agent
You can think of the agents I’ve discussed so far as pearls on a string; each agent runs, and if a message passes that agent's checks, the message goes on to the next agent. The Content Filter agent is another pearl, but with a few differences: It essentially acts as the equivalent of the Exchange 2003 IMF, which means it can block or accept messages according to the message's SCL. Each agent can adjust the SCL up or down depending on its evaluation of the message. The Content Filter can also block or reject messages according to the presence of key words or phrases that you define, and it takes into account the presence or absence of Microsoft Office Outlook 2007’s “email postmarks” (a kind of computational postage that I’ll cover in a future column).
The Content Filter also uses the aggregated Safe Sender List information. As its name implies, this feature gathers individual user Safe Sender and Safe Recipient Lists from Outlook 2007 clients, publishes it to AD, and shares that information (via EdgeSync) with the Edge servers. This allows the Edge machine to implement users’ preferences about which messages to allow or block before those messages are actually delivered to the mailbox server.
The Content Filter includes a quarantine mechanism, but unfortunately it requires the administrator to review and release messages. Most administrators would rather eat sand than review other people’s spam, so it’s unclear whether this feature will be well-received.
There are a number of other small but valuable features that Exchange 2007’s message hygiene arsenal includes. For example, the Content Filter can now automatically download updates to its filter file, and Microsoft has promised to issue those updates on a more regular and more frequent schedule than its updates for Exchange 2003. There have been significant changes to the way antivirus scanning works; for example, Exchange 2007-aware products (such as Microsoft’s own Forefront Security for Exchange) can now scan messages in Hub Transport server queues, which means infected messages can be blocked from delivery. As Microsoft gets closer to releasing Exchange 2007, look for more details here in Exchange & Outlook Pro VIP and Windows IT Pro about how these security features work in the wild.