Fetch, store, and search

FETCH requests specific data rather than forcing the whole message to download. A client can ask for headers, body sections, flags, sizes, or dates.

STORE changes flags. SEARCH finds messages matching criteria such as sender, date, subject, or flag state.

C: A003 UID SEARCH UNSEEN
S: * SEARCH 104 108
S: A003 OK Search completed

Server-side search reduces transfers, but clients must still handle unsolicited changes reported while the session is open.

Use UID commands for durable work:

C: A004 UID FETCH 104 (FLAGS BODY.PEEK[HEADER.FIELDS (FROM SUBJECT)])
S: * 7 FETCH (UID 104 FLAGS () BODY[HEADER.FIELDS (FROM SUBJECT)] {52}
S: From: Alice <alice@example.org>
S: Subject: Deployment
S:
S: )
S: A004 OK FETCH completed

The 7 is the current sequence number. 104 is the UID. BODY.PEEK retrieves data without setting \Seen; the equivalent non-PEEK body fetch can change shared flag state.

STORE should express the intended change. +FLAGS adds flags and -FLAGS removes them. Replacing the complete flag list can erase a change made by another client.

Search results are identifiers matching the query at that moment. A later expunge or delivery can change the mailbox before the client fetches them. Handle missing results and unsolicited updates instead of assuming a frozen snapshot.

Fetch only what the interface needs. Headers and small body sections make an inbox fast; download large attachments after the user asks for them.

Change the example to mark UID 104 as seen without replacing its other flags. Explain why using sequence number 7 in a later session is unsafe.