Serving Desktop Computers Using a Central Mail

1. Introduction
2. List of Protocols and RFCs
3. Other Sources of Information
4. Capabilities of Well-known mail clients
5. List of Implementations

Introduction

• Your desktop computer may be down quite a bit and less network bandwidth and less of the processing resources of the sending computer are used if the computer receiving your mail is ready to receive.
• Some people use more than one desktop computer to read mail.
• A desktop computer may not have the resources to store all the mail you receive.
• It can make your e-mail address more like other users

SMTP, the "internet" mail protocol used to deliver mail between multi-user systems only supports mail transfer initiated by the sender.
(to actually, it has a method to initiate reception, but the method didn't catch on and is not used).

Other protocols have been devised to allow a desktop computer to request transfer of mail, thus able to make use of a central server. These include the published protocols POP (probably not used anymore), POP2, POP3, IMAP2, IMAP3 (not used), IMAP4 and DMSP.

POP, POP2, POP3:

These are rather minimal and are designed to be so.
The three are similar but not enough alike to be interoperable. They are basically designed to identify the user by username and password, to transfer the mail from server to desktop computer and to delete the mail transferred. It is assumed that SMTP will be used to send mail.
Messages can be retrieved individually, but the only information you can get about a message without transferring it is its length in bytes-- useful for desktop computers with limited storage.

POP3 has a number of extensions including Xtnd Xmit which allows clients to send mail through the POP3 session rather than using SMTP.

Another extension is APOP which allows RSA MD5 encryption of passwords passed over the network.

POP3 is now the most-used POP, but POP2 is still used. POP3 has a couple of optional extensions: one to avoid sending passwords, and one to aid in reading bulletin boards.

IMAP2, IMAP2bis, IMAP3, IMAP4:

The IMAP family is similar to the POP family, but also gives clients a way to do string searches through mail that still resides on the server (though I've heard that this is little used). This is designed to allow the desktop computer to be more selective as to which mail will be transferred. The POP protocols, on the other hand, are designed for simpler server software.

IMAP2 is used quite a bit.

IMAP3 is an incompatible offshoot that has not been implemented much.

IMAP4 is a relatively recent extension of IMAP2 which makes the servers cognizant of the MIME-structure of a message.
IMAP2bis was the original name of IMAP4, which has since been refined, but there are/were some implementations of IMAP2bis that are not IMAP4 compliant. IMAP4 also extends IMAP to have many other features including some of DMSP's.

ACAP (Application Configuration Access Protocol), formerly IMSP (Interactive Mail Support Protocol), is a protocol which is being developed to compliment IMAP4 by offering related e-mail services beyond the scope of IMAP4. It includes the ability to subscribe find & subscribe to bulletin boards, mailboxes, and to find and search address books.

IMAP vs POP:

• as of this writing (10/96), there are a many more POP than IMAP client implementations and an Internet Service Provider is much more likely to provide POP3 service than IMAP4. But interest in IMAP4 is growing with big-time software houses announcing support. IMAP4 has more features, basically designed to support a model where users store their received mail on a server rather than on their own computer.
• The big advantage cited for IMAP is that people who "do e-mail" from different computers at different times have the same access to their message store from any of the client-computers they use.
• The cost of the IMAP model (aside from issues such as the complexity and the availability of implementations) is in running a server with sufficient space for the clients' message stores. With personal computer disks now often above a gigabyte (presumeably growing to 10s of gigabytes over the next few years) and multimedia messaging in our future, people storing e-mail on their own hard disk will have a lot of space and ways to use it. A central store serving 10-20 users will not be overly difficult, but one for 1,000 or 10,000 users will be very large (terabytes?) if it is to offer comparable space. The question comes down to the tradeoff between the advantage to users who computer-hop against the costs of managing the large amount of central store.

DMSP (aka PCMAIL):

desktop computers can use this protocol to both send and receive mail. The system is designed around the idea that each user can own more than one workstation; however, the system doesn't seem to handle the idea of a "public workstation" very well.
The desktop computers are assumed to hold state information about the mail, a directory so to speak, and when the desktop computer is connected to the server, this directory is updated to "reality".
Note: DMSP never gained the following of IMAP or POP and I've heard the software is no longer available.

Who uses these protocols? These protocols were designed and implemented mostly by Internet-connected universities with some participation by other Internet-connected research institutions. They were certainly devised to handle the type of electronic mail that universities must do. A typical site has probably 10 to 10,000 desktop computers and has an Internet connection and also runs Unix, giving them the Unix sysadmin expertise that makes running a Unix-based server attractive. Most of the servers listed here run under Unix though some run under other large systems and as time goes on, we are seeing more servers that run on PCs and Macintoshes.

Disadvantages: there are a number of disadvantages associated with the use of these protocols:

• since these methods do not dominate the industry, software using these methods is often incompatible with other useful and/or well-known software. A couple of examples are:
• Use of mail-enabled applications on desktop computers (there is no fundamental reason that mail software using these protocols can't provide the API used by mail-enabled applications, but in general this hasn't come about yet)
• Use of the usual Unix mail readers & the Unix .forward files.
• since the server is holding mail for the person, the person can use the server for storage. This leaves the potential for all the disk-space problems inherent in shared disks: people hogging disk-space or forgetting to clean up, etc.
• sizing the server: a perennial question people ask is "How big a machine do I need to serve my campus (or department, or whatever)".

Naturally no one can give a straight answer because it depends upon so many factors.

Issue of Remote Access: Modern commercial e-mail packages typically have features designed to assist in remote access of ones e-mail. Features include:

• ability to download mail through a modem
• ability to synchronize two different systems which you are using to read your e-mail by plugging them together.

Also, any LAN-based method can be used by using one of the several methods of providing the same protocol support over dialup lines as are on LANs (SLIP or PPP for the above-mentioned, TCP/IP-based protocols, ARA for Appletalk-based protocols, etc, and sometimes using two different protocols, one incapsulated in the other) under the constraint that any operations that use the network will be much slower. Also, POP3 is often used directly over modems (for example, Eudora can be used in this manner).

The ideal protocol for remote access would not penalize the user for the much slower communications speed (usually slower by a factor of 100: note that a lot of LAN-based software was written without regard to minimizing the necessary communication, thus is really hurt by such slow speeds), yet would allow the same software to run both remotely and locally, with a wonderful user interface. It would also not be overly expensive in communications equipment or services.

This is a difficult set of objectives and the above-three protocols can achieve some of them for some users, but what they actually achieve depends a lot on the user's pattern of e-mail usage.
If a user reads just a small amount of mail, then we would not worry about the length of time necessary to download it remotely with POP3, but if the person receives a lot of mail, but just wants to read a small amount of it at home, then with IMAP2, they could pick and choose what to read, eliminating some download time. If someone is paying for the telephone line time (possibly the user if it is a long distance call; in any case, the institution pays a monthly fee for each line it offers, which is dependent upon how many users it is serving, how often they call, and how long their calls are) then IMAP2's natural method of usage which requires the phone call to remain while a user is reading, poking around, sending, and rearranging mail can be much more costly than using POP3 if one call is used to quickly download all the mail and another later call is used to send any replies. Thus with POP3 a user might have two 1 minute calls before and after a 30 minute e-mail session instead of keeping the call for 30 inutes with IMAP2, and each phone line the institution offers could be serving 15 times as many such users who would each pay a lot less in long-distance phone bills. Note that with the advent of multimedia mail (see MIME below) whose messages can be very large, it is possible that downloading even one message that you end up not reading remotely could ruin such a nice-sounding scenario. MIME: MIME (Multipurpose Internet Mail Extensions) is a relatively new Internet standard for the format for messages with multiple parts, and with non-ASCII data. Any client that can import or export files can use MIME in a clumsy way if you have a program to create and/or decode a MIME message. Some clients have built-in features to do this.

Client-server mail protocols generally only deal with entire messages, and can retrieve MIME messages as well as any other messages since MIME was carefully designed to be transparent to existing mail systems.
However, IMAP4 has features to allow retrieval of individual parts of MIME-encoded messages. The chart below lists whether a package has MIME support. Servers for protocols that don't offer any special MIME features are marked na for Not Applicable since they need do nothing for users to use MIME. All IMAP4 servers can also do this, but the chart lists whether they include explicit MIME support.

Approaches not covered by this memo: proprietary protocols; file sharing; APIs; X.400. Vendors can invent their own protocols similar to those listed above, and some have.

LAN e-mail can also be implemented using file sharing, e.g. using NFS to allow separate Unix workstations to share the same mail spool area just as if it were mail being stored on one system, or using Novell's SMF (Simple Message Format) in a Novell file server. If the applications are written so that they are careful to lock files correctly, then this works. An advantage is that any network file protocol can be used and the e-mail application can be somewhat independent of the file protocol.

For example, Unix systems could use either AFS or NFS. Pegasus is a PC & Mac application that uses Novell file service to do something similar.
Specifications for client-server interaction consist of the file service protocol along with the server directory structures & conventions used for storing e-mail.

A very popular approach with commercial vendors is the use of APIs.
The client talks to the server using an API (Applications Programming Interface), i.e., a set of subroutine/procedure library call definitions for a library providing subroutines/procedures to send, receive, and manipulate e-mail. With the use of any remote procedure call mechanism, the client can be located on a different computer from the server. This allows some mixing and matching of RPC mechanisms, underlying protocol stacks and APIs: e.g., a vendor defines an API, and it can be run over IPX or TCP/IP, in each case over the protocol stack's RPC mechanism. There are a number of APIs now being pushed by vendors:

• MAPI (Microsoft)
• VIM (Lotus)
• AOCE (Apple).

Note that though the API approach in combination with remote procedure calls allows one to implement client-server e-mail without the use of the protocols covered by this document (IMAP, POP, etc), that there is no theoretical reason why such APIs can't be used in an IMAP or POP environment. The necessary software would be a "driver" or piece of "middleware" that provides the APIs calls to mail-enabled applications and uses POP, IMAP, or whatever over a LAN to reach a server. The advantages/disadvantages of such an approach as compared to the use of RPCs is open to debate.
UniPalm's Mail-IT is an example of client software that provides MAPI within the client and uses POP3 to access the server.

X.400 is the message transport defined for use between telecommunications vendors and customers by the international consortium of national standards bodies known as ISO. It roughly corresponds to TCP/IP's SMTP and RFC822 header format. A consortium of X.400 vendors (XAPIA) have developed an API for X.400 applications called CMC.

LDAP: a protocol (the Lightweight Directory Access Protocol) being incorporated in some clients as an Internet way for the client to get information about e-mail addresses from a server, i.e. to give you the capability to type in someone's name and have the mail client software retrieve the address from a server-based directory. LDAP also has other uses. There are plans to incorporate LDAP clients into some IMAP and POP clients. LDAP is essentially an Internet-based, simplified X.500-like protocol and one of the original intentions of its creators was to be gatewayed to X.500, thus giving relatively simple Internet clients access to X.500 servers.
Both LDAP and X.500 provide a method for naming, retrieving, and searching fields in a directory, but do not define the field-names or what is supposed to go in the fields.
Thus server/client interoperability requires further conventions.

Java: a programming language currently (1996) touted as a tool for web-based applications. It can affect the use of LAN protocols in a number of ways: first of all, POP or IMAP clients can be written in Java, using its cross-platform development capabilities to create version for a number of platforms. Second, clients could be written as "Applets", i.e. applications designed to be downloaded into web browsers such as Netscape from a server. With such a design, a user would only need access to a web browser to see their e-mail, e.g. drop into a library and see your e-mail from one of its Internet-browser kyosks. Applets are not normally allowed to access the client-machine's disk files (which would result in too much risk when browsing the Internet from the kind of people who develop computer viruses), so such an application fits a little better into the IMAP model (server storage of e-mail folders) than the POP model (client storage of e-mail folders). Thirdly, Applets enable more practical use of e-mail clients that use non-standard protocols rather than POP or IMAP; interoperability is achieved because the server itself distributes a compatible client applet right when the user accesses the server.

List of Protocols and RFCs

Name: Simple Mail Transfer Protocol
Nickname: SMTP
Document: RFC 821 (Postel, August 1982)
TCP-port: 25
Status: Internet standard (STD 10)

Name: Post Office Protocol, Version 2
Nickname: POP2
Document: RFC 937 (Butler et al, February 1985)
TCP-port: 109
Status: Functionally replaced by incompatible
POP3 but still used some

Name: Post Office Protocol, Version 3
Nickname: POP3
Document: RFC 1939 (Myers & Rose, May 1996)
TCP-port: 110 (109 also often used)
Status: In use, standards track
Sites: UC Irvine, MIT

Name Post Office Protocol, Version 3
Authentication command
Nickname: POP3 AUTH
Document: RFC1734 (Myers, December 1994)

Name: Post Office Protocol, Version 3 Extended
Service Offerings
Nickname: POP3 XTND
Document: RFC 1082 (Rose, November 1988)

Name: Distributed Mail Service Protocol
Nickname: DMSP, Pcmail
Document: RFC 1056 (Lambert, June 1988)
TCP-port: 158
Status: Used very little
Sites: MIT

Name: Interactive Mail Access Protocol, Version
2
Nickname: IMAP2
Document: RFC 1176 (Crispin, August 1990)
TCP-port: 143
Status: In use, being replaced by upward-compatible IMAP4
Sites: Stanford, U Washington

Name: Interactive Mail Access Protocol, Version 2bis
Nickname: IMAP2bis
TCP-port: 143
Status: Experimental, but in use, being replaced by upward-compatible IMAP4

Name: Interactive Mail Access Protocol, Version 3
Nickname: IMAP3
Document: RFC 1203 (Rice, February 1991)
TCP-port: 220
Status: Historical, not used
Sites: Stanford

Name: Internet Message Access Protocol, Version 4
Nickname: IMAP4
Document: RFC 1730 (Crispin, December 1994)
TCP-port: 143
Status: Being implemented, Standards track
Sites: U Washington
Related: RFC 1731 (Myers, December 1994),
RFC 1732 (Crispin, December 1994),
RFC 1733 (Crispin, December 1994)

Name: Interactive Mail Support Protocol
Nickname: IMSP
Document: Draft RFC: ? (Myers, June 1995)
TCP Port: 406
Status: Experimental, renamed ACAP
Sites: Carnegie Mellon

Name: Application Configuratino Access Protocol
Nickname: ACAP
Document: Draft RFC: ? (Myers, June 1996)
Status: ?
Sites: Carnegie Mellon

Also, Internet drafts are available at ds.internic.net, munnari.oz.au, and nic.nordu.net in directory internet-drafts. IMAP2bis is essentially an early version of IMAP4.

Other Sources of Information

http://web.syr.edu/~jmwobus/internet/

Web information on IMAP: http://www.imap.org

Web information from University of Washington: http://www.washington.edu/imap/