Article: Internet Mail, POP3 and the cc:Mail System

The following document compares Internet SMTP (Simple Mail Transfer Protocol) and POP3 (Post Office Protocol) e-mail technology to the cc:Mail e-mail system from Lotus Development, a division of IBM.

While there are over 10 million cc:Mail licenses in circulation today, there are perhaps 2 to 3 times as many combined SMTP users and POP3 clients across the Internet and on corporate intranets. Generally, POP3 is harder to manage but reliable, and low maintenance. The cost of ownership for SMTP/POP3 solutions is much less than for LAN-based e-mail systems. Generally, POP3 systems are scaleable and perform well compared to systems such as Microsoft Exchange, cc:Mail in a Mobile configuration, or Lotus Notes. On the other hand, the advantages of POP3 stem from it's architectural simplicity. In terms of features and flexibility in configuration, cc:Mail is a clear winner. The cc:Mail system sports network and server independence, data transparency and file attachment handling across platforms, a variety of protocols, and a stable of features and functionality both at the back-end of the system and in the user mail applications.

In any e-mail system there is a message store. The message store may be centralized, distributed, or a mixture of the two. It may be encrypted for reasons of security or messages may be clear text.

In LAN-based e-mail systems, the message store tends to be more or less centralized. In SMTP and POP3, there isn't a single message store. POP3 relies on an underlying SMTP system. In SMTP, messages are written to a mail file stored in each user's home directory.

In POP3, messages are downloaded to each user's workstation, therefore, the data are distributed rather than centralized. Users may optionally delete messages from the server when they are downloaded. Messages are typically stored in BSD mail file format, although this is not technically necessity. Storing messages in separate files can be less efficient than storing them in a single database.

In cc:Mail, the message store is centralized in the form of a 'post office'. Actually, the cc:Mail post office is a database in which message data for all users is stored. Users of cc:Mail Mobile products can be configured as fill-time or part-time Mobile users. If they are full-time Mobile users, messages are deleted from the post office when they are downloaded, otherwise the original messages are retained in the post office.

DUPLICATION OF MESSAGE DATA

In SMTP and POP3, as in MHS, a unique copy of each message is created for each recipient. This is wasteful of resources although it does create a crude type of redundancy.

In the cc:Mail system, there is no duplication of message data within a given post office. Correspondingly, there is no redundancy of message data for multiple recipients, although there is minimal redundancy of data used to generate index structures that refer to message data.

MESSAGE FORMAT, ENCRYPTION AND SECURITY

In SMTP and POP3, the format of message data is ASCII text. At the server, security is provided by the underlying operating system, typically UNIX. Although encryption of message data or of the underlying transport is possible, SMTP and POP3 mail is usually transmitted in the form of clear text, although POP3 may be implemented using underlying Kerberos, or S/Key encryption.

Encryption is possible for messages in transit through SMTP side using S/MIME or PGP. However, virtually no POP3 e-mail client applications support either of these standards.

Similarly, POP3 message data is typically stored in an unencrypted form at the user's workstation. Although the application may require a password to access a user's mailbox, in most cases it's possible to read a user's messages with an ordinary text editor. This latter fact, is commonly demonstrated to Lotus customers who have expressed an interest in POP3.

SMTP is notorious for it's general lack of security and every UNIX administrator knows how to telnet to the SMTP port of a host (TCP port 25) and enter in a message that can be to any valid address and that can appear to be From anyone. To be fair, this is mainly a problem in Berkeley sendmail and is prevented in other implementations of SMTP, although sendmail is the most widely used SMTP mailer.

In the cc:Mail system, the message store is encrypted. This also applies to the cc:Mail Mobile products, where, like POP3, message data is stored on a user's workstation. Data are also encrypted during transmission, and a secure negotiation protocol (introduced with Router version 5.13) prevents unauthorized exchanges.

DIRECTORY SERVICES

There are no directory services in SMTP. New POP3 mail implementations, however, support the Lightweight Directory Access Protocol (LDAP), which allows them to access X.500 directory services. However, this is a recent development and an emerging technology. Historically, POP3 mail applications have had minimal directories. Also, SMTP and POP3 have not in the past had any mechanisms for the distribution, update and synchronization of directory information. This can be expected change in the future.

