The document provides an overview of X.400 and its components for electronic messaging. It describes X.400's message structure and components including the User Agent, Message Transfer Agent, Message Transfer System, Message Store, and Access Unit. X.400 allows for transfer of different data types and provides features like delivery confirmation, encryption, and distribution lists. It also compares X.400 to the earlier RFC 822 standard for email.

1. ---------------------------------------------------------
A N O V E R V I E W O F X . 4 0 0
A N D R E L A T E D R E C O M M E N D A T I O N S
---------------------------------------------------------
Sualeh Fatehi Shoeb Bhinderwala Krishnan G S
TABLE OF CONTENTS
1 Introduction . . . . . . . . . . . . . . . . . . 2
2 RFC 822 . . . . . . . . . . . . . . . . . . . . . 2
3 X.400 . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Introduction . . . . . . . . . . . . . . . . 4
3.2 Message Structure . . . . . . . . . . . . . . 7
3.3 Components of MHS . . . . . . . . . . . . . . 9
3.3.1 The User Agent (UA) . . . . . . . . . . . 9
3.3.2 The Message Transfer Agent (MTA) . . . . 9
3.3.3 The Message Transfer System (MTS) . . . . 10
3.3.4 The Message Store (MS) . . . . . . . . . 11
3.3.5 The Access Unit (AU) . . . . . . . . . . 12
3.4 Naming, Addressing and Routing . . . . . . . 12
3.5 MHS Management Domains . . . . . . . . . . . 14
3.6 OSI Realisation of MHS . . . . . . . . . . . 15
3.7 Security Capabilities of MHS . . . . . . . . 20
3.8 Interpersonal Message (IPM) . . . . . . . . . 21
4 Gatewaying between X.400 and RFC 822 . . . . . . 22
5 Acknowledgements . . . . . . . . . . . . . . . . 23
6 Authors . . . . . . . . . . . . . . . . . . . . . 23
7 References . . . . . . . . . . . . . . . . . . . 23
7.1 Standards . . . . . . . . . . . . . . . . . . 23
7.2 Books . . . . . . . . . . . . . . . . . . . . 24
7.3 RFCs . . . . . . . . . . . . . . . . . . . . 24
8 Appendix A: Abbreviations . . . . . . . . . . . . 25
Fatehi, Bhinderwala, Krishnan [Page 1]
_
An Overview of X.400 June 1994

2. 1 INTRODUCTION
The earliest electronic mail (email) in networked environments (and
otherwise) was simple automated file transfer. There were several
email transfer methods, and it was felt that there should be some
standardisation. The first attempt at codification was "Standard for
the Format of ARPA Network Text Message" [Crocker, Vittal, Pogran and
Henderson, RFC0733] {RFC stands for Request for Comments; these
documents are the main methods for discussion of research concepts,
or status memos in the Internet community, and relate to Internet
standardisation, protocols and administration.} Later, with the
development of ARPANET and Internet, the standard for email was given
in "Standard for the Format of ARPA Internet Text Messages", [David
H. Crocker, RFC0822, 1982], later STD 11. The RFC 822 standard was
primarily for ASCII text.
In October 1984, the CCITT (Comite Consultatif International de
Telegraphique et Telephonique), (which has as its members
standardisation bodies of various countries, the ISO (International
Organisation for Standardisation) manufacturers and other interested
bodies) accepted the X.400 recommendation for email. At the same
time, the ISO was working on a compatible document - ISO IEC 10021,
and the ISO standard is now known as MOTIS (Message Oriented Text
Interchange Service). However, the ISO standards and CCITT
recommendations began to converge only in 1988. The X.400 Mail
Handling System works on the 7th or topmost layer of the Open Systems
Interconnection (OSI) reference model of the ISO, the Application
Layer. This was the first CCITT recommendation for a network
application for information exchange between computers which provide
store-and-forward message services, and hierarchical address space.
X.400 gives allows transfer of ASCII text, extended character set
documents, voice data, graphics and video. Additionally it provides
delivery confirmation, encryption, probing and other useful services.
2 RFC 822
RFC 822, "Standard for the Format of ARPA Internet Text Messages",
[David H. Crocker, 1982], has become a de facto standard for email
with the development of the ARPANET.
RFC 822 messages consist of lines of text. No special provisions are
made for encoding drawings, facsimile, speech, or structured text. No
significant consideration has been given to questions of data
compression or to transmission and storage efficiency, and the
standard tends to be free with the number of bits consumed. For
example, field names are specified as free text, rather than special
terse codes. The message consists of rigid formats, with several
headers, followed by the body of the message. Some of the headers
must be included in all messages, others are optional, and some are

