8. Sender Filtering
Sender filtering is one of the oldest antispam
features in Exchange; it is probably also the least effective. The
premise is that you provide a list of SMTP addresses or domains that
should not be able to send your users email. The problem is that most
spammers don't use the same email address twice, so this is less than
completely effective. Figure 8 shows the Blocked Senders tab of the Sender Filtering object's properties.
You can block individual senders and you can block
all senders in a specific domain. One interesting antispam technique
that some organizations employ is to put their own domain in this list.
This prevents those spam messages that claim to be from one of your own
recipients. However, if you do that on an internal Hub Transport
server, make sure that it is not being used for POP3, IMAP4, or other
clients that use SMTP to send mail internally.
Another interesting antispam technique that blocks a
few pieces of mail is selecting the check box Block Messages That Don't
Have Sender Information. If a message does not have a sender (and it
should), then this rejects the message.
The interface is a little different than in previous
versions of Exchange Server. When you add or edit blocked senders, you
have the option of adding an individual user or an entire domain and
subdomains.
On the Action tab of the Sender Filtering object's
properties, you can specify what action to take. You can either reject
the message entirely or stamp the message with a blocked sender and
allow it through. If you stamp the message as being from a blocked
sender, the content filter will rank it as spam.
9. Sender ID
We talked a bit about
sender protection framework records and DNS and how to make sure that
yours are registered properly. Contrary to popular misconception,
Sender ID is not an antispam technology but an antispoofing technology.
Quite simply, each organization on the Internet that sends email should
register a sender protection framework (SPF) record in their public DNS
server. This SPF record contains a list of the servers authorized to
send mail on behalf of their domain.
When an STMP server receives a message from a
particular domain, it analyzes the message to determine the actual
sender and determines which server sent it. If the message originated
from an authorized server, it is probably not being spoofed. If it is
accepted from a server that is not in the DNS SPF record, the message
might be from a spoofed sender.
On the Action tab of the Sender ID object's properties, you can specify which action to take. Figure 9
shows the Action tab. You can reject the message, delete the message,
or accept it for further processing by the content filter.
The problem with Sender ID is that fewer than 15
percent of all domains on the Internet have an SPF record, at least by
some estimates. And frequently an organization's SPF records get out of
date and are therefore wrong. The only thing worse than not having an
SPF record is having one that is wrong. Therefore, it is impractical to
reject or delete messages that fail the Sender ID test. You should keep
this setting configured to Stamp Message With Sender ID Result And
Continue Processing.
