It is common to find local `sendmail(1)`-compatible Mail Transport Agent on workstations, usually configured as nullmailer (relay-only) to a remote submission agent. However finding a local IMAP server seems less common. Instead a typical desktop Mail User Agent implements the full mail stack, from storage to rendering/edition, via custom caching, threading, searching, and notification mechanisms. I will argue for local IMAP servers in order to reduce latency and enable offline mode with _thin clients_: such a client conforms to the UNIX philosophy as it takes care of rendering and nothing else, and relies on the underlying IMAP server for [searches](https://tools.ietf.org/html/rfc3501#section-6.4.4 "The IMAP SEARCH Command"), [sorting/threading](https://tools.ietf.org/html/rfc5256 "The IMAP SORT and THREAD Extensions"), [notification](https://tools.ietf.org/html/rfc5465 "The IMAP NOTIFY Extension") as well as storage (including caching). Such solution is fully compositional as it relies on documented protocols (namely [IMAP4rev1 and its extensions](https://tools.ietf.org/html/rfc3501 "IMAP4rev1")) for the gluing part. That leaves the problem of synchronization between multiple devices (and/or IMAP accounts), in arbitrary topologies. There again IMAP comes to the rescue with its [QRESYNC extension](https://tools.ietf.org/html/rfc7162 "The IMAP CONDSTORE and QRESYNC Extensions"), which enables stateful and efficient bi-directional synchronization between two IMAP4rev1 servers. I will briefly present such a synchronization program, [InterIMAP](https://tracker.debian.org/pkg/interimap "InterIMAP"), and show a few benchmark metrics to justify its presence in the ecosystem and compare with so-called “full” synchronization solutions.
Speakers: Guilhem Moulin