Encryption for People

Encryption for People

Written on 24 September 2026 from hmailserver/docs/OpenPGP.md, ZeroAccess.md, SmimeAuthority.md, SealedMail.md, RemoteDomains.md (Gateway encryption) and ConfidentialMessages.md, and brought up to 6.3.4 (27 September 2026, schema 6104), on 26 September 2026. S/MIME in the webmail has been there since 6.3.2, and everything else on this page is new in 6.3.4. Brought up on 5 October 2026 to 6.3.6 (6 October 2026, schema 6108), for what 6.3.6 changes on this page. 6.3.7, the latest release (17 October 2026, schema 6108), is not yet reflected here.

Encryption and Certificates is about transport: TLS between servers and between a client and this server, which protects a message on the wire and ends at the next server. This page is about encrypting the message, so that the person it is for - and nobody on the way, this server included - can read it.

The design rule running through all of it: this server holds nothing that decrypts a person's mail. Keys are made in the browser, kept wrapped under a passphrase or password the server never sees, and the cryptography happens in the page. The one exception is gateway encryption (§6), which encrypts at the server to a partner organisation's key, and holds no private key either. The cost of that rule is said as plainly as its benefit: nothing on this server can recover mail encrypted to a key that was lost.

You want	Use	Section
Colleagues and partners who use S/MIME in Outlook, Apple Mail or the webmail	S/MIME in the webmail	§1
S/MIME inside the organisation without buying a certificate per person	A domain's S/MIME authority	§2
Correspondents who use GnuPG, Thunderbird, Proton, Mailvelope	OpenPGP in the webmail, and the Web Key Directory	§3
To write privately to somebody who has no key at all	A password-protected message	§4
A mailbox the administrator cannot read	Zero-access	§5
Everything to one partner organisation encrypted, whatever the sender's client did	Gateway encryption	§6
A message that stops being readable after a week	A message that expires - which is not encryption	§7
A stolen disk or backup to hold nothing readable, while the mailbox works as it always has	Mailbox encryption at rest - which the server can read, and so is not on this page	Message Storage

1. S/MIME in the webmail

Since 6.3.6 a signer's certificate is kept for encrypting replies only when its chain is trusted, only under the message's From address, which it must name, and a different one for an address that has one only when the reader chooses Keep this certificate, shown with its fingerprint (a correspondent's renewed certificate takes that one click). A correspondent whose certificate is self-signed or from an authority this machine does not trust is imported on the Security page once it has been checked with them. Certificates kept before the upgrade stay: the Security page lists each with its address and fingerprint, and Remove takes one out (SmimeAuthority.md). Up to 6.3.5 the webmail kept the certificate of any signed message as a correspondent's, without a trust check and under the first address it named.

In 6.3.2 and 6.3.3. The webmail signs, verifies, encrypts and decrypts S/MIME with the browser's Web Crypto API. The person imports their certificate and key (a PKCS#12 file) on the Security page; the private key is wrapped with the account's password before the server stores it, so the server keeps a blob it cannot open. It works only on a page opened over HTTPS - the browser withholds its cryptography from any other - and the page says so instead of offering Sign and Encrypt.

2. A domain's S/MIME authority

Schema 6095, since 6.3.4. S/MIME needs a certificate for every person, normally bought one at a time. Inside one organisation that is the wrong shape; Exchange with Active Directory Certificate Services gives every mailbox one from the organisation's own authority. This server does the same, one domain at a time:

• An administrator creates the domain's authority in the Control Deck: a P-256 (or RSA-3072) root, constrained to the domain's own addresses, its private key held under the platform's secret store (DPAPI with the machine's key on Windows, the key file on Linux).
• A person enrols in the webmail: the key pair is made in the browser and never sent; the authority signs a certificate request for the account's own address, valid for a year.
• A colleague's certificate is looked up by address when a message to them is to be encrypted; the webmail trusts the domain's roots by itself, and reads the authority's record, so a revoked certificate is refused and no longer encrypted to.
• The root and a signed CRL are served over plain HTTP by the web services listener, named by the root's fingerprint, for other clients - Outlook, Apple Mail - to trust and check.
• A deleted account's certificates are revoked; a rotation keeps the old root published and trusted until its last certificate expires.

What it is not: not Active Directory Certificate Services and not connected to one; no key escrow, so no recovery of mail encrypted to a lost key; no OCSP; no elliptic-curve encryption in the webmail (a P-256 certificate signs); one address per certificate; no automatic renewal; no Control Panel page and no COM - the Deck and REST are the surfaces. The authority's key opens only on the machine that made it; restored elsewhere it must be rotated (Backup and Restore §15.8).

3. OpenPGP in the webmail, and the Web Key Directory

Schemas 6050 and 6080 to 6082. Two halves, worth keeping apart.

The page does OpenPGP in the browser, in a module written on the Web Crypto API with no library vendored:

• A key is made or imported there - Curve25519 or RSA - and kept as an ordinary OpenPGP secret key encrypted under a passphrase this server never sees, so the same bytes open in GnuPG. PGP/MIME is signed, encrypted, decrypted and verified in the page; inline PGP is read, never written. Both directions are proved against GnuPG 2.4 by build/check-portal-openpgp.js, which ran on every pull request until GitHub became unavailable on 18 September 2026 and is run by hand since (Contributing).
• A key page with fingerprints in groups of four, expiry and revocation.
• Autocrypt headers written on outgoing mail and read on incoming.
• Trust made visible: a correspondent's key is remembered the first time it is seen; a different key for the same address is a warning in the reader naming both fingerprints, and is neither encrypted to nor shown as good until the reader accepts it; a key marked verified in person puts a green mark beside that sender on every good signature from then on.
• A correspondent's key is looked up in their own domain's Web Key Directory, or at a keyserver where the administrator allows it (lookup_keyserver, off by default).

