Field Notes

synthesis

Open standard for federated e2ee email

StatusWorkingReviewdue UpdatedStands on13 sourcesSupportsnotes

Proton and Tuta each encrypt mail at rest and between their own customers, but neither can deliver end-to-end encrypted mail to a recipient on the other service, or on any ordinary provider, without falling back to PGP or a password-protected message. That gap is real, and it is the same gap that has defeated every open encrypted-email effort for three decades. The question this note answers is not whether the gap exists, but whether a new open standard, built and led by a challenger provider, is a viable way to close it.

The user’s proposal

Build an open, federated standard for end-to-end encrypted email, distinct from both PGP and the Proton/Tuta walled-garden model. Any provider could implement it; the venture competes by being first to market and by remaining the standard’s principal maintainer. The design would be backwards-compatible with unencrypted mail: a sender’s client would learn, before sending, whether a recipient’s provider supports the standard, and would fall back to PGP or plaintext when it does not. The architecture splits into a server-to-server federation protocol and a client-to-server access protocol, with a local IMAP proxy offered for compatibility with existing mail clients.

This is a coherent, well-specified proposal. It is also, piece by piece, a proposal other people have already tried, and the reasons their attempts stalled bound how a new attempt should be scoped.

Why PGP did not close this gap

PGP already is an open, federated, provider-agnostic encryption standard for email, and Proton Mail already supports it for external recipients. It has not solved the interoperability problem in practice, for reasons a new protocol must either fix or inherit.

The Latacora critique, widely cited in security engineering circles, argues that PGP fails on several axes at once: key discovery and revocation are unsolved usability problems, long-lived keys make forward secrecy impossible, the CFB and non-AEAD constructions used in practice have a poor track record against tampering, and, most relevant here, PGP encrypts the message body but not the envelope. Sender, recipient, subject line, and timing remain visible to every relay the message crosses, because SMTP headers must stay legible for routing.1 A regulator, employer, or intelligence service that cannot read a PGP-encrypted email can still build a complete social graph and conversation timeline from its headers alone.

Autocrypt, an IETF-adjacent effort from 2017, tried to fix the usability half of the problem by having mail clients exchange keys automatically inside ordinary email headers, opportunistically and without manual key verification. It succeeded at removing key-management friction in clients that implemented it, but explicitly accepted an active machine-in-the-middle risk as the price of that automation: an attacker able to inject mail can substitute a victim’s key silently, and Autocrypt performs no verification ceremony to catch this.2 Its adoption also remained confined to a handful of clients, notably K-9 Mail, Thunderbird, and Delta Chat, and never reached majority webmail providers. Web Key Directory, a complementary discovery mechanism that lets a domain publish its users’ keys at a well-known path, has the opposite problem: it is simple to specify but requires every domain operator to deploy and maintain a correctly configured HTTPS endpoint, and adoption has been correspondingly slow and uneven.3

The pattern across all three: the hard part of encrypted email was never the cryptography. It has been key discovery, revocation, metadata exposure, and getting a critical mass of independent operators to deploy the same profile correctly. A new protocol proposes the same deployment problem under a different name unless its design changes who bears the deployment cost.

Why Proton and Tuta chose walled gardens instead

Tuta’s design decision is the more informative data point. Tuta deliberately does not use PGP. It encrypts the subject line, which PGP leaves exposed, using a proprietary scheme that only interoperates with other Tuta accounts.4 That is not an oversight; it is a considered tradeoff. Metadata protection and cross-provider interoperability were in direct tension, and Tuta chose metadata protection. Proton chose the opposite tradeoff: PGP support for interoperability, at the cost of leaving headers exposed exactly as Latacora describes.

Neither company’s choice was primarily commercial lock-in, though lock-in is a real side effect. A standard that promises both full interoperability and full metadata protection is promising to resolve a tradeoff that the two most credible European encrypted-email vendors independently concluded could not be resolved within the constraints of SMTP-compatible transport. A viable proposal needs an account of what changes that constraint, not just a restatement of wanting both properties at once.

The closest working prior art: Delta Chat and Chatmail

Delta Chat is already close to the user’s architecture, and the wiki’s Secure and decentralized communication stacks covers it as a messenger. It deserves separate attention here because its design directly answers several of the proposal’s open technical questions.

Chatmail, Delta Chat’s purpose-built relay, federates over standard SMTP between relay operators, so any operator can stand up a compatible server without coordinating with a central authority. Clients speak a constrained mail protocol to their home relay rather than full IMAP, and Delta Chat’s desktop and mobile apps implement that client role directly, which is the rough equivalent of the user’s proposed c2s protocol. Chatmail-native accounts cannot send or receive without encryption at all; there is no plaintext fallback within the chatmail profile, and a “classic” mode exists separately for talking to ordinary, non-chatmail email addresses, marked visibly as unencrypted in the client.5 Current Delta Chat V2 encryption uses a minimal, carefully selected subset of OpenPGP rather than a new cryptographic design, and does not yet provide perfect forward secrecy; a planned Autocrypt v2 revision is intended to add it.6

