WORKSHOPS

Making Good Connections With X.400 & SMTP

Today, we can add "And it's who knows what you know." But, how do you get this word out? By making good connections, staying up close and personal and keeping in touch. In the Information Age, these connections more often are made by electronic means rather than by face-to-face meetings or telephone conversations. Providing the ability to exchange information with other people, programs and processes is critical to the success of the business, dynamic work teams and individuals. Including reliable and available X.400 and SMTP transports in the corporation's electronic-messaging infrastructure is one way to ensure this connectivity.

The Standards In 1984, the International Telegraph and Telephone Consultative Committee (CCITT), now known as the ITU Telecommunication Standardization Sector, completed work on the first release of the X.400 message handling system standard. The standard provided for the exchange of messages in a store-and-forward manner without regard to the user's location or computer system. As soon as implem entor's guidelines were made available, public carriers and messaging vendors began to develop products and services using X.400. The standard has had two more releases, in 1988 and 1993, to provide additio nal features and functionality such as the message store, access units, replication and strong authentication. Today, the only widely adopted and supported X.400 standard deployed in the United States is the 1984 version. If the organization has implemented a 1988 X.400 system that communicates with a 1984 system, the resulting exchange will be "dumbed down" to the 1984 level, with, unfortunately, some loss of fidelity.

Simple Mail Transport Protocol (SMTP) is also an international messaging standard, developed for the Internet community in 1982 in a document called Request for Comment (RFC) 821. Later, RFC 822 defined the ASCII text message structure, which was just fine for the simple requirements of messaging on the Internet at that time.

When it became apparent that users wanted to exchange more complex message types such as the output from computer applications, images, audio and so on, the Multipurpose Internet Mail Extension (MIME) standard was released. Like X.400, SMTP is computer platform- and location-independent. SMTP, because of the exponential growth of the Internet and the Web, has emerged as the dominant message transport protocol in the United States today, whereas, X.400 is more dominant in Europe.

Implementations Not that they're available on every street corner, but a bevy of X.400 and SMTP systems abound. Their basic architecture differs: Some are simple gateways or connectors as used by Novell GroupWise and Microsoft Exchange and others are the more complex Message Transfer Agent (MTA) variety as provided by Lotus Notes. What is the difference between an MTA and a gateway or connector?

A gateway or connector is positioned between two different electronic messaging systems and converts messages including content, headers and any attachments from one protocol format to the ot her. For example, a Microsoft Mail/SMTP gateway would receive a message from the Microsoft Mail side, convert it to an internal format and then convert that to the SMTP format before sending the messa ge on its way again. With this number of format conversions required, it's likely that some of the text formatting or other information may be lost in the translations.

An MTA, however, is capable of relaying messages from one MTA to another without first converting them to an internal format. This preserves more of the original content and formatting of the message. MTAs also can perform other tasks, such as expanding distribution lists embedded within messages.

Architecture aside, there are three vital steps that must be taken to ensure good SMTP and X.400 connections; naming, networking, and optimizing--knowing who you are, where you're going and how to get there and making the most of your journey.

The Name That Domain Game The most critical initial task in implementing an SMTP or X.400 gateway or MTA is to develop and implement a comprehensive and cohesive naming and addressing convention for the entire enterprise. In most systems, once the domain names have been entered, they cannot be changed without reinstalling the system.

You must have a crystal clear naming hierarchy of your domain, including its remote sites and various organizational entities. SMTP is not naturally hierarchical, so it's a good idea to create subdomains. When the naming strategy is in place, configuring any gateway, connector, or MTA is so much quicker and simpler--just a matter of filling in the blanks and testing the connection.

This is, of course, much easier said than done. Most corporations today are an amalgamation because of mergers, acquisitions and the fierce autonomy of internal divisions, rendering it massively difficult to formulate any strategy, much less a consistent one.

What can be done to reduce the confusion and confidently name your domain and users? You must know and understand three things: which elements are required in an SMTP or X.400 address, how these elements are implemented in the gateway or MTA you have chosen, and how the various sites within your domain will be named.

To s uccessfully name your domain, you must first complete a diagram showing all the company's locations, their e-mail systems and the connections among the sites. An example of this schematic for "XYZ Corp." can be seen below. From this type of diagram, you can create subdomain and domain names that make sense to your users, are easy to remember and have some staying power.