X.400

--------------------------------------------------------- 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 []_An Overview of X.400 June 1994

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

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

"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.


*--------------------------------------------------------------------* | | | 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

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


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 []_

An Overview of X.400 June 1994

*---------------------------------------------------------------* | user user Message Handling Environment| | | | |

| *--------------------------------------------------------*| | | | | 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.


However, the subdivision of the Application Layer contradicts the

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.


+---------------------------+ |\______ ______ /| | \----\/----/ | | +---------------+ | ENVELOPE | | | | |

+---------------------| |

| 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


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

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


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.


+-----------+ | MTS-user | +------------+ | (intended | | MTS-user O--->>-\ message | recipient | |(originator)O-<<-\ \submission +-----O-----+ +------------+ \ \ / \ \ / report | | /---->>----/

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.


----------+ +----------+ +--------- | | | | UA | | MS | | MTS | | | |

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 TransferService; 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 ("[email protected]") 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:


==================================================================== Attribute | Abbrev. | Remarks ==================================================================== MTS.CountryName | C | Identifies country ---------------------------------|-------------|--------------------

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


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.


\ ------ \ \ |PRMD| \------ \ ------ \ +--------+|PRMD| ~~\ \ | /----------------| ADMD |------ \_+--------+ \ \ / \ +--------+ ------ / | ADMD |-------\ |/ \ | |PRMD|_/ +--------+ \ \ +--------+ \ \ ------ | \ \_| ADMD | \ \ | \ +--------+ \ ------

\ \ _| \ |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


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).

- 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)


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.


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.


+-----------------+ |Application Layer| | User | +-------+---------+ | | ----------- +----------------+----------------+ ^ | | | | X.400 MHS (1988) | | | (MSSE, MDSE, MRSE, MASE) | | | | |

+----+----------+---------+-------+ | | | | | | | | | | +------+------+ | | | | 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


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

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


delivery provides the originator of a message with proof of delivery of the message which will protect against any attempt by the

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


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


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


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

A content-type header field for Internet messages March 1988


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

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


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

X.400

Technology

Transcript of X.400