Have you had your e-mail today? The future of e-mail and electronic messaging may relieve much of the tedium of today's software technology.

August  1995

This survey of current mail terms, standards, and technology, with a brief explanation of the major standards, will familiarize or update the reader on current developments in the E-mail industry and possible new directions in the market. We examine current and future Internet e-mail standards, and X.400 in particular. We also overview future messaging products from Novell, Lotus, IBM, and Microsoft.

Mail this article to a friend

The typical corporate business manager considers computer networks useful for one of two main applications: databases and electronic communication. When translated to plain and simple English, "electronic communication," means e-mail. This one application brings millions of people in contact with each other every day, wherever they may be. You can now send e-mail to more than 100 countries via the Internet, Bitnet, Fidonet, and other global and regional networks that carry e-mail. Or, you can transmit e-mail to a single co-worker, 10 feet away.

Either way, the user simply launches a mail application and types in an the recipient's e-address and the message. A few more keystrokes or the touch of a mouse button, and viola!, the message is sent. But the apparent simplicity of sending an e-mail message is a facade generated by the masterful techniques of the network administration staff. In this article we will review current e-mail technologies and glance at the future of the e-mail and electronic messaging industry.

Setting up today's electronic mail systems almost always involves more nomenclature than can be found in mainframe hardware manuals. A seemingly unrelenting demand for better and more capable services spurs complications, which multiply when one group of developers prefers one method above others, causing some discord, however justifiable, across different mail systems.

The simple idea of text-only mail messages harkens back to days when computing resources were costly and scarce. Around this time, marketers proclaimed an 80286-based computer offered "more power than you'll ever need" for your business, let alone for the home. Times change.

Today's users want to send pictures, software, sound, video, and a multitude of other media formats alongside their text messages. E-mail now not only lets you describe to others what your new yacht looks like; it actually shows the yacht -- in motion, if you like. Whatever the purpose of multimedia mail, the demand for it cannot be ignored. This means the administration staff now has to worry about the mail system's ability to process such messages.

Step by step
Just as e-mail has broadened its horizons content-wise, so has it moved beyond single homogeneous networks. In today's supernetwork-hungry world, messages may be sent from a PC NOS LAN in Toledo, Ohio to a VMS system in Jakarta, Indonesia. This odyssey probably involves more computers, programs, message formats, and unseen people than you can count on both hands. The multitude of mail protocols requires gateways that unpack, disassemble, mark up, repack, stamp, acknowledge, and in general probably go through more processing steps than the U.S. Postal Service. Thank goodness for automation.

The first phase of an e-mail message involves the use of a mail-reader/sender application program, which is more technically known as the Message User Agent (MUA). This is the program users see; they use it to receive, read, send, and sort their messages. There are hundreds of MUAs.

Some (such as Pine, a popular freeware Unix MUA) understand only how to read, prepare, and sort messages and leave the actual delivery to another program known as the Message Transfer Agent (MTA). Others, such as sendmail, handle both functions. The MUA and MTA reside on your local machine.

The MTA processes the message headers, which declare who, what, when, how, and where to send the message. The message might be sent to a user directly on the same system -- a simple, elegant action. It might be sent to a mail hub elsewhere on the network for further processing, perhaps en route to a location outside the network. It might be sent to a mail gateway to convert the format into something that can be transported over the Internet. Or, it might simply be trashed, which seems a common occurrence in many misconfigured software packages these days.

A simple gateway converts mail from one message format to another. For example, the Microsoft Mail SMTP gateway converts a message from MS-Mail format to that transportable by the Simple Mail Transport Protocol (SMTP) of the Internet, and vice versa. In truth, gateways like these serve as solutions for small- and possibly medium-sized organizations; they cannot support the massive network complexity of a large corporation.

A more complex gateway, sometimes called a mail hub, performs this same conversion step across numerous mail protocols. X.400/MHS, SMTP/MIME, GroupWise, MAIL-11, cc:Mail, and an alphabet soup of other protocols can make the matters of transporting a simple ten-word text message a Herculean task. Let's examine a few of these protocols.

Primitive protocol
SMTP is a primitive mail transport protocol that is still very popular today, largely because of the Internet phenomenon. Originally, SMTP and the old Unix mail helped enable the transfer of ASCII text messages across Internet hosts with each message packed in TCP. Here's an example:

1. Jane writes a message using an MUA of her preference.
2. The MUA sends this message to an MTA (e.g., sendmail).
3. The MTA opens a connection to port 25 of the TCP/IP host, where John has an account.
4. Through this connection, Jane's MTA sends two or three of the 10 simple SMTP commands to the MTA of John's system.
5. This MTA of John's system will then place it in a mail queue in wait for John to access with his MUA.

This is but a simplified version of what happens; sometimes, the mail may be exchanged among multiple points as it is forwarded along the structure and through firewalls and gateways.

A problem arose about a decade after SMTP's adoption. PCs were becoming commonplace items, and some were even networked. Still, the PCs only ran PC operating systems. ("None of that Unix stuff. Our people can't handle it.") But how could PC users receive e-mail without having to connect to a Unix host through a terminal session?

Along came the Post Office Protocol (POP). This nifty little doohickey, combined with the proper application programs, allowed PC users to read and send messages using a mail application program with buttons and arrows and other familiar interface components. Users prepare their messages within a local application, then transfer them to a POP server that handles the actual delivery. To receive messages, users download their set from the POP server every time.

IMAP, IMSP, and MIME
POP helped, but pretty soon people wanted to work off-line to develop messages, partially read or scan message headers, and all sorts of other user conveniences. So J.K. Reynolds came up with the Internet Mail Access Protocol (IMAP) to solve all of these problems.