3. Fatehi, Bhinderwala, Krishnan [Page 2]
_
An Overview of X.400 June 1994
ignored (for example, any header beginning with "X-"). The format for
the body is not specified.
Since RFC 822 was developed taking into account several existing
protocols, it is used in conjunction with several different message
transfer protocol environments (MTSs). Some of these are: SMTP
(Simple Mail Transfer Protocol) [RFC 821], UUCP (Unix to Unix CoPy
protocol) over telephone networks, BITNET (which sometimes uses
EBCDIC encoding) and JNT (Joint Network Team) Mail used mainly in the
UK universities.
RFC 822 needs and uses an underlying service, which would identify
the list of recipients, identify error return address, and also
transfer the message. The message itself consists of a header, and
the content which is uninterpreted ASCII text. The header is divided
into fields, which are protocol elements. Very often, SMTP is used to
transfer mail. SMTP [RFC 821, "Simple Mail Transfer Protocol",
Jonathan B. Postel] mail data may contain any of the first 128 ASCII
characters. If the transmission channel provides an 8-bit byte data
stream, the 7-bit ASCII codes are transmitted right justified in the
octets with the high order bits cleared to zero.
It can be seen from the above that there are many limitations to the
RFC 822 email system. There is a lack of structure in the message
body which makes it difficult to support multiple data types (ASCII
text with voice for example) within a single message. Also, if one
message is included within another, as in the case of a forwarded
message, the structure of the original message is lost, and the
message cannot be extracted without expensive processing. The headers
in Internet email are text strings, which can lead to misuse by
humans or badly written mailing software - binary encoding in the
envelope (as specified in X.400) is more strict. Expressive status
reports, giving detailed information regarding delivery or
non-delivery of messages in a specified format, are not possible.
There is no real distinction between envelope and contents of a
message: sometimes additional headers are added to the body of a
message, and the body of the message may be examined by intermediate
processing agents.
Some of the above difficulties are solved by "MIME (Multipurpose
Internet Mail Extensions): Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", [Borenstein & Freed, RFC
1341], which specifies a protocol for the transfer of multi-part
textual and non-textual message bodies. RFC 822 says very little
about message bodies; RFC 1341 is therefore orthogonal to RFC 822. It
specifies extra headers, among them "MIME-Version" which specifies
the extensions that the mailing software can recognise, and a

4. "Content-Type" header field which can take on values of "text",
"application", "multipart", "image", "audio", "video" etc. Also, a
"Content-Transfer-Encoding" header field can specify the encoding
that was applied to the data in order to allow it to pass through
mail transport mechanisms.
Fatehi, Bhinderwala, Krishnan [Page 3]
_
An Overview of X.400 June 1994
*--------------------------------------------------------------------*
| |
| Apart from the drawbacks mentioned above a good message |
| handling system should also overcome and provide solutions to |
| the following practical problems: |
| |
| - What should be done to a message which cannot be |
| delivered because of an addressing error in the |
| receiver's name? Should it be returned to the |
| originator? Well, there is an alternative. It could |
| be redirected to a responsible person who could then |
| consider re-routing it to the right person in the |
| organisation. |
| |
| - A user can configure his account in such a way that |
| all messages for him be forwarded to his colleague. |
| Can the originator prevent such auto-forwarding from |
| happening if his mail happens to be of a sensitive |
| nature? |
| |
| - A user may not be bothered about the successful |
| delivery of a message if it is sent to a long list of |
| people. Can he suppress non-delivery reports for such |
| messages? |
| |
| - The capabilities of user equipment may vary widely. A |
| message created at the originator's end could look |
| very much different when displayed on the recipient's |
| equipment. Can the originator specify only the |
| logical structure of his message which can be |
| interpreted and displayed with an appropriate layout |
| on the recipient's machine? |
| |
*--------------------------------------------------------------------*
3 X.400
3.1 INTRODUCTION
The CCITT X.400 recommendation describes a functional model for a

5. Message Handling system (MHS) and its associated services and
protocols. The purpose of MHS is to provide a medium for the
exchange of messages between communicating users. The figure below
(Figure 1) shows the overall structure of MHS.
The User Agent (UA) is responsible for interfacing directly with the
end user. Since it is an application process, MHS does not define how
it interacts with the end user. Users of the MHS may be humans or
Fatehi, Bhinderwala, Krishnan [Page 4]
_
An Overview of X.400 June 1994
application processes. Thus, a UA may be implemented as a computer
program or programs that can create, send, receive, save and
retrieve (saved) messages. Each user has his own UA, and each UA is
identified by a unique name.
The Message Transfer Agent (MTA) provides the routing and relaying of
electronic mail. Information sent from UA to UA may be stored
temporarily in many intervening Message Transfer Agents (MTAs): thus
X.400 specifies a store-and-forward mechanism. When an MTA receives a
message from the UA, it checks it for syntax problems and then
delivers it to another UA or forwards it to the next MTA. A message
is stored in only one interveing MTA at a time. When the message is
successfully delivered to the next MTA en route, it is deleted from
the last MTA, and is the responsibility of the next MTA which accepts
it. A collection of MTAs is called the Message Transfer System (MTS).
The MTS sends messages across from an originating UA to a recipient
UA. In addition, the X.400 1988 document defines a Message Store
(MS) which is located with the MTA and provides for the storage and
retrieval of messages. Its job is to provide storage which is
continuously available. Thus, if a UA is not available (for example,
a program running on a personal computer), the MTA can deliver
incoming messages to the MS instead of the UA. An MTA may also be
able to file incoming messages.
Fatehi, Bhinderwala, Krishnan [Page 5]
_
An Overview of X.400 June 1994
*---------------------------------------------------------------*
| user user Message Handling Environment|
| | | |

6. | *--------------------------------------------------------*|
| | | | Message Handling System ||
| | ---- ---- ||
| | |UA| |UA| ||
| | ---- ---- ||
| | | | ||
| | | ---- ||
| | | |MS| ||
| | | ---- ||
| | | | ||
| | *-----------------------------------------------*||
| | | | | Message Transfer System |||
| | ---- | ----- ----- |||
|user-|-|UA|--|--|MTA|--------|MTA| |||
| | ---- | ----- ----- |||
| | | / |||
| | | / |||
| | | / |||
| | | / |||
| | | / |||
| | ---- | ----- ----- |||
|user-|-|UA|--|---------|MTA|-----------|MTA| |||
| | ---- | ----- ----- |||
| | | | | |||
| | *-----------------------------------------------*||
| | | | ||
| | ------ ---- ||
| | |PDAU| |AU| ||
| | ------ ---- ||
| | | | ||
| *--------------------------------------------------------*|
| letter post other CCITT services |
*---------------------------------------------------------------*
Key: MTA = Message Transfer Agent; UA = User Agent; MS = Message Store
PDAU = Physical Delivery Access Unit; AU = Access Unit
Figure 1. X.400 functional model
MHS also supports the use of distribution lists (DLs). If a message
originator provides MHS the name of the DL, then MHS expands the list
and distributes a copy to each recipient.
X.400 works in the Application Layer (Layer 7) of the OSI reference
model. The 1984 CCITT document had the Application Layer divided into
2 sublayers, the User Agent Layer (UAL), and the Message Transfer
Layer (MTL). This was because the properties of the Presentation
Layer and Application Layer elements were not then properly defined.
Fatehi, Bhinderwala, Krishnan [Page 6]
_
An Overview of X.400 June 1994
However, the subdivision of the Application Layer contradicts the

