If at any time during this process the Exchange filter mechanism sees SMTP
verbs in the wrong sequence (e.g., DATA before MAIL FROM) or with obviously
malformed arguments, Exchange drops the connection.
Sender and Recipient Filtering
At this stage, Exchange has accepted the P1 sender address and is ready to accept
the list of message recipients. Before it does so, however, Exchange performs
Realtime Blackhole List (RBL) checks. If you've configured Exchange with RBLs,
Exchange checks the first RBL in the list by querying the RBL provider with
the sender's IP address in reverse. For example, if the sender's IP address
is a.b.c.d and the RBL provider is example.com, Exchange queries the RBL provider
for d.c.b.a.example.com. If the RBL provider has a record for the sender's IP
address, the provider returns a status code indicating which RBL contains the
IP address; otherwise, it returns a Host Not Found error message.
Exchange queries each RBL on the list until it either finds a match or runs
out of RBLs. When Exchange finds a match, the Exchange SMTP server returns a
5.7.0 error with an optional custom error message you can use to explain why
the email message bounced. You can also define a list of recipients for whom
RBL checks should not be performed (e.g., your postmaster or abuse mailboxes).
Messages to those recipients are accepted, even if the sender's IP address is
on an RBL, and are flagged to exempt them from further checks.
Next, Exchange accepts the RCPT TO verb, which specifies the message recipients.
Like senders, recipients are checked against two lists: a list of blocked recipients
(for whom all mail is refused) and a list of allowed recipients (for whom all
mail is accepted). If the recipient doesn't appear on either list, what happens
next depends on the Filter recipients who are not in the Directory setting
on the Message Delivery Properties dialog box's Recipient Filtering tab that
Figure 3 shows. When the check box
is selected, Exchange compares the recipient alias against AD to ensure that
the recipient is valid; messages to invalid recipients are returned with an
NDR. When the recipient is valid or if the check box isn't selected, Exchange
accepts the DATA verb, which contains the message contents.
The DATA conversation includes transmission of the message headers, which contain
the sender's reply address (aka the P2 address). If this address appears on
the sender filter list, Exchange drops the connection and deletes the message.
If the SMTP connection is still active and Sender ID checking is enabled, Exchange
looks for a Sender Policy Framework (SPF) or Sender ID resource record on the
DNS server. When a record for the purported sending domain is found, Exchange
checks it against the sender's P1 address. If no record exists or if the record's
information doesn't match the sender's P1 address, Exchange processes the message
according to the setting selected on the Sender ID Filtering tab of the Message
Delivery Properties dialog box, which Figure
4 shows. Because the Sender ID result factors into the IMF's decision about
whether a message is legitimate, Microsoft recommends that you use the default
of accepting messages even if they fail the Sender ID check. Few organizations
have set up Sender ID records to date; as more organizations do, you'll want
to consider enforcing Sender ID checks by deleting or rejecting messages from
domains that don't have Sender ID records. (See Additional Resources for more
information about Sender ID and IMF.)
Content Filtering
Content filtering is performed by the IMF. Unlike most third-party solutions,
the IMF has few administrator-adjustable settings, depending instead on a corpus
of filtering data that's produced by analyzing hundreds of thousands of messages
sent to MSN Hotmail users. The IMF assigns messages two numerical scores: the
spam confidence level (SCL) and the phishing confidence level (PCL). The higher
the number, the more likely the message is illegitimate: An SCL of 9 means the
IMF is sure the message is spam, whereas an SCL of 1 means the message is probably
legitimate. An SCL of -1 means that the message was exempted from IMF scanning
because it came from a trusted IP address or sender, was delivered over an authenticated
connection, or came from another user in the same Exchange organization. The
PCL is similar to the SCL, but it measures the likelihood that a message is
phishing.
As Figure 5 shows, the IMF lets
you control two threshold values: the gateway threshold, which controls the
SCL at which messages are rejected; and the store threshold, which controls
the SCL at which messages are accepted but routed to the user's Junk E-mail
folder. (There are no corresponding settings for the PCL, unfortunately.) You
can also tell Exchange what to do when a message exceeds the gateway threshold:
Delete the message, reject it with an NDR, archive it for later inspection,
or take no action. Microsoft recommends that you initially set gateway blocking
to No Action, then let the filter run for a few days and use the IMF's performance
counters to help you decide where to set the gateway SCL.
You can make a couple other adjustments to the IMF, although they're not exposed
in the UI. For example, you can define a custom word list as an XML file (stored
in MSExchange.UceContentFilter.xml in the \exchsrvr\bin\MSCFV2 directory) and
adjust the SCL up or down for messages that contain the specified words. This
is a useful function, provided you're careful about which words you include.
You can also use the CustomRejectResponse registry key to force the IMF to return
a custom SMTP response for messages that are rejected (e.g., 550 5.7.0 Die,
spammers, die!). There's really nothing else to adjust or set. This simplicity
is an advantage for many sites, though some administrators want more granular
control over which messages are accepted and rejected.
The Future Looks Good
Exchange Server 2007 adds several new features. The basic IMF engine is largely
the same, but it runs as part of the Content Filtering agent, a component that
runs on the Hub Transport or Edge Transport server role to protect your network
by filtering messages at the perimeter.
Exchange 2007 also introduces Automatic Updates to the IMF's filter corpus;
a UI for setting the IMF's custom words list; and a flexible engine for defining
rules to block, quarantine, forward, or drop messages according to criteria
such as subject, attachment size or type, sender, and recipient. The Edge Transport
server role can collect safe and blocked sender lists from individual Outlook
mailboxes and aggregate them for perimeter filtering, and there are a host of
other minor tweaks.
Prev. page
1
[2]
3
next page 