POP still survives today in newer versions with a few enhancements, however, IMAP is far more powerful. It supports the transferring of individual mail items, scanning all headers to select the items if necessary. This allows off-line or partial on-line/off-line work as the system connects only for the brief time necessary to transfer the data, thereby saving resources.

A new draft proposal known as the Internet Mail Support Protocol (IMSP) provides an even better structure for an enterprise-level IMAP system. With IMSP, several individual IMAP servers can work in concert with the IMSP server to provide a uniform mail system accessible from any point of the network. The IMSP client also supports the IMAP and POP protocols, thus allowing a fallback mechanism in case a user could not directly access the IMSP server. The client will pass on the transaction information to the IMSP server the next time it connects.

With IMSP, the user can now have address books, extended mailbox management facilities, and e-mail security. For the administrator, the mail management system is combined into one large server that allows better control facilities. IMAP and IMSP will become more predominant with mobile users who cannot always maintain a single point of access.

The necessity of more-than-text messages brought up a new problem: How do you send a multimedia message without converting the entire Internet from a text-based message system to something else? The answer: Change all multimedia formats into text. Simple enough solution but one requiring quite a bit of legerdemaining on the part of the delivery system.

This led to the rise of the Multipurpose Internet Mail Extensions (MIME) system. This encoding system allows all the fun things in mail by hiding the actual work of conversion in the program itself; users merely type a message and add pictures as they please, right next to the text.

X.what??
A step away from the Internet mail standards is the X.400 and related standards developed by the Consultive Committee for International Telephony & Telegraphy (CCITT) and now the International Telecommunications Union (ITU). The X.400 message handling system differs greatly from the relatively simple SMTP mail delivery system. For exacting measures of identity of e-mail users, it relies upon the X.500 directory services system.

In X.500, you can specify users precisely -- down to the color of their shoes, if necessary. An entry specifies a country, administrative domain, organization, organization unit, the full name of the user and a host of other mechanisms -- quite a bit more than user@domain.com. Just accessing an X.500 requires a Directory User Agent (DUA) to access the Directory Information Base (DIB) that holds the actual data; in the process, you may encounter several Directory Service Agents that coordinate this information from where the actual DIB exists.

Users who wish to access their mail directly make use of the User Agent (UA). The UA then talks to the actual Message Transfer System (MTS), which can consist of a number of MTAs. The MTAs coordinate with the X.500 system and Message Stores at intermediary or remote locations. At the receiving end, another user will make use of another UA.

Sounds familiar, doesn't it? The difference between X.400 and SMTP lies partially in how the process is done in code and more in the message formats and conversion systems that were formally designed as part of the X.400 family. Since it was designed to support such variety of services from the beginning, X.400 did not encounter the limitations of Internet mail.

As opposed to the Internet "Pony-Express" concept, X.400 makes absolutely sure that a message is delivered when and where necessary and is only limited by sub-units such as gateways to other systems. This is why X.400 is more common in large corporations.

Agents: MUAs, MTAs, and Maxwell Smart
Starting with the Internet MUAs, the most common would undoubtedly be Unix's mail, which has survived the eons of technology improvements in its primitive but robust form.

For PCs and Macintoshes, the Eudora mail software from Qualcomm with its POP version 2 and 3 support has become quite common. Z-mail from Z-Code Software, now a division of Network Computing Devices Inc., is a more commercially oriented package that's available for all major platforms and provides support for the entire cacophony of Internet e-mail standards.

Two interesting products provide an MUA interface to multiple mail systems. E-Mail Connection from ConnectSoft and MailPlus from Mail Services (810-352-6700) consolidate access to the Internet, as well as to popular on-line services such as CompuServe, Prodigy, and America Online. These products also support MHS and the mail interfaces for PC systems.

On the MTA side, fewer products exist. Among them are PMDF from Innosoft International, Microsoft's Exchange Server (MS-Mail reborn), IBM's MQSeries, Lotus' cc:Mail Communications Server (version 4.0 in particular, if it comes to market), and Novell's GroupWare and Collaborative Computing Environment (a combination of Novell GroupWise, SoftSolutions, InForms, and the Open Messaging Environment). PMDF is the traditional mail-exchange hub concept, originally available on VMS systems and now also on Digital Unix (OSF/1) machines.

This strategy of Microsoft, IBM, Lotus, and Novell takes the hub concept one step further into an entire collaborative environment supporting not just e-mail but also discussion databases, forms, workflow systems, and scheduling systems. Where MQSeries and the Lotus Communications Server go is yet to be seen in light of the recent purchase of Lotus by IBM.

In summary, the complexities of e-mail systems will progressively increase over time. However, the presentation to the user at the same time will show a more friendly face.

Mail systems consist of two main units: the User Agent, which is responsible for the main core of creating and accessing messages, and a Transfer Agent, which is responsible for sending the message through all the right turns and passageways of e-mail tunnels. The SMTP mail system of the Internet is a hangover from yesteryear's simplicity. It can still meet some of the needs of today but is limited in other senses.

The X.400 mail handling system was designed with multiple and complex mail access and delivery systems in mind. In the future, we will see more cooperation between mail systems and other related areas such as workflow and group scheduling; many companies are already taking advantage of this knowledge and bringing impressive new packages to market. For now, my best hope is that this article gets to my editor on time over the Internet.

About the author
Rawn Shah is the vice president of RTD Systems & Networking, Inc., a Tucson, AZ based consultancy and software developer. Reach Rawn at rawn.shah@sunworld.com.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-08-1995/swol-08-connectivity.html
Last modified: