Exchange 2003 SP2 adds a couple of new features. One of the most talked about is Sender ID.

With Sender ID capabilities in Exchange 2003 SP2, should you enable it and reject all mail from servers without SPF records? No, while Sender ID is one tool in the anti-spam arsenal it should not be relied on as the solution to your spam problems. Once you understand how Sender ID works, you'll see why rejecting messages which fail the sender ID test is probably not in your best interest.

How it works: Sender ID is used to verify that each e-mail message is actually sent from the Internet domain from which it claims to come, based on the sending server's IP address. This will help to eliminate address and domain spoofing and should make it easier to identify and filter junk e-mail and phishing scams. But it's not fool proof, in part because it relies on administrators to create an SPF record for their mail servers.

When a mail server receives a message, it looks up the SPF record of the sending domain, which is published in the Domain Name System (DNS) record. If the sending computer's IP address matches the IP address that is published in the DNS record the message is considered legitimate and passes through.

Exchange can be configured one of three ways to deal with unmatched IP addresses. The message can be deleted and no NDR generated, the message can be rejected, or the message accepted and the Sender ID result used by IMF when it determines the spam confidence level (SCL).

Accepting the message is recommended. Deleting or rejecting email from senders that have no SPF record is useful only if you only care if the sending server has a correct SPF record and aren't concerned whether the messages are legitimate email or spam. The absence of SPF info in a TXT record doesn't implicate the sender domain or server as a spammer. Why? Because while publishing information in SPF is good, it's absolutely no guarantee that a message is or isn't junk mail. There are more spammers with SPF info published than there are legitimate domains and incorrect SPF info may be published by domain owners.

In time, as more and more sites configure Sender ID records, it might have more direct benefit, until then, it's just one tool in the fight against spam, and best used in conjunction with the IMF or other anti-spam solutions.

Creating a SenderID Record

Before you enable filtering for Sender ID records at your site, you should verify that you have a valid SPF record for your domain configured in DNS. This isn't because you need your own SPF records to use Sender ID with Exchange, but because it's not right to hold incoming mail to higher standards than others can apply to the email you send. Plus, it adds one more domain to the short list of domains who currently have SPF records.

If you don't already have an SPF record, create one using the wizard at //www.anti-spamtools.org/SenderIDEmailPolicyTool/Default.aspx and enter it into your DNS records. It's going to look something like this:

v=spf1 include:spf.intermedia.net ~all

After adding the record to your DNS, you can find out if your record is valid by sending a message to your gmail account (or another email server that supports SPF) and view the message source. If your record is correct, the message header will have a line similar to this, indicating it passed.

Received-SPF: pass (domain of [sender's address] designates [IP address] as permitted sender)

If it failed, review your SPF record for errors and try again.

Enabling SenderID Filtering

Once your SPF records are in place, enable Sender ID filtering on the Exchange server. Open the Exchange System Manger and navigate to Global Settings then view the Message Delivery property sheet. Verify it is set for Accept and close the dialog.

Tip: If your Exchange server receives mail from another SMTP server within your network, add that server's IP address to the Perimeter IP list on the General tab before closing the dialog. You'll need this configured if you decide to enable other filtering options on the SMTP server.

Next, navigate to the SMTP server node and view its properties sheet. On the General tab click the Advanced button then select the IP address and click Edit. Enable Sender ID filtering, as well as any other filters you desire. Repeat as needed for each IP address assigned to the SMTP server and close the dialog. From this point forward, all mail that goes through this SMTP server should have a Sender ID value attached to it.

Once you create some custom views in Outlook, you can judge for yourself how effective Sender ID might be in your organization.

Viewing the Sender ID Value

Exchange 2003 SP2 allows you to use Sender ID to help identify potential spam. When it's enabled you can choose to include add the SPF value to the message as a MAPI property for use by IMF and pass the message along or drop the message. As I mentioned in the last issue of EMO, at this point in time Sender ID is not very useful for judging the legitimacy of a message. Not enough sites have SPF records configured in DNS, which means it can only be a small part of your anti-spam arsenal. Also, there is nothing to prevent spammers from creating SPF records, so the presence or absence of SPF records is no guarantee the message is from a spammer.

But why take my word for it when you can see the usefulness (or lack of) within your own organization? All you need to do is turn on Sender ID on the Exchange 2003 SP2 server and look at the MAPI property value assigned to your messages, using a custom form file which exposes MAPI property fields for use in a custom view.

Don't panic. It's much easier than it sounds, especially since Konstantin Ryvkin from the Exchange team did all the work for you. He posted the contents of the necessary cfg file on the Exchange team's blog, You had me at EHLO. All you have to do is copy and paste it into a text file and save it using the extension cfg then add the view to your field. Complete details are in the Sender ID article including instructions on adding the fields to your view.

Once you add the Sender ID field to your view, you'll see a number listed in the column on all newly received email. This code corresponds with the following Sender ID values:

1 - Neutral: the domain records make no assertion that the IP address is valid for sending mail
2 - Pass: the client is authorized to send mail on behalf of the domain
3 - Fail: This means one of the following: the sending domain does not exist, the sender is not permitted, it's a malformed domain, no PRA (Purported Responsible Address) was found in the header, or the client is explicitly NOT authorized to send mail on behalf of the domain.
4 - Soft Fail: the client might not be authorized to send mail on behalf of the domain.
5 - None: No Sender ID records are published for this domain. This is the most common value at this time.
Temporary error: the receiving server encountered a transient error when performing the check
-2147483641 - Permanent error: the domain's published records couldn't be correctly interpreted.

So, how accurate is Sender ID at identifying spam? In looking at the Sender ID values on the email in my mailbox, it's not very good. Most of the messages that make it past the anti-spam filter on the server are from domains that do not have SPF records, including a number of well known sites that publish email newsletters about technology in general and Exchange specifically. I expected they would be first in line with published SPF records.

Soft failures appear to be common with hosted mail servers. Permanent error values are found on messages that qualify as solicited junk email (i.e. advertising from companies I do business with), because the sites created Sender ID records but used a format Exchange doesn't understand, such as this one for the email servers used by Handango: rm04.net text = "v=spf1 ip4:129.41.69.0/25 ip4:129.41.76.0/24 ip4:129.41.77.0/24 -all"

Because it's interesting to see who is using SPF and who isn't, I recommend enabling it in Exchange 2003 SP2 and configuring the custom form to display the values.