Email Authentication Schemes - Friends or Foes?

jtprice writes "At a time when spam levels have exceeded 80%, there's growing momentum behind Microsoft's email CallerID, the SPF effort, Yahoo!'s DomainKeys, and the IETF's new MARID Working Group initiatives to address various email abuse problems including spam, joe-jobbing, phishing, and so on. Sendmail has already implemented DomainKeys and CallerID. 10,000+ domains have turned on SPF now. Where the heck are we going with this? Are these efforts at cross purposes, confusing at best or likely to be consolidated? Seems to be less about the end of spam and more about the end of open, uniform, standards-based email as we know it. Apparently the people behind these initiatives are getting together for the first time for something called the Open Email Accountability Symposium next month, at the Inbox Email Conference in San Jose, with the intent of outlining their proposals and answering questions. Any thoughts about all of this, or hard questions that should be asked of these people? Is the email dilemma creating just another monopoly opportunity to force email into proprietary territory?"

Comments

Re:no real solution on the orizon

[CatLord42]

IMO there main alternative is:
1) a solution compatible with original RFC (that is it does not rule out any sender that the original spec would permit)
2) a completely new and different system. Redesigned from scratch.

Even if we could completely revamp SMTP, it still sits on top of TCP/IP (etc.), and there will still be ways to get around any protections we could add to SMTP.

Unfortunately, I think it will take some major overhauling of the Internet and its core protocols to solve this problem. And that means lots of work, lots of new equipment and lots of new applications, all at enormous expense.

So, what's worse, loss of bandwidth, over-burdened mail servers and everyone spending time deleting junk out of their inboxes, or everyone spending a significant amount of money, users for new e-mail programs, companies for the same programs, new mail servers and routers, ISPs and backbone providers for expensive new infrastructure, and none of it possible until all the protocols are reworked, let's say, five years from now?

Re:It still won't work

[Nasarius]

Right. Just like they hacked Apache or PGP or SSL or...
Open standards and peer review are profoundly *good* things.

Re:no real solution on the orizon

[AnalogFile]

Even if we could completely revamp SMTP, it still sits on top of TCP/IP (etc.)

Not exact. If we are revamping there's no need to sit on TCP. It may be TCP or UDP or something completely new. Or it may be even just be a non problem.
- If the protocol assumes a connection and does not depend on it being anything in particular (technically: if it's an appllication level protocol), than it'll sit on any connection oriented protocol. That's exactly what the ISO layering is supposed to mean.
- It is possible to design a completelly new connection layer protocol. TCP is having it's own problems. True most of these have been addressed with a handfull of extensions. Reno is good and Vegas is even better. But big speed*RTT links are still problematic. And links are going to become much faster and with possibly bigger RTTs. We should not abandon TCP. But maybe we could start thinking alternatives.

and there will still be ways to get around any protections we could add to SMTP.

There'll always be ways to get around anything, probably. Down this line of thinking there's no solution at all. But we may come to a point where getting around is not worth doing.

I think it will take some major overhauling of the Internet and its core protocols to solve this problem.

Ageed. That is exactly the point in my post. But if we take that lane, we may get extra benefits. Mail-ng need not just be mail. We may think messaging here, instead of mail. Mailing lists can be designed in upfront. And news too. Maybe even chatting and instant messaging. And did you notice people is now using SMTP to do what FTP was designed for (remember FTP supports push and even sidewise transfers, even if today it's mostly used in pull mode)?

And that means lots of work, lots of new equipment and lots of new applications, all at enormous expense.

Maybe. Maybe not. We should keep those possible consequences in mind. Lots of work in SW development may be a non problem (not for the F/OSS community, at least. I do not care what that means for an individual company that's not going to share). Lots of equipment I doubt. If we can sit on IP and care not what version of it is below us, than the routing infrastructure need not change. The firewalling/natting/tunneling part may need some fixes. But these are mostly SW and generally very close to the endpoints, not really a big deal if we are doing a revamp. Expenses? Again: SW upgrade at the endpoints is not a big cost. Not if you are on the sharing side of the fences. It is not zero (not for large companies with thousands of servers and more clients, for example). But it needn't cost more than any other SW upgrade.

none of it possible until all the protocols are reworked, let's say, five years from now

This sentence is the one I agree upon. That's what I worried about in my post. This may take time. And the problem is now so much urgent that people may be unwilling to wait. The worse that can happen is a partial solution. It would slow down a revamp (NAT slowing IPv6 is an example. And we risk the mail 'solution' is much worse than NAT is).