Extending Email to the World: X.400 and SMTP

Curator's note:  This is the third in a series of commentaries by Ralph Ehlers, discussing the early days of email implementation. This commentary describes connecting his firm's internal email system to the external world: in the 1990s, this was a major technical challenge.


When my company ABB decided to push MEMO as the only supported email system in 1988, we already expected that eventually email between organizations would become a hot topic. While we were focused on internal email (see my previous blog, Early Days of Corporate Email: Selling the Idea), we occasionally did some trials of external connectivity. We were aware of a several options which, however, were just product specific and not really suited for the average user. Instead, we wanted a general purpose solution.



For a general approach to inter-organizational email a standard was needed, and X.400 seemed to hold the promise of the Holy Grail. We went on in-depth courses, learned the ASN1 descriptive language to be able to read the source  documents, and started to look for X.400 gateways on the market.

X.400 was a very impressive standard. It appeared that its creators had really thought things through, creating a comprehensive functional architecture for email systems. But the standard was very complex and difficult to understand. That had unfortunate consequences for implementations. The computing power which was available at the beginning of the 1990s was barely sufficient for X.400 implementations at acceptable cost. This caused many vendors to make simplifications in their implementations. Also, the complexity of the standard led to many different interpretations. Both effects meant that sadly, early X.400 devices frequently failed to interoperate.

During the early 1990s the EEMA (European Electronic Messaging Association)--along with other email user and promotional organizations--engaged in intense efforts to demonstrate interoperability of X.400 devices made by various vendors. This was closely watched by the trade press. While interoperability gradually improved, the risk  still inhibited rapid adoption of X.400 by most user organizations. Another significant inhibitor was the unclear business model of the providers and the associated operational cost*. On the other hand, for an organization like ABB the demand from the business for external email connectivity was rising only slowly, so that we had no compelling business reason for a determined, rapid adoption of the service.

In spite of all these issues I am convinced that X.400 services would eventually have made it in the business world, had it not been for the rise of the internet and SMTP.



X.400 and even more so the subsequently developed X.500 directory standard had one  flaw: they had been developed by the wrong set of people with a context in mind, which was outdated by 1990. I believe this eventually proved deadly. That context was the world of the national, monopolistic telecom companies of the 1980s, prior to the deregulation frenzy starting during the second half of the 1980s. Telecoms businesses were considered to be slow moving, centralized, frequently not very customer-oriented,  and expensive.

The internet and all organizations involved in developing it were almost always opposite: fast moving, innovative, bottom-up, more global than national focus. Well, perhaps the extra-national focus is not entirely true, since most of the earlier development was done in the US, and there was much of US cultural substance embedded in the internet, such as only standard ASCII character support.

And the best thing was that most of it came for free. During the first half of the 1990s, when the business world and its IT vendors and analysts became increasingly aware of the internet world, SMTP, the internet mail transport standard was one of the primary points of interest. Its context, its relative maturity, the perceived simplicity of implementation and the free service on the internet gave SMTP so much momentum.  As a result, from the mid-1990s it rapidly established itself in the business world as the only interorganizational email standard that really mattered. Thus, X.400 was history before it had really started to fly.

To be continued…


About the Author

Ralph Ehlers graduated with a PhD in Physics from RWTH Aachen, Germany, in 1981. Read full bio here.

* Curator David Ferris notes: X.400 carriers would usually charge a fee per message, typically as I recall of the order of $1 per message. Another factor affecting the limited success of X.400 was the complex email addresses, which were long and hard to remember.

One Comment

  1. Erik
    Posted June 18, 2012 at 9:01 PM | Permalink

    The first fully-functional X.400 product was developed by the University of British Columbia and commercialized by Sydney Development in Vancouver in 1984 and it was very successful. Still, the variety of platforms (IBM MVS, VM/CMS, VAX/VMS, PrimeOS, SunOS, Unix, etc..) made it hard for us to develop an actual end-user package, so we focused on the MTA software (although we did have a user agent for select platforms). At the time, the email world was also fragmented into a large number of proprietary email systems and we had to develop gateways in order to make inroads in the corporate world.

    I do not agree that X.400 is history. I believe there is still a large installation base in the defence area because of the excellent security features. It failed mainly because of the cumbersome address structure and the developers’ lack of creativity in making the address mode friendly to the consumer. In addition, the rigid hierarchical addressing scheme was a big mistake. It was imposed upon us by the PT&Ts of the world.

    In any case, X.400 gave us much more than a set of protocols. It gave us an architectural framework based on an Object-oriented paradigm such as it was in 1988. Actually, I may be wrong, but I believe that Microsoft’s mail server is based on at least some of the X.400 concepts.

    BTW, many of the architectural concepts were later used in X.500 and LDAP.

Post a comment

You must be logged in to post a comment. To comment, first join our community.