eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Tuesdays E-Mail Authentication Summit in Times Square was a reminder that work continues in this important effort. The basic idea of it was to give those who run mail servers a kick and urge them to adopt one or more authentication standards. If you looked past the cheerleading, though, you see how far we have to go.
Im a cheerleader for authentication, too. SMTP e-mail is broken in more ways than are worth counting, and none of the real fixes can begin until spoofing is put to an end. This is what authentication does, to varying degrees in its various forms: It ensures that the sender is who it claims to be.
Much of yesterdays conference was dedicated to clarifying misconceptions and half-truths, such as the one in my last sentence: In fact, authentication, as it is commonly proposed for SMTP, does not ensure that senders are who they are, but that the message was sent from the domain purporting to send it. Drilling down to the user level adds complexity well beyond what is already a difficult task.
But the major caveat that speakers made a point to explain is that authentication is not a solution in and of itself; it is an enabler of solutions. People who dont get the point are forever noting that spammers were among the first to adopt Sender ID and other authentication solutions. But the point is that when they do this, they allow us to track them.
Authentication must be used in combination with reputation systems to be useful. An authenticated spammer will soon develop a bad reputation, and everyone will know to block their mail. In other words, we want the spammers to authenticate.
Reputation systems, alas, are not a developed industry, although they are developing.
We can see Trend Micro, which recently purchased Kelkea, sort of a proto-reputation business.
Kelkea and other organizations have been maintaining blacklists (whoops, the PC term is “blocklist”) to track spammers by the IP address of their server. Necessary as this is, and things would be a whole lot worse without them, it does cause collateral damage when other users of the server are inconvenienced. Moving to a domain-based system will help.
Authentication and reputation are a chicken-and-egg problem, of course. Theres a limit to what you can do with your authentication results in the absence of robust and mature reputation systems, but thats no excuse not to authenticate.
Some of the biggest hold-outs, and therefore problems, are major hosting services and registrars. I have my own domains registered at Register.com, and I use their DNS hosting.
Their management interface does not allow me to create the records necessary to provide for authentication of my own e-mail. Eventually I will move, but I still have some time left on my registrations.
Its not just laziness. Many of these companies are running old DNS software that doesnt support the TXT record type used by the Sender ID, SPF and DKIM authentication specifications. (In fact, a new SPF DNS record type was just approved by the IANA and will eventually be the better way to go.)
But hosting services and registrars have known, just as everyone has for some time, that these changes were coming, and they do their customers and the rest of the Internet a disservice when they fail to provide this feature for their customers.
I look at all this and I see progress, but not quickly enough. If youre an admin, push your organization to adopt authentication.
If youre a service client, push your provider to adopt authentication. Dare to imagine an Internet where people really are who they say they are.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983. He can be reached at larryseltzer@ziffdavis.com.