IMAP serves next generation of e-mail

by David Kosiur

June 15, 2001 —

POP, the Post Office Protocol, has been the
long-standing mail retrieval protocol for TCP/IP networks. But it's
started showing its age at a time when users are becoming more mobile,
accessing mail servers from a variety of locations, often using more
than one computer. And the shift from text-only e-mail to complex
messages containing graphics and multimedia attachments has further
strained the capabilities of POP.

New protocols are needed. One likely candidate is IMAP, or Internet
Message Access Protocol. Implementations of this protocol are finally
moving out of academic environments and other test beds to broader
commercial support, making it possible for corporate messaging systems
to shift to IMAP.

IMAP has been designed to pick up where POP left off, offering new
advantages. For instance, IMAP lets you routinely store your messages
on a central server and only request the messages you want to store
locally on their desktop or laptop computers. Additionally, IMAP
users can perform more manipulations on their messages at the
server, either by storing them in archive folders, requesting only
parts of a message, or sharing a mailbox with other users.

Let's take a closer look at how the two e-mail systems work.

Models of client/server e-mail

Both POP3 and IMAP4 (the latest versions of POP and IMAP, respectively) are protocols for handling
e-mail access. They each depend on another protocol, SMTP (Simple
Mail Transfer Protocol), for sending mail. To see some of the
differences between POP and IMAP, let's review the three basic
models of client/server e-mail--offline, online, and disconnected
use.

The offline model is the most popular form of
client/server e-mail, and is used by protocols such as POP3. In this
model, a client application periodically connects to a server,
downloads all pending messages to the client machine and then deletes
these messages from the server. You process all of your mail locally on
your client computer.
The online model is most commonly associated with
remote filesystem protocols, such as NFS. In this model, a client
application manipulates mailbox data on a server, maintaining a
connection throughout the session. The client stores no mailbox data
and only retrieves data from the server as needed. You cannot do
anything with your messages if you're disconnected from the server.
The disconnected user model offers a hybrid of the
offline and online models. In this model, a user can download some set
of messages from the server, manipulate them offline, and then upload
the changes at some later time. The server is again the main repository
of the messages.

POP: A brief review

As mentioned, POP is the Internet's most popular e-mail
retrieval protocol today. It's a relatively simple protocol to
implement, and there are many client packages available for a variety
of computing platforms, including Unix, DOS, Windows, and Macintosh.

POP was designed to operate mainly in the offline mode and uses the
"store-and-forward" paradigm for handling your mail. You use your POP
client to connect to a mail server (the "store") and download all of
the pending mail to your own machine ("forwarding" the mail to your
client machine). Anything you do afterwards with your mail is
reflected only on your client machine, not on the server. And if you
use more than one machine to check your mail with POP, you won't be
able to check and cross-reference other messages you've saved on
other machines.

POP can be invoked to leave messages on the server after you download
them, but that depends on using a remote filesystem protocol on the
server. And if you have a multipart MIME message, you're still forced
to download the entire message and all its parts, unlike IMAP.

There are no provisions for sharing mailboxes or messages; if you
want someone else to see a message you've received, they either have
to be on the original list of recipients (as a "cc," for example) or
you can forward the message to them.

The POP protocol does offer one possible advantage over IMAP when it
comes to server resources. Since you're downloading messages to your
client machine with POP, there's no need to consign the server's disk
capacity to storing your old messages. Of course, there's the
downside--you're now personally responsible for archiving your old
messages.

IMAP's features

While IMAP can handle offline processing of mail, its strengths are
in online and disconnected operation. In the online mode, mail is
processed in an interactive fashion. You can use the client
application to ask the server for only message headers, and then
request only specified messages, or even parts of certain messages.
For example, if you're on the road checking your mail using IMAP,
you have the luxury of leaving large messages on the server, or you
could decide to download a co-worker's comments about your latest
presentation, but leave the edited MPEG movie that's another
message part on the server until you return to the office.

Another IETF standard used in both e-mail and the World Wide Web is
MIME, or Multipart Internet Mail Extensions. MIME provides a
systematic way of identifying the data in the body of a message so
that the mail client software can automatically decide what to do
with it. In addition, MIME allows single e-mail messages to include
multiple components, or body parts. Each body part can have a
different type (text, image, audio, for example) and a subtype
assigned to it. The subtype provides an added description of the
data, to help determine what external application can handle it. (Using Sparkle to play an MPEG video file, for example).

