Dovecot, Post-Quantum TLS and Sieve: The BOFH Guide to a Hardened IMAP Server

A cryptographically relevant quantum computer doesn’t exist yet, and a nation-state is almost certainly recording your IMAP session anyway. That’s not paranoia, it’s procurement: encrypted traffic is cheap to store and patient adversaries are betting that the RSA key protecting your mailbox today will be trivially crackable in 2032. They’re probably right. The strategy even has a name in the literature, “harvest now, decrypt later”, and it’s the single best reason to turn on Dovecot post-quantum TLS this year, not when the headlines force you to. Dovecot post-quantum TLS is the whole point of this guide.

Which brings us to Dovecot, the quiet workhorse that’s been holding your email together while you weren’t looking. If you’ve ever read a mail header and felt a flicker of dread, this one’s for you. We’re going to take Dovecot apart, explain what cryptography actually does under the hood (no hand-waving), wire in genuine post-quantum key exchange, lock down every cipher that has any business being shot behind the barn, and bolt on Sieve so your inbox files itself. And we’ll do it the way the Bastard Operator From Hell would: with contempt for defaults, suspicion of every open port, and a container that trusts absolutely nobody.

What Dovecot actually is (and why you already depend on it)

Dovecot is an IMAP and POP3 server. That’s the boring one-liner. The useful version: it’s the piece of software that lets your phone, your laptop, and that one ancient Thunderbird install all see the same mailbox, in sync, over an encrypted connection. When Postfix or another MTA accepts a message from the outside world, it hands it off for local delivery, and Dovecot is what stores it, indexes it, and serves it back when a client connects on port 993 (IMAPS) or 995 (POP3S).

It’s the most popular IMAP server on the public internet by a wide margin, surveys have put it north of 70% of all IMAP-capable hosts for years. There’s a good reason for that dominance. Dovecot is fast (its index format is built for the access patterns mail clients actually use, not the ones a textbook assumes), it’s pedantically standards-compliant, and its security record is genuinely excellent for software this widely deployed. Timo Sirainen, the original author, was famously willing to pay out of his own pocket for any security hole found in the core. That kind of confidence is rare and earned.

Dovecot also does more than serve mail. It runs LMTP (the local delivery protocol that lets your MTA drop messages straight into Dovecot’s storage), ManageSieve (so users can edit their own mail-filtering rules), and a SASL auth service that Postfix leans on to decide who’s allowed to send mail. In a modern stack, Dovecot isn’t a leaf node, it’s load-bearing. If you’re running a mail server at all, you should treat its config like you treat your SSH config: paranoidly.

Crypto in ninety seconds, properly this time

Before we talk post-quantum anything, let’s get the foundations right, because most “TLS hardening” guides skip the part that actually matters.

When your client connects to Dovecot over TLS, three different jobs happen, and people constantly conflate them:

1. Key exchange (the asymmetric part)

Your client and the server need to agree on a shared secret over a wire that’s being watched. They do this with asymmetric cryptography, maths where a public value can be shared openly but a private one stays secret. Modern TLS uses ECDHE: Elliptic Curve Diffie-Hellman, Ephemeral. “Ephemeral” is the important word. A fresh key is generated for every single session and thrown away after. This gives you forward secrecy: even if someone steals the server’s long-term private key next year, they still can’t decrypt the session they recorded today, because the ephemeral key that protected it never touched disk and no longer exists. Forward secrecy is non-negotiable. Any cipher that lacks it, anything starting with plain RSA key exchange, belongs in a museum.

2. Authentication (the signature part)

Key exchange stops eavesdropping, but it doesn’t stop someone pretending to be your server. That’s what the certificate is for: the server signs part of the handshake with the private key matching its public certificate, and a CA you trust vouches for that certificate. This is where the “is this really mail.example.com?” question gets answered.

3. Bulk encryption (the symmetric part)