The directory publishes your accounts' OpenPGP public keys at the well-known address a correspondent's client asks, so that "I would encrypt to them if I had their key" is not the end of it. It needs three switches on - the server's (OpenPGPWebKeyDirectoryEnabled), the domain's and the account's own - all off by default, the web services listener's HTTPS port, and, for the advanced method clients try first, an openpgpkey.<domain> host record and a certificate for it (DNS for Your Domain §8.10). Keys are served over HTTPS only.

Not implemented, and refused by name: version 5 and 6 keys and AEAD; DSA, ElGamal and the NIST and Brainpool curves; smartcards and hardware tokens; the web of trust; a draft or a scheduled send that is to be sealed. Curve25519 needs Chrome 137, Firefox 130, Safari 17 or later. There is no Web Key Service (no submission by mail), no upload to any key server, no OPENPGPKEY DNS records, and a revoked key stays published until somebody removes it.

4. A password-protected message to anyone

Schema 6082. For the correspondent with no key. The sender ticks Protect with a password, types a password (the form says how strong it is and sends it nowhere) and optionally a hint. The page encrypts the text and the attachments to the password as one OpenPGP message - the shape gpg -c writes - and what goes out by SMTP is a short notice with a link to a reading page on this server. The recipient's browser decrypts there, shows the message and offers each attachment, and a reply goes back the same way, under the same password. The plaintext never crosses the internet and never rests on this server.

It cannot stop the recipient copying what they read; the sender's own Sent folder keeps the notice alone; and the password has to reach the recipient another way - by phone, in person.

5. Zero-access mailboxes

Schema 6083. A mailbox this server holds and cannot read - the Proton model, with its trade-offs. An administrator allows it server-wide once (zero_access_allowed, off by default); the person then switches it on for their own account on the webmail's Security page. From then on every message delivered to them is encrypted - after the spam and virus filters, the rules and the Sieve script have had the text - to their own OpenPGP key, and what is stored is PGP/MIME with the headers in the clear. The copy of what they send from the webmail is sealed too.

The key's secret half is held in two forms only the person can open: under a passphrase the browser derives from their account password, and under a recovery key they write down before the switch is thrown - the webmail refuses to switch until it has been typed back.

What it costs, said before the switch:

• The administrator cannot read, search or recover it. The message source and the account export answer 403; a password reset finds the key sealed under a password the page never saw. A forgotten password without the recovery key is the mail lost for ever.
• IMAP and POP3 hand out ciphertext - valid PGP/MIME that Thunderbird with the key imported, or GnuPG, opens. Until a client holds the key, the account is a webmail account. No bridge that decrypts for a local client exists.
• Search finds the subject, not the body.
• The plaintext was on the disk from acceptance until the seal; the account's copy is overwritten with zeros before the sealed one takes its name, and whether the bytes are gone is the filesystem's decision.
• Only what arrives afterwards is sealed; switching it off decrypts nothing already stored.
• A journal rule's copy (see Routes and Relays §14.2d) is taken before the seal, and is plaintext.
• eDiscovery sees its headers alone. A case's search matches a zero-access mailbox's messages on their headers and marks them so, and its export lists them without writing them; a legal hold still keeps what the person deletes, sealed (Compliance and eDiscovery).

Zero access is not encryption at rest. Since 6.3.4 an administrator can also have an account's stored messages encrypted to a key of the account's own, which its password opens at sign-in (Message Storage). That protects a stolen disk, a snapshot or a backup, but not the mail from the running server, which reads it while the key is open - so IMAP, POP3, search and the rules work as before, and a lost password is recovered with the domain's recovery key. The two are never on one mailbox: each switch is refused where the other is on.

6. Gateway encryption to a partner domain

Schema 6094, since 6.3.4. The organisation's shape of end-to-end mail: on a remote domain policy, Encrypt mail to this domain at this server encrypts every message to that partner, here, to the partner's own gateway key - OpenPGP (PGP/MIME) or S/MIME - whatever the sender's client did, and the partner's gateway decrypts it on arrival. One key per partner domain, pasted by the administrator and judged when saved. The Subject is not hidden. When a message cannot be encrypted the default is to refuse it (5.7.10) and tell the sender it was not sent in the clear. It does not sign, does not look keys up and does not decrypt the partner's replies - a reply encrypted to a person is opened by that person's own client or not at all, which is what §1, §3 and §5 are for. Encryption and Certificates §9.6b has the detail.

7. What the server does with a sealed message, and what is not encryption

A sealed message - signed or encrypted end to end, S/MIME or PGP/MIME - must leave this server byte for byte as it arrived, and since 6.3.4 every part of the server that would rewrite a message asks one class whether it is sealed: the blocked-attachment list does not gut it, the domain disclaimer and a list's footer are not appended to it, a mail flow rule's text conditions do not match it, and the virus scanner says in the log that it scanned ciphertext rather than calling it clean (Stopping Viruses §11.6b). None of this is a setting.

A message that expires - Gmail's confidential mode, since 6.3.4 - keeps the message on this server behind a link and deletes it on a timer. It is not end-to-end encryption: the server can read it while it exists. For a message only the recipient can read, use §1, §3 or §4.

See also: The Webmail · Encryption and Certificates · DNS for Your Domain · Backup and Restore · Security Hardening