Message Handling Systems

Electronic mail (e-mail) represents one of the most successful classes of network applications currently enjoyed by many users. Early e-mail systems were network dependent, and their use was limited to the private networks of individual organizations. The CCITT X.400 and the ISO 10021 series of standards for Message Handling Systems (MHS) have paved the way for standardized and widely-available e-mail services.

Figure 8.85 illustrates the X.400 view of MHS architecture. At the center of MHS is a Message Transfer System (MTS) which handles the delivery of messages. The system consists of the following components:

• A Message Transfer Agent (MTA) is responsible for the routing of complete e-mail messages (called envelopes) through the MTS. MTAs handle envelopes in a store-and-forward fashion.

• A User Agent (UA) manages a user’s mailbox. It enables the user to create, submit, and receive messages. The UA may serve an application or provide a user interface for direct interaction. UAs typically run on multi-user systems (e.g., mainframes).

• A Message Store (MS) acts on behalf of a UA running on a system which may not be available on a continuous basis (e.g., personal computers). MSs are typically used within a LAN environment, serving a collection of personal computers.

Figure 8.84 MHS architecture.

MTA

Message Transfer System (MTS)

UA UA UA MTA MTA MTA MS UA

UAs and MSs make it possible for users to receive messages when they are not personally present, and while even their terminal or personal computer is not switched on. They simply store the messages and notify the user at the earliest opportunity.

Each user has its own UA. Furthermore, each user is identified by a unique address which is structured in a hierarchical fashion (similar to a postal address). The address structure reflects the division of MTAs into domains. Domains exist at various level of abstraction: country, organization, unit, etc.

Figure 8.85 illustrates the general structure of an envelope. It consists of contents and addressing information. The contents consists of two parts: heading and body. A heading is comprised of fields such as recipients’ addresses, addresses to which the message should be copied, originator’s address, subject, etc. Some of the heading information is provided by the user (e.g., recipients’ addresses and subject), others are automatically inserted by the UA (e.g., date and originator’s address). The body contains the message information itself. It may consist of more than one part, each of which may be of a different type (e.g., text, digitized voice, digitized image).

An envelope is constructed by a UA by deriving envelope addressing information from the heading and adding it to the contents. MTAs only deal with envelopes and their addressing. They have no interest in the contents of an envelope. Each receiving MTA looks at the addressing of an envelope, records on it the last leg of the route so far, time stamps it, and hands it over to the next MTA. The envelope therefore bears a complete trace of its route through the network of MTAs.

Figure 8.85 Envelope structure. To: Cc: From: Subject: ... Heading Body Contents Envelope

Envelope addressing info...

As would be expected, the MHS service is defined by a set of service primitives. Figure 8.35 summarizes the primitives and their purpose.

Figure 8.86 MHS service primitives.

Primitive Issued By Types Purpose

LOGON UA request

response

To initiate a session. If successful, the UA is informed of any messages waiting.

MTA indicate confirm

LOGOFF UA request To terminate a session.

MTA confirm

CHANGE UA request To change the UA's logon password.

PASSWORD MTA indicate

confirm

REGISTER UA request To change the UA's profile maintained by the

MTA confirm MTA.

SUBMIT UA request To submit a message (an envelope) to the MTA.

MTA confirm

DELIVER MTA indicate To deliver a submitted message to the UA. NOTIFY MTA indicate To notify the UA of message delivery. CANCEL UA request To cancel a message delivery to a UA.

MTA confirm

PROBE UA request To check if a SUBMIT would be successful.

MTA confirm

CONTROL UA request

response

To alter the ways in which message storage and delivery is controlled by the MTA.

MTA indicate confirm

MHS uses four protocols (P1, P2, P3, and P7) to provides two types of service:

• The Message Transfer (MT) service supports the handling of envelopes. This service operates between MTAs (P1 protocol), between UAs and MTA/MSs (P3 protocol), and between UAs and MSs (P7 protocol).

• The Inter-Personal Messaging (IPM) service supports the handling of the contents of envelopes. This service operates between UAs (P2 protocol). IPM depends on the MT service for its operation.

These services are organized as service groups, each of which contains related service elements. The service elements are supported by the service primitives depicted in Figure 8.35. Figure 8.87 summarizes sample MT and IPM service elements.

MHS protocols use the three common service elements described in Section 8.2 (i.e., ACSE, RTSE, and ROSE). All envelopes are transferred as APDUs using the RTSE. All MHS protocols and messages are defined in ASN.1 and have BER codings. This includes a set of application-wide tags defined for identifying the various data types defined for MHS.

Figure 8.87 Service groups and sample service elements.

Group Service Element Purpose

Basic Content Type Indication Allows the originating UA to indicate the message content types (e.g. text, binary) to the recipient. Message Identification Used by the MTS to uniquely identify each

message passing through it.

MT

Submission Delivery Notification Allows the originating UA to request notification of receipt from the receiving UA.

& Delivery Multidestination Delivery Allows the originating UA to specify multiple destination addresses.

Conversion Prohibit Conversion Allows the originating UA to ask the MTS not to perform any conversion on the message. Explicit Conversion Used by the UA to ask the MTS to perform code

conversion on the message.

Basic Same as MT Same as MT

Action Receipt Notification Used by the originating UA to ask the receiving UA to notify the originator of the receipt.

IPM

Auto-forward Indication Used by the receiving UA to determine if the message has been auto-forwarded.

Information Subject Indication Used by the originating UA to convey the message subject to the receiving UA.

Conveying Expiry Indication Used by the originating UA to specify when the message will become invalid.

The X.400 series of standards consist of a number of recommendations, of which the following were touched upon in this section:

CCITT X.400 / ISO 10021.1 MHS Service Overview CCITT X.402 / ISO 10021.2 MHS Architecture

CCITT X.411 / ISO 10021.4 MHS Message Transfer Service Definition CCITT X.419 / ISO 10021.6 MHS Protocol Specification