Comment by jcranmer

To forestall confusion: there are two different ID mechanisms in IMAP.

The first mechanism is message sequence IDs. If you have a mailbox with N messages in it, these messages are numbered 1-N (inclusive); a new message gets N+1; and deleting message, say, 3 causes 4-N to be renumbered to 3-(N-1). Note that the server can be the one to delete the message (say another connected client deletes it), but server-to-client notifications of message deletion can only happen at specified times in the protocol. The client might still have stale sequence numbers when it sends you the next command however, because IMAP is pipelined. And if you think this sounds like a recipe for lots of weird bugs, you are indeed correct in those thoughts.

So what everyone uses instead are UIDs, which are stable IDs for a message (kind of). UIDs are monotonically increasing (a message with UID 100 is newer than one with UID 95, but there's no guarantee that UID 97 exists), and are not impacted by message creation or deletion. One way to think of them are offsets in the underlying mbox file of where the message lives. If UIDs need to be renumbered (... yay mbox), the server changes the UIDVALIDITY which means that previous UIDs are no longer necessarily valid.

The message sequence numbers kind of make sense, if you imagine that IMAP clients are very, very thin clients that don't maintain any local information, and if you imagine that servers are not expected to support two clients connecting to the same mailbox at the same time. But modern email clients need to maintain their own local database of email metadata, which means that the IMAP protocol has become, in effect, a database synchronization protocol, even though it's not originally designed as such (later IMAP extensions added features that made some elements of synchronization much faster).