This matters for scoping the user’s proposal in two ways. First, capability discovery and graceful fallback are already solved at the product level, just not at the protocol level: Delta Chat’s fallback is a client-side mode switch, not a machine-readable federation-wide capability advertisement that any compliant provider could query. Second, and more importantly, Delta Chat has spent years proving the deployability half of exactly this idea and has not converted that into mainstream adoption beyond a privacy-conscious niche, despite being free, open, and requiring no new provider relationship. That is evidence about the demand side of the problem, not only the supply side.

Why MLS is not a drop-in answer

Messaging Layer Security, standardized as RFC 9420, is the strongest modern cryptographic substrate for exactly the properties PGP lacks: forward secrecy, post-compromise security, and efficient group key agreement. It is a natural reference point for a new standard, and the user’s instinct to look past PGP toward something “MLS-shaped” is well-founded technically.

MLS is also, by its own specification, not an application protocol. It defines group key agreement and leaves identity, authentication, delivery, metadata protection, abuse handling, and backup entirely to the system built on top of it.7 No IETF work applies MLS to email specifically; current MLS deployment activity targets synchronous messengers such as Air and White Noise, and experimentally Matrix, none of which share email’s asynchronous, multi-hop, store-and-forward delivery model or its expectation of working with decades of existing infrastructure. Adapting MLS to email’s delivery model, rather than a messenger’s, would itself be a multi-year specification effort, not a matter of pointing an existing library at SMTP.

The federation objection

Signal’s Moxie Marlinspike made an argument in 2016 that is a direct, unresolved objection to this proposal, not a historical curiosity. His claim: federated protocols move at the pace of their slowest deployed operator, because a new client-visible feature cannot ship until every federated peer supports it or the protocol accepts fragmented behavior. He named email as the canonical failure case, arguing that federation is the specific reason email was never end-to-end encrypted by default and, in his view, never would be.8

The historical record since then complicates, without refuting, that claim. Matrix and XMPP remain federated and add features more slowly than centralized competitors, consistent with Moxie’s prediction. Chatmail is a counterexample of sorts: it federates, and it did ship default encryption, by making the tradeoff Moxie said federation could not afford, namely accepting a smaller, opinionated feature set and a strict all-or-nothing encryption policy rather than trying to keep every legacy behavior compatible. That suggests Moxie’s argument is better read as a warning about scope discipline under federation than a hard impossibility result: a federated encrypted-email standard can plausibly move fast enough if it is willing to be a strict subset of email’s current behavior, the way Chatmail is, rather than a strict superset that also stays compatible with every legacy client and server. The user’s proposal, by including a general IMAP-proxy compatibility layer and graceful plaintext fallback, is scoped closer to the superset, harder case.

What the s2s/c2s split would actually need to specify

Treating the proposal as an engineering problem, independent of adoption risk, the split into a federation protocol and an access protocol maps onto real, partly solved pieces:

Layer Nearest existing building block Open problem
s2s federation and transport SMTP plus DKIM plus MTA-STS Advertising per-recipient e2ee capability and key material during routing, not just after delivery
Key discovery and capability advertisement WKD, Autocrypt headers, DNS-based discovery A verifiable, revocable, phishing-resistant binding between address and key, at federation scale
Message-layer cryptography MLS group state, or a minimal OpenPGP profile as Chatmail uses Applying either to asynchronous, multi-recipient, store-and-forward delivery with working forward secrecy
c2s access JMAP, a modern replacement for IMAP already shipping at Fastmail and elsewhere None specific to encryption; JMAP is a credible base regardless of the encryption design
Legacy compatibility An IMAP proxy translating the new c2s protocol for existing clients Proxies cannot expose message content a legacy client’s crypto stack does not understand, so the fallback path likely means plaintext-to-legacy-client, not silently-decrypted-to-legacy-client
Metadata protection Chatmail’s random addresses and header minimization; Tuta’s proprietary subject encryption No federated design has protected recipient and routing metadata to the degree a closed system like Tuta can, because routing metadata is what federation is

The IMAP-proxy compatibility goal deserves a direct caution. An IMAP proxy can translate protocol framing, but it cannot give a legacy client a decryption capability it does not have. Practically, the proxy either hands the legacy client already-decrypted plaintext, which reintroduces exactly the server-side plaintext exposure the standard exists to remove, or the legacy client simply cannot read the encrypted message, which is the plaintext-fallback case by another name. “IMAP compatibility” and “end-to-end encryption to legacy clients” are close to mutually exclusive; the proposal should pick which one it means.

JMAP deserves separate note-worthiness independent of the encryption question: it is already displacing IMAP at Fastmail and other operators as a general modernization, and a new encrypted standard could simply adopt JMAP as its c2s layer rather than design one, concentrating novel work on the s2s and cryptographic layers.