Once both sides share a secret, they switch to fast symmetric crypto for the actual data, your IMAP commands, your messages, your folder list. This is AES-GCM or ChaCha20-Poly1305. Both are AEAD ciphers: Authenticated Encryption with Associated Data, meaning they encrypt and tamper-detect in one pass. If an attacker flips a bit, the connection dies instead of quietly delivering corrupted data. The bad old CBC-mode ciphers didn’t do this cleanly, which is exactly how attacks like BREACH and its CBC cousins got their teeth. We turn CBC off entirely.

Here’s the thing that should make you sit up: a quantum computer threatens exactly one of these three. Symmetric crypto (AES, ChaCha20) is basically fine, Grover’s algorithm halves the effective key length, so AES-256 still gives you a comfortable 128 bits of quantum security. The thing that shatters is the asymmetric key exchange. Shor’s algorithm turns the hard maths behind RSA and elliptic curves into a tractable problem. The padlock holding your session secret is the part that breaks.

Dovecot post-quantum TLS and harvest-now-decrypt-later

So we have a clear, bounded threat: when a cryptographically relevant quantum computer arrives, every ECDHE and RSA key exchange ever recorded becomes decryptable. Not future traffic, recorded traffic. Anything an adversary stored on tape today.

That’s the harvest-now-decrypt-later attack in full. It doesn’t require the quantum computer to exist yet. It only requires an adversary patient enough to keep your encrypted blobs until one does. For most web traffic, a cat photo, a session that expires in an hour, who cares. For mail? Mail is forever. The contents of your inbox in 2026 may be every bit as sensitive in 2034. Email is the canonical worst case for HNDL, which is precisely why Postfix 3.11 shipped post-quantum TLS and why your IMAP server has no excuse to lag behind.

The fix is a new family of algorithms whose hardness doesn’t collapse under Shor’s algorithm. NIST ran a multi-year competition and standardised the winners in 2024. The key-exchange winner is ML-KEM (Module-Lattice Key Encapsulation Mechanism, FIPS 203, formerly known as Kyber). It’s a lattice-based KEM, and the lattice problems it relies on have no known efficient quantum attack.

But, and this is the part the marketing skips, nobody fully trusts a brand-new algorithm on its own yet. Lattice crypto is young. So the sane deployment is a hybrid: combine the classical, battle-tested X25519 elliptic-curve exchange with ML-KEM-768, and derive your session secret from both. An attacker now has to break both the lattice maths and elliptic curves to win. If ML-KEM turns out to have a flaw, you’re no worse off than classical TLS. If quantum computers arrive, X25519 falls but ML-KEM holds. You lose only if both break, and if that happens, we have bigger problems than your email. That hybrid group is called X25519MLKEM768, and it’s the de-facto default that browsers and OpenSSL already negotiate.

Wiring real PQC into our Dovecot

Here’s where theory becomes config. Post-quantum key exchange in Dovecot isn’t a Dovecot feature at all, it’s an OpenSSL feature that Dovecot inherits, because Dovecot is built with --with-ssl=openssl and links the system library. Hybrid ML-KEM landed in OpenSSL 3.5. No OpenSSL 3.5, no post-quantum handshake, full stop.

That single fact drove a deliberate decision in our package: we build Dovecot only for Debian trixie and Ubuntu resolute, the two suites that ship OpenSSL 3.5+. Older distros (bookworm, jammy, noble, bullseye) carry OpenSSL 3.0 or 1.1 and physically cannot negotiate ML-KEM. Building for them would be shipping a security promise we couldn’t keep. So we don’t.

The TLS config itself lives in conf.d/10-ssl.conf, and it’s where the BOFH energy goes. The key-exchange group list puts the post-quantum hybrid first:

ssl_curve_list = X25519MLKEM768:X25519:X448:secp384r1:secp256r1

Read that as a preference order. A modern client that speaks ML-KEM gets the post-quantum hybrid. A client that doesn’t falls back gracefully to classical X25519, still forward-secret, still strong, just not quantum-resistant. Nobody gets locked out; everybody capable gets the best available. That’s the whole philosophy.

For the symmetric ciphers, we keep only AEAD suites and shoot everything else:

