Have you ever decided you needed to contact someone in another area of the world, only to discover you do not have their email address, nor any way to find their email address? You could go to your favorite social media site, of course, but if they are not on any form of social media? Or if they do not put their contact information there? Or—perhaps—this little situation happened before the rise of social media? GASP! From some of the younger readers.
If there were only some form of directory service you could use, things would be much simpler. My last post in this series described various attempts at building and deploying such a directory service. These directory services would not be included in this series if they were widely deployed today.
So what other option would you have? What if you could send an email to their name at a local or regional provider, and count on the provider to forward the email to the right person? This was, in fact, one of the many features of the X.400 mail system developed by the International Organization for Standards (the ISO) and some key vendors beginning in 1984. As an ISO standard, x.400 was designed to run on top of the OSI protocol suite, including the Connection Oriented Network Service (CONS), which is parallel to the more common CLNS. In 1987, x.400 was adapted to run on top of TCP/IP; the most recent revision of this specification was published in 1997 as RFC2126.
As x.400 was designed by telephone companies, it was designed to run at the national telephone service level. If you knew where someone lived, you could send an email to their name and the correct country code. In theory, the local provider would know the person you were trying to reach, replacing the ambiguous destination address in the email with the correct one, and ultimately delivering the email to the right person. This would be problematic, of course, in larger countries with many different providers, but the idea of sending an email to someone through a geographic location is rather neat.
Why didn’t x.400 become the all-encompassing email standard? First, it was difficult to implement. For instance, the geographical email service described above is interesting, but the directory services required to make such a system work had largely already failed by the time the x.400 standard was formalized and available for implementation. Second, while it attempted to solve many problems in a simple and clean way, it was actually very difficult to implement even the basic parts of the system.
The competing set of standards, built around RFC822 and the Simple Mail Transport Protocol (SMTP), was already widely established in networks that needed inter-system email by the time x.400 was standardized. Mail clients and servers using SMTP were, in fact, widely available in the form of open source software, making the implementation of SMTP based mail systems much less expensive than purchasing a commercial x.400 system.
In parallel with this, the primary means of access to any sort of computing platform was through private services, such as American Online and Prodigy, which had their own internally developed mail systems. Apple, Novell Netware, Banyan Vines, and many other email systems were used for mail within an organization, and email gateways were developed to allow emails to be exchanged between organizations.
When the addition of Multipurpose Internet Mail Extensions (MIME) to SMTP through RFC2045 in 1996, SMTP based email gained most of the capabilities available to x.400 systems. MIME, rather than being only available as a commercial product, was an open standard built by the collaboration of many providers and vendors, and an initial implementation was available as an open source package that could be added to most free or low-cost email packages.
The availability of open source implementations driving the widespread adoption of SMTP based email systems ultimately drove x.400 into obsolescence.
Lesson learned? While open source and open standards do not always produce the “pretty” and “clean” protocols many people prefer, they can often do “good enough,” and be distributed widely enough, to create a standard that overtakes even a well-funded effort on the part of international operators.
Russ White has more than twenty years' experience in designing, deploying, breaking, and troubleshooting large scale networks. Russ is currently a member of the Architecture Team at LinkedIn, where he works on next generation data center designs, complexity, and security. His most recent books are The Art of Network Architecture and Navigating Network Complexity.