Protocols

IMAP and POP3 — the way back

In email, sending and fetching are two separate systems that know nothing of each other. For fetching there are two answers, and the difference between them is a question about where the truth lives.

The separation

SMTP pushes messages from server to server until one arrives at the mailbox responsible for it. There it sits. How it gets from there onto a device is not something SMTP solves, and never was its job.

Which is consistent: SMTP pushes, and a user's machine is not permanently reachable. So a second protocol is needed, one that fetches. There are two of them, thought out thirteen years apart.

POP3: collect and take away

The mailbox is a locker at a railway station. You go there, take everything with you, the locker is empty again. What happens to the messages afterwards is the business of the device they are sitting on.

S: +OK POP3 ready
C: USER bert
C: PASS ********
S: +OK mailbox open, 2 messages
C: LIST
S: 1 4211
S: 2 8390
C: RETR 1
S: +OK 4211 bytes follow …
C: DELE 1
S: +OK deleted
C: QUIT

The whole protocol consists of about a dozen commands. It knows no folders, no search, no state beyond "present" and "deleted".

For the world of 1988 that was exactly right: one machine per person, one telephone line that costs money. Connect briefly, fetch everything, read offline.

IMAP: the server stays in charge

Here everything stays on the server, and the devices merely display what is sitting there. The mailbox is not a locker but a filing cabinet several people look into at once.

Everything else follows from that: folders, because there is something to order. Flags for read, answered, important — on the server, so that every device sees them. Search on the server, because that is where everything is. Partial fetching, so that a phone can show the list without pulling down twenty attachments.

The difference is not a feature list but the answer to a single question: where does the authoritative state live?

Why IMAP won

Not because of the features but because of the second device. The moment people wanted to read the same mail on a computer and on a phone, the question was settled: a model in which the truth lives on one device cannot serve two.

POP3 has not disappeared for all that. It is still the right tool when somebody deliberately wants to pull their mail down from a provider and archive it themselves — that is, precisely when "the server stays in charge" is not what is wanted.

What neither of them can do

Neither POP3 nor IMAP sends messages. SMTP handles that, over the submission route. Which is why you have to enter two servers in every mail program, and why receiving can work while sending fails.

The "Sent" folder is no exception either: the mail program sends the message via SMTP and then files a copy in the folder itself, via IMAP. Two operations that belong together only inside the program — which is why a message occasionally goes out without a copy appearing.

Encryption

Both protocols have two modes of operation: start unencrypted and switch over by command (port 143 and 110 respectively), or be encrypted from the first second (port 993 and 995).

The second is the more robust, because it has no state in which nothing is protected yet. Anyone running their own server should not open the unencrypted ports in the first place — a door that is shut needs no lock.