X.400 Messaging

team lib

E-mail is an essential application, one that can often justify the installation of a network all by itself. E-mail provides a vehicle for people to communicate regardless of their physical location and time zone. A form of e-mail exists for nearly every type of operating system, from ones running on personal computers to large hosts . Mail-enabled applications can be constructed on the mail system, allowing greater productivity.

A corporation's departments are likely to use a wide variety of systems. IBM's PROFS and SNADS are commonly used on IBM mainframes; All-In-1 is popular on VAX/VMS systems; WangOffice is used on Wang VS machines; HPOffice is used on Hewlett-Packard minis; SMTP is used on Unix and TCP/IP systems; Lotus' cc:Mail, DaVinci's eMail, and Microsoft Mail are among those used on PC LANs; and CE Software's QuickMail is often used on Mac LANs.

As corporations build enterprise networks, the dissimilar e-mail systems must be connected via a common transport. Very often, that platform is X.400. X.400 is vendor-independent, able to run on a wide variety of computer systems, and internationally accepted and used.

The International Organization for Standardization (ISO) X.400 Message Handling Systems (MHS) is a suite of protocols that define a standard for store-and-forward messaging. X.400 provides message creation, routing, and delivery services. It runs over an X.25 packet-switched network or asynchronous dial-up lines.

X.400 software is available for a variety of computers, either as native implementations or as gateways.

There are two versions of the X.400 standard: the 1984 and the 1988 specifications. [Note: the specification was further upgraded in 1992.] Most X.400 mail systems implement the older specification. The new spec offers key additions to X.400's flexibility and usefulness . It permits the use of asynchronous lines, a useful tool for PC or laptop users not connected to an X.400 network. Directory services and security features have been added. As more 1988 X.400 implementations become available, native X.400 usage should rise.

X.400 Components

X.400 divides an electronic mail system into a client, called a User Agent (UA) in ISO parlance, and a server, called a Message Transfer Agent (MTA). Essentially, the User Agent is a mail box; it interfaces directly with the user. It is responsible for message preparation, submission, and reception for the user. It also provides text editing, presentation services, security, message priority, and delivery notification. The User Agent is an interface, not an end-user application, so it does not define the specifics of how it interacts with the user. The product developer decides those issues.

The Message Transfer Agent routes and relays the messages. Its responsibilities include establishing the store-and-forward path , ensuring channel security, and routing the message through the media. An MTA's operation is relatively straightforward. The User Agent sends its message to the local Message Transfer Agent. The MTA checks the message for syntax errors, then delivers the message to a local User Agent, or if the message is not local, it forwards it to the next MTA. That MTA repeats the process until the message is successfully delivered.

A collection of MTAs is known as Message Transfer System (MTS). The MTS is usually specialized to a particular vendor's product.

X.400 also uses Distribution Lists (DLs), which are like routing lists commonly used in offices.

The Message Store (MS) provides a facility for message storage, submission, and retrieval. It complements the User Agent for devices that are not always available, such as PCs or terminals. Essentially, it is a database of messages.

The Access Units (AUs) provide connections to other types of communications systems, such as telex and postal services. AUs defined in the 1988 spec are the Telematic Agent for Teletex terminals, Telex Agent for Telex service, and Physical Delivery Agent for connection to the traditional postal service.

A management domain is a collection of at least one Message Transfer Agent and zero or more User Agents that is administered by a single organization. Management domains may be private (PDMD) or administrative (ADMD). An ADMD is managed by an administration such as a PTT or telephone company, and a Private Management Domain is managed by any other type of organization. A hierarchy of management domains enables the configuration of a worldwide X.400 system with unique addressing.

Sending X.400 Mail

An X.400 mail system follows the metaphor of a post office, and X.400 messages follow the metaphor of the letter. Messages are packaged into envelopes, and an envelope describes the control information necessary to deliver the message's content, including the body type, syntax, and semantics. X.400 can deliver messages to other X.400 users via a message transfer service or to other communications facilities such as Telex via an interpersonal messaging service.