ssl_cipher_suites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
ssl_cipher_list   = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:\
                    ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:\
                    ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
ssl_server_prefer_ciphers = yes
ssl_min_protocol = TLSv1.2

What got the bullet: kRSA (no forward secrecy), all DH(E) and 3DES and DES, RC4, MD5, SHA1-MAC, every CBC suite, PSK, SRP, NULL, EXPORT. If a cipher was ever in a CVE title, it’s gone. We set ssl_server_prefer_ciphers = yes so the server dictates the ordering, we don’t let a client downgrade us into something weaker because it asked nicely. TLS 1.3 is negotiated whenever the client can; TLS 1.2 stays as a hardened fallback (forward-secret AEAD only) so we don’t break older-but-not-ancient clients. TLS 1.0 and 1.1, being thoroughly broken, are simply not on the menu.

The rest of the hardening: an IMAP server that trusts nobody

TLS is the front door. The BOFH worries about the whole house. Our dockerized Dovecot is built to a single principle: assume the process will be compromised, and make that compromise worthless.

Privilege separation, caged. Here’s where a lot of “hardened” images get it backwards. Dovecot is built around privilege separation: a small root master process binds the ports and loads the TLS key, then immediately hands every network-facing job to an unprivileged user. The processes that actually parse hostile input off the internet, the pre-auth IMAP/POP3 login workers, run as dovenull, a user that owns nothing. The processes that touch your mail run as vmail (uid 5000). Root never reads a byte from an attacker. Collapsing all that to a single uid (which a lot of “fully unprivileged” containers do) actually weakens you: a bug in the login parser would then already be running as the mailbox owner. So we keep Dovecot’s separation and cage the root master instead, cap_drop: ALL, then add back only the handful of capabilities it genuinely needs (drop privilege to dovenull/vmail, chroot the login workers, own its runtime sockets), plus no-new-privileges, AppArmor, and every setuid bit stripped out of the image. As a bonus we move every listener to a high port inside the container (via conf.d/99-unprivileged-ports.conf) and map the real public ports down to them host-side, so we don’t even need CAP_NET_BIND_SERVICE. Pop the login worker and you’re dovenull in a chroot with no capabilities and nowhere to go.

Read-only rootfs. The filesystem is immutable. The only writable surfaces are the mail volume, your config mount, and a few small tmpfs mounts the daemon needs at runtime (/run for its sockets, /var/lib/dovecot for its instance registry, and a noexec /tmp that $HOME points at, pyzor and razor insist on writing a dotfile somewhere). Everything else is carved in stone. Drop a webshell and it’s got nowhere to live, and because /tmp is mounted noexec, nowhere to run even if it did.

Architecture-independent malloc tuning. The image runs unchanged on amd64 and arm64; the LD_PRELOAD’d allocator (mimalloc or jemalloc) is selected at runtime by resolving the multiarch lib dir in bootstrap.sh, so there’s no per-arch image to maintain.

And the binaries themselves are hardened at compile time, not just at runtime. Our Dovecot package builds with -D_FORTIFY_SOURCE=3 (tighter buffer checks than the usual level 2), -fstack-clash-protection, -fcf-protection=full for Intel CET branch-target enforcement on amd64, -fno-plt to shrink the PLT-overwrite attack surface, and full RELRO with bindnow. None of these break old hardware, they’re no-ops on silicon that lacks the feature, but they make memory-corruption exploitation genuinely harder on hardware that has it.

Sieve: your inbox filing itself

Now the fun part, because security without convenience just trains users to disable it.

Sieve (RFC 5228) is a small, deliberately limited scripting language for filtering mail at delivery time, on the server, before your client ever sees it. It’s implemented in Dovecot by the Pigeonhole plugin, which tracks Dovecot’s release cycle tag-for-tag (our build resolves both from matching version tags). The language is intentionally not Turing-complete, no loops, no shell-out, no way to wedge the delivery agent in an infinite loop. That constraint is a feature: a hostile or buggy Sieve script can misfile your mail, but it can’t take down the server.

