IMAP stands for the Internet Mail Access Protocol, a remote mail retrieval and archival standard originally developed at the University of Washington. It is an alternative to POP3 as a way to serve mail from users' mailboxes.

The difference between POP3 and IMAP basically comes down to where the user's mail is stored. With POP3, the user's mail is usually downloaded to the user's own desktop. With IMAP, the user's mail usually remains on the server.

Consider the post-office metaphor. With POP3, the user goes to the post-office, opens her post-office box, takes custody of all her mail, and leaves the post-office box empty.

With IMAP, the user goes to the post-office, opens her post-office box, looks at the mail, and then leaves it all sitting there in the mailbox.

From the point of view of the post-office, IMAP is pure evil.

The protocol is complex, described over the course of numerous RFCs. The complexity leads to variations in interpretation, and no two IMAP implementations will behave in exactly the same way. In addition to the complexity of IMAP itself, a number of popular email clients have buggy implementations of IMAP, and IMAP servers have to work around them.

It should come as no surprise then that Bernstein --who can barely tolerate SMTP-- has completely disregarded IMAP. So, if we want IMAP along the djb way, we have to look for other developers.

Fortunately, some brave programmers have stepped up to the challenge and taken their best shot. If you've just gotta have IMAP, this section includes a look at a few servers to consider. The common denominator here is support for serving from Maildirs.