IMAP
UIDs, synchronization, and IDLE
Use stable identifiers and mailbox state to synchronize safely while receiving near-real-time updates.
8 minute lesson
IMAP sequence numbers are positions and can change when messages are expunged. UIDs are stable within one mailbox and UIDVALIDITY generation.
A synchronizing client records UIDs and mailbox state, fetches changes, and rebuilds local state when UIDVALIDITY changes. It should not treat a sequence number as a durable message ID.
The IDLE extension lets a server report changes without constant polling. TLS-protected IMAP commonly uses port 993.
A local cache key should include the account, mailbox, UIDVALIDITY, and UID. A UID alone is not globally unique and can be reused after the mailbox generation changes.
C: A010 IDLE
S: + Idling
S: * 43 EXISTS
C: DONE
S: A010 OK IDLE terminatedDONE is not a tagged IMAP command. It ends the idle period associated with A010, whose tagged completion arrives afterward. Clients leave and re-enter IDLE periodically according to server and network behavior.
An EXISTS update says the selected mailbox count changed. It does not contain the new message. The client still fetches new UIDs and the data it needs.
When UIDVALIDITY changes, discard UID-based assumptions for that mailbox and rebuild. When a connection drops, reconnect, reselect, compare saved state, and ask the server for changes; do not assume every pushed update was received.
Design a cache record for one message. Then write the recovery steps after the network disappears while the client is idling.
Lesson completed