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, 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.
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.
SenderID is an
invaluable tool that can combat more sophisticated spam attacks such as
the Reverse NDR attack that delivers spam email to recipients using a
forged FROM field and targeting accounts that obviously don’t exist. The
spam message is sent to bogus e-mail addresses in an organization;
however, the NDR is relayed to the address in the FROM field—the target
of the spammers campaign. This attack makes it appear to other systems
that the organization sending the NDRs could be spamming and places the
organization at risk of being placed on a block list. These types of
NDRs are also referred to as backscatter.
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 requires to determine how to handle the message.
Note
SenderID also works with
the Sender Reputation Agent to help the Sender Reputation Agent compute
a Sender Reputation Level (SRL) for the sending entity.
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.
Note
More information regarding Sender ID and Sender Policy Framework (SPF) can be found at http://www.ietf.org under Request for Comments (RFC) 4405, 4406, 4407, and 4408.
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.
Creating a Sender Policy Framework Record
This section walks you through setting up an SPF record using the Microsoft Sender ID Framework SPF Record Wizard located at www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/.
On the Microsoft Sender
ID Framework SPF Record Wizard web page, first enter the domain for
which you want to create a record (for example, companyabc.com)
in Step 1 of 4: Identify Your Domain field on the website, and click
Next. The website checks DNS information about the domain to see what
records, including SPF, exist. If no records exist, you are taken to the
next step, Step 2 of 4: Display Published DNS Records. Review the
information provided to ensure its accuracy, and click Next when you are
ready to proceed to Step 3: Create SPF Record.
In Step 3 of 4: Create
SPF Record of the Microsoft Sender ID Framework SPF Record Wizard, seven
sections can be configured to support the organization’s email
structure. On this page, you can create an SPF record to reflect the
following:
- That the domain does not send email.
- That inbound email servers also send email for the domain.
- That outbound email servers are different from the domain’s inbound email servers.
- That all reverse DNS records (PTR) resolve to the domain’s outbound email servers.
- That a domain’s outbound email is routed through another domain (outsourced).
- That the domain will send email from an IP address not listed in the SPF record being created.
- That
the SPF record can be used to validate either the Purported Responsible
Address (PRA) derived from the message headers, or from the MAIL FROM
(or reverse-path) address derived from the SMTP protocol’s MAIL command,
or both. The PRA is the [nonforged] IP address of the system
responsible for sending the email message and the MAIL FROM tag (often
forged) designates the email address the message is being delivered as.
Note
Some fields in the
form might already contain data when the wizard queried DNS for
information about the domain entered in Step 1.
For this example, you will create an SPF record in which companyabc.com’s
SMTP server is running the Edge Transport server role and handles both
incoming and outgoing email. No other domains or IP addresses should be
allowed to route email for companyabc.com.
In the form, specify that
the domain’s inbound email servers can send email by selecting the
check box of the same name in the Inbound Mail Servers Send Outbound
Mail section of the form. Next, specify that the IP address of the
outbound email server for companyabc.com
is 192.168.2.150 by adding that IP address to the Outbound Mail Server
Addresses field in the form. Accept the default of Discouraged to the
question regarding whether legitimate email can or will originate from
an IP address not included in this record, and allow the record to be
used to validate both the Purported Responsible IP address (PRA) and
MAIL FROM address in the message headers. Now that the information has
been entered, you can proceed to Step 4 of 4: Generate SPF Record, where
the record can be created so it can be reviewed and saved for later
use.
The record example for companyabc.com looks like this:
v=spf1 mx ip4:192.168.1.150 –all <or> ~all
The v=spf1 designates that this is an SPF record and it is version 1. The portion mx IP4:192.168.2.150 signifies the email server at 192.168.2.150 is authorized to send and receive email for company abc.com. The -all closes the record by stating that no one besides the IP addresses in companyabc.com’s MX records are authorized to send email using a companyabc.com
and can be rejected. From here, you can copy the syntax, paste it into a
Notepad or WordPad document, save the file in standard ASCII text (TXT)
format, and add it to DNS so other organizations using Edge Transport
servers or an implementation of SPF can look up companyabc.com’s SPF record.
Note
The SPF record must be
published in DNS as a text file to be properly recognized. Beyond
formatting of input on the form, the Sender ID Framework SPF Record
Wizard does not test or validate the settings entered. After the wizard
has finished creating your SPF record, take a moment to view it for
accuracy before exporting it for use on the DNS servers.
More
information about SPF—extensive SPF record creation, supporting
different SPF configurations, multiple domains, and advanced syntax
use—is beyond the scope of this text. More information can be obtained
at the Microsoft website (www.microsoft.com/mscorp/safety/technologies/senderid/resources.mspx) or Sender Policy Framework (www.openspf.org).
So far, we’ve
covered how SenderID works, how to create and manage simple SPF records,
and considered the impact SenderID can have on legitimate email. At
this point, the SenderID Agent on the Edge Transport server(s) can be
configured.
Configuring the SenderID Agent on the Exchange Edge Transport Server
The SenderID Agent is
enabled by default on Exchange Server 2010 Edge Transport servers.
Configuration is quick and straightforward because SenderID only relies
on a couple of items to function properly. SenderID like other
spam-filtering technologies can impact legitimate email but, as
discussed earlier, there are ways to mitigate this impact while still
identifying messages that don’t have an SPF record.
To begin configuring SenderID, do the following:
1. | Launch
the Exchange Management Console by doing the following on the Exchange
server. Click Start, All Programs, Microsoft Exchange Server 2010.
|
2. | Choose Exchange Management Console.
|
3. | Double-click the SenderID Agent in the action pane.
|
4. | Select the Action tab.
|
From here, you can
change the action taken on messages if the SenderID check fails. There
are different actions to choose from. One action is to Stamp Message
with Sender ID Result and Continue Processing. This is the default
action and appends certain information to the message headers for
further processing by the Content Filtering Agent. The Content Filtering
Agent then takes this information into account when tabulating the
overall spam score assigned to the message, also known as the Spam
Confidence Level (SCL).
Tip
When you first
implement SenderID filtering, it is recommended to “stamp” messages to
assist in filtering out false positives and generate a white list of
legitimate senders and domains. After the organization is comfortable
with the established white list, messages can be rejected.
Another option is to use
the “exp” modifier in your SPF record and include a uniform resource
locator (URL) to an Internet web page where others can retrieve
information about your email policy, SPF records, and contact
information. This helps offset false positives when rejecting email
messages that fail to comply with SPF.
The actions available if a SenderID check fails include the following:
Choosing to reject
the message sends an error response to the sending server. The text
contained in this error message corresponds to the Sender ID status
derived from processing the SPF record of the message.
Choosing to delete the
message sends a fake OK SMTP command to the sending server. The message
is deleted and the sender is not notified.
Accepting the default
action of Stamp Message with Sender ID Result and Continue Processing
appends the Sender ID status derived from the SPF record lookup into the
message headers for further processing by the Content/IMF filter. This
information, often called metadata, is used by the Content/IMF filter to
create the SCL.
Using the Exchange Management Shell to Configure SenderID
One limitation of
SenderID is the inability to exclude recipients and domains from
SenderID filtering through the Exchange Management Console. Exclusion of
recipients and domains from SenderID filtering can only be accomplished
using the Exchange Management Shell’s Set-SenderIdConfig
command. The following example enables the SenderID Agent on external
SMTP connections, bypasses checking one external domain, and sets the
action on spoofed messages:
Set-SenderIdConfig -BypassedSenderDomains Microsoft.com -Enabled $true -ExternalMailEnabled $true -SpoofedDomainAction Delete
You can test the configuration of SenderID using the Test-SenderID Exchange shell command. The following example tests to see if the SPF record resolves correctly:
Test-SenderId -IPAddress 192.168.1.150 -PurportedResponsibleDomain mail.companyabc.com
