Guilhem Moulin

InterIMAP — The case for local IMAP servers and fast bidirectional synchronization

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, sorting/threading, notification as well as storage (including caching). Such solution is fully compositional as it relies on documented protocols (namely IMAP4rev1 and its extensions) 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, which enables stateful and efficient bi-directional synchronization between two IMAP4rev1 servers. I will briefly present such a synchronization program, InterIMAP, and show a few benchmark metrics to justify its presence in the ecosystem and compare with so-called “full” synchronization solutions.