7. current standardisation. To overcome this, in the 1988 document,
CCITT defined five Application Layer service elements specific to
MHS: the Message Administration Service Element (MASE), the Message
Delivery Service Element (MDSE), the Message Retrieval Service
Element (MRSE), the Message Submission Service Element (MSSE) and the
Message Transfer Service Element (MTSE), in addition to using the
common elements, the Reliable Transfer Service Element (RTSE), Remote
Operations Service Element (ROSE) and the Applications Control
Service Element (ACSE).
The protocols which realise the services offered by the entities must
be defined. The following protocols are defined in X.419:
The MTS Transfer Protocol, P1, provides for relaying of messages and
other interactions between MTAs. It thus serves as the backbone
switching protocol.
The MTS Access Protocol P3, and enables a UA or MS to obtain access
to the MTS services. P3 is an access protocol, and may be initiated
by either the MTS or the UA or MS.
The MS Access Protocol P7, is for the access of a UA to the MS. The
UA in all cases is the initiator.
3.2 MESSAGE STRUCTURE
The primary goal of the MHS is to convey `information objects' called
messages from one user to another. A message consists of an envelope
and a content. They are formally defined by X.400 recommendations as
follows:
- Envelope: An information object whose composition varies from
one transmittal step to another and that variously
identifies the message's originator and potential
recipients, documents its previous conveyance and
directs its subsequent conveyance by the MTS, and
characterises its content.
- Content: An information object that the MTS neither examines
nor modifies, except for conversion, during its
conveyance of the message.
Fatehi, Bhinderwala, Krishnan [Page 7]
_
An Overview of X.400 June 1994
+---------------------------+
|______ ______ /|
| ----/----/ |
| +---------------+
| ENVELOPE | |
| | |

8. +---------------------| |
| CONTENT |
| |
| |
| |
+---------------+
Figure 2. Message Structure
The UA creates the message content comprising the header and one or
more body parts, this is the IP-message (one of the message content
types defined in the X.400 series). From the IP-header, the MTS
creates a (P1) envelope with sufficient information in it to transfer
the message across to its recipient(s). The MTA uses the envelope
information to transfer the message through the MTS. The envelope
also identifies the type of the content. The content-type is an
identifier that denotes the syntax and semantics of the content. This
identifier enables the MTS to determine the message's deliverability
to particular users, and enables UAs and MSs to interpret and process
the content correctly. Also contained in the envelope is the type of
encoded information represented in the content. An encoded
information type (EIT) specifies the format (eg. IA5 text or Group 3
facsimile) of individual portions of the content. It further enables
the MTS to determine the message's deliverability by providing
opportunities for it to make the message deliverable by converting a
portion of the content from one EIT to another. Although, the
conversion of EITs is a function which appears to belong to the
presentation layer, in MHS these conversions are performed within the
application.
MHS also defines two other message types: probe messages and report
messages. A Probe is a message that contains only an envelope. It
specifies the description of a message whose deliverability needs to
be tested and is used to determine if the message can be delivered,
because it provokes the same behaviour from the target MTA as would a
submitted message. This is useful when a user is not sure about the
characteristics of the destination UA and wants to find out whether
it will be able to handle his message. In this way, long
undeliverable messages can be saved from substantial processing. The
MTS does not deliver the probe message nor does it redirect it.
Rather, The MTS generates a delivery report, which is returned to the
originator of the probe message.
The Report message is a status indicator. It is used to notify an
originator about the outcome of the delivery of a User or Probe
Fatehi, Bhinderwala, Krishnan [Page 8]
_
An Overview of X.400 June 1994
message. By default the MTS generates report only if it could not
deliver the message, but a user can instruct it to generate a report

9. message for successful delivery or suppress it for unsuccessful ones.
3.3 COMPONENTS OF MHS
3.3.1 The User Agent (UA)
The interaction between the UA and the MTA depends on their physical
connection. If both are implemented as processes on the same computer
system, then submission and delivery is performed by direct local
interaction between the two, and is not subject to OSI
standardisation.
UAs are grouped into classes, according to the content-type of the
messages which each is capable of processing. The class of a UA is
known by the content-type of the message originating from it. Only a
recipient UA of a similar class is capable of interpreting the
message content correctly. An IPM (interpersonal message) is one
content-type that has been so far defined and standardised, and it is
likely that in the future other standard content-types may emerge (in
particular a business oriented message type). IPM UAs use the P2
content-type protocol which is designed to serve the needs of
person-to-person communication.
3.3.2 The Message Transfer Agent (MTA)
The MTA in co-operation with other MTAs transports messages through
the MTS. It handles service requests from two sources: submission
request by a client UA, and message received from remote MTA.
When an MTA receives a message from either source, it is responsible
for handling it correctly depending on whether it is a user message,
a probe or delivery report. Upon receipt of a message, its envelope
is validated and other functions are performed like recording the
submission time, generating a message identifier, etc.
If the recipient is a direct client of this MTA, the action taken in
such a case will vary according to the message type. If the message
is a user message, then it is delivered if possible. If the
originator requested a confirmation for the delivery, then a delivery
report is generated and transferred back to him. If delivery is not
possible, then a report containing the reason for non-delivery is
prepared and transferred back. If the incoming message is a delivery
report, and if the MTA needs to do accounting for charging purposes,
the charge or statistic is recorded. In case of a probe message, the
MTA determines whether a message of the described content-type can be
delivered, and an appropriate report is generated and transferred
Fatehi, Bhinderwala, Krishnan [Page 9]
_
An Overview of X.400 June 1994

10. back. The MTA also takes care of redirection and conversion if
required.
If the recipient is associated with a remote MTA, then the message if
first checked for looping. If it is found to loop, it is deleted. If
it is a probe, or a user message, it is sent to a recipient MTA.
Several copies may be made, and sent along different paths, to
different MTAs if there are many recipients. The recipient MTA is
made aware of the message recipients it is responsible for.
3.3.3 The Message Transfer System (MTS)
The Message Transfer System (MTS) is the backbone of the
communication systems of the MHS. It is a distributed system for
international message transfer.
The MTS is modelled after objects. An MTS object contains ports,
where services are requested, and provided. The type of port
represents the view of services provided by the MTS. A port may be
symmetrical, where services can be both provided and consumed, or
asymmetrical, where services may either be supplied (supplier), or
consumed (consumer) but not both.
The MTS object supports three different kinds of ports: a submission
port, delivery port and an administration port. A submission port is
where messages or probes are submitted for transfer and delivery to
one or more recipient MTS-users. A delivery port is where the
MTS-user accepts delivery of messages or reports of delivery or
non-delivery. A An administration port enables a MTS-user to change
long-term parameters held by the MTS.
The MTS object consist of a large number of MTA objects. Each MTA
objects has an additional port which is not visible at the boundary
of the MTS: the transfer port. This port is used transfer messages,
probes and reports to another MTA. In general, this may have to be
done a number of times between different MTAs to reach its final
destination.
Fatehi, Bhinderwala, Krishnan [Page 10]
_
An Overview of X.400 June 1994
+-----------+
| MTS-user |
+------------+ | (intended |
| MTS-user O--->>- message | recipient |
|(originator)O-<<- submission +-----O-----+
+------------+ /
/
report | | /---->>----/

11. delivery| | | message delivery
+---------+-O--O+--------------+--O---+--+
| | MTA | | MTA | |
| +--O--+ +----O-+ |
| | | |
| +------+ / |
| --->>-O O->>-/ |
| message | MTA | |
| transfer| O->>- |
| +------+ |
| M / | |
| - M T S - +-O----+
| / S | MTA O-- non-delivery
| +------+
+----------------------------------------+
+------O-----+
| MTS-user |
| (intended |
| recipient) |
+------------+
Key: MTA = Message Transfer Agent; MTS = Message Transfer System;
O = A MTS or MTA Port.
Figure 3. Message Transfer System Model
3.3.4 The Message Store (MS)
The 1988 the X.400 document introduced the concept of a Message Store
(MS), between the User Agent and MTS. The MS has the primary function
of accepting delivery of messages on behalf of a single MHS end-user,
to retain them until retrieval by the user's UA. This was found
necessary because some UAs could be run on personal computers not
permanently connected to their main systems. In such cases, the MTA
would hold the message for a period of time, after which it would
declare the queued messages as undeliverable, and discard them.
In effect, the MS provides indirect message submission and message
administration facilities to the UA. Like the UA, the MS acts on
behalf of a single MHS end-user: multiple users do not share an MS.
Also, the interaction between the MS and the UA has been standardised
as the P7 protocol.
Fatehi, Bhinderwala, Krishnan [Page 11]
_
An Overview of X.400 June 1994
----------+ +----------+ +---------
| | | |
UA | | MS | | MTS
| | | |

12. MTS X---retrieval---X MS X---delivery----X MTS
abstract | | abstract | | abstract
service X---indirect | service |---submission--X service
user | submission----X provider | | provider
| | | |
X-----admin-----X X-----admin-----X
| | | |
| | | |
----------+ +----------+ +---------
Key: UA = User Agent; MS = Message Store; MTS = Message Transfer
Service; admin = administration.
Figure 4. Message Store Abstract Service
3.3.5 The Access Unit (AU)
The Access Unit (AU) as defined in X.400, 1988 provides a gateway
between the MHS and an external communications service like physical
postal services (snailmail), teletex, or telex.
3.4 NAMING, ADDRESSING AND ROUTING
For a message to reach its correct destination, there should be an
effective way of naming (identifying) each user uniquely, giving his
or her location. This name can be used for sending and receiving
messages. The X.400 names and addresses are rather more complicated
than RFC 822 names. RFC 822 names are text strings
("root@shakti.ncst.ernet.in") while in X.400 they are binary encoded.
Such binary encoded addresses can be made human readable by many
notations. Every MHS user thus has an O/R (originator/ recipient)
name. It consists of two parts: the directory name, and the O/R
address. The O/R address contains information that the MTA can use to
convert into routing instructions.
The directory name is a user-friendly and stable form of name, and is
defined in the context of the directory services provided under
X.500. When directory services become widespread, the O/R address may
be just looked up from the O/R name. The directory service may also
be consulted by a user to check that an address is valid.
The O/R address is modelled after an ordered list of attributes, each
with a type and value, and binary encoded. Some attribute types are:
Fatehi, Bhinderwala, Krishnan [Page 12]
_
An Overview of X.400 June 1994
====================================================================
Attribute | Abbrev. | Remarks
====================================================================
MTS.CountryName | C | Identifies country
---------------------------------|-------------|--------------------

13. MTS.AdministrationDomainName | ADMD | Identifies ADMD
| | within country
---------------------------------|-------------|--------------------
MTS.PrivateDomainName | PRMD | Identifies PRMD
| | within country
---------------------------------|-------------|--------------------
MTS.TerminalIdentifier | T-ID |
---------------------------------|-------------|--------------------
MTS.OrganizationName | O | Identifies
| | organisation
| | within country
---------------------------------|-------------|--------------------
MTS.OrganizationalUnitNames | OU OU1 OU2 |
.value | OU3 OU4 | Identifies
| | sub-unit in the
| | organisation
---------------------------------|-------------|--------------------
MTS.PersonalName | PN | Identifies the
| | individual, and
| | can consist of:
---------------------------------|-------------|--------------------
MTS.PersonalName.surname | S |
---------------------------------|-------------|--------------------
MTS.PersonalName.given-name | G |
---------------------------------|-------------|--------------------
MTS.PersonalName.initials | I | (zero or more)
---------------------------------|-------------|--------------------
MTS.PersonalName | |
.generation-qualifier | GQ |
---------------------------------|-------------|--------------------
MTS.CommonName | CN | Defined in X.400
| | 1988, and can be
| | used instead of,
| | or with the PN
=====================================================================
Table 1. O/R Name Attributes.
Other attributes are for specialised access to the MHS, like numeric-
user-indentifier, network-address and terminal-identifier.
The recommendations define a series of O/R address forms. For each
form, a different set of attributes may be used. A mnemonic O/R
address user-friendly naming of users, while a numeric O/R address
consists of completely numeric user indentification. A telex O/R
address identifies a user by a telex number and a terminal O/R
Fatehi, Bhinderwala, Krishnan [Page 13]
_
An Overview of X.400 June 1994

14. address allows identifying users on terminals belonging to other
networks. A postal O/R address is used to identify users who can
receive physical messages.
The method of routing using O/R addresses is basically incremental.
The MTS first attempts external routing, that is, the transfer of the
message to its destination MD. The originating MTA can either can do
this itself, or knows another MTA in its MD more likely to have this
capability. Within the destination MD, the process of internal
routing relies on the ability to map a private domain name or
organisation name to an MTA name. The evaluation of personal name
will be performed at the destination MTA.
X.400, 1988 has a suggestion to maintain a "neighbours" set, that
is, a set of directly reachable MTAs, and to remove from the set any
MTAs which the trace information suggests would cause a loop if
routed through. It is essentially left to each implementation of MHS
to devise a routing scheme of its own: to map a given O/R address to
the name of a relay MTA and to maintain essential information to
perform this routing operation.
3.5 MHS MANAGEMENT DOMAINS
Management domains are the primary building blocks used in the
organisation of the MHS. A collection of at least one MTA and zero or
more UAs that is administered by an organisation is called a
management domain (MD). An MD controlled by a CCITT administration
(for eg. a Postal, Telephone and Telegraph Agency), is called an
administration MD (ADMD), and one managed by any other organisation
is called a private MD (PRMD). A requirement for an ADMD is that it
should provide services to the public. A Recognised Private Operating
Agency (RPOA), which has received permission from the CCITT
administration to operate a network can also be an ADMD. Also a CCITT
administration can operate a PRMD for users internal to the
organisation. X.400 recommendations enable the construction of a
Global MHS i.e. an MHS providing international inter-organisational
message handling.
Fatehi, Bhinderwala, Krishnan [Page 14]
_
An Overview of X.400 June 1994
------
|PRMD|
------ ------ +--------+
|PRMD| ~~ | /----------------| ADMD |
------ _+--------+ / +--------+
------ / | ADMD |------- |/ |
|PRMD|_/ +--------+ +--------+
------ | _| ADMD |
| +--------+ ------

15. _| |PRMD|
/ _ ------
| ------
+--------+ |PRMD| __
| ADMD | ------ |
+--------+ ------
|PRMD|
------
Country 1 Country 2 Country 3
Key: ADMD = Adminstration Management Domain;
PRMD = Private Management Domain.
Figure 5. The Global MHS
ADMDs play a central role in the Global MHS. By interconnecting to
one another internationally, they provide an international message
transfer backbone. By interconnecting domestically, (depending upon
national regulations), they can also provide domestic backbones
joined to the international backbone. ADMDs also serve as primary
naming authorities in the assignment of O/R addresses to users and
DLs.
3.6 OSI REALISATION OF MHS
Before proceeding it will be helpful to review a few definitions and
concepts that pertain to the Application Layer in the OSI model.
- Real Open System: A system that complies with OSI in its
communication.
- Application Process (AP): A component within a real open system.
It is an abstract representation of the elements of the open
system which performs processing for a particular application.
- Application Entity (AE): Represents the AP within OSI. Provides
a set of communication capabilities to the AP.
- Application Service Element (ASE): Part of an application entity
Fatehi, Bhinderwala, Krishnan [Page 15]
_
An Overview of X.400 June 1994
that provides a defined OSI capability for a specific purpose.
Permits the interworking of AEs of the same kind with the use of
application protocol data units (APDUs).

16. - User Element (UE): Part of an Application Entity. It is specific
to the application, and concerned with the actual OSI services
The ASE provides a defined set of services that are needed by a
number of applications. It is analogous to a common software routine
that has been written to satisfy a community of users. An AE consists
of one UE and one or more ASEs, and operates through a single Service
Access Point (SAP) address with the presentation layer.
An Association Control Service Element (ACSE) is invoked by the ASEs,
and it provides for the establishment, maintenance, and termination
of all `application associations'. An application association is a
detailed description of a co-operative relationship between two
application entities through the use of presentation services within
a defined application context. An application context is the set of
service elements and supporting information used on the application
association.
The ACSE provides services needed between application processes that
are independent of any application-specific needs. In other words, it
supports the use of common services.
Reliable Transfer Service Element (RTSE):
RTSE is a common service element that supports a reliable transfer of
APDUs between applications, and ensures that the sender is notified
about a successful or unsuccessful delivery. RTSE also supports other
important functions. It recovers from communication and end-system
failures. It supports the negotiation and use of size parameters for
PDUs, segmentation into smaller units, and to put checkpoints to
verify the delivery of the units to the receiving RTSE.
Remote Operations Service Element (ROSE):
ROSE defines the procedures for supporting interactive communications
between two distributed entities. The originator can invoke
operations in another system (the performer). Since the performer
system may be different from the one in which the invoker resides,
the interactive transaction may involve remote operations; hence the
name remote operations service element (ROSE). ROSE does not have any
transfer capabilities. It uses other ASEs for this operation. Some
applications need confirmation of a transaction submittal and some do
not. In any event, ROSE can achieve almost the same result by
requiring the performer to report the outcome of the operation. If
this capability is not sufficient, ROSE can invoke the services of
RTSE to obtain reliable transfer of its data units.
In OSI the communication capabilities of open systems are organised
into groups of ASEs. The figure below shows two communicating open
systems. Each Application Entity (AE) comprises a User Element (UE)
Fatehi, Bhinderwala, Krishnan [Page 16]
_
An Overview of X.400 June 1994

