File
SMF·CANARY-MAIL
Received on
31.07.2026
Reviewed on
28.09.2026
Exhibits annexed
3
Questions
4

SMF·CANARY-MAIL

Can a prompt replace Canary Mail?

Email — email clients and hosted mail

Almost Verdict recorded on 28.09.2026 · Verified on 31.07.2026
Price
$3/moSource: canarymail.io · Checked on July 31, 2026
Per year
$36
Build time
A week
Category
Email
Votes
0 votes
YesAlmost (checked)Not yet

Exhibit tracking slip

Exhibit A The prompt
Exhibit B What you lose
Exhibit C Why people still pay: mail infrastructure, integrations, and client polish
Exhibit Q Questions

Verdict

OpenPGP libraries are mature and free, so encrypting, signing and verifying mail is not the obstacle. Key management is. Canary's contribution is hiding that: it finds the recipient's key, warns you when a signature does not verify, and stops the encryption from becoming a chore you abandon. Building that discipline well is real work on top of an already substantial IMAP client, and a single missed verification failure defeats the whole point.

Exhibit B — What you lose

Exhibit A — The prompt

Received on31.07.2026
Build a desktop email client with first-class OpenPGP support. Encryption is the organising feature, not a settings page.

Account: one IMAP and SMTP account, credentials in the OS keychain, password and OAuth authentication both supported. Incremental resumable sync, SQLite index with full-text search, standards-based threading, HTML rendered in a sandbox with remote content blocked by default.

Key management, which is where this build earns its place. Use a maintained OpenPGP library; never implement crypto primitives. Support:

- Generating a key pair, with the private key encrypted at rest under a passphrase and never written unencrypted to disk.
- Importing and exporting keys in standard armoured format.
- A local keyring mapping addresses to public keys, showing each key's fingerprint, algorithm, creation and expiry date.
- Importing a correspondent's key from an attached key block on a received message, which is how keys actually travel in practice. Never import silently: show the fingerprint and require confirmation.
- Marking a key as verified after an out-of-band fingerprint check, and displaying verified and unverified keys differently everywhere.

Sending: when every recipient has a key in the keyring, encrypt by default and show it clearly in the composer. When any recipient does not, refuse to encrypt to a subset silently — either send in the clear with an explicit acknowledgement, or drop the recipient. Sign every outgoing message. Encrypt attachments along with the body.

Receiving: decrypt on the fly with the passphrase held in memory for a configurable timeout. Show three distinct states on every message, never collapsed into one badge: encrypted or not, signed or not, and signature valid, invalid, or from an unverified key. An invalid signature must be visually loud — this is the single most important interface decision in the build, because a quiet warning is the same as no warning.

Subject lines are not encrypted by OpenPGP. Say so in the interface when composing an encrypted message, since users routinely assume otherwise.

Search: index decrypted bodies locally so encrypted mail is searchable, and state plainly in the README that this means the local index contains plaintext and should sit on an encrypted disk.

Display a persistent notice that this build has had no independent security review.

Out of scope: mobile apps and push, running a mail server, S/MIME, any key-exchange service for recipients without PGP, and AI features.

Opening prefills the prompt — press enter to run it.

Exhibit B — What you lose

  • B.1 the iOS and macOS apps and their push notifications
  • B.2 Canary's own key-exchange service for recipients without PGP
  • B.3 the AI features layered on top of the client
  • B.4 provider-specific handling that keeps threading correct everywhere

Prior art

Exhibit C — Why people still pay: mail infrastructure, integrations, and client polish

Because encrypted mail only works if the person on the other end can read it, and bridging the gap for recipients who have never heard of PGP is a service, not a library call.

Questions

Can I bring my Canary setup over?

Mail stays on the server. Your PGP keys export from Canary in standard armoured format and import directly, which is the part that matters. Canary's own key-exchange contacts — recipients who used its service rather than real PGP — do not transfer and cannot be reached encrypted here.

Will my recipients be able to read encrypted mail?

Only if they use PGP, which almost nobody does. This is the honest limitation of the whole approach: it works well between two people who both set it up, and not at all otherwise. The prompt refuses to fake it by encrypting to a subset of recipients.

What does it cost to run?

Nothing beyond the mail account you already have. The library is free, everything is local, and the only real requirement is that the machine holding the local plaintext index has full-disk encryption.

What is the one thing that does not survive the rebuild?

Bridging to people without PGP. Canary can get an encrypted message to someone who has never installed anything, through its own service. A pure OpenPGP client cannot, which means the feature only works inside a circle you have already convinced.

Receipt

Already built this yourself?