A familiar screen hides several systems
An inbox is an unusually convincing illusion. A sender, a subject and a date fit on one line, making the product look like a straightforward database application. From a small product studio’s perspective, the difficult work starts when that line must remain trustworthy across providers, devices and messages written decades apart. The interface is compact because it hides the machinery, not because the machinery is simple.
Email grew through separate standards rather than one application contract. SMTP moves messages between mail servers; IMAP lets a client access and manage a mailbox; MIME describes how message bodies carry different media types and encodings. Confusing those jobs leads to misleading promises about what a new client or protocol can repair. See the SMTP specification, IMAP4rev2 and MIME’s foundational specification.
Compatibility becomes product behavior
A message is not simply a UTF-8 paragraph with a file attached. It can contain nested multipart sections, alternative plain-text and HTML bodies, encoded headers and attachments with filenames that need interpretation. A rendering decision can change whether someone can read an old receipt. A parsing shortcut can turn a familiar message into a blank preview. Historical variety becomes a present-day interface responsibility.
The same is true of mailbox state. Someone reads a message on a phone while a desktop is disconnected. Another client moves it into a folder. A provider exposes labels through its mailbox model. The app must reconcile identity, membership and flags without treating every discrepancy as a new message. A progress indicator that says “done” has to mean something defensible under those conditions.
Build for recovery before polishing the happy path
IMAP is not frozen in its earliest form: modern IMAP and extensions address capabilities including more efficient synchronization. The practical difficulty is discovering what a server supports and implementing the paths the product actually needs. Compatibility is a matrix of server behavior, authentication, network interruption and local persistence, not a contest between an old acronym and a new one.
For a studio, that suggests a concrete order of work. Separate transport and parsing from the local data model. Keep representative fixtures for unusual messages. Make interrupted work resumable, and distinguish “not downloaded yet” from “not present on the server.” Test deletion and reconnection with the same care as initial import. These choices rarely make a launch screenshot, but they decide whether the screenshot can be trusted.
A narrower contract leaves more room for the product
MailVault’s work on email makes this boundary useful: improving how a client talks to a server can remove coordination work, while preserving messages locally remains its own engineering job. The useful question is which complexity belongs in a protocol contract and which still belongs in the app.
Our companion note, JMAP and the architecture of modern email apps, explores one answer. For the user-facing explanation of the same history, read MailVault’s why email is still complicated. A better protocol helps builders spend more attention on reliable behavior; it does not erase email’s accumulated history.