17. and one or more Application Service Elements (ASEs). A UE represents
the controlling or organising portion of an AE which defines the open
system's role (eg. that of an MTA). The ASE represents one of the
communication capability sets, or services (eg. for message
submission or transfer), that the UE requires to play its role.
Application Entity Application Entity
+--------------------+ +--------------------+
| +---------+ | | +---------+ |
| | User | | | | User | |
| | Element | | | | Element | |
| +---------+ | | +---------+ |
| | Application | |
| +--------+ | / association | +--------+ |
| | ASE 1 | |/-----------------| | ASE 1 | |
| | |--+ |-----------------/| | |--+ |
| +--------+ | | / | +--------+ | |
| | ASE 2 |--+ | | | ASE 2 |--+ |
| +--------+ | | | +--------+ | |
| | | | | | | |
| +--------+ | | +--------+ |
| . . . . | | . . . . |
+--------------------+ +--------------------+
^ ^
Application Layer | |
------------------------------------------------------------------------
Presentation Layer | Presentation Connection |
|___________________________________|
Key: ASE = Application Service Element
Figure 6. The ASE Concept
The ASEs in each open system communicate with their peer ASEs in the
other open system via a presentation connection between them. That
communication is what creates and sustains the relationship embodied
in the application association. For several ASEs to be successfully
combined in a single AE, they must be designed to coordinate their
use of the application association.
An ASE plays the largely mechanical role of translating request and
responses made by its UE to and from the form dictated by the
application protocol that governs the ASE's interaction with its peer
ASE in the open system to which the association connects it. The ASE
realises an abstract service, or a part thereof, for purposes of OSI
communication.
In MHS, the message handling ASEs can perform two type of services:
symmetric and asymmetric. The symmetric service means a UE both
supplies and consumes a service; the asymmetric service means a UE
either consumes or supplies a service, but does not do both.
Fatehi, Bhinderwala, Krishnan [Page 17]
_
An Overview of X.400 June 1994

