                       White Paper

AN OPEN-SYSTEMS E-MAIL ARCHITECTURE FOR THE ENTERPRISE NETWORK

                      April 4, 1994
-----------------------------------------------------------------
                   Z-Code Software Corp.
                 101 Rowland Way, Ste. 300
                     Novato, CA 94945
            Tel: 415-898-8649,  Fax: 415-898-8299
-----------------------------------------------------------------

Electronic mail has emerged as perhaps the leading productivity tool for
communicating within and between organizations. But the most widely-used
architectures for implementing e-mail solutions -- based on mainframes or
PCs, with central file servers and proprietary protocols -- are becoming
obsolete as networks grow larger and more complex. A new e-mail paradigm
is needed to address the emerging enterprise network -- a paradigm that
involves standard protocols, separation of user and transport functions,
and the use of a messaging "backbone" that in many enterprises already
exists.

How Traditional E-Mail Systems Work

On a typical PC LAN-based network, e-mail packages are implemented through
a common file system architecture, where the sender and recipient have
access to the same shared file system. When one user sends mail to
another, the mail is deposited directly into a central file server, or
main message store, which resides on a shared network drive. This design
assumes the use of some kind of PC LAN system (such as Novell) and a
configuration in which all users share the same network file server and
network drive.

While nothing is wrong with a centralized message storage design in
principle, this solution breaks down when the user community grows or
becomes geographically dispersed. Once a certain threshold of users is
exceeded, bandwidth bottlenecks begin to occur at the file-server level.
At this point the message-storage function must be distributed among
multiple servers. The result is increasing expenditures on hardware,
software and personnel resources as this configuration becomes more
complex. Furthermore, network administration becomes difficult because
this design allows no flexibility for segmenting the network and network
drives into different (or even separate) configurations.

While some PC-based e-mail systems provide for add-on gateways that can
forward messages to other LANs or disparate networks, these typically rely
on proprietary protocols. Novell's Mail Handling System (MHS), for
example, is a platform-specific implementation that operates only on
Novell networks. Furthermore, the MHS specification and implementation are
dependent on the Novell NetWare architecture and require the (also
proprietary) IPX/SPX protocol suite. Similarly, Lotus cc:Mail and
Microsoft Mail use proprietary message store protocols, requiring gateways
when messages are sent to users on other systems.

In short, PC-based e-mail packages are not inherently "open" systems --
i.e., their design and architectural specifications are not openly
available, and any two implementations are not interoperable. Because such
packages rely on specific networking protocols, the user's choice of mail
servers is limited to PCs -- not the server platforms of choice for widely
distributed networking environments.

A New Paradigm for E-Mail Architectures

How, then should an e-mail system work? In today's growing networks and
internetworks, a prime consideration is interoperability with other
computers, networks and applications -- a true open system. For this
reason, e-mail systems are best designed with two separate components: a
Mail User Agent (MUA) and a Mail Transport Agent (MTA). The user interacts
only with the MUA, which acts as his electronic mail manager, allowing him
to view, compose and store messages, and perform other actions associated
with e-mail.

The MTA is responsible for delivering mail to an address, usually another
user. After a message has been prepared for processing by the MUA, it is
given to the MTA for delivery. The user should not have to be concerned
with the nature or function of the MTA -- only with the fact that his
message will arrive at its destination.

This arrangement can be likened to that of the U.S. Postal System. The
"user agent" here is anyone who receives mail at his residence. He can
throw some letters away, save others, reply to still others; those replies
can be composed in any language or format. The envelope, however, must be
addressed according to accepted standards, so that, when he drops it into
a mailbox, the "transport agent" - the post office -- can deliver it to
its intended destination.

Without the use of open-systems technologies and standards, the U.S. Postal
System would break down -- and so would a broad-based e-mail system. Three
principles apply to constructing an effective enterprise e-mail system:

1 ) an end-user application must be available to help the user compose
messages and manage his incoming mailbox:

2) a "messaging backbone" must be in place to move messages around the
organization's computer network and deliver them to their destinations;

3) the end-user application must be able to submit messages to the
messaging backbone for delivery, and access messages from the message
store once they have been delivered.

In the open-systems paradigm, each of these three components is completely
separate from the others, with which it communicates using standard
network protocols. Price, performance and feature set can be optimized
because the user can choose the best MUA, MTA and message protocols for
his needs, rather than being forced to buy a single package containing all
three. He can decide, for example, to acquire a new MTA but keep the old
MUA with which his user community is familiar. (This could be compared to
a company using Federal Express instead of the post office for all its
mail: individual users would still write letters in the same way, but
management would have to consider cost tradeoffs.) This approach alone
gives users the flexibility necessary to configure their networks
optimally for their specific mix of computers, networking hardware and
software, and application software.

Open-Systems E-Mail -- Not a New Paradigm After All

The "new" e-mail paradigm described above has existed for some time -- as a
peer-to-peer implementation in the classic UNIX environment. This approach
doesn't rely on a file-system-supported central message store. If user A
sends a message to user B, the message is actually sent from user A's
computer to user B's computer via a Mail Transport Agent.

This solution has emerged in UNIX environments simply because such
environments have provided a peer-to-peer model for electronic messaging,
a model long recognized to be scalable to large environments. Using
peer-to-peer communication for e-mail allows a network architecture to
avoid bottlenecks at messaging servers, if too many users are based on a
single server, the network topology can be dynamically reconfigured. This
architecture is so flexible that a message store can be anywhere, or
anything, from a single central repository to a separate entity on every
user's desktop. And this open-systems e-mail design is not restricted to
any one computer hardware or operating system configuration.

