Random Developments

This is SPF as in Sender Policy Framework, an antispam method that is becoming more and more popular. I liked it at first but, after thinking a little more about it, I realized that I don’t.

For those that are not familiar with it, read their How It Works page, there’s a fairly good explanation there. The basic principle is that a domain owner (usually not a regular user) will nominate a set of servers that are allowed to send messages that claim to have a sender from his/her domain. Compliant recipients (servers, not users) will check this nomination and reject (or mark) messages that come from “unauthorised” servers. The idea is to eliminate spam coming from forged addresses.

The reason I don’t like it is that it tries to fix the problem in the wrong way. It tries to authenticate servers, not people; and, in trying to do so, it enforces rules that don’t really exist and that most users don’t know about (and wouldn’t understand, anyway). Servers don’t send e-mail, people do, and unless you can authenticate the person sending a message, by whatever method, you can’t be sure the message is invalid.

Let’s see one scenario where legitimate e-mail will be dropped. Take an hypothetical ISP, which we will call T, where SPF is enabled. Also, take an hypothetical web site that we will call U. Now say that a user, W, who has an e-mail account with T, goes to the web site U and sees a news report that he thinks might interest another user, X, who happens to also have an account with T. There are a few ways for W to send the news item to X, but the easiest one is to click on the “send this news item to a friend” link on the web page. He does that, fills in the form with his e-mail address as the sender and C’s address as the recipient, and off the message goes.

And back the message comes with this error:

Now, I know what this message means. Would a regular user know? I think not. And, even if we get past this user-friendliness issue (one could always give a better explanation in the returned message), was this message properly blocked? Again, I think not. It was a legitimate message, initiated by the person listed in the envelope From: (thus ensuring that eventual errors are directed to the message initiator, and not to the web site owner) and sent to a person with whom the user had a previous relationship.

Granted, the message wasn’t sent from one of T’s e-mail servers, but why should it? That’s not a contractual obligation between T and its users, is definitely not an RFC requirement, and may not even be a technical possibility: many, many access providers block SMTP access out of their networks, or silently redirect it to their own servers. Yes, I know about port 587; do regular users know? Once again, I guess not.

This error is not hypothetical, in case you didn’t guess. And it’s just one of the failure modes: one other is the issue I mentioned above of access providers silently redirecting port 25; e-mail forwarding sounds like another, but I haven’t tested it.

As I said above, the problem here is that servers are being authenticated in an attempt to verify that messages are valid, but server authentication says nothing about this. Unless you have a way to actually validate the person who initiated the message (and I don’t really see how you can do that in all cases), you can’t guarantee messages are valid or not. And, if you drop messages that fail the SPF test, you will drop valid messages without your users even knowing that they are missing messages.

I would be a little more sympathetic to using SPF as a means to score messages in order to possibly mark them as spam, or to allow end users the option of rejecting/quarantining them. Rejecting the message in a way that does not allow the recipient the option to accept it (and, by the way, generating backscatter when forged addresses are used for real spam) is really bad.