Why can't my mom email me?
Proton Mail’s automatic use of public PGP keys to encrypt outgoing email is causing some recipients to get messages they can’t read, highlighting how fragile encrypted email remains in practice. Commenters clash over whether uploading a key to a public keyserver should be treated as blanket consent to receive encrypted mail, and point to poor UX, forgotten keys, and non‑email use cases for PGP as sources of failure. More broadly, the thread contrasts Proton’s “privacy by default” push with arguments that true end‑to‑end encryption for federated email is hard to deploy safely at scale and may be better served by alternative messaging systems.
Why the mom’s emails were unreadable
- Proton automatically encrypts outgoing mail if it finds a recipient key on keys.openpgp.org (KOO).
- KOO’s operator states: email addresses are only published after verification; the OP’s address was verified and discoverable.
- The recipient apparently lost or no longer used their private key, so encrypted messages appeared blank in their client.
What does publishing a PGP key imply?
- One camp: uploading an encryption key, verified for a specific email, is an explicit invitation to encrypt mail to that address. That’s what public keyservers are for.
- Other camp: PGP keys serve many purposes (signing packages, git commits, backups, password stores). Publishing a key with an email UID is not consent to default email encryption.
- Several people note the distinction between signing and encryption subkeys and argue users often don’t understand or configure this correctly.
Opt‑in vs. opt‑out and UX expectations
- Critics say Proton “silently” opted people into E2E for federated email:
- No obvious UI cue, no per-recipient prompt, no easy way to see which key was used.
- Encrypted mail may be undecryptable if the recipient’s PGP setup is old, experimental, or broken.
- Suggested fixes:
- Per-recipient prompts (“we found a key; encrypt?”) or opt-out toggles.
- A standard flag or metadata indicating “use this key for email by default.”
- Rely primarily on WKD/domain-level policy as a stronger, explicit signal.
- Proton staff defend “privacy by default,” compare it to HTTPS-by-default, acknowledge this failure mode, and say they’ll improve visibility and possibly opt-out.
PGP usability and ecosystem limits
- Multiple commenters recount ancient, forgotten, or unrecoverable keys and expired keys on servers.
- Classic “Why Johnny can’t encrypt” research is cited: PGP remains hard for normal users, especially across devices and with smartcards.
- Some argue email is simply the wrong medium for mass E2E; better for niche or expert use.
Alternatives and provider choices
- Fastmail’s public rationale for not doing server-side PGP (search, spam, key loss, limited threat reduction) is discussed and largely respected.
- Proton’s bridge and protocol choices are critiqued by power users who want more standard IMAP/SMTP behavior.
- Many suggest using Signal, Matrix, or XMPP for everyday secure messaging instead of email-based PGP.