Home / Blogs

A Political Analysis of SPF and Sender-ID

In my spare time when I’m not dealing with the world of e-mail, I’m a politician so now and then I put on my cynical political hat.

At the FTC Authentication Summit one of the more striking disagreements was about the merits and flaws of SPF and Microsoft’s Sender-ID. Some people thought they are wonderful and the sooner we all use them the better. Others thought they are deeply flawed and pose a serious risk of long-term damage to the reliability of e-mail. Why this disagreement over what one might naively think would be a technical question?

SPF does what’s known in the mail biz as path authentication, that is, it attempts to check whether the route that a message took to get to the recipient is valid for that kind of message. In particular, SPF provides a very complex scheme through which a domain can publish the IP addresses from which it expects its mail to be sent. Microsoft’s Sender-ID works almost identically to SPF, with the only difference being which of several possible return addresses on a piece of e-mail it checks.

If all of a domain’s mail is indeed sent from the same place, then SPF or Sender-ID work fairly well. (It still has problems with mail forwarders, but that’s a separate issue discussed at great length elsewhere.) On the other hand, if the domain’s mail can legitimately come from lots of different places, particularly lots of different places that are hard to predict in advance, SPF and Sender-ID are useless.

So what kind of domain sends all its mail from one place? Corporations, mostly. A business will often have a single mail server, or a mail server per branch office, and a policy that all company mail is sent through the company’s server. If employees are traveling, they have to connect back to their home network to get and send mail.

A bulk mailing service, known in the biz as an Email Service Provider or ESP, sends all of its mail from its own servers. That’s both because the servers exist, and because it’s easier to get recipient ISPs to whitelist their mail if the ESP can give the recipients a small set of IP addresses to add to the whitelist.

On the other hand, mail from university domains can come from all sorts of unexpected places. Students and faculty travel, and being clever academics, lash up all sorts of ad-hoc schemes to send and receive their mail. Many universities provide courtesy mail addresses for alumni that the alums can forward to whatever ISP they happen to be using. The alums send their outgoing mail from their own ISP, so mail from the university’s domain can originate at any ISP in the world.

Internet Service Providers are in about the same situation as universities. Their customers may check mail from work, and send mail with a personal ISP address via their work servers. Or they might move and keep an old account to avoid changing their e-mail addresses, sending mail with their old ISP address from their new ISP.

Corporations and ESPs run a lot of Microsoft servers. Businesses use Microsoft’s Exchange to integrate e-mail and calendar facilities, ESPs run various integrated mail and database applications. Universities and ISPs are more likely to be running Unix or Linux servers. Universities do so since they’ve been running Unix since before Windows existed, ISPs because Unix and Linux mail software can support vastly more users per server than Windows mail software can.

So places that run a lot of Microsoft software tend to be set up so that Microsoft’s Sender-ID works, and places that don’t aren’t. Coincidence? You make the call.

By John Levine, Author, Consultant & Speaker

Filed Under


Alan Levin  –  Dec 20, 2004 4:20 PM

So MS has tried to convince the IETF to adopt its patented technology. I suggest that anyone who has an incling of the information society will realise what an absolute joke that is.

Surely the political view of this is more humourous than how this appears to be just another case of MS vs the rest? and surely this goes well beyond a technical argument?

There’s a decent related story by Declan McCullagh at http://news.com.com/2100-1032-5445504.html?tag=yt ... with a few more useful comments

Bill Cole  –  Jan 25, 2005 6:25 PM

Better a late comment than none, eh….

I think there’s a little problem with the MS vs. everyone analysis, and I am no fan of MS. The problem is that they are a latecomer to the MARID concept and their model for a MARID is almost universally rejected by everyone else including people who are big MARID fans.

I first argued publicly for a MARID almost 5 years ago, and I still believe in the basic concept having *some* utility, but recent experience trying to get a large corporate system to enforce a policy akin to SPF for their own domains has demonstrated a major problem. It turns out that a significant number of companies providing B2B services involving email use the cheap trick of generating mail that is technically both to and from their business users. For example, there is at least one company providing resume searching facilities for HR departments that allows users to enter their email address and search criteria and have email sent to them with the search results later, using the address they give as the sender and recipient at both the SMTP envelope level and the RFC822 header level. This makes a sort of sense formally, when view with just the right tilt of mind, and it makes a lot of sense technically for the service provider because it means that bounces as a result of SPF-like rules end up directed right back at the person who triggered the email but as a null-sender bounce instead (which presumably will get delivered…)  while truly bogus addresses double-bounce and can be piped right to /dev/null.

For the first dozen cases like this which I encountered in trying to tighten this corporate mail gateway, I thought little about them other than to grumble about sloppiness and laziness and how dumb dotcommers think that anything which does not fail must be right and other evil BOFHish things. Then I thought more carefully. It is actually hard to make a coherent case against this sort of behavior, as long as the technical mail generator (i.e. the service provider) reigns in any risk of abuse by making sure that they have their legitimate users’ addresses right. The only reason to NOT do this would be to fit such a service into a MARID world, and the cost would be the construction of a mail routing facility for the service vendor that handled bounces in a manner as reasonable as sending them back at the user who initiated the mail. A lot of work for what end?

I don’t like it, but after 5 years of consideration and wanting to be in favor of them,  I’m left with the conclusion that the MARID ideas which apply to SMTP envelope senders and RFC822 headers are essentially unworkable for anyone other than geeks like me who run their own little microdomains off their own little servers and have pretty simple business relationships.  My only solace is that MS seems to have put a lot of effort into SenderID…

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



Brand Protection

Sponsored byCSC


Sponsored byVerisign


Sponsored byDNIB.com

IPv4 Markets

Sponsored byIPv4.Global

Threat Intelligence

Sponsored byWhoisXML API

New TLDs

Sponsored byRadix

Domain Names

Sponsored byVerisign