E-mail's swan song: How this affects programmers

Back in the day, e-mail was a killer app that was getting people onto the Internet in droves. Even people without computers ended up with Hotmail or Yahoo! Mail accounts and would check them whenever possible. People were thrilled that they could easily, conveniently, and cheaply get in touch with people over a long distance.

E-mail was going to revolutionize our world, but this is no longer the case. E-mail is hopelessly devalued to the point where I barely use it. The problem is the SMTP protocol. Most people seem to be fleeing standard SMTP/POP3 (or SMTP/IMAP, or SMTP/MAPI) e-mail when an alternative presents itself. SMTP e-mail is so bad that people will use any pile of garbage with zero features, as long as traditional e-mail’s problems are not there.

The death of e-mail (while not being a causing factor) removes a roadblock towards the decline of traditional desktop computing. This decline will affect a huge portion of programmers, as the need to shift to new platforms, display sizes, and so on becomes necessary.

How did we get to this point?

The SMTP protocol was shortsighted; it is good enough for delivering the mail, but it does a lousy job of protecting mail. (If you want the precise technical details of SMTP, read RFC 2821.) To enumerate SMTP’s shortcomings and the consequent results:

• SMTP does not enforce any assurances that the server sending e-mail is authorized to act on behalf of the domain that the sender is from. There are add-ons for this like SenderID and the use of SPF tags in DNS, but they are hardly universal. Result: Spam.
• There is no requirement that encryption of the SMTP connection must always be available. Result: E-mail is open to snooping, which increases the cost and hassle of using add-on e-mail encryption products.
• SMTP pushes the full message across to the destination — as opposed to a system like RSS (or most NNTP readers) where it only pushes a notice or message header across — to be picked up at a later time. Result: Wasted bandwidth. Disclaimer: This guarantees delivery even if the sender is unavailable at the time of reading whether by accident or by design.
• SMTP doesn’t have any way of controlling or even monitoring the progress of the mail sent. Result: E-mail is not nearly as useful for business purposes as it should be.
• SMTP does not offer any authentication, verification, or proof of identity. Result: E-mail is not trusted; spam.

We blame our e-mail clients, systems, and administrators, and we buy even more software to address many of these issues. The reality is, those e-mail clients, systems, and administrators have accurately and faithfully implemented the SMTP protocol. For them to add better, more efficient protections against the dangers of SMTP, it would render them out of spec.

SMTP has its roots in an era in which many servers placed long-distance phone calls to each other (sometimes waiting until the middle of the night when the call was cheaper) to establish connections to the next destination in the routing tables. E-mail delivery time was measured in hours and sometimes days. In other words, e-mail was fine for non-critical items. The SMTP standard, and many of the legacy systems for sending it (such as sendmail), are written to meet the demands of that environment. As a result, it is nearly worthless in today’s environment and, in fact, it makes matters much worse due to the security and spam issues involved.

How programmers benefit from e-mail’s death

“But wait… I use some sort of magic elixir algorithm/software/firewall that solves these problems!” you say. This proves my point. If SMTP, as a protocol, fit the modern world, you would not need it.

For programmers, this has led to some wonderful opportunities to make a buck without actually accomplishing much of anything; it is not hard to write rules-based filtering systems, and people will pay a lot of money for one that promises to solve the spam problems. The slow death of e-mail removes one of the major legs that the current computing environment stands upon. When the current paradigm falls, programmers will need to adapt to what takes its place.

The point is simple: Sending messages no longer requires the resources of a desktop PC (when I say desktop, I also mean laptop). So what happens when people no longer use PCs, or they only use PCs of necessity? Well, it depends on if they have found any other reason to stay on that platform. And for many users (particularly in the consumer space), the blossoming of Web applications means that they really do not need a PC per se — they just need a device that can access the Web and preferably has a way of attaching a large display and a full-size mouse and keyboard.

I will continue to explore this theme in a slew of upcoming blog posts. In the meantime, what do you think about how the death of e-mail is affecting programming work?

J.Ja