Exchange Server Anti-Spam Features

Published on Saturday 24th May, 2008 (AEST)

I've seen a few Exchange 2003 servers lately that have been left, more or less, in their default state in terms of spam filtering. Exchange server includes a number of different tools to inhibit spam, but it seems many of its less obvious anti-spam features are often glanced over. Some, such as IMF, are well documented. Others, like SMTP tar pits, are less well known and could be better utilised.

Fortunately, more of these features are now enabled by default in Exchange 2007, which will hopefully make life tougher for spammers.

Content Filter / Intelligent Message Filter

I was excited when IMF first came out for Exchange 2003. Effective content scanners for Exchange Server had typically been too expensive for many small organisations, and Microsoft generously made IMF available for free. However, while the scanning capabilities of IMF are quite good, the archiving functionality in Exchange 2003 was simply too primitive to be of use to most organisations. Messages identified as spam were simply saved as EML (ie, Outlook Express) files in a folder on the server. Since a typical server can block thousands of spam messages a day, checking for false positives was impractical. As a result, it was often more appropriate to simply reject messages with a high probability of being spam - at least the sender will receive a non-delivery report (NDR) and can make contact another way.

Fortunately things have improved a lot with Exchange 2007. Spam messages can now be quarantined in a dedicated mailbox, which is a lot easier to check and maintain than a folder of EML files. However, where budgets allow, third-party spam filters usually still prove to be more manageable.

Sender ID / SPF

Sender Policy Framework aims to add trust to SMTP. As an anti-spam measure, it can reduce spam levels significantly. In a sense, SPF can be thought of as reverse MX records. While MX records list the mail servers which can receive email for a particular domain, SPF records list the servers authorised to send email from a particular domain. Servers can be configured to check these DNS records when receiving email, to ensure that the sending SMTP server is allowed to send mail from that domain. If it's not, then the receiving server can reject the email, or treat it as possible spam.

SPF has a lot of potential, but its take-up has been slow to date. As a result, only a small percentage of domains have SPF records published (I think it's around 10-15% at present), and Sender ID is often not enabled on servers. Although SPF popularity has yet to reach a critical mass, it is still worthwhile enabling Sender ID on Exchange servers, if for no other reason than to block spam from non-existent domains. On Exchange Server 2007, Sender ID is enabled by default on the Edge Transport server role for unauthenticated inbound messages.

Sender ID provides three options for dealing with SPF failures: Accept (and treat as possible spam), Delete (with no NDR returned to sender) or Reject (and have the sending SMTP server send the NDR). My preference is usually to reject failures, since it lessens the load on the server and prevents it from being used to bounce spam and viruses in NDRs. It also means that if the message was in fact legitimate, the sender should receive a NDR from the sending SMTP server. This behaviour complies with RFC 2821.

Here's an example SMTP session with Sender ID enabled, and set to reject failures.

1. 220 targetdomain.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at Fri, 23 May 2008 10:07:31 +1000
2. helo
3. 250 targetdomain.com Hello [10.1.1.1]
4. mail from:<test@nonexistentdomain.com>
5. 250 2.1.0 test@nonexistentdomain.com....Sender OK
6. rcpt to:<test@targetdomain.com>
7. 250 2.1.5 test@targetdomain.com
8. data
9. 354 Start mail input; end with <CRLF>.<CRLF>
10. test
11. .
12. 550 5.7.1 Sender ID (PRA) Domain Does Not Exist

As you can see, the transaction is rejected with a 550 error (line 12), after the data has been received. If SMTP tar pits are enabled, there will also be a delay before the 550 error is returned.

For specific details on implementing Sender ID, check out the Microsoft SenderID Home Page, and the TechNet article Fighting Spam and Phishing with Sender ID.

SMTP Tar Pits

Spammers rely on speedy communication with mail servers in order to send their masses of mail. SMTP tar pits are one way of inhibiting the work of spammers by slowing suspicious SMTP connections down. For instance, when a remote server attempts to send an email to a non-existent mailbox, the receiving server can pause the session for a few seconds before rejecting the command. If a spammer is probing a server to determine the names of valid mailboxes (assuming Recipient Filtering is enabled), then a 5 second delay for each incorrect guess will slow his efforts down enormously.

Tar pits are most commonly enabled to prevent this type of directory enumeration, but "550 5.1.1 User unknown" errors are not the only responses that are delayed. Most SMTP failure responses will be delayed, including the more general "Unrecognized command" and "Bad sequence of commands" errors.

Tar pits first became available with Windows Server 2003 Service Pack 1, and had to be enabled through a registry key. They are enabled by default on Exchange 2007, with a five second delay. (It's tempting to increase the time delay, but doing so can result in high numbers of open connections and greater resource usage.

In my mind, tar pits are one of the neatest ways to inhibit mass mailers. They cost nothing to implement, have no impact on legitimate communications, conserve resources and bandwidth, and aren't reliant upon blacklists or definition updates. Though they don't stop correctly addressed junk mail getting through, they do effectively restrict address harvesters and mass mailers.

For more information on SMTP tar pits, refer to Microsoft's "SMTP tar pit feature for Microsoft Windows Server 2003" article.

Recipient Filtering

Enabling Recipient Filtering on an Exchange server allows the SMTP service to check that the recipient exists before accepting an email. If the recipient does not exist, the receiving SMTP server will reject the message and the sending SMTP server should generate a NDR (Non-Delivery Report). Recipient Filtering does not reduce the amount of spam received, since the messages would otherwise be rejected later on. It does, however, reduce the bandwidth used by spam, by rejecting undeliverable emails early in the transaction before the message body is received.

The following is an example SMTP session with Recipient Filtering enabled.

1. 220 targetdomain.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at Fri, 23 May 2008 22:04:38 +1000
2. helo
3. 250 targetdomain.com Hello [10.1.1.1]
4. mail from:<test@sendingdomain.com>
5. 250 2.1.0 test@sendingdomain.com....Sender OK
6. rcpt to: <nonexistantuser@targetdomain.com.au>
7. 550 5.1.1 User unknown

Recipient Filtering also reduces the likelihood of an Exchange server inadvertently 'bouncing' messages to spoofed (innocent) addresses in the form of NDRs. I know I hate receiving NDRs for emails I never actually sent.

A major downside to Recipient Filtering is that it can be used by spammers to quickly build a list of valid email addresses on a domain:

1. 220 targetdomain.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at Fri, 23 May 2008 22:04:38 +1000
2. helo
3. 250 targetdomain.com Hello [10.1.1.1]
4. mail from:<test@sendingdomain.com>
5. 250 2.1.0 test@sendingdomain.com....Sender OK
6. rcpt to: <aaron@targetdomain.com.au>
7. 550 5.1.1 User unknown
8. rcpt to: <adam@targetdomain.com.au>
9. 550 5.1.1 User unknown
10. rcpt to: <andrew@targetdomain.com.au>
11. 550 5.1.1 User unknown
12. rcpt to: <anne@targetdomain.com.au>
13. 250 2.1.5 anne@targetdomain.com
14. rcpt to: <barry@targetdomain.com.au>
15. 550 5.1.1 User unknown

The spammer would now know that anne@targetdomain.com is a valid email address. Because of the ease at which spammers can do this, Recipient Filtering should be used in conjunction with SMTP tar pits.

Save to del.icio.us Digg this Submit to StumbleUpon