No, I am not talking about the Sun Protection Factor that you are used to seeing when you pick out your Coppertone or Bullfrog at the beach. I am talking about Sender Policy Framework, one of the latest efforts to help protect you from Unsolicited Commercial Email.

What is Sender Policy Framework? Let's go to the source:

SPF fights email address forgery and makes it easier to identify spams, worms, and viruses. Domain owners identify sending mail servers in DNS. SMTP receivers verify the envelope sender address against this information, and can distinguish legitimate mail from spam before any message data is transmitted.

They give a longer explanation on their website:

Have you ever gotten spam from yourself? I have, and I've been thinking hard about how to stop it! I didn't send it. It came from a spammer. If we could stop spammers from forging mail, we could easily tell spam from ham and block the bad stuff.

SPF makes it easy for a domain, whether it's an ISP, a business, a school or a vanity domain, to say, "I only send mail from these machines. If any other machine claims that I'm sending mail from there, they're lying."

When an AOL user sends mail to you, an email server that belongs to AOL connects to an email server that belongs to you. AOL uses SPF to publish the addresses of its email servers. When the message comes in, your email servers can tell if the server on the other end of the connection belongs to AOL or not.

And that's it! SPF aims to prevent spammers from ruining other people's reputations. If they want to send spam, they should at least do it under their own name.

And as a user, SPF can help you sort the good from the bad. Reject mail that fails an SPF check. Use it to help your spam filters make a decision. Have confidence that mail that SAYS it's coming from your bank, your credit card company, or the government really is!

If you do get spam that passed an SPF check, then you know you should hold the sending domain responsible for the message.

Want the short version?

It is sort of like "Caller ID" for e-mail, and whether we think that the SPF program is good, bad or somewhere in between... It is going to be in broad usage beginning October 1st, 2004. Already companies like AOL and Microsoft's HOTMAIL are implementing SPF records and using SPF as a spam testing tool for their clients.

I have my doubts as to its overall effectiveness, personally. Let's discuss how the program works before I explain them to you.

The SPF program starts by adding a special DNS record to your domain. The record is a "Text Record", something DNS servers have supported since the mid-eighties. (Most of you had not even heard of the internet back then)

This text record tells people what servers are authorized to send mail on behalf of that domain.

What good is that, you ask?

Well, when a mail server receives a piece of mail for a user, it looks at the "originating server" as well as who the mail is from. It looks up that SPF-Text record for the sending domain and compares it to the actual originating server. If the mail is from foo@foo.com then it looks up the SPF record for foo.com to see who is authorized to send mail. If the mail was actually sent by server.bogus.com, and that server is not listed in the SPF record, then it fails the test.

At first this sounds like a good idea. It could be a useful tool to detect all that spoofed-spam that pretends to be from one domain, but actually is not.

But...

What about the user who does not use their domain's authorized SMTP server? What if they are required to use their ISP's SMTP server?

Unless you use the SPF record like a huge whitelist, then those messages will fail the SPF test.

This is why I, as a system administrator, will implement these new SPF records so my users are not subject to the prejudice of overzealous mail admins around the world... but I will not weigh them heavily in my own spam tests. I refuse to use the SPF record as a huge whitelist, this is not the purpose of the DNS server, and I refuse to add large ISPs to the SPF record because their dynamic clients are the ones who send all that spam in the first place.

So. I'm sure that this will be an effective tool in the general sense, but I am also sure that unless some ISPs change their SMTP policies, we'll get false positives from this test, too.

By the time those ISPs are on board, I'm sure the spammers will have figured out how to spoof the originating server as well.

Moot point.

Posted by Michael at August 10, 2004 07:35 AM

Posted by: JP Balzen at August 12, 2004 06:54 PM