Using Exchange s Spam Control Features

Exchange 2000 Server had a relatively small set of antispam features. That s because its designers couldn t have reasonably expected the volume of spam to grow to its current level. During the design phase for Exchange Server 2003, though, it became abundantly clear to Microsoft that Exchange administrators wanted some built-in tools for slowing the onslaught. Exchange does allow you to block mail sent by specified individuals or domains, to block mail sent from servers that appear on third-party or your own block lists, and to block SMTP connections from specified IP addresses. Exchange 2000 Server allowed you to filter inbound mail based on sender or recipient address; Exchange Server 2003 expands on these features, so there are now separate tabs for sender, recipient, and connection filtering. These features work together with each other, and with the Outlook junk mail filter, in a complex but interesting manner.

Let s start by examining what happens purely on the Exchange side. Exchange s filters are designed to filter mail before it reaches the store. You saw how Exchange accepts and authenticates connections at the virtual server level earlier in Figure 8-3; now let s look at what happens in that mysterious box labeled Apply Connection, Sender, And Recipient Filters. Figure 8-10 shows the flowchart for this process, which begins after the SMTP virtual server has already accepted the sender s authentication (if any). The process then looks like this:

Figure 8-10: The filter application process.

1. The SMTP server accepts the MAIL FROM verb, which carries the sender s self-proclaimed identity. This is known as the envelope from, and Microsoft refers to it as the P1 address. SMTP doesn t guarantee this address s integrity or authenticity; it can be forged or wrong and the sending server won t care.

2. The sender s IP address is checked to see if it matches the accept list of IP addresses. If so, the message is flagged to indicate this fact, so it won t be cheked against Realtime Block Lists (RBLs) and the deny IP address list. Otherwise , it s checked against the deny IP address list. If it matches that, the SMTP connection is dropped with a 5.7.0 Access Denied error.

3. The P1 address of the sender is checked against the sender filter list (if it s enabled). If the address is on the list, the connection is dropped with a 5.1.0 Sender Denied error; if not, the Exchange server sends a 250 OK status message.

4. The sender s IP address is checked against each of the connection filters, in the order in which they appear in the connection filter list. This check is performed by making DNS queries against each DNS block list (DNSBL) server. Any matches are compared against the filter rules for that filter to see what should happen. If any connection filter matches, the connection can only be used to send mail to addresses on the recipient exception list; otherwise, a 550 5.7.1 error (with a custom error message set by the connection filter, if desired) is returned. If no connection filters match, processing continues.

5. The SMTP server accepts the RCPT TO verb. If the recipient address is on the exception list maintained for connection filters (more on that in a bit), the next step is skipped .

6. If the option to filter messages sent to recipients who are not in the directory is enabled, the recipient s address is checked to see if it s on the list of recipients to reject. If so, it s rejected; if not, Exchange queries to make sure the recipient matches an alias of a mailbox in Active Directory. If the address doesn t match any aliases, the recipient is rejected. If the address does match, Exchange accepts the DATA verb and the message data.

7. After the message contents have been accepted, the final check is of the sender s reply address, known as the P2 address. If the P2 address appears on the filter list, the connection is dropped and the message discarded.

8. The message is processed by any third-party event sink filters that have been installed. These filters can drop or modify the message, as described later in the chapter.

9. If the message wasn t thrown away by the event sink filter stage, it s submitted to the store for delivery.

Filtering by Recipient Address

You add recipient restrictions on the Recipient Filtering tab of the Message Delivery Properties dialog box. To get there, open Exchange System Manager, open the Global Settings node, right-click the Message Delivery node, and select the Properties command. When the Properties dialog box appears, click the Recipient Filtering tab (see Figure 8-11). This tab is pretty simple: the only thing you can do is specify the addresses of users for whom you want to reject inbound mail. You can use the * wildcard in address specifications.

The Filter Recipients Who Are Not In The Directory check box gives you an additional layer of defense: when checked, it tells Exchange to reject inbound messages sent to addresses that don t appear in the global address list (GAL). The utility of this measure is a matter of some debate: when it s on, your Exchange server won t accept messages for bogus recipients, but a patient attacker might be able to mount dictionary attacks against your server to determine which addresses are valid. The likelihood of this happening is pretty low unless you have a large or well-known mail system, so I normally recommend enabling this option. Leaving the option off means that Exchange will accept any message to any recipient, then NDR messages to recipients that don t exist. This takes time and server resources, particularly if the NDR recipient doesn t exist either.

