Say why S/MIME rather than OpenPGP, and why neither is urgent #283

New Issue

Closed

opened 2026-09-04 20:28:17 +00:00 by jcoffey-dev · 0 comments

jcoffey-dev commented

2026-09-04 20:28:17 +00:00

Owner

The S/MIME entry recorded what the live probing established and what the one-way-door caveat is. It said nothing about why this is the encryption worth building, or why it sits on ROADMAP rather than in the tracker — so the choice reads as arbitrary to anyone coming to it fresh, including its author in six months.

Why neither is urgent. End-to-end encrypted mail never reached the mainstream and the reasons are structural, not a tooling gap: everyone in a thread has to take part, so the network effect works against it from the first reply; key discovery was never solved, and the keyservers were weaponised in the 2019 certificate-flooding attacks; there is no forward secrecy, so one compromised key opens everything ever received; the metadata stays in the clear, and who corresponded with whom is often the sensitive part; a lost key loses the mail permanently; and it breaks server-side search and spam filtering. EFAIL showed in 2018 that the clients themselves were exploitable through MIME and HTML handling. The privacy win that actually landed — STARTTLS, MTA-STS, DANE — needed nothing from users at all.

Why S/MIME of the two. It is the one more deployed where software gets paid for: native in Outlook and Apple Mail, routine in defence, healthcare, finance and government, because a CA issues and revokes certificates an IT department can actually administer. The web of trust never became something anyone could run at scale.

The paragraph that will matter in practice is the last: a self-hosted webmail for Stalwart draws self-hosters, privacy-minded users and European SMEs — about the densest concentration of PGP users left — so this will be asked about far more often than it would be used. That is the argument for keeping it on this page, described honestly, rather than building it on the strength of the requests or refusing it outright.

Docs only — no code, no strings, no catalogue changes.

Merged 2026-09-04 as coffey-labs/ihasmail@1f9c17ad18

_{Rebuilt from: git history, session transcript.}

The S/MIME entry recorded what the live probing established and what the one-way-door caveat is. It said nothing about **why this is the encryption worth building**, or why it sits on ROADMAP rather than in the tracker — so the choice reads as arbitrary to anyone coming to it fresh, including its author in six months. **Why neither is urgent.** End-to-end encrypted mail never reached the mainstream and the reasons are structural, not a tooling gap: everyone in a thread has to take part, so the network effect works against it from the first reply; key discovery was never solved, and the keyservers were weaponised in the 2019 certificate-flooding attacks; there is no forward secrecy, so one compromised key opens everything ever received; the metadata stays in the clear, and who corresponded with whom is often the sensitive part; a lost key loses the mail permanently; and it breaks server-side search and spam filtering. EFAIL showed in 2018 that the clients themselves were exploitable through MIME and HTML handling. The privacy win that actually landed — STARTTLS, MTA-STS, DANE — needed nothing from users at all. **Why S/MIME of the two.** It is the one more deployed where software gets paid for: native in Outlook and Apple Mail, routine in defence, healthcare, finance and government, because a CA issues and revokes certificates an IT department can actually administer. The web of trust never became something anyone could run at scale. **The paragraph that will matter in practice** is the last: a self-hosted webmail for Stalwart draws self-hosters, privacy-minded users and European SMEs — about the densest concentration of PGP users left — so this will be *asked about* far more often than it would be *used*. That is the argument for keeping it on this page, described honestly, rather than building it on the strength of the requests or refusing it outright. Docs only — no code, no strings, no catalogue changes. **Merged** 2026-09-04 as coffey-labs/ihasmail@1f9c17ad18f1 <sub>Rebuilt from: git history, session transcript.</sub>

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coffey-labs/ihasmail-github-archive#283