Using IMAP on Mac OS Xby Jason McIntosh
IMAP or POP? Which is the best mail protocol to use on your Macintosh? This IMAP primer will help you understand its benefits and limitations, especially when using the Mail.app client on Mac OS X.
Most modern email clients, including Mac OS X applications such as Apple's own Mail.app, Qualcomm's Eudora, or Microsoft's Entrourage, all default to using the same mail transfer protocol: the venerable Post Office Protocol, more commonly known as POP. POP defines a simple set of instructions that lets users connect to a mailhost account, download new mail, and then disconnect. Nearly every ISP's mailhost supports POP, so it's a safe choice for mail-fetching client applications to support as well.
More recently, an alternative protocol known as the Internet Message Access Protocol (IMAP) has been steadily gaining popularity and support from Internet providers. IMAP contains a more sophisticated command set that allows users to store and organize mail on the server, instead of simply downloading and deleting it.
IMAP gives the most benefit to people who connect to a mailhost using more than one computer, since an IMAP-enabled mail account will look the same on all these machines, from overall mailbox structure down to the status of individual messages, and any changes made to a mailbox on one machine become visible to the rest.
This article provides an IMAP primer, focusing on receiving email though IMAP on computers running Mac OS X. It assumes you have some familiarity using Apple's mail application, or can at least fake it.
Before getting into Mac specifics, we'll look at IMAP's primary features, comparing them to those of the more familiar POP.
POP has been with us in its present form since the early 1990s. This protocol defines very few commands; just enough for a client to authenticate a user with a mail server, download all new mail from the server to the user's computer, and then bid the server adieu.
Most of the time, a client will clean up after itself by having the server delete all its new messages once they've been safely downloaded to a local hard disk. In other words, a POP client usually treats the server like a physical mailbox, letting it hold mail for only as long as it takes for the recipient to arrive and empty it out.
In this way, POP lets you read mail with minimal connection time. Because a POP client always downloads mail messages in their entirety to a user's local machine, one can then disconnect from the Internet and browse new mail offline, going back online only when it's time to send replies and check for more new mail.
POP3's simplicity won it fast adoption across the Internet, but its disadvantages also lie in this simplicity. For one thing, it makes fetching mail an all-or-nothing proposition. If someone mails you a 50-megabyte attachment with an email, for example, you can't choose to download it later (or not at all); you must swallow it with the rest of the mail you're downloading during this session.
Furthermore, its download-and-delete usage model presents problems for users who access their mail accounts from multiple machines -- perhaps using one PC at work, another at home, and a laptop for traveling. Every time one machine's mail client downloads new messages, they then exist only on that machine, and remain inaccessible to the others unless manually transferred.
You can solve this problem to an extent by directing your client to keep mail stored on the mail server after downloading, but this isn't a perfect solution since you're left dealing with multiple copies whose structure and status can get out of synch with one another. For example, if you move or delete a message on one machine, it will retain its previous location on the others that have already downloaded it.
IMAP gets around POP's weaknesses simply by replacing the download-and-delete model with what we could call a keep-and-reveal one. An IMAP-aware mail server expects its users to permanently store all mail, both new and old, on the server. IMAP contains many commands for organizing all this server-side mail, including creating and editing mailboxes and folders (see the section called "Organizing Mailboxes"), and variously flagging individual messages (see the section called "Organizing Messages").
By keeping mail on the server, your view of your mailbox remains consistent, no matter where you travel, since all your email remains in only one place, instead of scattered across all the computers you use to read mail. Delete a message, and when you connect to your IMAP mailbox from a different machine, it's still gone. Reply to a message, and all your other computers can also see that you've replied to it.
(On the other hand, you can only store as much server-side mail as your mailhost account allows. You'll have to either delete or download some mail if you start running out of space. Fortunately, clients that support automatic caching, such as Apple's mail application, can assist with the latter option.)
IMAP also contains commands for fetching only immediately relevant parts of an email. When it checks for new mail, an IMAP client can request only the new messages' headers and bodies, and not immediately grab any large attached files, leaving their download up to the user's discretion.
|Are you using IMAP with the Mail.app client on Mac OS X? If so, let's here what you've learned. If you haven't tried it yet, ask your questions here.|
While IMAP uses its own mail-fetching model, it doesn't totally abandon all the nice ideas that POP introduced. You can, if you wish, use IMAP in the same download-and-delete style as POP, and thus browse your mail while offline; the commands for this are all in the protocol. It's just up to your client application how deeply it supports these commands.
With that in mind, we'll use Apple's mail application (which I'll henceforth call by its formal name of "Mail.app" to prevent confusion between it and the small-m mail it handles), the one it bundles with every Mac OS X distribution, for the examples in the remainder of this article, because it does quite a good job in supporting IMAP's major features.
However other mail clients, including the aforementioned Eudora and Entourage, have IMAP modes of their own. You should feel free to explore the functionality of your favorite clients, even on ones outside Mac OS X. While the examples in this article are specific to Mail.app, the concepts apply to all IMAP-supporting mail applications.
I'll now guide you through setting up and using an IMAP-enabled mail account through the Apple mail application, covering IMAP-specific concepts as terminology as they come up.
Note: Of course, before you can start having fun with IMAP, your mailhost must support it! You can find out simply by asking your ISP or network administrator about it, and you can also poke your mailhost machine directly to find out, by launching the Terminal application and running a command like this:
If the host runs an IMAP service at port 143 (where IMAP usually lives, if it's anywhere), then you'll see a response that looks something like this:
* OK [CAPABILITY IMAP4REV1 X-NETSCAPE
LOGIN-REFERRALS STARTTLS AUTH=LOGIN] mail.my-mailhost.net IMAP4rev1
2001.315 at Sun, 5 May 2002 10:35:13 -0400
If so, you're good to go. If you instead receive a blunt
Connection refused or
something altogether different, ask the mailhost's masters
about its IMAP support.
By the way, this is how you can connect to an IMAP
server in the raw, without any friendly client program in
between. If you're feeling ambitious, you can type in IMAP
commands (as defined in the IMAP RFC -- see the section called "References") here and watch what happens. This
is probably only of interest to people who want to create
their own mail clients, or are otherwise curious about what a
mail-fetching program really does. For now, though, you can
send the server the LOGOUT command (just type
foo LOGOUT followed by
Return), which ends the IMAP session you manually started.