SMTP moves mail between servers, but it does not tell a person’s mail program how to fetch the messages waiting for them. That retrieval job belongs to a separate pair of protocols, POP and IMAP, which represent two different philosophies about where email should actually live. POP assumes mail belongs on the user’s own device; IMAP assumes mail belongs on the server. Both remain in wide use, and the choice between them shapes how email behaves across multiple devices.
The Post Office Protocol, Version 3 (POP3) is defined in RFC 1939, written by John Myers and Marshall Rose and published in May 1996. Its purpose, in the words of the specification, is to “permit a workstation to dynamically access a maildrop on a server host in a useful fashion.” A POP3 client connects, authenticates during an AUTHORIZATION state, lists and downloads waiting messages during a TRANSACTION state, and then, during an UPDATE state when the session closes, the server deletes the messages that were marked for removal. The standard is explicit that POP3 “is not intended to provide extensive manipulation operations of mail on the server; normally, mail is downloaded and then deleted.” This download-and-delete model works well for a single computer but fits poorly with the modern reality of reading the same mailbox from a phone, a laptop, and a desktop.
The Internet Message Access Protocol takes the opposite approach, keeping the authoritative copy of every message on the server. RFC 3501, “Internet Message Access Protocol - Version 4rev1,” written by Mark Crispin of the University of Washington and published in March 2003, defines the version of IMAP that came into general use. The abstract describes its goal directly: to let a client “access and manipulate electronic mail messages on a server.” IMAP treats remote folders the way a user would treat local ones.
Because the messages stay on the server, IMAP offers a much richer command set than POP3. RFC 3501 lets a client create, delete, and rename mailboxes, check for new messages, set and clear flags such as seen or answered, search the contents of a mailbox, and selectively fetch parts of a message, for example retrieving only the headers or a single MIME attachment rather than downloading everything. It also supports clients that go offline and later resynchronize their state with the server. This server-centric design is what makes a message read on one device show up as read everywhere, which is why IMAP became the dominant choice as people accumulated multiple devices.
Together, POP3 and IMAP complete the email picture. A message is composed by a sender’s client, relayed between hosts by SMTP, structured and given its attachments by MIME, deposited in the recipient’s mailbox, and finally pulled down to be read through POP3 or IMAP. The split between sending and retrieval, and the two contrasting retrieval models, reflect deliberate engineering choices made in the IETF Request for Comments process to match the different ways people actually use their mail.