Where a European challenger has genuine standing

None of this means the wedge is worthless, but it relocates where the wedge is.

The IETF’s OpenPGP Email Summit has met nine times as of April 2025 and is actively revising the OpenPGP standard itself, including work on header and subject-line encryption and a post-quantum “crypto refresh.”9 That is the existing venue where this exact problem is being worked on by the community that would need to adopt whatever a new entrant proposes. A credible standard effort more plausibly starts by contributing to or forking that process, with Proton and other vendors already present, than by specifying a parallel protocol from zero and hoping providers migrate to it.

The strongest asymmetric argument for the user’s proposal is Proton and Tuta’s own commercial incentives. Both companies profit from a partially closed garden: cross-provider friction pushes couples, families, and organizations toward consolidating on one paid provider. Neither has a strong commercial reason to fund the metadata-protection and capability-discovery work a truly open standard needs, even though both publicly favor open standards rhetorically. A challenger without that installed base has less to lose from interoperability and could credibly commit to the standard-maintainer role in a way an incumbent cannot. That is a real structural opening, not a technical one.

Assessment

Claim in the proposal Verdict
Proton and Tuta lack cross-provider e2ee True, and a real customer-visible gap
The gap is unaddressed by existing standards False; PGP addresses it and has for decades, with known, well-documented failure modes
A new protocol is needed rather than fixing PGP’s gaps Plausible only if it solves metadata protection and key discovery, which is most of PGP’s unsolved problem restated
MLS is a natural cryptographic base True for the message layer; MLS supplies none of the identity, delivery, or metadata design email needs
Federation is compatible with fast iteration Contested; Chatmail is a working counterexample, but only by accepting a narrower feature set than the user’s IMAP-compatible design implies
An IMAP proxy can preserve compatibility without weakening the standard Not as stated; full legacy compatibility and end-to-end encryption to that legacy client are in tension
A first-mover, standard-maintainer position is a viable business strategy Structurally plausible, given Proton and Tuta’s incentive not to do this work themselves, but unproven: no venture has converted “we wrote the open email-encryption standard” into a sustainable business, and Delta Chat’s adoption ceiling is the closest available evidence of ceiling risk

Decision

The strongest version of this venture is not “build a new protocol and hope for adoption.” It is:

  1. Treat Delta Chat and Chatmail as the closest working reference implementation of the s2s and c2s split, and evaluate contributing to Autocrypt v2’s forward-secrecy work or Chatmail’s federation model directly before specifying a parallel protocol.
  2. Contribute to the active OpenPGP Email Summit process on header and subject-line encryption, since that is the standing venue where Proton and other vendors are already present, rather than compete with it for attention.
  3. Scope the first shippable product narrowly, Chatmail-style: a strict, opinionated encrypted profile with no plaintext fallback inside the profile, rather than a general IMAP-compatible superset, to test Moxie’s objection empirically rather than inherit its risk by design.
  4. Treat capability discovery as the genuinely novel, unsolved piece worth specifying: a machine-readable, federation-queryable “does this address support X” check, before send, is closer to new work than the cryptography or transport layers are.
  5. Compete on being the operator who does the unglamorous deployment and support work Delta Chat’s volunteer-driven ecosystem has not resourced, consistent with Privacy market gaps’s broader finding that the market’s scarce resource is usually polish, migration, and support, not new cryptographic primitives.

  1. The PGP Problem sets out the metadata-exposure, forward-secrecy, and legacy-cipher critiques of PGP for email. ↩

  2. Autocrypt Level 1 specification documents the deliberate choice to perform opportunistic key exchange without verification, and its accepted active machine-in-the-middle risk. ↩

  3. GnuPG’s Web Key Directory FAQ describes the discovery mechanism and its dependence on correct per-domain deployment. ↩

  4. Proton’s own comparison of Proton Mail and Tuta describes Tuta’s proprietary, non-PGP-interoperable encryption and its subject-line protection. ↩

  5. Delta Chat’s Encryption v2 announcement and the chatmail relay documentation describe the mandatory-encryption chatmail profile versus the separate classic-email compatibility mode. ↩

  6. Delta Chat’s security documentation distinguishes current OpenPGP-subset guarantees from planned Autocrypt v2 forward-secrecy properties, as summarized in Secure and decentralized communication stacks. ↩

  7. RFC 9420 specifies group key agreement and explicitly leaves identity, delivery, and metadata protection to the application. ↩

  8. Moxie Marlinspike’s federation argument is best preserved in community discussion of Signal’s ecosystem posts and the widely cited Hacker News thread on Signal and federation, which quotes his email-specific claim directly. ↩

  9. The 9th OpenPGP Email Summit and its predecessor meetings show active, vendor-attended work on the standard’s remaining gaps. ↩

Built on 13 sources (13 external).

Working out connections…