Q&A: E-mail's Past, Present, and Future
The co-creator of the MIME e-mail standard takes a look at the past and future of e-mail communication, how it's tied to social networking, and e-mail in the cloud.
E-mail has come a long way since the MIME days. It's a vital part of business and personal communication. Who better to help us understand where e-mail has been, how standards have helped, and where it's headed in today's world of social networking and cloud computing than the co-creator of the MIME e-mail standard -- Nathaniel Borenstein, chief scientist at cloud-based e-mail management company Mimecast.
Enterprise Strategies: I understand that you’re the co-creator of the Multipurpose Internet Mail Extensions (or MIME) e-mail standard. How did MIME come to be recognized as the e-mail standard? What does a process like that entail -- and how long did it take?
Nathaniel Borenstein: There are really two ways to answer that question, reflecting the formal and informal aspects of the standards process. From a formal perspective, MIME was developed under the auspices of the Internet Engineering Task Force (IETF), which is responsible for all core Internet standards. Just about all of the technical aspects of a standard are developed in the IETF, which is a strict meritocracy of super-pedantic geeks. A successful participant has to be technically competent, verbally precise, and socially adept -- because, in the end, it is a largely political process as well as a demanding technical one. The IETF meetings that created MIME took place in a span of 2- 3 years, which is remarkably short for standards efforts, in large part because of the unusual sense of urgency on the informal side of the process.
That urgency reflected one of the two driving motivations for MIME. I and a few others were primarily motivated by the desire for universal multimedia mail; a larger faction was motivated by the need for interoperable mail in languages other than English.
Prior to MIME, it was a real mess. For example, if you composed mail in Hebrew but sent it to someone in Russia, your mail would show up in Cyrillic characters. Most Americans were blissfully unaware of the difficulties this caused and saw this as a low-priority issue, but that’s not how the non-English speakers saw it.
The achievement I’m proudest of, in MIME, is that I managed to hitch the twin horses of multimedia and multilingual e-mail to a single wagon. Because it solved both of these problems at once, it garnered widespread support from both sides of the pond -- and moved through the IETF at a rather fast pace for a standards effort. However, what really made MIME take off -- and this is something I can only describe as dumb luck or good timing on my part -- was when a group in Switzerland asked about using MIME to add media and languages to a new experimental system they were building that they called the World Wide Web. I was helpful on general principle, but I had no idea how big it was going to be. With the explosive growth of the Web, in parallel with a quick uptake in e-mail (facilitated in part by an open source package, metamail, which made it easy to add MIME support to existing mailers), MIME became a runaway success in short order.
How has e-mail changed in the thirty-plus years that you’ve been intimately involved with the technology? Has the technology itself evolved, or has it pretty much stayed the same through the years with different bells and whistles attached to it?
The technology has evolved quite a bit. Of course, MIME greatly expanded the kind of information people could send by e-mail, but there were other important changes as well. The definition of POP in 1984, later joined by IMAP, introduced the separation of a “message store,” which holds and manages your e-mail, from the mail user agent that you interact with. This simplified many things, making possible the kind of server-based administration we've taken for granted for many years now -- and the wireless clients that are so effectively ensuring that we never need to have any free time with our families.
Another important development was universal addressing. Through the 1980s, there were a large number of independent, incompatible e-mail systems. By user demand, gateways were created, so that CompuServe users could relay messages to Usenet or ARPAnet users, for example, with complex relay addressing schemes involving odd characters such as “thumper!nsb%compsci@udel” or even worse. Having the world gradually converge on Internet protocols, particularly Internet addressing format, was a huge step forward toward universal availability of e-mail.
In the 1990s, the introduction of webmail was a big step architecturally. Without webmail, it’s not clear that a new generation of transiently-connected users without computers of their own would have been able to embrace e-mail when they did. It continues to be the best way for a non-corporate user to get hassle-free, zero-administration e-mail service.
Around the same time, the growing tide of spam forced another change in the e-mail architecture, which was to now put some kind of security-oriented intermediary between incoming mail and the recipients. This has been done in a variety of ways, from server-based software to e-mail appliances to third-party services, but it’s a fundamental change when you have an entity in the architecture whose primary purpose is to prevent e-mail from getting through!
Most recently, the emergence of cloud-based e-mail services is a logical next step because it frees enterprises from the burden of administering the steadily increasing complexity of a modern e-mail system. Ubiquitous, reliable, high-speed networks have enabled this latest change in the architecture, in which on-site software is radically simplified and the tricky stuff is administered by experts in a very large-scale system. One could say it's the modern business equivalent of webmail. I don’t see any obvious next direction for e-mail evolution, but I am hesitant to predict that it has stopped. Most of the evolutionary steps have been non-obvious before they happened, so I suspect there are still more to come.
From your perspective, what has been the most important e-mail (or communications tool) related innovation in the past 30 years? What has most changed how people do business?
That’s a tough question, but I guess I’d choose universal Internet-style addressing.
The value of e-mail, or any other communication medium, tends to rise exponentially with the number of people you can communicate with. When you compare the e-mail or telephone systems, which have truly universal addressing, with, say, instant messaging, it’s easy to see how a lack of universality limits the medium.
I remember the day when the folks at NPR stopped saying, “Our Internet e-mail address is…” and just started saying “Our e-mail address is…” I felt like a milestone had been reached and people were taking universal e-mail addressing for granted. I know this is going to make me sound hopelessly geeky, but I actually did a little victory dance when I heard that -- and I e-mailed several of my geekier friends with the news.
A recent point of discussion promoted by Facebook and other social networking sites is that “e-mail is dead” or, at the very least, will soon be passé within the enterprise because of the younger generation’s use of texting and social media sites. Do you agree?
No, of course not. I’m sure they said it to be provocative, because the folks at Facebook are pretty smart. Just to take a trivial counter-example, what does Facebook do if you forget your password? They e-mail it to you, of course, so if e-mail dies, they have a problem right there!
More seriously, the Facebook claim is that messaging within a social networking site such as Facebook is displacing large amounts of e-mail and that young folks are the vanguard of this trend. There are a couple of problems with that claim. First, young folks tend to travel in packs. If your whole posse is on Facebook, then you can make Facebook your primary messaging tool, but once you need to communicate with a more distributed set of people, that breaks down. You can’t count on everyone in the world using the same social networking site, but you can count on just about everyone having an e-mail address. When those young people get jobs, it’s unlikely they'll be conducting their business correspondence on Facebook.
A deeper problem with this claim is definitional: Facebook messaging is e-mail, by any definition I’ve ever heard. It’s not Internet e-mail; it’s sort of a step back to the era before unified e-mail addressing, but it’s still an e-mail system -- a closed one, much like the old CompuServe or AOL e-mail before they embraced the Internet. If anything, I suspect that Facebook will eventually add Internet addressing to its internal messaging system, thus turning all of those Facebook messages into e-mail that fully interoperates with the Internet. Then some people will only send and receive messages on Facebook, but it will still be Internet mail.
Will social networking technologies ever translate fully to the business world?
The word “fully” is a bit tricky here. The business world is indeed a social world, but a very different one from our personal lives. To succeed in business, social networking is going to need quite a few features that haven’t been necessary in the interpersonal social networking world.
Foremost among these are privacy and security. Things like status updates could be hugely valuable within large, distributed teams. A simple “I'm working on X” could trigger notification of something relevant far sooner than would otherwise happen. However, you don’t want your competitors seeing that kind of update, so you need a system that is built around the information security needs of a business. It gets even more complicated when you realize that some of these things really should be visible to the world, such as status updates of someone whose job is a technology evangelist. I don’t expect to see this sort of thing retrofitted to the personal social networking sites, because they ought to be designed in from day one. It may take a while, but you can see an early example of such a system in LotusLive from IBM. They still have some work to do, but that’s a social networking system aimed squarely at the needs of business.
The other “catch phrase” these days is the cloud. Everything’s moving to the cloud sometime in the near future, experts say. How does cloud technology effect e-mail? Does cloud-based e-mail ever make more sense for a business than traditional on-site e-mail?
Absolutely. In the long run, it is possible that it will always make sense. For now, it makes the most sense for businesses up to a moderately large size, particularly where technology is a necessity but not a part of their core business. It makes less sense for businesses with offices that have lousy connectivity or those with technical aspects of their mail system that are somehow a critical business differentiator. Both of those are pretty rare nowadays.
People sometimes talk as if the key issue in moving to the cloud is saving money -- and while it’s true that most businesses can save money by moving their e-mail to the cloud -- what really matters is how well it works. How many businesses can really run their e-mail system better than a cloud e-mail provider who specializes in nothing else? Which is more likely to have reliable archives, effective spam control, on-demand continuity services, or full regulatory compliance? Those things are hard. E-mail has gotten ever more complex, to the point where it's simply not a business for amateurs. I don’t believe that most businesses have the necessary resources to run their e-mail system as well as a specialized cloud provider.
How can a business know which applications are suitable for deployment in the cloud -- and when is the right time to move forward?
I think they key word is “utility.” If your application can be viewed reasonably as an information utility, it is probably suited for deployment in the cloud.
For example, If you have a strange in-house need for 42-volt AC power, you’d probably need to support it in-house, but if your need is for standard 110- or 220- volts, you’re best off dealing with your local power company.
Business applications are, I think, the same way: If you have truly unusual requirements for your e-mail system, or your CRM system, or whatever, then you may well want to keep it in house -- particularly if you think those requirements give you a strategic advantage. For anything else, I’d seriously consider the cloud.
How can a business move its applications to one or more cloud vendors without becoming overdependent or a captive of its vendors? Are standards the solution, and if so, what type of standards are needed?
Some standards are undoubtedly part of the solution, but this is often exaggerated as a stalling technique by vendors who really don’t particularly want to solve this problem -- who rather like the idea of vendor lock-in. By saying that standards are the solution, without being specific, they are trying to ensure that there won’t be a solution for many years, as standards processes are notoriously slow. Moreover, if they don't say precisely what they want to standardize, they're just blowing smoke.
There are a couple of important issues in cloud standards, but if the real issue of concern to most customers is lock-in -- and I believe it is -- there are simpler, quicker ways to achieve a solution. Vendor lock-in happens when it is hard or impossible for a business to get their data out of the cloud provider’s clutches, and the cloud provider doesn’t want to help.
The simplest solution is to ensure that your cloud provider makes the commitment that if a customer ever decides to leave -- it will help -- and will work with the customer and/or the new provider to ensure that the data is handed off successfully in a form that the new vendor can utilize. This kind of commitment should be demanded of any cloud vendor, in any contract; if they’re not confident enough in their service to make this kind of promise, you probably want to steer clear.
Beyond that, there is undoubtedly room for a few new standards to allow disparate cloud services to interoperate, for example (and you want to be sure your vendor supports those efforts, too). The key to avoiding lock-in is simply making sure you can get out, which is something you can demand that your vendor guarantees before you even sign up.
A lot has recently been made of the cloud’s supposed ROI. Is cloud ROI solely relegated to cost-savings -- or are there performance-based metrics IT pros can use to justify their cloud investments?
ROI, as I implied earlier, is potentially a great thing about moving to cloud services, but I don’t think it’s the most important one. Quality of service is at the top of my list. You want your services operated by experts, specialists in those specific services. There aren’t enough such specialists for most businesses to have them in house, and they’re increasingly clustered at the cloud service companies.
There are indeed a few metrics of interest here. How much down time does a provider have? In the case of e-mail, what percentage of your spam is removed (though this can be a bit tricky to answer)? How fast does the provider respond to support calls and what’s the average time to resolve a major problem?
If a cloud provider doesn’t have better numbers than your company for metrics like these, you’re probably talking to the wrong provider -- and you certainly shouldn’t trust them with your critical applications!