While an organization's end users may have PCs, Macintoshes, X terminals or
workstations at their desks, certain fundamental business operations
(e.g., inventory, payroll) require high-end databases that typically
demand the multitasking and multiuser support and security available only
on UNIX machines. Because of these and other business needs, UNIX -- along
with its complete integral mail transport mechanism -- has found its way
into many corporate environments. Once there, it is a natural choice for a
mail backbone server for the entire enterprise network. Using UNIX as the
backbone, all the "client" desktop computers can "talk" to the UNIX
servers through the common networking layer, TCP/IP, which is now regarded
as the de facto standard for networking in a multi-platform environment.

Mail Transport Protocols

The two most common mail transport protocols used today are X.400 and the
Simple Mail Transport Protocol (SMTP). Both specify local mail delivery as
well as intra-LAN and interLAN connectivity.

X.400

X.400, developed in 1984, has been positioned as the common e-mail
transport standard that might establish unity among the non-standard
LAN-based e-mail systems. The intent of its developers was to provide a
unified way to describe not only standard text documents, but other kinds
of binary data formats -- e.g., purchase orders, graphical data, database
documents.

Widely implemented in Europe on mainframes and other large systems, X.400
in the U.S. is used mostly by large organizations that require
connectivity between mainframes and PCs, but not to other networks or
operating systems. The PC arena, which evolved from the mainframe world,
has begun to embrace X.400 as LAN-based e-mail vendors have made their
first halting moves toward an MUA/MTA approach. But the presence of X.400
in UNIX environments is rare chiefly because SMTP, bundled with UNIX
systems since the 1970s (see below), became the standard UNIX e-mail
protocol.

X.400 is tainted by problems both technical and market-oriented. First, it
is so complex that no single implementation supports 100 percent of its
specifications (there are 1984, 1988 and 1992 versions of the protocol).
It has an overly complex addressing scheme. X.400 addresses are hard to
read and typically too long to remember; they require that the sender
either know which public telephone carrier the recipient uses, or go
through the cumbersome process of checking a directory service for that
information. Another issue is that of e-mail attachments: most X.400
transport agents today either implement only standard text messages or
support incompatible extensions that cannot interoperate with other X.400
servers. Microsoft, for example, is using X.400 in its Enterprise
Messaging System (EMS): but because there are no standards for identifying
document types as attachments, EMS must preserve existing proprietary
attachment specifications that only Microsoft Mail applications will be
able to read. Lotus is experiencing the same problem with its Lotus
Communications Server.

A key market obstacle to X.400's achieving critical mass is its absence
from the Internet, the worldwide computer network encompassing some 20,000
computers and 20 million users. The Internet uses SMTP as its native mail
transport protocol, and there is no indication that that will change.

SMTP and MIME

SMTP, initially funded by the government under DARPA, was derived as part
of a project involving a networking layer for UNIX using TCP/IP as its
lowest-level protocol. An extremely small and simple protocol, SMTP was
well designed for small and large computers alike. Since its appearance in
the 1970s as part of the Berkeley Systems Distribution (BSD) UNIX, SMTP
has been implemented on all types of computers and remains independent of
the lower-level networking protocol.

While standard SMTP does not support the exchange of non-printable ASCII
data, there is another standard that addresses this issue. The
Multipurpose Internet Mail Extensions (MIME) document describes how
information about multipart documents that include non-text data can be
sent through arbitrary transport agents. MIME-compliant user agents
convert such documents into ASCII format suitable for network
transportation and send them through SMTP without loss of data integrity.
With MIME, e-mail systems can be built on top of existing networks and
protocols and remain independent of the lower-level networking layer. But
MIME's biggest advantage is that it is dynamically extensible -- if a new
document type is introduced, the network doesn't have to be reconfigured,
and the transport and user agents do not have to be modified.

The SMTP/MIME combination makes an excellent basis for an e-mail
architecture. SMTP is simple, elegant, easily ported, independent of the
networking protocol, and free on UNIX machines, the accepted server
platforms for client-server computing (and thus the most apt choice for
providing an organization's messaging backbone). Adding the openness and
flexibility of MIME in the user agent, the user can build a power e-mail
system on any platform with minimal effort and expense.

The Most Functional E-Mail System for the Lowest Price

The configuration of the most optimally functional network at the best
price includes UNIX as the server platform, with TCP/IP and SMTP as the
messaging backbone. Desktop devices will be determined by the specific
needs of the organization, but any combination of PCs, Macs,
character-based ASCII terminals, smaller UNIX machines and X terminals is
possible.

In this environment, the cost of ownership of an e-mail system is driven as
low as it can be. The cost of the e-mail component is that of the client
e-mail software only. The user need purchase no mail transport. The need
for gateways is completely eliminated (unless there is a need to connect
non-"open" e-mail packages). As seen above, the cost of the messaging
backbone is fully absorbed in the already existing cost of having UNIX
servers in place to run the rest of the network and the business.

 ============================================================
 From the  'New Product Information'  Electronic News Service
 ============================================================
 This information was processed from data provided by the
 above mentioned company. For additional details, contact 
 the company at the address or telephone number indicated.
 OmniPage Pro is now used for converting all printed input! 
 ============================================================
 All submissions for this service should be addressed to:
 BAKER ENTERPRISES,  20 Ferro Dr,  Sewell, NJ  08080  U.S.A.
 Email: RBakerPC (AOL/Delphi), rbakerpc@delphi.com (Internet)
 ============================================================
