SMTP is Killing Email

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 “” 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.

  • Leverage the web: HTTPS, load balancing, distributed urls, resource manipulation, rich clients and javascript programmability.

  • 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.

The following two tabs change content below.

Liam Irish

Liam Irish is a software architect for CA Technologies Advanced Technology Group within the Office of the Chief Technology Officer. Liam is responsible for prototyping and research of potential product directions and acquisitions. Liam joined CA Technologies in 2010, bringing with him 15 years of experience in the field. He has worked as a software developer, systems engineer, and system administrator, in diverse areas such as cloud-based telecommunications infrastructure, fault-tolerant monitoring of telecommunications provision systems, feature enhancement of legacy mainframe-based full motion flight simulators, distributed robotics, TCP/IP stack research and development, high performance computing, and web crawler development. Liam graduated from the University of South Florida with a Bachelor of Science degree in Computer Science, where he published papers on performative communication for cooperation amongst heterogeneous mobile robots, and modifying the Linux kernel to allow computers to enter standby mode without disrupting network connections.

Latest posts by Liam Irish (see all)

This article has 1 comment

  1. I agree, SMTP has survived entirely to long. I currently manage an email farm that has a rough output of thirty-million messages per day; the amount of disk I/O is insane. Most of my day consists of a delicate tug of war between Active queue and the Deferred queue. The ISP's have developed a Gotti type "protection" payment to guarantee delivery; even though the user has selected to receive the messages. So, either pay the hush money or send at your own risk. The queues become quicksand to the MTA–the harder it struggles the more it sinks. It becomes quite cumbersome to roll out new nodes in the farm to keep up with demand.
    I think your suggestion to switch protocols is very interesting. I think Apache can handle 1000 requests per second, so it would be interesting to see what the real time delivery rate would be. Writing email servers into your web application making it completely portable. I look forward to seeing the industry trend in this direction for it will open up creativity and robustness to an archaic format.
    I enjoyed the article; Take care.

Leave a Reply