Four commands do the real work in a POP3 session. RETR downloads a message. DELE marks it for deletion. RSET clears every mark. QUIT commits the marks and closes the session.

The word marks is doing a lot of work in that paragraph. DELE 3 doesn’t erase message 3. It flags it. Nothing is removed until QUIT succeeds and the session enters the update state.

The safe sequence

Here is a session that downloads one message and deletes it properly:

C: RETR 3
S: +OK 1842 octets
S: ...message lines...
S: .
C: DELE 3
S: +OK Message marked
C: QUIT
S: +OK Deletions committed

Between RETR and DELE there’s an invisible step the transcript can’t show: the client writes the message to disk and checks the write succeeded. Only then does it send DELE. That gap is what protects your mail.

Why the two-phase design

The mark-then-commit model exists for interrupted sessions. If the connection drops after DELE 3 but before QUIT, the server never enters update. Message 3 stays in the maildrop, and the next session sees it again.

RSET gives the client the same escape hatch on purpose. Marked three messages, then realized the local disk is full? Send RSET, and every mark is gone.

Update can partially fail

Even a successful QUIT isn’t a hard guarantee. The server may fail to delete some marked messages, for instance if the maildrop was modified underneath it. The RFC allows that. Your client has to tolerate seeing a message again and recognize it by UIDL rather than downloading a duplicate.

TOP is a preview, not a download

Some servers support TOP 3 10, which returns the headers of message 3 plus the first 10 body lines. It’s handy for showing a preview before downloading a huge message.

Be careful with it. TOP is optional, so check CAPA first. And never treat a TOP response as proof that you archived the message. Only a complete RETR, saved to disk, counts.

“Leave on server” is a client policy

Your mail app’s “leave messages on the server for 14 days” option isn’t a POP3 feature. The client remembers UIDLs and dates locally, and sends DELE when its own rule says so.

That works fine with one client. With two clients and two different policies, the laptop deletes mail the phone hasn’t fetched yet, and nobody understands why messages vanish. POP3 has no shared state to coordinate them.

Try listing the crash points in the transcript: before the local save, after it, after DELE, and during QUIT. For each one, decide whether the next session can safely download the message again.

Retrieve and delete messages