As with the postal services, users and distribution lists must have unique addresses to deliver the message anywhere in the world. X.400 uses two kinds of names , a primitive name , which identifies a unique entity such as an employee number, and a descriptive name, which identifies one user of the X.400 system.

A name is typically looked up in a directory to find the corresponding address, but X.400 allows a machine name to also be a directory name, which makes it easier for humans to interpret. X.400 addresses consist of attributes that describe a user or distribution list or locate the user distribution list within the mail system. Attributes are personal (such as last name or first name), geographical (street name and number, town, or country), organizational (name or unit within organization), and architectural (X.121 addresses, unique User Agent identifier, or management domain). In practice, X.400 names are lengthy and complex and should be hidden from end users by offering them aliases.

In addition to messages, the message handling system and the message transfer system use probes and reports . A probe contains only an envelope-no content-and it is used to determine if messages can be delivered. For instance, a probe may be sent to test out a path, asking the receiving MTS if it can accept a particular message type. By testing the waters with a probe, a lengthy message is less likely to be rejected by the recipient. A report is a status indicator that relates the progress or outcome of a transmission to users.

Ways Of Handling Messages

X.400 defines several protocols for handling messages among the different system components. Two Message Transfer Agents may communicate directly with each other, without the intervention of a User Agent. They do so by using the P1 protocol. If a User Agent wants to communicate with a service outside the X.400 domain, it uses P2, the interpersonal messaging protocol. The 1988 implementation of P2 defined additional body types for messages, so beyond supporting Teletex and Group III fax, P2 supports externally defined body types such as word-processing formats. This specification paves the way for electronic document interchange.

P3 defines the conventions for transferring a message from the User Agent to the Message Transfer Agent. Initially defined in the 1984 spec, P3 assumes that the User Agent is online and ready to accept messages from its Message Transfer Agent. In 1984, X.400 did not provide for a User Agent that would be online intermittently. In practice, most User Agents are implemented on personal computers, and therefore will not always be online.

To remedy the situation, Message Store was added in the 1988 spec, and P7 was defined for the communication between the User Agent and the Message Store. The Message Store, always connected to the Message Transfer System, stores messages for the User Agents. User Agents submit messages through the Message Store as well as retrieve, list, summarize, and delete messages from the Message Store database. P7 support is crucial for anyone using laptops.

Directory And Security Issues

The 1988 X.400 recommendations suggest using ISO's X.500 directory service for naming, storing distribution lists, storing profiles of User Agents, and user authentication. By using X.500, users do not have to contend with ungainly machine-oriented names, but can use more intuitive names. However, X.500 is still under development in ISO. Pilot projects are under way, but there are no commercial implementations. No clear-cut solution exists for a directory service that's suitable for a heterogeneous network.

Security is another key issue. The 1988 spec provides facilities to authenticate who originated the message, verify who originated a delivery or nondelivery notice, check that the message or its contents were not altered and that all recipients received a copy. It also provides return receipt and registered mail services.

Security must be improved beyond these capabilities. Dangers lurk in one user masquerading as another. For example, no facility ensures that a user does not impersonate and misuse a Message Transfer System or falsely claim to originate a message. No facility ensures that message sequence is preserved. If a message were resequenced, messages could be replayed, reordered, or delayed.

X.400 is just one option for building the backbone of the enterprise messaging network; however, it has international acceptance and vendor independence. With the products based on the 1988 specification emerging, X.400 can serve a more useful role.

This tutorial, number 47, by Patricia Schnaidt, was originally published in the June 1992 issue of LAN Magazine/Network Magazine.

 
team lib


Network Tutorial
Lan Tutorial With Glossary of Terms: A Complete Introduction to Local Area Networks (Lan Networking Library)
ISBN: 0879303794
EAN: 2147483647
Year: 2003
Pages: 193

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net