cc:Mail provides it's own directory as well as mechanisms for distributing, updating, and synchronizing this information across post offices and with users of cc:Mail Mobile products. cc:Mail addresses are relatively simple in structure consisting of an ordinary user name, such as "John Valentine" or Valentine, John, and a post office name, such as "SILVER-HQ." Although in some ways this simplicity makes cc:Mail easier to administer and to use, it is also limiting. Mainly, identical or 'duplicate' names are not supported within a given post office. This limitation impacts the practical size of post offices. This limitation will be removed in future versions.

Of course, in every system, uniqueness comes into play at some level. In a traditional SMTP or POP3 scenario, every user name on a given server or host must be unique. Further, since these systems are commonly UNIX-based, typical UNIX naming conventions often apply. Generally, these addresses are less flexible than those allowed in cc:Mail. Of course, aliases can be used to create user-friendly e-mail addresses, but the management of these aliases is usually through a text editor interface whereas in cc:Mail, aliases are supported in the cc:Mail directory which is indexed for efficient searching by the cc:Mail Administration software as well as by the cc:Mail Router -- the rough analog of the UNIX sendmail daemon.

EXTERNAL E-MAIL ADDRESSES

In SMTP and POP3, there is no built-in mechanism, other than aliases, to support non-SMTP e-mail address formats. The cc:Mail directory, on the other hand, may contain various types of directory entries both internal to cc:Mail and those belonging to other e-mail systems, including SMTP.

TRANSPORT MECHANISMS AND PROTOCOLS

In SMTP and POP3, an SMTP daemon transfers mail between hosts, while a POP3 server transfers messages to the user's POP3 mail application. The SMTP and POP3 protocols are verbose protocols using TCP/IP. In the POP3 scenario, messages are usually, deleted from the server when they are downloaded by the user.

The cc:Mail system is network operating system (NOS) independent and will work with virtually any LAN and file server. In this sense, cc:Mail is protocol-independent. Communication may take place directly between Routers, or between a Router and cc:Mail Mobile, using modems, or using any of several supported network protocols, including TCP/IP. Like POP3, messages can be deleted or left of the server when they are downloaded by the user. In an all-Mobile installation of cc:Mail, message data is distributed, just as it is with POP3. However, in the cc:Mail scenario, the file server-based post office acts as a centralized management facility for the system. It's also worth mentioning that cc:Mail R7 will support both POP3 and IMAP4 protocols for transparent integration with POP3/IMAP4 systems.

INTERNET STANDARDS SUPPORT AND SECURE MESSAGE TRANSPORT

POP3 is non-proprietary and is 100% compatible with the de facto Internet standards -- the Requests for Comment (RFCs). However, there is only one transport and a network connection of some type must be available. This is not necessarily a disadvantage since dial-up networking solutions are increasingly popular and PPP, which can support TCP/IP protocols, has already become the de facto dial-up networking standard.

Internet standards are alien to cc:Mail. As with other LAN-based e-mail products, cc:Mail requires 'gateways' to communicate with SMTP and to handle MIME attachments. Historically, this has been a limiting factor, although at this point e-mail gateway technology is well understood. Actually, Lotus' current SMTP gateway product for cc:Mail does not support MIME, although several 3rd party products do. Nevertheless, the performance, reliability, and robustness of Internet gateways for cc:Mail has increased steadily. At the same time, cc:Mail has built-in support for TCP/IP and offers an X Windows product and a World Wide Web server.

Although cc:Mail is generally protocol-independent, it does use its own higher-level protocols, just as POP3 and SMTP run on top of TCP/IP. In the cc:Mail system, the underlying protocol is interchangeable. The higher-level cc:Mail protocols are proprietary and secure. For this reason popular Internet security standards such as PGP, or SSL, are not directly meaningful to cc:Mail. They are only relevant when cc:Mail is interfaced with Internet or when using World Wide Web protocols to access a cc:Mail post office (the cc:Web server product emulates the features of cc:Mail user mail applications using a web browser).

