Every time I have to do a mail server upgrade and have to tinker with my virtual mailbox configuration, I think about how it would be easier to just write my own mail daemon. These upgrades happen more than I would like. Consider the back to back vulnerabilities in exim over the past few months. In writing my mail daemon, I’d apply web technologies, such as URL routing, to email, but I always shelve the idea, because I’d still have to deal with SMTP, which offers no benefits, but considerably complicates both programming and configuration. I am not alone in experiencing these difficulties. Our collective trouble with email will lead to its eventual demise.
- Email’s usefulness is reduced by the volume of spam users deal with.
- Mail servers suffer from frequent exploits.
- Mail servers are difficult to administer.
- Mail servers haven’t kept up with mainstream technology, because they must support an archaic mail delivery protocol.
I don’t mean that people will no longer communicate on the Internet, of course. Rather, the classical technology we call “email”, which is the delivery of messages to “email@example.com” style addresses via SMTP, is going to go away. The Internet sees SMTP as “damaged” and is routing around it accordingly.
Technologies to replace email take a number of forms. Facebook wants to replace email with their own internal messaging system. Instant messaging services mimic email functionality, especially if they support offline messaging. Even the popular email services such as gmail, hotmail, and yahoo mail are proprietary services that provide SMTP gateways.
The problem is not the emails themselves. The problem is SMTP. It’s an archaic protocol from a more trusting age. Spammers take advantage of this trust. They break into insecure client systems to send spam through poorly configured mail servers. Failing that, they directly attack exploitable mail servers. Attempts have been made, such as Domain Keys, to add some security to SMTP, but it’s an ineffective hack to a protocol that has outlived its usefulness. So useless has it become, that some ISPs have blocked mail clients from using it.
This transition is already happening. The popular email services built ad hoc client side HTTP interfaces to support their web applications, but they still rely on SMTP as a gateway to other mail networks. The Internet needs a standard email gateway protocol to replace SMTP, so we can avoid the fracturing of email systems into technological fiefdoms which do not interoperate.
Some of the benefits of moving email to HTTP:
- Rich email applications. Compare joining a mailing list to a Facebook group.
- Program in your favorite language. Instead of learning the intricacies of a mail daemon, all you need are the correct HTTP urls to accept and deliver mail.
- Less exploitable surface area. Although Web servers suffer from exploits, too, removing a separate mail daemon reduces the code developers have to maintain, and there are many more web developers than email developers.
Email wasn’t always delivered via SMTP, although the protocol has been around for about 30 years. At one point, email piggybacked on FTP. HTTP has largely subsumed the functionality of protocols like FTP, gopher, and finger, except in legacy contexts. SMTP should be retired, too. The transport protocol for email should be HTTP.
Has email become more trouble than it’s worth for you? What do you use instead? Let me know in the comments.