Guilhem Moulin

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.

cryptsetup(8) is a popular tool to setup block-device encryption, usually based on the kernel's `dm-crypt` module. The debian package comes up with its own set of features such as initramfs integration, which enables encryption of root devices, resume devices, and other devices required at early boot stage. I will briefly talk about the new “LUKS2” format, which is not the default yet but is available since upstream [released v2.0.0](https://kernel.org/pub/linux/utils/cryptsetup/v2.0/v2.0.0-ReleaseNotes) last autumn. However the emphasis of the talk is on the Debian-specific features (such as key scripts, remote disk unlocking, storing key material directly in the initrd, etc.) and which use-case each of them covers. Most of these features have been added along the years per popular request; but as it turns out they are not always well known, and many users are still using more or less brittle workarounds while they could use our scripts — and blame us for regressions :-) — instead. I will conclude by sharing some of our future plans, the other features we'd like to have, the challenges and the blockers.