IMAP
The IMAP model
See IMAP as a protocol for manipulating server-side mailboxes rather than merely downloading messages.
IMAP flips the POP3 model around. The server holds the real mailbox. Your phone, your laptop, and webmail are all views onto it.
When you read a message on your phone, it shows as read on your laptop. When you move it to a folder in webmail, the phone sees the folder. That’s IMAP doing its job: keeping several clients in sync with one server-side truth.
Flags are shared state
Every message carries flags. The standard ones are \Seen, \Answered, \Flagged, \Deleted, and \Draft. The server stores them, and every client sees the same values.
This is different from POP3 in an important way. Setting \Seen from one client changes the message for everyone. A client that uploads its whole local view of flags can undo a change another device just made. Good clients send small, specific changes instead, and we’ll see how in the fetch and store lesson.
The states of a connection
An IMAP connection moves through a few states:
not authenticated -> authenticated -> selected mailbox -> logout
You log in and you’re authenticated. That gets you account-level commands like LIST to see the mailboxes. Then SELECT INBOX puts you in the selected state, and message commands like FETCH, STORE, and SEARCH become legal. CLOSE or UNSELECT leaves the mailbox without logging out, so you can select another one.
Try FETCH before selecting a mailbox and the server answers BAD. It has no idea which mailbox you mean.
The server talks when it wants
Here’s the part that surprises people coming from request-response protocols. An IMAP server can send data at any time, not only in reply to your command.
While you’re selected on INBOX, a new message arrives. The server sends * 43 EXISTS even if you asked for nothing. Another device marks a message as read, and you get an untagged FETCH with the new flags.
Your client can’t assume it’s the only thing changing the mailbox. Delivery, server-side filters, and other devices are all writing to it. Build clients that expect updates, not ones that assume a frozen snapshot.
IMAP reads, it doesn’t send
One last thing to keep straight. IMAP has no command that sends a message to another person. Your mail app still uses SMTP submission, or a provider API, to send.
After sending, the app usually stores a copy in the Sent mailbox through IMAP APPEND, or the provider does it automatically. That’s why sent mail syncs across devices in IMAP but not in POP3.
Try drawing the state changes for login, LIST, SELECT, UID FETCH, CLOSE, and LOGOUT. Then mark one command that’s invalid before a mailbox is selected.
Lesson completed