IMAP vs POP3

How are these to protocols different

The two most common standard protocols in use today for retrieving email are IMAP and POP3. Both of these will contact the email server specified in your email client configuration, and retrieve all of an email, or partial information from an email. But there is a huge difference between the two. Which protocol an email client uses depends on the settings used when you configured your email client.

POP3

With the POP3 protocol, all emails are downloaded directly to the email client and stored on your computer.

During a POP3 session, your email client contacts the server, authenticates your password, and then proceeds to download your email. Once all your new emails are downloaded into your email client program, the messages are deleted from the server, and your new messages are organized and presented to you for reading by your email client.

This is the most simplistic description of a POP3 session, and other settings are available on most clients. For example, often times it is desirable skip the step that deletes the messages from the server.

For example suppose you want to be able to be able to read your personal email while at the office. But you also want these emails kept in your home computer. With your office client configured to leave message on the server, you can permenently pop the messages off the server when you arrive home and check your email, deleting messdages from the server only when you POP from home.

By doing this you download your email to the office computer, inbox, and then do the same thing when you get home. You are keeping local client side copies of the emails on both machines, both inboxes look the same. It's a hasstle, but it works.

One benefit of POP3 to the administrator is that in the event of a broken email server, the users have all their messages available to them up until the last time the POPed. Again, this is because messages are POPed to the client side for storage.

IMAP

With the IMAP protocol, messages are always stored on the server until deleted. That is to say, your Inbox resides on the server.

IMAP does not move your email messages from the server to the client for reading. The IMAP protocol leaves the emails on the server, and only fetches them for reading when requested.

For example, when you first start your email client, each message is shown with information like Subject, To, From, etc. IMAP requests these bits of information from the server for each email. When you decide to read an email, the body of the email is read from the server for display.

Because your Inbox (Sent, Trash, and all other folders too for that matter) resides on the server, it always contains the same information no matter where you check from, no matter which computer you use.

This distinction makes IMAP preferred for people on the road, or anyone checking email checking from more than one computer. As an administrator it makes backing up the entire organizations emails more centralized.

The IMAP protocol also provides for shared folders. You can subscribe to, and create public folders for categorizing your emails - just as you can with a POP3 account, but here again, since the folders reside on the server, you have global access to them. They can also be shared out to other individuals or groups for collaboration using ACLs (Access Control List).

Manual telnet pop3 sessions - You can use this to debug issues with authentication or other troubleshooting of problems for which you need to rule out the client side software as the cause.

Since servers that expose the IMAP protocol almost always expose POP3 as well, most troubleshooting can be done using the POP3 manual sessions. You can conduct a manual IMAP session too, but it's a little more involved.

To conduct a POP3 session manually with telnet, first make sure you understand how start a telnet session in the email protocols article, and how to discover the MX record or name of your mail server.

So for example, if your mail account is betsy@browncow.com, your telnet command might look like the following: telnet mail.browncow.com 110. Here is a fictitious sample session. The < symbol indicates what you type, and > indicates what might be returned by the server (which can differ from what you see here). Note that in many cases, the characters you type will not appear as you type them, so be careful about typos, because backspace doesn't work either.

< telnet mail.browncow.com 100
> +OK Hello there
< user betsy@browncow.com
> +OK Password required
< pass moomoo
> +OK logged in.

Once you've authenticated yourself, you can now read your email. How's that for cool. First we issue the list command to get a list of emails by number

< list
> +OK 3 messages
> 1 82457
> 2 72945
> 3 34287

This gives a list of emails in your inbox that have not yet been POPed to your client. The first digit indicates the message number the second number is the message size. Now we can issue the top command to read the first x lines of the email

< top 1 10
> [lots of headers returned]

Here we request the first 10 lines of message 1. The top 10 lines are probably all headers, so to see the body of the email we might need to top 20 or 30 lines. Headers end and the body begins where you find the first blank line. This is per definition.

At this point we've verified our account details, we can logon, and we can read messages. Any problem you might be having reading your email messages has just been isolated to the software / setup you are using.

< quit

Enter quit to terminate the session.