18. Access to MTS or MS is provided by a number of application service
elements (ASEs):
- Message Submission Service Element (MSSE): Supports the services
of the submission functions.
- Message Delivery Service Element (MDSE): Supports the services
of the delivery functions.
- Message Retrieval Service Element (MRSE): Supports the services
of the retrieval functions for MS.
- Message Administration Service Element (MASE): Supports the
services of administrative functions among UAs, MSs and MTAs,
and controls subsequent interactions by the means of the ASEs
listed above.
These ASEs are supported by the three ASEs ROSE, RTSE, and ACSE. From
the context of the OSI model, MHS and its related ASEs (MSSE, MDSE,
MRSE, & MASE) appears as depicted in Figure 7.
Fatehi, Bhinderwala, Krishnan [Page 18]
_
An Overview of X.400 June 1994
+-----------------+
|Application Layer|
| User |
+-------+---------+
|
| -----------
+----------------+----------------+ ^
| | |
| X.400 MHS (1988) | |
| (MSSE, MDSE, MRSE, MASE) | |
| | |

19. +----+----------+---------+-------+ |
| | | |
| | | |
| +------+------+ | |
| | ROSE | | |
| | | | Application
| +-+-----------+ | Layer
| | | | |
| | |______|_____ |
+--+-----+----+ | | |
____| RTSE | | | |
| | | | | |
| +------------++ | | |
| | | | |
| | | | |
| ++----------+-+ | |
| | ACSE | | |
| | | | |
| +------+------+ | |
| | | |
| | | V
+--+-----------------------+----------+-------+ ----------
| |
| PRESENTATION LAYER |
| |
+---------------------------------------------+
Key: ROSE = Remote Operations Service Element; RTSE = Reliable
Transfer Service Element; ACSE = Association Control Service
Element; MSSE = Message Submission Service Element; MDSE = Message
Delivery Service Element; MRSE = Message Retrieval Service Element;
MASE = Message Administration Service Element
Figure 7. MHS Access Protocol Model
3.7 SECURITY CAPABILITIES OF MHS
Since MHS is a distributed system, protection against various
security threats is required. Some of the varieties of threats
Fatehi, Bhinderwala, Krishnan [Page 19]
_
An Overview of X.400 June 1994
identified by CCITT are access threats, intermessage threats, and
intramessage threats. Access threats are from invalid users using the
MHS, while intermessage threats are from unauthorised users, and
intramessage threats are from the communication participants
themselves.
Intermessage threats can take the form of masquerade, which is

