The layered approach to reducing spam in Microsoft Exchange Server 2007 refers to the configuration of several anti-spam features that filter inbound messages in a specific order. Each feature filters for a specific characteristic or set of related characteristics on the inbound message.
The following figure shows the order in which default Exchange Server 2007 anti-spam features filter inbound messages.
- A Simple Mail Transfer Protocol (SMTP) server connects to
Exchange Server 2007 and initiates an SMTP session.
- During the SMTP session, Exchange Server 2007 applies
connection filtering by using the following criteria:
- Connection filtering examines the administrator-defined IP
Allow list. If an IP address is on the administrator-defined IP
Allow list, no other filtering is applied, and the message is
accepted.
- Connection filtering examines the local IP Block list. If the
IP address of the sending server is found on the local IP Block
list, the message is automatically rejected, and no other filters
are applied.
- Connection filtering examines the real-time block lists (RBL)
of any IP Block List providers that you have configured. If the
sending server's IP address is found on a RBL, the message is
rejected, and no other filters are applied.
- Connection filtering examines the administrator-defined IP
Allow list. If an IP address is on the administrator-defined IP
Allow list, no other filtering is applied, and the message is
accepted.
- If connection filtering does not find the sending IP address on
any of its lists, then Exchange Server 2007 examines the sender
e-mail address-which is displayed in the P1 information that is
specified in the SMTP conversion by the MAIL FROM command-against
the list of senders that you configure in sender filtering. If a
match is found, Exchange Server 2007 rejects the message, and no
other filters are applied. Even if recipients in your organization
have put senders on their Microsoft Outlook Safe Senders List,
sender filtering that is configured on the Edge Transport server
will override the recipient setting and will reject the
messages.
- Exchange Server 2007 examines the recipient against the
Recipient Block list that you configure in recipient filtering. If
the intended recipient matches an e-mail address that you filter,
Exchange Server 2007 rejects the message for that particular
recipient. In the case where multiple recipients are listed on the
message that are not on the Recipient Block list, the message will
continue to process. Otherwise, if the message is bound for only a
single blocked recipient, no other filters are applied.
- If the message still contains valid recipients after recipient
filtering has been applied, Exchange Server 2007 runs Sender ID.
Exchange Server 2007 queries the sender's DNS for a sender policy
framework (SPF) record. The SPF record helps verify that the IP
address in the SMTP RECEIVED: header can send e-mail messages for
the sender's domain. If the SPF indicates that the IP address is
not permitted to send messages for the particular domain, the
Exchange Server 2007 default behavior is to mark the message as
Sender ID-Failed and continue to process the message. The failed
Sender ID status will be considered when content filtering
processes the message. Alternatively, you can configure Sender ID
to reject or delete the message if the Sender ID status
fails.
- If a message is not rejected by any one of the filters
described above, content filtering runs, and one of the following
actions occurs at the Edge Transport server:
- Content filtering compares the sender to the senders in the
safelist aggregation data from Outlook users. If the sender is on
the recipient's Safe Senders List, the message is sent to the
user's mailbox store. If the sender is not on the recipient's Safe
Senders List, the message is assigned an spam confidence level
(SCL) rating.
- If the SCL rating is higher than one of the configured Edge
Transport server thresholds, content filtering takes the
appropriate action of deleting, rejecting, or quarantining the
message.
- If the SCL rating is lower than one of the Edge Transport
server thresholds, the message is passed to the Exchange server
that has the user's mailbox store.
- Content filtering compares the sender to the senders in the
safelist aggregation data from Outlook users. If the sender is on
the recipient's Safe Senders List, the message is sent to the
user's mailbox store. If the sender is not on the recipient's Safe
Senders List, the message is assigned an spam confidence level
(SCL) rating.
The SCL Rating
When content filtering assigns an SCL rating to the message, it considers any assigned data from other filters in its SCL calculation. For example, a hoster can configure sender filtering to mark messages that have specific sender information instead of rejecting messages that have a sender who is on the list of senders who are prohibited from sending messages to the organization directly. Therefore, if hosters configure a specific sender, such as someone@example.com, on the sender filtering configuration, and hosters select the option Stamp message with blocked sender and continue processing, content filtering takes that specific sender information into account when it calculates the SCL rating.
The SCL rating is a number between 0 and 9. A higher SCL rating indicates that a message is more likely to be spam. The SCL threshold is a set of configurations that hosters set on the Edge Transport server and on the e-mail server. In Exchange Server 2003, the SCL threshold defines when the content filtering feature takes a specific action on a specific message, such as rejecting a message or deleting a message. In Exchange Server 2007, the SCL threshold functionality has been improved so that hosters can adjust the SCL to a more precise level. Hosters can now define three specific actions according to SCL thresholds. For example, hosters can now define different thresholds for rejecting, deleting, or quarantining a message on an Edge Transport server. The hosters' strategy for configuring the anti-spam features and establishing the aggressiveness of the filtering policy requires careful planning and calculation. Although hosters will be able to adjust filtering policies, planning and engineering documentation will pre-set a filtering level to ensure some level has been set.
It is a best practice to reject a message when connection filtering, recipient filtering, or sender filtering detects a bad message. This approach is better than quarantining such messages or assigning agent-specific data to such messages. Therefore, connection filtering and recipient filtering automatically block messages that are identified by the respective filters. Sender filtering is configurable. This best practice is recommended because the underlying confidence level in connection filtering, recipient filtering, or sender filtering is relatively high. For example, with sender filtering, where the administrator has configured specific senders to block, there is no reason to assign the sender filtering data to such messages and to continue to process them. In most organizations, blocked messages should be rejected. If the administrator did not want them rejected, the administrator would not have put them on the blocked senders list.
The same logic applies to RBL services and recipient filtering, although the underlying confidence is not as high as the IP Block list. Hosters should note that the further along the mail flow path a message travels, the greater the probability of false positives, because the anti-spam features are evaluating more variables. Therefore, hosters may find that by configuring the first several anti-spam features in the anti-spam chain more aggressively, hosters can reduce the bulk of spam, and therefore save processing, bandwidth, and disk resources to process more ambiguous messages.
Currently at Microsoft, connection filtering, sender filtering, and recipient filtering identify and reject about 70 percent of all inbound spam.
Ultimately, hosters must plan to monitor the overall effectiveness of the anti-spam features. With careful monitoring, hosters can continue to adjust the anti-spam features to work well together for their environment. With this approach, hosters should plan on a fairly non-aggressive configuration of the anti-spam features when hosters start. This approach lets hosters minimize the number of false positives. As hosters monitor and adjust the anti-spam features, they can become more aggressive about the type of spam and spam attacks that hosted organizations experience.
Further Information
For latest information on antivirus and anti-spam technologies and their operation in Exchange Server 2007, refer to the detailed information in Exchange Server 2007 online help Anti-Spam and Antivirus Functionality and New Anti-Spam and Antivirus Functionality.