IMAP's ability to present the user with a review of message headers
and attachments before downloading from the server integrates well
with MIME. You can use your IMAP client to check the sizes and types
of each MIME body part before downloading, ensuring that you copy the
text of a message to your laptop, but leave the attached 2-megabyte
multimedia presentation on the server, for example.

Another IMAP feature is shared mailboxes. Shared mailboxes are
nothing more than a server-based mailbox file with multiple-user
access. The IMAP server takes care of resolving shared access to the
mailboxes and messages. A workgroup could share a mailbox with
minutes of their meetings, for example, or different co-workers
manning a help desk could access and process messages from the same
mailbox. Down the road, shared mailboxes could form the
foundation for message-based groupware, particularly if you factor in
server-based processing of IMAP mail and Java applets within messages.

IMAP does have a few potential disadvantages, though. Because IMAP
clients offer the user more flexibility in picking and choosing which
messages are to be copied to his computer, sessions can be longer
than with POP as users review their mail headers and select the
messages or body parts they desire. But if you're dealing with
large multipart messages, IMAP's ability to leave large messages or
parts on the server can save you from large download times while
you're on the road.

Also, since messages are left on the server until deleted by the
user, server storage may be strained by users that are reluctant to
delete past messages, or simply forget to do so routinely. On the
other hand, servers usually have more routine, robust backup
procedures, helping guard against lost mail, should the client
machine crash.

Maturing the market

Schools such as the University of Washington, Carnegie Mellon
University, Stanford University, and the University of North Carolina
have been using IMAP for e-mail for several years. However, only recently
have commercial software developers begun to offer IMAP servers and clients. Control Data Systems, Esys
Corp., ICL's Teamware Group, and Innosoft now offer
commercially-available IMAP servers, with more on the way.

Between March and mid-July, SunSoft had been offering a downloadable
beta of its IMAP4 message server for the Solaris operating system,
called the Solstice Internet Mail Server. According to Roger Nolan,
Group Marketing Manager for Enterprise Products at SunSoft, more than
4,000 copies of the beta server and more than 6,000 copies of the
free IMAP client were downloaded during this trial period.

The 1.0 version of Solstice Internet Mail Server is now shipping at
a single unit price of $995. The Server includes support for IMAP4,
POP3, SMTP, and MIME, and ships with MS Windows DLL, which allows
Microsoft Mail client software to work with an IMAP4 mail server.
Roger Nolan pointed out that this product is aimed at providing
corporate clients with "reliable, scalable enterprise-wide e-mail
solution that utilizes open standards" and predicted that the next
major version, due out later this year, would include improved server
scalability (for 10,000s of users) and roll in support for Solstice
Workshop for management and Java for added functionality.

To help drive the use of IMAP, SunSoft is also offering free,
unsupported IMAP4 clients for Windows 3.1, Windows NT and Windows 95
as well as Solaris SPARC and Solaris x86 (versions 2.4 and greater).
These clients can be used with either the Solstice Internet Mail
Server or other IMAP servers. Sunsoft's planning to offer Solaris and
MS Windows clients with more features and SunSoft support sometime
this fall. SunSoft is also working with Esys on offering added IMAP4
clients for MS Windows and Macintosh platforms.

Other IMAP servers are on the way as well. Software.com and
Netscape have both announced intentions to offer
IMAP4-compatible messaging servers later this year. Netscape's
announced that their Navigator 4.0 client, due out before the end of
1996, will include support for IMAP4. Version 2.0 of its Mail
server will include IMAP support; a beta of the mail server is now
available for evaluation at Netscape's Web site.

Since IMAP is a relatively new messaging protocol, particularly in
the commercial marketplace, users may well be wary of the
interoperability of IMAP servers and clients. The Internet Mail
Consortium is currently planning MailConnect 1, an interoperability
testing event for MIME and IMAP. It's tentatively scheduled for
August 13-14 in San Jose, CA; check its Web site for more
information.

Unix Insider