20. imposting an authentic user to extract sensitive information.
Message modification may be done by unauthorised users to genuine
messages. Replay is the tapping of a message, and sending it to the
intended recipient at a later date to extract more information, or to
confuse him. Finally, analysis of traffic between MHS users can be
used to deduce information from the rate of traffic flow - for
example continuous, sporadic, bursty flow, or no flow.
Intramessage threats occur when a sender denies sending a message, or
a receiver denies receiving a message - this could have serious
implications in financial or legal transactions. Also, security level
violation can occur when users try to violate the security clearance
requirements of a management domain.
The security services in MHS are supported through the use of service
elements in the message envelope. The envelope contains security
relevant arguments. Many of the techniques employed rely on
encryption mechanisms and MHS allows for flexibility in the choice of
algorithms. Since each domain can have its own security policy, an
agreement on internetworking between two domains is required by MHS.
This has to be defined in such a way that it does not conflict with
the security policies of either domain.
Security services are provided by the establishment of an
authenticated association between adjacent components in the MHS, and
the setting up of the security parameters for the association. This
can be applied to any pair of components in the MHS: UA/MTA, MTA/MTA,
MS/MTA, etc. This allows the various components to verify the origin
of messages, test the integrity of their content, prevent
unauthorised disclosure, etc.
A few of the security capabilities provided for by the MHS are
message origin authentication, report origin authentication and probe
origin authentication. Proof of delivery enables the originator to
authenticate the delivered message, and the identity of its
recipients, and proof of submission, authenticates that the message
was submitted to the MHS. Content integrity enables the recipient to
verify that the message was received without any modifications, and
content confidentiality prevents unauthorised disclosure of the
message. Message security labelling provides a capability to
categorise a message, according to sensitivity, which determines the
policy for handling of the message. Non-repudiation of submission
provides the originator of a message with proof of submission of the
message, which will protect against any attempt by the MTS to falsely
deny that the message was submitted for delivery. Non-repudiation of
Fatehi, Bhinderwala, Krishnan [Page 20]
_
An Overview of X.400 June 1994
delivery provides the originator of a message with proof of delivery
of the message which will protect against any attempt by the

21. recipient to falsely deny receiving the message.
Some security services require the UA/MS to have security
capabilities, some require the MTA to have security capabilities,
while some require both. Security features that apply between the
originator's and recipient's UAs require the UA to have security
capabilities for eg. enciphering and deciphering messages. Such a
message (encrypted) is transferred by the MTS transparently. Some of
the security services involve interaction with the MTS, and require
the MTAs to have security capabilities. As an example,
non-repudiation of submission requires the MTA, to which the message
is submitted, to contain mechanisms to generate a proof of
submission. Some of the services apply to the MS as well as UAs and
MTAs, such as message security labelling.
3.8 INTERPERSONAL MESSAGE (IPM)
The InterPersonal Message (IPM) as defined in X.400 consists of an
envelope generated by the MTL, a "heading" which contains IPM
specific data such as information about the originator, the subject,
etc. Several "body parts" follow, each of which contain one type of
information, like ASCII text, voice, or even a forwarded message,
with its Previous Delivery Information (PDI).
Forwarded
MESSAGE IPM
- ---------- --- ---------- -
| message- |envelope| / | PDI | |
| content IPM ---------- / ---------- |
| - - ---------- / ---------- |
| | | IPM- |heading | / |heading | |
| | | body ---------- / ---------- |
| | | - ----------/ ---------- |
| | | | |bodypart| |bodypart| |
| | | | ---------- ---------- |
| | | | ---------- ---------- |
| | | | |bodypart| |bodypart| |
| | | | ---------- ---------- |
| | | | . |
| | | | . |
| | | | ---------- ---------- |
| | | | |bodypart| |bodypart| |
- - - - ---------- - ---------- -
Key: IPM = InterPersonal Message; PDI = Previous Delivery Information
Figure 8. X.400 InterPersonal Message structure
Fatehi, Bhinderwala, Krishnan [Page 21]
_
An Overview of X.400 June 1994

22. 4 GATEWAYING BETWEEN X.400 AND RFC 822
Since RFC 822 is very widely used, and X.400 is just being
implemented on a number of systems, there is a compatibility problem.
Between the two mail worlds, one can set up a "mail gateway", which
accepts messages in one format and forwards them in another. The main
goal of a gateway is to maintain the highest possible service
elements during conversion. Some conversions are supported, others
are partly supported (that is not performed satisfactorily), and
still others are unsupported.
Conversion of RFC 822 to X.400 is relatively easy, although the
address mapping is tricky. The RFC 822 fields are converted to the
corresponding X.400 fields. The "Keywords" field is dropped. An RFC
822 message is always converted to an IPM.
------------------------------------------------
RFC 822 X.400
------------------------------------------------
Reply-To: IPMS.Heading.reply-recipients
Subject: IPMS.Heading.subject
In-Reply-To: IPMS.Heading.replied-to-ipm
References: IPMS.Heading.related-IPMs
To: IPMS.Heading.primary-recipients
Cc: IPMS.Heading.copy-recipients
------------------------------------------------
Table 2. Service elements.
------------------------------------------------
RFC 822 X.400
------------------------------------------------
ASCII PrintableString
Boolean Boolean
------------------------------------------------
Table 3. Service element types.
The reverse conversion is difficult, though. Many of the X.400 fields
do not exist in RFC 822, and special RFC 822 headers may have to be
created (with an "X-" prefix). Also, some data types of X.400 are not
supported, and sometimes there is no option but to drop this data.
Thus, there can be loss if a message is to pass from an X.400 system
to another through a RFC 822 system.
5 ACKNOWLEDGEMENTS
We would like to acknowledge the help and guidance given to us by our
Fatehi, Bhinderwala, Krishnan [Page 22]
_
An Overview of X.400 June 1994

