Logo - tutorial.programming4.us
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
 
 
Windows Server

Implementing Edge Services for an Exchange 2010 Environment : Utilizing SenderID on an Edge Transport Server

3/21/2011 5:46:57 PM
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:

  • Reject the message.

  • Delete the message.

  • Stamp message with SenderID result and continue processing.

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

The Get- command is used to retrieve the configuration of the Sender Filtering Agent. For example, entering Get-SenderIDConfig displays the Sender Filtering configuration on the local system.

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					  
 
Other -----------------
- Implementing Edge Services for an Exchange 2010 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 2)
- Implementing Edge Services for an Exchange 2010 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 1)
- Exchange Server 2010 : Installing and Configuring the Edge Transport Server Components
- Installing Exchange Server 2010
- Preparing Your Environment for Exchange Server 2010
- Windows Server 2008 R2 : DirectAccess Scenario (part 6) - Monitoring the DirectAccess Server
- Windows Server 2008 R2 : DirectAccess Scenario (part 5) - Testing DirectAccess
- Windows Server 2008 R2 : DirectAccess Scenario (part 4) - Configuring DirectAccess Feature
- Windows Server 2008 R2 : DirectAccess Scenario (part 3) - Certificate Autoenrollment & IP-HTTP Certificate
- Windows Server 2008 R2 : DirectAccess Scenario (part 2) - Using a GPO to Configure Firewall Rules & Custom Certificate Template for IP-HTTPS
 
 
Top 10
- Microsoft Lync Server 2013 : Windows Client - Navigating in the Client - Useful Lync Client Shortcuts
- Microsoft Lync Server 2013 : Windows Client - Navigating in the Client - Managing Contacts, Managing Groups, Status View
- Microsoft Lync Server 2013 : Windows Client - Navigating in the Client - Configuring Basic Options
- Microsoft Lync Server 2013 : Windows Client - Installing the Client
- Microsoft Exchange Server 2013: Configuring mailbox delivery restrictions, permissions, and storage limits (part 4) - Setting storage restrictions on mailbox and archives
- Microsoft Exchange Server 2013: Configuring mailbox delivery restrictions, permissions, and storage limits (part 3) - Permitting others to access a mailbox
- Microsoft Exchange Server 2013: Configuring mailbox delivery restrictions, permissions, and storage limits (part 2) - Setting message send and receive restrictions on individual mailboxes
- Microsoft Exchange Server 2013: Configuring mailbox delivery restrictions, permissions, and storage limits (part 1) - Setting message size restrictions on delivery to and from individual mailboxes
- Microsoft Exchange Server 2013: Moving mailboxes (part 3) - Performing on-premises mailbox moves
- Microsoft Exchange Server 2013: Moving mailboxes (part 2) - Performing on-premises mailbox moves and migrations
 
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone