Ramblings from another nerd on the grid
You may have started to hear rumblings about the Sender ID Framework (SIDF). The SIDF technology takes another step towards curtailing spam and phishing. If your Inbox is anything like mine, it regularly receives a considerable amount of unwanted and offensive email. So how in the world do you block this stuff? Hopefully you are already using the IMF, RBL and client technologies. Lets take look at the emerging technologies in the Sender ID Framework and the enhancements to Exchange Server 2003.
The first thing you’ll want to do is download the Exchange Server 2003 SP2 Customer Technology Preview (CTP). This preview is for testing purposes and should not be used in production. You might consider Microsoft Virtual PC 2004 or Microsoft Virtual Server 2005 as your VM testing tools. Undo is your friend… We’ll get to installing and looking at the Exchange stuff later in this post.
Domain Name Service (DNS) and the Sender Policy Framework (SPF)
The first thing you need to realize, it that DNS is a core component to the framework. You’ll need to create some policy records in DNS to implement the authorisation aspects of the policy. The record(s) are called Sender Policy Framework (SPF). Since you are authoritative for your DNS zone, email systems are going to query the authoritative DNS Name Server for your zone and check for those policy records. We’ll get to the email systems in a few minutes so hang on.
Sender ID works in a three-step process.
Fortunately, there are several tools on the internet that will help you create and format the SPF records and implement them on your DNS server, or request that they be implemented on your ISP’s DNS servers. Microsoft has a wizard at http://www.anti-spamtools.org/SenderIDEmailPolicyTool/Default.aspx. You’ll also find another tool at http://spf.pobox.com/.
Lets take a look at an example for our favorite demo domain, contoso.com. In the Microsoft tool, we said that “Domain's inbound servers may send mail”, “All addresses listed in A records may send mail”, “All PTR records resolve to outbound email servers”, “No; this domain sends mail only from the IP addresses identified above.” and “Both” for the scope of the identities to validate.
This is what was generated:
v=spf1 a mx ptr -all
Ok, does everyone have their decoder ring handy? As usual, we have something that’s easy for computers to deal with but difficult for us mere mortals. No fear, we can download and review the draft documentation and pick the string apart to see what it means if we like. In the docs, you’ll learn about mechanisms, modifiers and redirection. For those of you that host several domains from a single server or have other complex DNS, web and email requirements, review the specifications carefully. Our wizard handles many cases but you’ll likely need to make some manual changes.
After we get this string, we need to add it to DNS. Easy! In Windows Server 2003, fire up the DNS management console and go to the forward lookup zone for the domain you want to add the record to. Right click the domain name and select the “Other New Records” context menu item. You’ll see the following dialog box and you’ll need to scroll down to the Text (TXT) record type (see screen shot).
Click the Create Record button and you’ll be presented with the following dialog box.
As you can see, all you need to do is paste the contents of the string into the Text: block area and click OK to save. If you go back and look at the properties for this record, it will look like the following screen shot.
Now that we have DNS implemented, you’ll probably want to test things. Port25 Solutions has created an automated testing tool to verify your Sender ID implementation. To use the tool, send an e-mail message to firstname.lastname@example.org. In return, you receive a reply containing an analysis of the authentication status of the message you sent.
Wait a second, we haven’t done anything with Exchange Server 2003 SP2!!!
Microsoft Exchange Server 2003 SP2 CTP Sender ID Feature
Like I mentioned before, download the Exchange SP2 CTP. Run E3SP2ENG.EXE and unpack the contents. Review the release notes, please. As usual, you’ll find update.exe sitting in the setup\i386 area. Update your test Exchange server.
After installation is complete, go to your Orgs Global Settings | Message Delivery properties (as shown in the following screen shot).
You are probably already familiar with some of the tab pages for Connection, Recipient and Intelligent Message filtering. Like those settings, you’ll want to set some globals, but apply those settings to one or more of your protocol virtual servers.
Click the Sender ID Filtering tab. As you can see, we have some pretty interesting choices. Although Delete is selected in the screen shot, I’m leaning towards the Reject option for my domains. This prevents email that doesn’t pass the Sender ID test from ever being sent to my server. I like the idea of preventing all those .zip, .scr, .cmd and other attachments from ever touching my hard drives.
Each of the Sender ID validation actions have value. You might decide to accept the connection and receive the email then later process the email (strip attachments, re-route, etc.).
Or you may decide to accept the connection, receive the message but immediately delete it, but never tell the sender what you did with the message. No NDR in this case seems like an invitation to continue sending email to me.
Or you may just reject the message. This will certainly stick it in the face of the sender.
Pick the option that makes the most sense for your organisation and click OK to save the change.
Now that we have the global setting implemented, we need to go apply the filtering to the appropriate protocol server. For small and medium organisations, this will most likely be the Default SMTP Virtual Server. In larger organisations that have multiple SMTP virtual servers, you’ll want to apply the filtering on the virtual servers handling inbound connections.
Go to the Servers | <server name> | Protocols | SMTP container and expand it. Right mouse click “Default SMTP Virtual Server” and select the Properties menu item. Click the Advanced button next to the IP Address: field. Highlight the appropriate ip address and click the Edit button. You should see the following dialog box:
As you can see, I am using all IP addresses for my puny VM instance and have applied Recipient filters, IMF Filters and Sender ID filters.
Now that we have this implemented on our SMTP server, it’s going to use the extension of the SMTP protocol called “Responsible Submitter”.
Sending SMTP servers (Exchange in this case) will stamp outgoing messages with the “purported responsible address” and include this address in a new header field called “SUBMITTER”. If this field is present and recognised by a receiving SMTP server (like our SP2 CTP SMTP server), it will do those fun little DNS lookups and validate the responsible address using the DNS SPF RR records.
If the SPF RR lookup fails, Exchange will handle the SMTP MAIL command stream in the manner you specified in the Global settings above.
Have some fun with this!!! I’ll probably post some telnet sessions of this in action later.
For More Information
For more information on all of this, keep an eye on the Exchange Server 2003 website, our webcast area, and Harold Wong’s blog. Harold is kicking off a ten part webcast series in October on Exchange Server 2003 SP2 and beyond. It isn’t advertised yet, but it is definitely coming.
You’ll also want to bookmark http://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx and some of the resources on that site.
Just going thru the RSS feeds I monitor and came across a very detailed post by Keith Combs from Microsoft