23. professors Anant G. Joshi and Kirtikumar G. Satam, of the National
Centre for Software Technology, Bombay.
We are deeply grateful to Bjorn Myrstad, Postmaster of UNINETT, for
reviewing this paper in its draft stages, and providing us with
detailed comments.
We are also extremely grateful to Erik Skovgaard, for reading our
paper, and sending us valuable suggestions for its improvement, and
encouraging us while we were writing it.
6 AUTHORS
This paper was submitted as part of the requirements of the Computer
Networks course conducted for the Post Graduate Diploma in Software
Technology at the National Centre for Software Technology, Bombay,
from May to June 1994.
Sualeh Fatehi (BE Construction) is a civil engineering consultant.
Shoeb Bhinderwala has done his graduation in Electronics Engineering
from Bombay University, and is currently a practising software
engineer.
Krishnan G S is a graduate in Computer Technology and is currently a
Software Engineer at TERA Informatics Pvt. Ltd, SEEPZ, Bombay.
The authors can be contacted at (by snailmail):
Sualeh Fatehi Shoeb Bhinderwala Krishnan G S
1/B, 'Sherbanoo', 28th Rd., TPS III 201, B-2, E-Wing, Plot No.5
111, M. Karve Road, Panaah, 2/12 Guru Krupa, 2nd Cross Road,
Churchgate, Bandra, Swami Samarth Nagar,
Bombay 400 020 Bombay 400 050 Andheri(W), Bombay 400 053
INDIA. INDIA. INDIA.
7 REFERENCES
7.1 STANDARDS AND RECOMMENDATIONS
1. CCITT Blue Book: VIII.7 Recommendations X.400 - X.420
Data Communication Networks
Message Handling Systems.
X.400 Message Handling System and service overview

24. Fatehi, Bhinderwala, Krishnan [Page 23]
_
An Overview of X.400 June 1994
X.402 Message Handling System: Overall architecture
X.411 Message Handling System: Message transfer system: abstract
service definition and procedures
X.413 Message Handling System: Message store: abstract service
definition
X.419 Message Handling System: Protocol Specifications
X.420 Message Handling System: Interpersonal messaging system
7.2 BOOKS
1. Computer Networks
Andrew S. Tanenbaum
Prentice-Hall
2. OSI Explained. End to end computer communication standards.
John Henshall and Sandy Shaw
Ellis Horwood Limited
3. OSI A Standard for Computer Communications
Ulysses Black
Prentice-Hall
4. ISDN - An Introduction
William Stallings
Macmillan Publishing Company
5. MHS and Distributed Applications
Edited by E. Steffernd, O. Jacobsen & P. Schidder
North Holland
6. X400 Message Handling: Standards, Interworking, Applications
B. Plattner, C. Lanz, H. Lubich, M. Muller, T. Walter
Translated by Stephen S. Wilson
Addison Wesley Publishing Company
7.3 RFCs
1. Request For Comments: 821
SIMPLE MAIL TRANSFER PROTOCOL
August 1982
Jonathan B. Postel
2. Request for Comments: 822
Standard for the format of ARPA Internet text messages
August 13, 1982
Revised by David H. Crocker
3. Request for Comments: 1049

25. A content-type header field for Internet messages
March 1988
Fatehi, Bhinderwala, Krishnan [Page 24]
_
An Overview of X.400 June 1994
M. Sirbu
4. Request for Comments: 1327
Mapping between X.400(1988) / ISO 10021 and RFC 822
May 1992
S. Hardcastle-Kille
5. Request for Comments: 1341
MIME (Multipurpose Internet Mail Extensions): Mechanisms for
Specifying and Describing the Format of Internet Message
Bodies
June 1992
N. Borenstein, N. Freed
6. Request for Comments: 1465
Routing Coordination for X.400 MHS Services Within a Multi
Protocol / Multi Network Environment Table Format V3 for
Static Routing
May 1993
U. Eppenberger
7. Request for Comments: 1495
Mapping between X.400 and RFC-822 Message Bodies
August 1993
H. Alvestrand, S. Kille, R. Miles, M. Rose, S. Thompson
8. Request for Comments: 1506
A Tutorial on Gatewaying between X.400 and Internet Mail
August 1993
J. Houttuin
8 APPENDIX A: ABBREVIATIONS
ACSE Association Control Service Element
ADMD Administration Management Domain
AE Application Entity
AP Application Process
APDU Application Protocol Data Unit
ARPA Advanced Research Projects Agency
ARPANET Advanced Research Projects Agency Network
ASCII American Standard Code for Information Exchange
ASE Application Service Element

26. AU Access Unit
BITNET Because It's Time Network
CCITT Comite Consultatif International de Telegraphique
et Telephonique
DL Distribution List
EBCDIC Extended Binary Coded Decimal Interchange Code
Fatehi, Bhinderwala, Krishnan [Page 25]
_
An Overview of X.400 June 1994
EIT Encoded Information Type
IPM Inter-Personal Message
IPMS Inter-Personal Messaging Service
ISO International Organisation for Standardisation
JNT Joint Network Team (UK)
MASE Message Administration Service Element
MD Management Domain
MDSE Message Delivery Service Element
MHS Message Handling System
MIME Multipurpose Internet Mail Extensions
MOTIS Message Oriented Text Interchange Service
MRSE Message Retrieval Service Element
MS Message Store
MSSE Message Submission Service Element
MTA Message Transfer Agent
MTAE Message Transfer Agent Entity
MTL Message Transfer Layer
MTS Message Transfer System
OSI Open Systems Interconnection
PDAU Physical Delivery Access Unit
PDI Previous Delivery Informatio