Figure 8-11: Recipient filtering allows you to block mail to specified addresses within your domain.

Filtering by Sender Address or Domain

You add sender-based or domain-based restrictions with the Sender Filtering tab (see Figure 8-12) of the Message Delivery Properties dialog box; it turns out to look very much like the Exchange 2000 Server version (which was just labeled Filtering).

Figure 8-12: Block senders or domains with the Sender Filtering tab of the Message Delivery Properties dialog box.

The controls on the Sender Filtering tab are easy to understand:

• The Senders list shows which current senders and domains you ve chosen to block. You can add new senders with the Add button, edit existing ones with the Edit button, or remove them with the Remove button. You can use the * wildcard character in domain names . This feature allows you to block multiple domains or senders with judicious wildcarding.

• The Archive Filtered Messages check box controls whether Exchange will keep copies of messages that it filters. By default, those messages are stored in the Filter directory under the SMTP virtual servers directory in the server s mailroot (for example, filtered messages for the first virtual server will be in \Program files\Exchsrvr\Mailroot\Vsi 1\Filter). When you select this check box, Exchange starts filtering messages, and it never removes the archived mail. You ll need to create a script or scheduled task that periodically compresses or moves the archive contents.

• The Filter Messages With Blank Sender check box allows you to automatically filter messages that don t contain a valid RFC 822 “format sender name . Many spammers generate messages with a blank From line, so selecting this check box cuts those off. Unfortunately, Exchange system monitoring messages will be caught by this filter unless you upgrade your Exchange servers to Windows 2000 Service Pack 3 or later.

• The Drop Connection If Address Matches Filter check box tells Exchange to immediately drop the SMTP connection if the sender claimed in the MAIL FROM verb appears on the filtering list.

• The Accept Messages Without Notifying Sender Of Filtering check box determines whether an NDR is generated for each message that s filtered. Normally, you ll leave this check box cleared ”after all, why give a spammer notice that your server is working properly? For machines with large filter lists and lots of incoming mail, generating NDRs can create a performance burden . (In addition, a malicious person could forge lots of fake messages and cause your server to generate a large volume of NDRs to an uninvolved third-party domain.) If you tell Exchange to drop connections from filtered senders, this check box will be disabled.

  Note  

  The message filtering directory (also known as the turfdir for some obscure reason) is automatically created if it doesn t already exist. In Exchange 5.5, you had to create it manually or nothing would be filtered.

Filtering Connections

Exchange Server 2003 allows you to filter connections in a much more sophisticated way than Exchange 2000 Server did. Exchange 5.5 introduced the idea of blocking connections based on the originator s IP address, but for that to be useful, you need to know what IP addresses to block, and the sender has to not change addresses ”frequently, neither of these conditions holds true. The solution lies in the notion of a real-time block list (often abbreviated as RBL, although that s a trademark of MAPS; I ll call these lists DNS block lists, or DNSBLs) that a server can query to determine if an address is clean or not. This is done by having the SMTP server make a DNS query against a special DNS zone that s been prepopulated with A records corresponding to IP addresses of known spammers. If there s a match, then that address is said to appear on the block list.

There are a wide variety of DNSBLs available; some are free, and others require a subscription. You can always create your own, although this is a time-consuming process; by the time you encounter enough spammers to make your list big enough to be useful, your servers will have absorbed a ton of junk mail. (See the Additional Reading section at the end of this chapter for more information on finding a DNSBL service.) If you re using your own DNSBL, you ll have to set it up, as described in the sidebar Creating Your Own DNS Block List ; if not, then you have two ways to use the list:

• Use the DNS zone transfer mechanism to import the entire list to a zone on your own DNS server. This has the advantage of being efficient, because your Exchange server never has to make queries of an outside DNS server, but it requires you to find a service provider that allows zone transfers, and there might be some performance impact of the transfers if the DNSBL zone is sufficiently large.

