The POP3 model

POP3 gives a client access to a server maildrop. Its classic workflow is simple: authenticate, list messages, retrieve them, optionally mark them for deletion, and quit.

The protocol has three states. Authorization identifies the user. Transaction works with messages. Update applies deletions when the client quits successfully.

POP3 can leave copies on the server, but it does not provide IMAP’s rich shared mailbox model. It fits best when one client owns a downloaded archive.

The states control which commands are legal:

TCP/TLS connected -> AUTHORIZATION -> TRANSACTION -> UPDATE -> closed

The server starts with +OK or -ERR. Successful authentication enters transaction state. STAT, LIST, UIDL, RETR, and DELE operate there. QUIT commits deletion marks and closes the session.

POP3 message numbers are session positions, not durable identifiers. If another session changes the maildrop, “message 4” can refer to a different position next time. Use UIDL values to remember which messages were already downloaded.

A client should write the retrieved message durably before it sends DELE. Otherwise a local crash can lose the only copy after a successful update.

The server commonly locks the maildrop for a transaction. A second client may receive an authentication or lock failure until the first session finishes.

Write the valid state beside USER, PASS, STAT, RETR, DELE, and QUIT. Then explain what should happen if the TCP connection dies before update.