A trivial example that files everything from your mailing list into a folder and drops obvious spam:

require ["fileinto", "mailbox"];

if header :contains "List-Id" "debian-devel" {
    fileinto :create "Lists/Debian";
}
if header :contains "X-Spam-Flag" "YES" {
    fileinto "Junk";
    stop;
}

The killer feature is that users can manage their own Sieve scripts over ManageSieve (port 4190) without touching the server filesystem, Thunderbird, Roundcube and friends all speak it. And Sieve’s vnd.dovecot.execute extension is what lets you wire spam-reporting into the delivery pipeline, which is exactly where the next section comes in.

Batteries included: rspamc, spamc, pyzor, razor and the vimbadmin scripts

A bare IMAP server is half a mail stack. Our dockerized image ships the other half, the spam-fighting and administration tooling that a real deployment needs, so you’re not apt install-ing things into a “temporary” container that somehow becomes production.

Inside the image you get the full spam-reporting client set: rspamc and spamc (the command-line clients for Rspamd and SpamAssassin respectively), plus pyzor and razor, two collaborative spam-fingerprinting networks. These aren’t decoration. Wire them into a Sieve script and “report this as spam” becomes a one-line filter action: the message gets fingerprinted, the fingerprint is fed back to the network, and Rspamd’s Bayesian classifier learns from it. Move a message to Junk, and the whole feedback loop fires. That’s how a self-hosted server gets smarter over time instead of staying as dumb as the day you installed it.

The image also bundles the vimbadmin helper scripts, the Perl glue that lets ViMbAdmin, the Postfix + Dovecot mailbox admin panel, drive Dovecot for quota reporting and mailbox operations. ViMbAdmin gives you a proper web UI (with TOTP and brute-force protection) for managing virtual domains, mailboxes and aliases, instead of writing raw SQL into your mail database at two in the morning. The helper scripts are what connect that web panel to Dovecot’s actual mailbox state. And because the whole thing pulls its packages straight from the deb.myguard.nl APT repository baked into the base image, every component is the same hardened build, signed by the same key.

And when Sieve needs to send mail outward, a redirect that forwards a copy elsewhere, a vacation auto-reply, a notify, the container doesn’t run its own MTA at all. There’s no sendmail binary in the image, nothing to exploit. Instead Dovecot hands the outbound message over SMTP to the real Postfix container via submission_host. Mail access is Dovecot’s job; mail transport is Postfix’s, with all the queueing, retries, DKIM and bounce handling that implies. One egress point, one place to sign and rate-limit, and the smallest possible attack surface on the mailbox server itself.

Putting it together

Pull the picture back and the design philosophy is consistent at every layer. The crypto is post-quantum where it counts and forward-secret everywhere. The cipher list is AEAD-only and the protocol floor is TLS 1.2. The root master is caged behind dropped capabilities and no-new-privileges, hands every hostile byte to an unprivileged separated user, and sits on a read-only filesystem. The binaries are fortified, CET-protected and RELRO-locked. The spam pipeline learns. The admin happens through a hardened web panel instead of raw SQL. And the whole thing is two distros wide on purpose, because we’d rather ship a smaller promise we can actually keep than a bigger one we can’t.

Your mailbox is going to outlive the cryptography currently protecting it. The only question is whether someone’s keeping a copy of the handshake. Build for the answer being yes.

Frequently Asked Questions

Related reading

• Postfix 3.11: Post-Quantum TLS, TLSRPT, Milters and the Modern MTA Stack: the MTA half of the stack, with the same post-quantum TLS story on the sending side.
• ViMbAdmin: The Postfix + Dovecot Mailbox Admin Panel: the web UI that manages the virtual domains and mailboxes Dovecot serves.
• Rspamd Explained: How Modern Spam Filtering Actually Works: the spam engine that rspamc, pyzor and razor feed into.
• Hardened Roundcube Docker: The Webmail Container That Trusts Nobody: the same cap-dropped, read-only hardening philosophy, applied to webmail.