• Allow your Exchange server to make direct queries of an RBL provider. With this approach, your own DNS servers aren t involved, which might be a good thing if your organization s DNS servers are outside your control. However, when you use direct queries, you re putting mail acceptance at the mercy of the external DNS server; if your Exchange server can t resolve the senders IP addresses against any of the DNSBLs you ve specified, mail will be delivered without filtering.

Exchange Server 2003 doesn t care which of these approaches you take; either way, you specify the DNSBL service on the Connection Filtering tab (see Figure 8-13). You use the Add, Edit, and Remove buttons to control which DNSBL services you re using. When you add a new service, you need to specify the name you want shown and the DNS name (not the IP address) of the RBL service or server. You can optionally specify a text error message to be returned to the sender (usually some variation on 5.5.0 You are a spammer and must die ); if you don t specify a message, the default message ( ipAddress has been blocked by RBL display name ) will be used. You can customize this message using three parameters: %0 is the IP address of the connecting server, %1 is the display name of the RBL server, and %2 is the RBL provider s DNS suffix.

Figure 8-13: The Connection Filtering tab lets you specify which DNSBLs your Exchange server should use.

You also have some flexibility in controlling which filter list you use. Many DNSBL providers keep three separate lists for different groups: one for known spammers at fixed IP addresses, one of blocks of IP addresses allocated to dial-up users (often used by spammers to get easy, cheap Internet connectivity), and one for known open relays. DNSBL systems that support these lists typically work by returning different IP addresses for each list; for example, 127.0.0.1 is the default address returned to indicate that an IP address is on the spammers list, but 127.0.0.99 might indicate a dial-up user . If you want to apply different settings to connections from these different groups, you can do so with the Return Status Code dialog box, which you get to with the Return Status Code button in the Connection Filtering Rule dialog box. This dialog box gives you three choices for the particular filter rule you use it on:

• The Match Filter Rule To Any Return Code option, selected by default, tells Exchange to ignore the specific return code sent back from the DNSBL server; if any response to the query is received, the rule will apply and the message will be rejected for any recipient that s not on the connection filtering exception list.

• The Match Filter Rule To The Following Mask option, and the text field immediately below it, allow you to specify that you want a particular response to trigger the rule. You do this by entering a mask in the text field; the mask indicates what bits Exchange should pay attention to in the response. This choice is only useful if you want to force the rule to apply to a single returned status value, because the address returned must match the mask ”if you enter a mask that encompasses, say, the DUL and open-relay values from your DNSBL provider, you ll only trigger the rule if the IP address of the sender appears on both lists.

• If you want to trigger a rule in the case of multiple responses, the Match Filter Rule To Any Of The Following Responses option is the correct choice. When you select this option, the Add button becomes active so that you can add return status codes; if the response returned by the DNSBL server matches any of the codes you list, the connection filter will apply.

Sharp-eyed readers (particularly those with UNIX backgrounds) might be wondering whether there s an escape hatch for these filters. For example, you probably want anyone to be able to send mail to your postmaster account, even if they re using a dial-up system. The Exceptions button on the Connection Filtering tab lets you provide a list of recipients whose messages are never blocked by RBLs, no matter where they come from. You should add postmaster @yourdomain to this list; if you have separate mailboxes for other important functions (like sales, customer service, or service-abuse complaints) you should probably add them, too.

Exchange has another connection-filtering trick up its sleeve. You might remember that IP block and allow lists have been included in Exchange for a while (as described earlier in this chapter), but that they only apply to one server at a time. Exchange Server 2003 allows you to specify a global list of addresses to allow or deny traffic from. The IP addresses or ranges you add here are stored in Active Directory, and they apply to all of your Exchange 2003 servers. You modify these lists with the Accept and Deny buttons on the Connection Filtering tab; each button displays the corresponding list and gives you controls to use to add or edit individual addresses or address blocks.

Creating Your Own DNS Block List

If you re really intent on creating your own DNSBL, you can; the process is fairly straightforward. You begin by creating a new zone in DNS and giving it whatever name you like; this is the name that you ll specify in the connection filter that uses your homebrew list. Next, assemble the list of IP addresses you want to filter and sort them in order of their first octet; Microsoft Excel works well for this. The reason is that you need to create domains in the new zone for each unique first octet. For example, let s say you wanted to block 1.2.3.4 and 4.5.6.7 using connection filters: you d create two new domains named 1 and 4 in your new zone. You then have to create subdomains for each of the second and third octets, so for 1.2.3.4, you d create a domain named 3 underneath the 2 domain.

