Group 6: X.400 (Electronic Mail)

Table of Contents

Introduction to X.400 - Electronic Mail

What is X.400?

We will first define the scope and purpose of X.400. Here we will explain what X.400 is and what it aims to do. We will also explain where X.400 fits into the OSI model for data communications.


Electronic mail has now been established as an important service in many areas. This has been achieved through a number of different (and hence incompatible) message protocols, leading to a situation where there are islands of electronic mail connectivity.

With the introduction of the CCITT X.400 recommendations on message handling systems, the aim was to supply a single international standard for the electronic interchange of messages.

With the massive and continuing growth in the internet and its associated protocols (more on these later), one might think that, for better or worse, it is unlikely that another protocol will displace it (in the near future in any case) as the primary means for exchanging electronic mail messages. This may be the case - but the fact remains that there are several other substantial networks out there and the internet mail protocols were not designed with generality and connectivity with other systems in mind.

There is a clear need to have a common international standard which can be used as a mechanism to glue together the disjoint services in order to provide a single coherent global electronic mail service.

The Standards

There are two versions of the X.400 reccommendations - those published in 1984 and those published in 1988:

Reccommnedations X.400, October 1984. CCITT SG 5/VII, Message Handling Systems: System Model - Service Elements.

CCITT recommendations X.400/ISO10021, April 1988. CCITT SG 5/VII ISO/IEC JTC1, Message Handling: System and Service Overview.

The standards define how Message Transfer Agents can operate together to provide an end-to-end Message Transfer Service. Specifically, they describe how the message transfer service may be used to provide an InterPersonal Messaging (IPM) Service (ie. Electronic Mail).

The standards are designed to work over the OSI communications stack. It uses the application layer elements of service defined in (???). It uses the Association Control Service Entity (ACSE) to establish connections and either the Remote Operations Service Entity (ROSE) or the Reliable Transfer Service Entity (ROSE) to transfer the messages. (These are accessed through several new service entities for X.400 - eg. the Message Transfer Service Entity (MTSE) - see the protocols section for more information).

The standards use the OSI request/indication view of protocols, that is, one of the entities originates a request whihc is then received as an indication on the other side of the link; for example a P7 MS-Bind operation could be seen as follows:

Put some more stuff here - detail individual standards in documents etc.

The X.400 MHS/MOTIS model

In this section we detail the main components of the X.400 model for the interchange of electtronic mail messages - their purpose an and the services they provide, and the protocols used to communicate between the various compenents.

Comceptually, the model looks something like this (click on component or protocol in image to go directly to description):

X.400 Components

The main components of the model are:

From the users, point of view, immediate interaction with the system is carried out through a User Agent . The user agent allows the user to compose, submit, and receive mail messages. It is worth noting that the messages that a user can receive are not neccessarily IPM's - even if the user is only using P2/P22 , he can also receive receipt (and non-receipt) notifications, and delivery reports. In addition, other standards exist for the format of messages and more might well be invented in the future should the need arise. (For example, a standard has already been defined for the sending of EDI messages over X.400 (called Pedi or P35, defined in X.435) - a P35 user agent will typically be very different from a P2 user agent from the users point of view, but the mechanisms used to transmit these EDI messages are essentially the same as those used in the transport of P2 messages). (MGMT - add link to EDI page).

The actual transmission of messages is done via a Mesage Transfer Agent (MTA) . These perform all the routing and delivery functions needed.

One difficulty with the original X.400-84 standard was the the neccessity of having the user agent available from the MTA at all times to avoid spurious non-delivery problems. This problem was addressed in the 1988 standard by the introduction of the Message Store (MS) into the model. The message store is available to the MTA at all times (often co-located) and supplies a store and forward service to the User Agent. This is particularly useful in the more distributed modern environment where the User Agent may be running on a users personal machine and hence might not be available for long periods of time.

Thus, in the 1988 model, the MTA delivers the message to the Message store, which may well store the message for a considerable period of time, an option not available to the high-traffic MTA, and which is outside the scope of the service the MTA is supposed to provide.

The user may then connect to the message store at any time and fetch the messages stored for him/her by the Message Store. When this system is used, the user typically conducts all his business through the message store, including message submission. This has lead to the increasing use (and importance) of the P7 protocol (see below).

Click here for a more detailed overview of the model components.

X.400 Protocols

The Protocols defined by the standard are:

The P1 protocol is an end-to-end message transfer service. The P3 protocol is a protocol for communication between User Agents and MTA's. The P7 protocol is an increasingly widely used protocol for communication between the User Agent and the Message Store. Typical P7 operations are:

The P2/P22 protocol defines the format of a highly strucutured memo-like document. The two main components are the heading and the body part(s). The heading specicifies things like the originator and recipient of the message, copy and blind copy recipients of the message, whether the originator wishes to receive a notification for the message and in what circumstances etc.

The body part may be one of many forms of data - those specified by the standard include Ia5 text, G3Fax, Images, Audio data etc.

Messages may also be encapsulated within messages, providing a very clean and strucutured forwarding mechanism.

Click here for a more detailed overview of the protocols.

The Internet Mail Protocols

The main competitor at the moment to the OSI protocols are the equivalent Internet Protocols (Not to be confused with IP!).

The main strength of these standards in the past has been their simplicity, implementability and the accessability and readability of the standards documents themselves. They have also benefited from the ethos of free software, services and information that has been responsible for much of the success of the Internet.

However, one would have to say that the present time, the single greatest advantage of these protocols is their enormous user base - with an estimated 20 million people on the net (with more joining all the time), most of whom would consider electronic mail to be the most basic (and important) service provided by the internet, the chances of another protocol family displacing them in the near future are slim.

The main Internet standards in relation to electronic mail are:

Comparison of X.400 to the Internet Mail Protocols.

( Warning these are the authors personal opinions only and should be treated as such. As with Marshall.T. Rose, purists from either side would be advised to stay clear.)


This page created by:
Gavin Doherty,