Troubleshooting Exchange’s Built-In Anti-Spam Technologies: Pt. 6 Sender IDWritten by Casper Manes on September 4, 2012
Sender ID filtering is another of the anti-spam agents that run on Exchange 2010 Edge Transport servers. Sender ID filtering uses information in the SMPT header, and SPF records in DNS, to decide what to do with a message. Let’s do a quick review of just how this works, and then we’ll move on to how to troubleshoot it.
Sender ID filtering is on by default, and depends upon Sender Policy Framework (SPF) records in DNS. An SPF record includes information on systems that are allowed to send email for a domain, and can include IP host or network addresses, other domain names, A, MX or PTR records, etc. It also indicates what a receiving system should do when a message comes from an unauthorized system. When an email is received at the Edge Transport server from the Internet, the header is examined to find the mail from: address in the header. Then, the Edge Transport server performs a DNS lookup for the SPF record associated with the domain. If our subject email is from email@example.com, then the Edge Transport server will look up the SPF record for example.com and compare the information in the SPF record to the system sending the message. If the sending system is listed within the SPF record, the message passes, but if it is not, then the first thing to consider is what the domain owner indicates should be done with suspect messages. An SPF record can indicate any of the following:
+ for a PASS result. This can be omitted; e.g., +mx is the same as mx.
? for a NEUTRAL result interpreted like NONE (no policy).
~ for SOFTFAIL, a debugging aid between NEUTRAL and FAIL. Typically, messages that return a SOFTFAIL are accepted but tagged.
- for FAIL, the mail should be rejected.
You can configure how your Exchange server reacts when a message FAILs or SOFTFAILs, or what to do when a DNS lookup for an SPF record fails, using the Set-SenderID command. You can set your Edge Transport server to either stamp the message as probably spam but pass it through for further processing, reject the message with a 550 response, or delete it. The default action is to stamp the message but pass it to other agents for further processing.
Checking your Sender ID filteringconfiguration
You can check your Sender ID configuration using the Get-SenderIDConfig command. Pipe the output to a formatted list for easy reading, and to see each of the settings you can customize.
Get-SenderIDConfig | fl [enter]
Turning Sender ID filtering on or off
Sender ID filtering is on by default. You can easily turn Sender ID filtering off using this command.
Set-SenderIDConfig –Enabled $false [enter]
To reenable Sender ID filtering, use this command.
Set-SenderIDConfig –Enabled $true [enter]
Bypassing Sender ID filtering for specific users or domains
You can configure exceptions to Sender ID for either specific recipients, or for specific sending domains, as follows.
To bypass Sender ID filtering for specific recipients, use a comma separated list with the following command.
Note that this list is limited to a maximum of 100 recipients, and works with literal SMTP addresses. If Joe has three aliases and you want all three to be bypassed, you need to enter all three in this command.
To configure sending domains to bypass Sender ID filtering, use this command with a comma separated list for multiple domains.
Set-SenderIDConfig –BypassedSenderDomains example.com, example.org [enter]
Again, this command has a maximum 100 domains. For both commands, entering new records will overwrite the existing entries, so either re-add them all or use a command syntax like this to read the existing settings and append.
$Configuration = Get-SenderIDConfig
$Configuration.BypassedRecipients += “firstname.lastname@example.org”
Set-SenderIDConfig -BypassedRecpients $Configuration.BypassedRecipients
Testing Sender ID
You can use the Test-SenderID command to see how Sender ID will interpret a particular message from a specific IP address.
Test-SenderId -IPAddress 192.168.0.1 -PurportedResponsibleDomain example.com
Configuring how to handle spoofed email
If an email arrives at your gate from a sending system that is not in the SPF record for the domain, I prefer to reject the message. The default action is to stamp the message and pass it on to other agents for additional processing. To set your Edge Transport server to reject the message, use the following command.
Set-SenderIDConfig –SpoofedDomainAction Reject
With Sender ID filtering in place, you work with legitimate domains and the SPF records set up by their admins. If there is no SPF record in place, then the default action is to stamp a message and pass it on for additional processing. Encourage your peers to use SPF records and configure them to FAIL any senders not in the SPF record. It’s an easy way to combat spoofing and costs only a few moments to get an SPF record properly formatted.
Do you have SPF records in place, and if so, do you SOFTFAIL or FAIL?