At COMDEX last November, Bill Gates spent a portion of his keynote address announcing a new product: Exchange Intelligent Message Filter (IMF). COMDEX might seem like an odd venue for an Exchange Server announcement until you consider that IMF is really a spam filter and that spam is a growing problem and annoyance to users, administrators, and pretty much everyone except the people who send it. After you know what IMF does, how it works, and how to deploy it, you'll realize that IMF might not solve your spam problem all by itself but can be a valuable adjunct to other spam-reduction measures.
IMF Requirements
IMF is implemented as an event sink that extends the behavior of the Exchange Server 2003 SMTP service. IMF runs only on Exchange 2003 because it requires some changes that Microsoft made to support the tagging of suspect messages with a spam confidence level (SCL)--more about that later. In a typical deployment, you put IMF on an Internet-facing bridgehead server so that it can scan incoming SMTP mail. Because IMF requires Exchange 2003, you can't put it on a standalone server as a front-end filter. The only other limitation is that IMF doesn't support Exchange clusters, but you probably aren't using clustered bridgeheads to receive mail from the Internet, so this limitation isn't likely to be a problem.
How IMF Works
IMF uses Microsoft SmartScreen Technology, filtering technology that Microsoft Research originally developed for use with Hotmail. Depending on whose estimate you use, somewhere between 65 percent and 85 percent of the mail arriving at major ISP servers is spam, so Microsoft obviously needs a powerful filter. However, given Hotmail's end-user base, the filter also needs to be simple to use. Several Microsoft products--Hotmail, IMF, the Outlook 2003 Junk E-mail Filter, and Microsoft Entourage 2004 for Mac--use SmartScreen. In all these products, it provides more-or-less- automatic filtering services that work without much user or administrator intervention.
One of the key differences between SmartScreen and other filters is that users and administrators can't train or adjust SmartScreen--it's a black box that uses a large set of filtering data. Microsoft's data-gathering approach is interesting: Users who sign up for a Hotmail feedback program are asked each day whether one particular message they've received is spam. The contents of the messages are fed into the corpus used to build the SmartScreen filter list. In January 2004, Microsoft Research reported that the corpus contained more than 10 million messages.
The contents of the corpus are used to build a filter file that positively and negatively weights key message phrases and words. To determine whether a message is spam, the filter uses the weights to calculate a weight for the subject and one for the message body. These weights are added together to give the message a total weight. The filter then performs more checks, which Microsoft hasn't completely described. (The company says that fully describing these checks would help spammers outwit them.) The message can gain or lose weight depending on the result of these tests. After IMF calculates the final weight, the filter converts that weight into an index from 1 to 10. This index is the aforementioned SCL.
IMF supports two filtering thresholds--the gateway threshold and the store threshold--that use the SCL. As its name suggests, the gateway threshold is on the IMF server. Messages whose SCL exceeds the threshold are subject to an action that you select: You can reject them and send a nondelivery report (NDR), delete them and send no NDR, archive them to a location that you specify, or ignore the SCL. It's important to note that IMF operates in conjunction with the Exchange 2003 transport-filtering mechanisms. IMF won't filter out any messages to or from any names, IP addresses, or domains that you've configured as trusted senders. IMF's filtering happens after the Exchange SMTP service has accepted a message. If the message SCL exceeds the gateway threshold, the selected action occurs. If the SCL is lower than the threshold, IMF passes the message on to the mailbox store that contains the recipient's mailbox, just as would happen if IMF weren't present.
At that point, the store threshold kicks in. If the user uses Microsoft Office Outlook 2003 or Outlook Web Access (OWA) 2003, the store compares the message SCL with the store threshold. If the SCL is lower than the threshold, the store checks the message against the user's Blocked Senders List. If the sender is on the list, the store processes the message according to the user's junk-mail-filtering setting--filing the message in the Junk E-mail folder or deleting it. If the sender isn't on the list and the SCL is below the store threshold, IMF delivers the message to the user's Inbox. If the message SCL exceeds the store threshold, the store files the message in the Junk E-mail folder or deletes it--unless the sender is on the user's Safe Senders List, in which case the message SCL is ignored.
Users who use earlier Outlook, earlier OWA, or non-Outlook clients don't benefit from IMF. Servers that run Exchange 2000 Server can't interpret the SCL; they deliver messages tagged with an SCL to Exchange 2000 mailbox clients as usual. Store threshold filtering depends on the presence of Safe and Blocked Senders lists, which exist for a mailbox only if it has been logged on to via Outlook 2003 or OWA 2003. If you use POP or IMAP clients, no store-level filtering will occur.
IMF has one additional wrinkle: If you have multiple Active Directory (AD) forests and your inbound SMTP bridgeheads in one forest can accept mail for recipients in the other forest, you need to enable cross-forest authentication if you want the SCL property to persist when messages move between forests. Cross-forest authentication is necessary because the SCL is an extended message property that's transferred only within an Exchange organization or between Exchange organizations that have an authenticated connector. The Microsoft Exchange Intelligent Message Filter Deployment Guide has a complete description of how to set up cross-forest authentication; in brief, you need to set up user accounts in each forest, give them the correct permissions, then specify the account to use for each end of the connector.
Prev. page
[1]
2
next page 