That s the hard part; once you ve created a correct domain structure, you only need to add A records. The host name for each record must correspond to the last quad of the IP address to be blocked, and the IP address for the record should be 127.0.0.1, with no pointer (PTR) record. Once you ve added the IP addresses, create a connection filter that points to the new zone you created and it should begin filtering. As soon as you add new records to the appropriate domain, Exchange can use them in the filter.

 

Using the Exchange Intelligent Mail Filter

At the COMDEX show in late 2003, Microsoft chairman Bill Gates surprised the attendees by announcing that Microsoft had built a server-side spam filter for Exchange, the Intelligent Mail Filter (IMF). IMF is based on the SmartScreen technology developed by Microsoft Research; SmartScreen is already used by Hotmail s filtering engine and by the junk mail filter built into Outlook 2003. IMF is a separate server-side component that runs on an Exchange 2003 server and filters mail in two ways.

Each inbound message is evaluated for spammishness, and the IMF assigns a score (the spam confidence level, or SCL) to each inbound message. The SCL for a message travels with it. You get to set two thresholds: a gateway threshold and a mailbox server threshold. Messages whose SCL is higher than the gateway threshold are blocked at the gateway (actually, they can be deleted, quarantined, or blocked); messages whose SCL is lower than the gateway threshold are passed on to the mailbox server. If the message SCL is higher than the mailbox store threshold, the message is automatically put in the recipient s Junk Mail folder.

Note  

Because the IMF was still in beta while this book was being written, I couldn t document it completely. However, there s a more detailed explanation of how to manage the IMF on my book s Web site at http://www.E2ksecurity.com .

Using Third-Party Filters

One important enhancement in Exchange Server 2003 is invisible to administrators: the set of interfaces and properties used to connect transport event sinks to Exchange has changed quite a bit. Microsoft designed the IIS and Exchange SMTP servers to be extensible by adding code that runs when specific transport events (like the arrival of a new message) occur. This gives us a wonderful opportunity to make changes to incoming or outgoing messages: all we need is a bit of code that follows the Exchange conventions for a message filter. These filters, more properly known as event sinks , can be called when various events occur during message transport and storage; when called, the sink has the opportunity to inspect (and in some cases modify) the message.

The event sink model in Exchange Server 2003 has been enhanced to allow third parties to write better spam filters. However, it s important to understand that Exchange itself doesn t provide any additional spam filtering beyond the filtering technology I ve just described. However, third parties can write filters that use whatever methods they think will be effective. Exchange Server 2003 makes these filters work better by allowing them to specify a spam confidence level (SCL) for each message. The SCL is carried as a message property until the message is stored in the user s Inbox. This is important, because it allows the Information Store service to make a decision about whether a message is spam so it can automatically decide whether to file the message in the user s Junk Mail folder. The SCL threshold is stored in Active Directory and is adjustable by the administrator using the third- party filter s toolset; this gives you control over how aggressive your filtering is. In addition, different third-party filters might allow you to tweak how they calculate the SCL for incoming messages.

Activating Your Filters

Once you ve specified filter settings in the Message Delivery Properties dialog box, you still have to tweak the SMTP virtual servers that accept mail from the Internet so that they honor the filter restrictions (see Figure 8-14). This behavior is by design; filtering has a performance cost, so it s turned off by default. Fortunately, you can easily control filtering on individual virtual servers by following these steps:

1. Open the virtual server s Properties dialog box, and click Advanced on the General tab.

2. In the Advanced dialog box, select the port and IP address combination for which you want to activate filtering, and then click Edit.

3. The lone checkbox in the Identification dialog box controls whether filtering is applied or not; the filtering settings themselves are applied separately using the rules and processes described earlier in the chapter. (Don t forget that you can selectively disable individual connection filters with the Disable This Filter check box in the Connection Filtering Rule dialog box.)

   
   Figure 8-14: You must turn on filter evaluation on individual SMTP virtual servers.