The IMAP model

IMAP keeps the authoritative mailbox on the server. Clients synchronize mailbox names, messages, flags, and changes.

A message can appear with flags such as \Seen, \Answered, \Flagged, \Deleted, and \Draft. Several clients can observe the same state.

That model is more complex than POP3, but it matches how people use phones, laptops, and webmail with one account.

An IMAP connection moves through states:

not authenticated -> authenticated -> selected mailbox -> logout

Authentication gives access to the account. SELECT INBOX enters selected state, where message commands such as FETCH, STORE, and SEARCH become valid. CLOSE or UNSELECT leaves that mailbox without ending the account session.

The server can send untagged updates at any time. A client cannot assume that only its own actions change message counts or flags. Another phone, a server-side filter, or a delivery process can update the selected mailbox.

Flags are shared state, not local decoration. Setting \Seen on one client can make the message appear read everywhere. Use UIDs and mailbox state to merge changes rather than uploading one device’s entire view over another.

IMAP accesses mail; it does not submit it. A mail app still uses SMTP submission or a provider API to send outgoing messages, then usually stores a sent copy through IMAP or provider behavior.

Draw the state transitions for login, LIST, SELECT, UID FETCH, CLOSE, and LOGOUT. Mark one command that is invalid before a mailbox is selected.