SPF and Sender ID

I've been reading up on several of the new anti-spam measures being put forth by the industry. Microsoft and http://www.pobox.com/ are teaming up to make a new system called Sender ID Framework that adds mail authentication in two different parts of the mail delivery process. It's still young, but it's being adopted very quickly.

SPF (sender policy framework) aims to add authentication to the e-mail envelope (the package that carries the message) by adding DNS records (this is a sample DNS record for mcneel.com) that indicate the IP addresses that are allowed to send e-mail via a domain. So for example, we can add a DNS entry to our DNS servers that says 204.177.179.x are all valid IP addresses for mcneel.com and rhino3d.com mail delivery. Optionally, we can specify that all other addresses are not allowed to use these domains.

When a receiving mail server that supports SPF gets a message from a mcneel.com address, it verifies that the sender was also from a 204.177.179.x IP. If it is then they are more certain that the message was from mcneel.com (and can decide from there if they consider us spammers). If it is not, then it's either spam or someone in our office sending e-mail incorrectly.

Sender ID Framework (a Microsoft invention) combines "Caller ID for E-mail" with SPF. This is more complex but also handles authentication better for roaming people (people that send e-mail from Starbucks cafe's, for example). It adds authenticating the entire chain of e-mail delivery. Servers can forward e-mail and declare themselves the "authority" having already checked to make sure the previous link in the chain was secure. Presumably any mail that goes through a "secure" link that is not "secure" gets dropped. This framework has been submitted to the Internet Standards group for review.

My recommendations:

1. Make sure we have correct SPF DNS entries for all our domains. I have a pretty good idea of what's required. This will make it possible for the rest of the world to determine what messages are from us.
2. Ensure everyone in our organization sends mcneel.com e-mail through one of our servers. If this is not feasible (because of bandwidth requirements) then we need a short list of trusted IP addresses from our regional offices that they can use to send legitimate mcneel e-mail.
3. Wait. This stuff is really really new. There's a massive churn in the industry and people are clamoring for a standardized spec for e-mail authentication. People are a bit scared that they'll be beholden to Microsoft if Sender ID Framework is adopted, but Microsoft is big.
   
   It looks like IMail and Declude are both waiting to release products that support SPF and/or Sender ID Framework. I'm sure there will be lots of stuff available soon.

Tim: In the mean time, I think we should roll ahead with the new mail server. It looks like it's doing a good job of reducing the spam that gets to my computer. For that, I am happy.

There are already implementations of SPF checkers available. I downloaded one today, and it worked. I considered adding it to the mail server, and then realized how early the adoption of this stuff is. I'm not really interested in working to integrate it into our mail server if Declude is going to do it better in the next 3 months. I think this is likely.

Oh, I found some cool DNS tools at http://www.dnsstuff.com/ and http://www.dnsstuff.com/pages/spf.htm