IMAP

Originally developed at Stanford in 1986,

IMAP stands for Internet Message Access Protocol. It is a method of accessing electronic mail or bulletin board messages that are kept on a (possibly shared) mail server. In other words, it permits a "client" email program to access remote message stores as if they were local. For example, email stored on an IMAP server can be manipulated from a desktop computer at home, a workstation at the office, and a notebook computer while traveling, without the need to transfer messages or files back and forth between these computers.
IMAP's ability to access messages (both new and saved) from more than one computer has become extremely important as reliance on electronic messaging and use of multiple computers increase, but this functionality cannot be taken for granted: the widely used Post Office Protocol (POP) works best when one has only a single computer, since it was designed to support "offline" message access, wherein messages are downloaded and then deleted from the mail server. This mode of access is not compatible with access from multiple computers since it tends to sprinkle messages across all of the computers used for mail access. Thus, unless all of those machines share a common file system, the offline mode of access that POP was designed to support effectively ties the user to one computer for message storage and manipulation.

Thus IMAP is a Mail Access Agent which manipulates a user's incoming mail and stored mail folders on his behalf. It does not send mail.

Our mail system uses the Dovecot Server running on the mail hub at gpo.stanford.edu.

How IMAP Works

The IMAP protocol consists of commands and responses sent between a client and server. Normally this is done over a network connection established at TCP/IP port 993 for encrypted connections, however, it could also be done by invoking the server locally and talking to it over the STDIN and STDOUT file descriptors.

Since the IMAP server wants to act as the agent of a specific user, it assumes that users identity thereby limiting itself to resources that that user can access. For network connections, the server authenticates the user by checking a userid and password. A locally spawned server simply executes as the user who spawned it and considers that connection preauthenticated..

Communication with the server is via character string commands. Each command consists of a tag, the command, and possibly some operands. For example:

A0001 LSUB "Mail" "*"
asks the server to return the list of subscribed mail folders in the directory Mail tagging its response with A0001.

IMAP Folders and Subscriptions

The IMAP server looks for folders relative to the user's home directory. You must configure your mail client to tell it which directory holds your stored mail. Each file in a directory is assumed by the server to be a mail folder in Maildir++ format. Since some servers support folders which contain both subfolders and messages, this choice may be presented to you by a mail client. Our server does support this.

The IMAP server always refers to the inbound mailspool by the distinguished name INBOX no matter what that file's actual name is (in our system, it is ~/Maildir. The INBOX is always monitored for new messages.

An IMAP subscription is a list of mail folders that you want to access from your clients. The IMAP server stores your subscription in a file on the mail server in ~/Maildir/.subscriptions. This file contains a list of Unix paths to the folders in the subscription.

Secure IMAP

The IMAP server is only accessible over the net via secure imap (imaps) at TCP/IP port 993. The client identifies the user via a login/password. We do not use client certificates.

Some mail clients will offer to remember your password in order to make subsequent logins automatic. To do that, the client must store your password on your computer. Most clients disguise the stored passwords, but if a hacker were to gain unfettered access to the machine, your password could be compromised.

Some clients will permit you to tunnel a connection to the mail server via ssh to run /etc/rimapd as a locally spawned IMAP sever. You can use this method to subsitute the ssh key authentication mechanism for the userid/password authentication above although, once again, if you choose not supply an ssh passphrase, your ssh identity is subject to the same vulnerabilities as any stored password above.

IMAP Namespaces

The IMAP design permits the server to provide access to services other than mail such as internet news and anonymous ftp. It does so by reference to auxilliary Namespaces. We do not offer any of these services.