SenderID is a very effective defense
mechanism against spam, phishing schemes, and mass-mailing computer
viruses when an organization has their SenderID information properly
registered. One of, if not the most common trick used by malicious
email authors is the forging of fields in an email message’s header
information, specifically, the From address. This is often referred to
as spoofing a sender’s email address. SenderID processes inbound email
from the Internet. These are the messages that are routed through the
Receive Connector on the Edge Transport server.
1. Configuring SenderID
The
SenderID Agent is installed and enabled by default when the Exchange
Edge Transport server is installed on a Windows Server system. Because
it is installed and enabled, the focus of this section is to identify
the specific configuration tasks needed in configuring SenderID using
the Exchange Management Console or Exchange Management Shell.
Note
Changes
described in this section are applied only to the local system. This is
important if you have more than one Edge Transport server in your
environment.
To disable
the SenderID Agent using the Exchange Management Console, right-click
the agent icon in the action pane and select Disable. To disable the
SenderID Agent using the Exchange Management Shell, run the set-SenderIDConfig command with the -Enabled $false parameter, for example:
"set-SenderIDConfig -Enabled $false"
The General tab of the Agent
Properties window displays a brief description of the agent and its
capabilities, its current status, and the last time the agent’s
settings were modified.
Malicious email
crafters forge this field to hide their identity to avoid being
discovered or direct any reply traffic to a specific or random domain,
purposefully or not. Another reason this field is commonly forged is to
trick the recipient into believing the message is from someone they
know, thus increasing the likelihood it will be read and actions such
as opening an attachment or web page will be carried out.
SenderID’s
primary purpose is validating that the server sending the message to
your email server was authorized to do so for the domain specified in
the From field of the message headers. When configured and maintained
correctly, SenderID can accurately eliminate malicious email without
extensive analysis of the content contained inside. In this section,
you learn how to create and look up SPF records, how to configure
SenderID, and how SenderID Framework (SIDF) has merged these
technologies together.
When configuring
SenderID, take into consideration which sending entities should always
be allowed to deliver email messages to your organization, regardless
of having a published SPF record. For example, in medium to large
organizations a coordinated outreach to the other companies the
organization does business with might be necessary to inform them of
the impact SenderID could have on email they send to your organization
and how to mitigate that impact. Administrators should avoid
automatically rejecting or deleting messages initially to help identify
any senders that should be “white listed.” Following this
recommendation drastically reduces the impact the loss of legitimate
email can have on an organization.
There
are two components to getting SenderID functional on an Edge Transport
server; the SenderID Agent and SPF records. SPF records aren’t
something that is configured on the Edge Transport server, but rather a piece of information SenderID is required to determine how to handle the message.
SenderID
validates the sending email server by querying the DNS server providing
name resolution for the Internet for the sending server’s Sender Policy
Framework (SPF) record, provided the administrator of the sending
system created and published one correctly. SPF is the “part” that
makes SenderID work. SPF is an open standard added to the SMTP protocol
and was designed by Meng Weng Wong and Mark Lentczner to help combat
unwanted email without the use of antispam engines or extensive content
filtering. Extensive SPF record creation, supporting different SPF
configurations and/or multiple domains, and advanced syntax use is
beyond the scope of this text. This section outlines what SPF is, how
it works, how it integrates with SenderID, and how to create and
activate a basic SPF record.
An SPF
record, put simply, is a listing in DNS of what systems are authorized
to send email for a specific domain or set of domains. Publishing an
SPF record allows others to cross-reference the IP addresses of the
mail servers in an organization against that organization’s DNS entry
for their domain, specifically a mail exchange (MX) record. This is
also sometimes referred to as a reverse MX lookup.
The following is a sample SPF record for CompanyABC.com:
v=spf1 mx ip4:192.168.1.150 –all
The following is a sample SPF record for CompanyABC.com using multiple identifiers to include MX and A record lookup in DNS, and to allow email from another domain: Company123.org:
v=spf1 mx a:mail.companyabc.com include:company123.org –all
An
SPF record can contain multiple domain mechanisms and domain modifiers
to provide the correct identification and email handling or policy
information when queried by other email systems running a SenderID or
SPF filtering configuration. Although SenderID supports both SPF 1.0
and 2.0, this section focuses on SPF 1.0 because it is presently the de
facto version.
Note
At the time of writing, SPF 2.0 was currently being reviewed by the Internet Engineering Task Force’s (IETF; http://www.ietf.org) Internet Engineering Steering (IESG; http://www.ietf.org/iesg.html) unit for publication as a new Request for Comments (RFC). SPF 2.0
includes new mechanisms and modifiers for SPF records offering greater
flexibility for antispam filters. The review focuses around whether the
SPF 2.0 record should distinguish between a SPF record lookup and
SenderID record lookup. The Microsoft SenderID supports both SPF 1.0
and 2.0.
SPF only needs three pieces of information to work:
The domain of the From address in the message headers
The purported IP address of the email server that sent the message
The HELO or EHLO parameter of the server that sent the message
Using
this information, SenderID can determine if the IP address was
authorized to send email for the domain listed in the sender’s email
address.
SenderID Framework
(SIDF) is a combination of two similar technologies: Sender Policy
Framework (SPF) and Microsoft’s CallerID for email. The SenderID
Framework has been finalized and submitted to the IETF (http://www.ietf.org/) for final review in hopes it will soon become an Internet standard.