The cc:Mail system also supports protocols other than TCP/IP, including Novell SPX, IBM APPC, and Banyan SPP, in addition async, and X.25 transports. No POP3 mail system sports such an array of protocols but this is of little importance in most POP3 environments where the mainstay of protocols is TCP/IP.

CROSS PLATFORM FILE-ATTACHMENTS

The cc:Mail system handles cross-platform file attachments transparently. In the traditional post office model, interoperability across platforms is provided by the NOS. Data transparency, is built-in. This includes file attachments handling. A standard such as MIME is, therefore, not meaningful within the cc:Mail system itself. It is only relevant when connecting a cc:Mail system to an e-mail system that supports MIME, mainly Internet mail.

CENTRALIZED MANAGEMENT AND ADMINISTRATION FACILITIES

One of the main issues with SMTP and POP3 is centralization of administration and management. On the one hand, many more users per server can typically be supported with SMTP and POP3. On the other, the main administration tools are usually standard UNIX administration facilities. In other words, there really aren't any administration tools for the e-mail system as such. To be fair, the system maintains itself fairly well and no time-consuming maintenance and repair procedures are necessary (the latest version of cc:Mail's database also maintains itself in 7x24 operation).

Other issues include public mailing lists and shared bulletin boards. Once again, in SMTP and POP3, there is no centralized management facility as such, no public mailing lists, no shared bulletin boards.

In the cc:Mail system, there is full centralization of directory management, public mailing lists, and shared bulletin boards across post offices. In an all-Mobile configuration, which is closely analogous to POP3, cc:Mail supports distribution of shared bulletin boards to users and users can access public mailing lists through the cc:Mail directory.

For POP3 systems, administration must be done by a system administrator. Users cannot perform routine functions such as updating mailing lists or adding a user to a bulletin board propagation list. With cc:Mail, specific administrative rights can be delegated to users.

CC:MAIL MOBILE AND POP3 APPLICATIONS COMPARED

In the cc:Mail system, the cc:Mail Mobile application is closely analogous to a POP3 mail application. In the cc:Mail scenario, a cc:Mail Router transfers messages to the user's cc:Mail Mobile application, where, like POP3, the message are stored locally on the user's workstation.

Like users of POP3 mail applications, users of cc:Mail Mobile have the ability to work off line, although unlike POP3 applications, Mobile users have a broad choice of transports. In fact, several communication methods may be configured in the cc:Mail Mobile application. In the TCP/IP scenario, cc:Mail Mobile can communicate with a cc:Mail Router via TCP/IP over a LAN or over a dial-up network connection including communications across the Internet.

THE FUTURE OF POP3

Newer standards, such as MIME and IMAP, extend both SMTP and POP3 mail in general, adding enhanced security to POP3 and sophisticated file attachment handling to both SMTP and POP3 (technically, IMAP4 obsoletes POP3). Vendors such as NCD (Z-Mail), Qualcomm (Eudora), and Netscape (Netscape Mail) are systematically enhancing their implementations of POP3 mail. These vendors are targeting two markets: 1) individual Internet users who look to Internet and especially World Wide Web as the ultimate on-line service; and 2) corporate customers.

Historically, corporate customers have shunned Internet mail on their internal networks because of its many historical limitations and weaknesses, especially in terms of security, administration and file attachment handling. Remember that in SMTP, there are no file attachments as such. Corporate customers have favored more secure proprietary network operating systems and LAN-based e-mail products, until now.

THE FUTURE OF CC:MAIL

Historically, cc:Mail's forays into the UNIX/Internet arena have consisted of e-mail gateways for SMTP and UUCP and the cc:Mail for UNIX/X Windows product. At this point, TCP/IP-based installations of cc:Mail Mobile and World Wide Web are important strategic directions for cc:Mail. It's also worth mentioning that cc:Mail's upcoming SMTP gateway will support MIME. LAN-based e-mail has in the past been feature rich and offered superior directory and administration facilities. Moving forward, we can expect to LAN-based e-mail products extending this legacy into the Internet arena.