CircleID

I also wonder if any of these authentication schemes would be able to deal properly with the first@last.name addresses supported by the .name registry, where the user doesn't actually own last.name by itself.  In this case, the mail is always forwarded somewhere else.

DKIM provides multiple "selectors" per domain for multiple keys.  If the .name registry wanted to give each user his own selector for mail signing, they could do that, allowing them to cancel the selectors for people who misused them. If they're going to sell email addresses individually, that's not my problem and they'd best have a plan to police their misbehaving users if they want their mail to be deliverable.

The whole point of authentication schemes is to assign responsibility for mail, in DKIM's case at the domain level. There are a lot of people, notably ESPs who mail for other companies, who really wish they could disclaim responsibility for mail with their name on it. Tough noogies. If it's got your name and your signature, it's your problem.

I don't understand the resistance to SPF/S-ID because it doesn't have to be universally implemented to provide clear benefits to those who do implement it. 

In your example with Cornell e-mail addresses, Cornell would be free to publish an SPF record that put no restriction on who could send mail from the cornell.edu domain.  (Or, they could require that outgoing mail be routed through their mail server, but I'll even accept for the sake of argument that this would present an unbearable burden).  So SPF would provide no protection to Cornell against non-Cornell users spoofing mail from cornell.edu.  But likewise it would do no harm to Cornell.  At the same time, a company rightly concerned with protecting its image (like, for example, PayPal) would publish a very restrictive SPF record thus ensuring that any SPF-aware mail transport agent could immediately recognize a malicious email attempting to phish by spoofing a paypal.com return address. 

While I don't think that publishing SPF records is such an administrative burden, the whole thing would still work even if SPF adoption was low enough that MTAs needed to default to passing a message from a domain without any SPF information published.  So the system can only do good—why the resistance?

There's two somewhat separate reasons not to waste any effort on SPF.

One is that it's considerably harder to get SPF right, even for simple configurations, than it looks.  I was talking to someone at Godaddy a while ago that said he was fixing about two broken customer SPF records per day every day. And even if it's right, senders rarely have any idea which of their recipient addresses are in fact forwarders.  In the Cornell example, some addresses are really at Cornell, some are forwarded for alumni which will make the SPF on the next hop fail, and there is deliberately no way to tell the difference.  This is what I meant when I said that people who say they use SPF are just pretending.

The other reason is keeping our powder dry.  Getting people to do any sort of broad mail software upgrade is a huge amount of work, and I most definitely do not want to tell anyone to go to the effort of adding SPF support, knowing that it will never check more than a small fraction of their incoming mail and a fair amount of what it tells them will be wrong.

John: Great post. Yes, the reputation database piece is key.  I've been thinking about some ways to do reputation right, and in way that will make it feasible for large and small legitimate mail sources to maintain a good reputation.  I've been developing and hope to make and see announcements about 'competitive' services anon.  FWIW, Meng is working on one, IIRC.

Daniel Tobias: CSV, like DKIM, is an authentication scheme (http://en.wikipedia.org/wiki/Certified_Server_Validation) that would work fine with .name email addresses. 

Unlike SPF and DKIM, it is easy to set up.  (The guy at Godaddy would have no records to fix, instead of 2 a day.  All Godaddy customers would use Godaddy's mail server, which would already have a correct CSV record and reputation. Most domains won't need CSV records at all...) Also, it will cover all legit mail with a relatively small number of records.  It's also perhaps 1000% more efficient than DKIM or SPF.

But the adoption motivations are KEY.  A solution to the spam problem would be a problem for much of the ISP and ESP factions.  With the most egregious spammers going out of business, more focus will be on them, as sources of mixtures of wanted and unwanted mail.  The ISPs, and to a lesser degreee, institutions, are having to put more resources into keeping their networks free of zombie spam.  All ISPs benefit from there being less spam to store and ship around.  ESPs and ISPs that keep their noses clean have the largest net gain from adopting email authentication, which is probably why they are early adopters.  There's a lot of folks who would like to maintain the status quo. 

Clearly, important big businesses in the institional faction, despite the large costs instituions pay to receive spam, prefer the status quo.  Since the U.S. Congress does their bidding, the sick joke that is CAN-SPAM makes clear what their goals are.