Retrieve and delete messages

RETR 3 downloads message 3. DELE 3 marks it for deletion; it does not necessarily erase the message at that instant.

RSET clears deletion marks during the transaction. A successful QUIT moves the session into update and commits marked deletions. If the connection dies before update, the server should not apply them.

This transaction model protects against some interrupted downloads, but the client still needs durable bookkeeping before it deletes the server copy.

A safe sequence is explicit:

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

First parse and store the entire multiline response. Verify that local storage completed. Only then mark the server copy for deletion.

DELE changes session state, not necessarily disk state. RSET removes the marks before QUIT. If update fails, the server can leave some or all marked messages undeleted; the client must tolerate seeing them again.

TOP can retrieve headers and a limited number of body lines when supported, but it is optional. Do not use a partial preview as proof that the full message was archived.

Deletion policies such as “leave mail on server for 14 days” are client behavior layered over POP3. Several clients applying different policies can produce surprises because POP3 has no shared folder or flag model.

List the crash points before local save, after local save, after DELE, and during QUIT. State whether the next session can safely redownload the message at each point.