X.400: What is It?, Part I
by Ruben Boiardi (RUBEN)

>*<

This month I had the opportunity to spend some time at Telenet
headquarters in Virginia with Ed Lane and others. Lane is one of
Telenet's education and training specialists and something of a "guru"
on the topic of X.400. We spent the better part of a week discussing
X.400 implementations and various strategies for handling mail messages
in the X.400 environment.

X.400 is the name of a series of recommendations ranging from X.400 to
X.430 set out by the Consultative Committee for International Telephone
and Telegraph (CCITT) governing the development of communications among
messaging systems on a global basis. In other words, the CCITT has
established methods by which different electronic mail systems can
exchange mail with each other.

X.400 didn't suddenly appear. It has a history--one that is closely
tied to the history of electronic mail.

Before electronic mail systems became as popular as they are today,
Telex was the method of choice for electronic business communications.
Telex has several drawbacks. It is slow, requires special equipment,
its character set is limited, and in some cases requires that both TTY's
(Telex terminals) be available. The year 1970 saw the introduction of
the first computer-based message system (CBMS) on a time-shared
computer, launching the revolution. In 1977, the International
Federation for Information Processing (IFIP) set up Working Group 6.5 to
deal with the proliferation of CBMS's. Their work led to the formation
of the CCITT X.400 Rapporteur Group in 1980. By 1984, the X.400 "Red
Book" series was ratified. This year will see the updated information
published in a "Blue Book."

So much for the historical perspective. Now, for the basics of how
X.400 works.

The basic components of an X.400 message handling system are the User
Agents (UAs) and Message Transfer Agents (MTAs). UAs and MTAs are
actually software; they're nothing you can "see."

The User Agent is the mechanism through which the end user sends and
receives messages. In essence, it is what the user sees as the mail
program. The User Agent could be on a PC or on a mainframe. Its job is
to package the message composed by the user and sent it along to the
Message Transfer Agent. The MTA and UA may, in fact, actually reside on
the same machine.

The Message Transfer Agent routes your message to its destination. Your
message may be sent through several other MTAs on the way to its final
destination (sort of like a baton in a relay race).

The typical X.400 message might take the following path:

------------- ============= ============= -------------
+ UA +-->--+ MTA +-->--+ MTA +-->--+ UA +
------------- ============= ============= -------------
A B C D

A user would enter his message at his User Agent (A), which then sends
the packaged information to its Message Transfer Agent (B). The Message
Transfer Agent (B) can't deliver the message immediately, so it passes
the message on to another Message Transfer Agent (C). This Message
Transfer Agent (C) can deliver the message and proceeds to do so into
the destination User Agent (D).

X.400 also defines a set of rules known as protocols by which UAs and
MTAs can communicate with each other. They are simply known as the P1,
P2, and P3 protocols.

Of course, there's far more to X.400 than I've discussed here. If
you're interested in learning more, get a copy of the CCITT "Red Book."
It is available through the United Nation's bookstall in New York City.
Ask for CCITT, Volume VIII - Fascicle VIII.7. The cost is approximately
thirty-five dollars.

Next month, we'll look at the question that is really more interesting
than "How does it work?" We'll take a look at "Why Isn't Everyone
Already Using X.400?"

author's note: This article was originally published in IN UNISON FEB88
and is reprinted with permission of the author. Ruben Boiardi is Unison's
Technical Director. Part 2 will discuss the political and technical
implications of establishing a world-wide X400 network.