Email is the most over-trusted communication medium in the editorial-register customer’s working life. A journalist composes a sensitive message, hits send, and trusts that the recipient will read it without intermediate parties seeing the content; the trust is misplaced more often than the working assumption suggests. The SMTP protocol that carries the message was designed in the early 1980s for an internet of cooperating academic hosts; the privacy properties the protocol provides are nil by default, and the layered improvements (opportunistic TLS, MTA-STS, DANE, PGP) are uneven in coverage, optional in deployment, and bypassed by default in most threat models the customer ought to be working against.
This article reads the forensic surface of email honestly — what the mailhost operator sees mechanically, what the operator does not, what TLS-in-transit and PGP narrow down — and the practical posture an editorial-register customer can reach with offshore mail hosting from a civil-liberties jurisdiction. It is the operational counterpart to the post-Snowden framing of privacy hosting that sits one step earlier in the threshold-questions decision tree.
The envelope metadata that cannot be avoided
The SMTP protocol requires the mailhost to know, in plain text, who is sending mail to whom. The envelope metadata — the MAIL FROM: and RCPT TO: lines that drive delivery — is what the protocol uses to route the message; a mailhost that did not see this would not be a mailhost. The same holds at every hop in the delivery chain: the sending mailhost, every intermediate relay, the receiving mailhost. The envelope metadata is the operational reality of email, and any mailhost provider that claims otherwise is misrepresenting what it operates.
What this means for an editorial-register customer is that the mailhost the customer chooses sees, mechanically, the timestamps of every inbound and outbound message, the addresses of every correspondent, the size of each message, and (because the receiving mailhost negotiates TLS at the protocol layer with the sender’s mailhost rather than with the user’s mail client) the IP addresses of the mailhosts the customer corresponds with. These facts are not hidden by sober operator policy; they are visible to the operator in the same way that the recipient address on a posted envelope is visible to the postal service.
The discipline that narrows the surface, where it matters, is to write less. A correspondence with a sensitive source that uses email is a correspondence whose envelope metadata exists on three or four mailhosts and is durably retained at each of them. The conservative posture is to use email for the introduction (where the source first reaches out) and to move to a Tor hidden service or to OnionShare for any subsequent transfer; the leak-aggregator stack covers the architecture that supports the move.
What the operator does NOT see
The operator’s mechanical visibility is bounded. The body of a TLS-protected message in transit is not visible to a passive observer between the two mailhosts that negotiated the TLS session, and (assuming the sender’s mailhost negotiated outbound TLS, which most modern mailhosts do) the inbound message body is not visible to the operator’s network operator either. The contents of a PGP-encrypted message are not visible to the operator regardless of TLS state — the PGP layer protects the body even when stored at rest on the operator’s disk. The IMAP login from the user’s client to the mailhost is TLS-protected by default; the IMAP login IP is visible to the operator (because the mailhost terminates the TLS session) but the user’s password is not retrievable from the mailhost’s records (the operator stores a salted hash, not the cleartext).
These bounds matter. A customer whose threat model is “the operator sees less than my domestic ISP does” is well-served by an offshore mailhost in a civil-liberties jurisdiction; the operator-side visibility is the envelope-metadata surface, not the message-body surface, for any TLS- and PGP-disciplined correspondence. The customer whose threat model is “no party other than the recipient sees anything” is mistaken about email; that threat model wants Signal, not email, and email is not the right tool for it.
The discipline that compounds with offshore hosting: PGP for any correspondence whose body matters, MTA-STS published on the customer’s domain so that opportunistic TLS becomes opt-out rather than opt-in, DKIM signing so that the operator’s DKIM-private-key compromise becomes a singular operational event rather than a long-tail forensic surface. The Mail Unlimited tier and the Mail Team tier publish DKIM/SPF/DMARC on the customer’s behalf; the Mail Solo tier publishes them as well, with the customer choosing the domain.
The TLS-in-transit reality
Opportunistic TLS — the SMTP STARTTLS extension — is the dominant deployment pattern for mail-server-to-mail-server encryption. The pattern is opportunistic in the operational sense: the sending mailhost asks the receiving mailhost whether TLS is supported, and if the answer is yes, the session upgrades to TLS; if the answer is no, the session continues in cleartext. The opportunistic posture is honest about its limitations — a network observer between the two mailhosts can downgrade the connection by stripping the STARTTLS advertisement, and the sending mailhost’s default behaviour is to fall back to cleartext rather than to refuse delivery.
MTA-STS (RFC 8461) hardens this. MTA-STS is a domain-published policy that tells sending mailhosts that the receiving mailhost requires TLS and refuses cleartext delivery. A customer whose mailhost publishes an MTA-STS policy with mode: enforce is operating a mailhost that will not accept cleartext mail from any sender that respects the policy; the policy is published as a DNS TXT record and a small static file at a well-known URL on the customer’s domain. DANE (RFC 7672) provides a separate hardening through DNSSEC-signed certificate associations; both layers are operational and OffshorePress’s mail tiers ship MTA-STS policy templates that the customer enables at provisioning time.
The discipline matters because the typical adversary at the network layer is not Mossad-tier; it is a domestic ISP or a national-firewall infrastructure that strips the STARTTLS advertisement on a small fraction of connections and harvests the cleartext that results. MTA-STS in enforce mode rejects the downgrade. The cost is small (the customer’s mail is rejected by the small fraction of legacy mailhosts that have not deployed TLS, an increasingly small fraction); the benefit is that the customer’s correspondence is no longer downgradable on the wire by a network adversary.
PGP’s actual protection versus its expected protection
PGP encrypts the body of a message between the sender’s PGP public-private keypair and the recipient’s PGP public-private keypair. The body is opaque to anyone who does not hold the recipient’s private key, including every mailhost in the delivery chain and every network observer between them. The protection is durable: a PGP-encrypted message intercepted by an adversary in 2026 and stored against future cryptographic compromise is protected against today’s cryptographic primitives, and the long-term forward-secrecy property is bounded by the recipient’s private-key custody rather than by network-layer state.
What PGP does NOT protect: the envelope metadata (PGP encrypts the body, not the SMTP envelope), the subject line (Subject is a header, headers are not encrypted by PGP — the OpenPGP standard offers an extension for protected headers but support is uneven), the timestamps and routing trace in the Received headers, the size of the message, the from-and-to addresses. A correspondence between a journalist and a source that is PGP-encrypted is a correspondence whose bodies are protected and whose patterns are not. The discipline that compounds is to keep the subject lines neutral, to write short messages where possible (so that size patterns do not signal content shape), and to move to a non-email channel for the substantive correspondence after the introduction.
The practical limitation of PGP that operationally matters: the recipient must have set up PGP. A journalist with a PGP keypair and a source without one cannot have a PGP-encrypted correspondence; the body is in cleartext on the wire. The discipline of asking “do you use PGP?” before sending a sensitive draft is the discipline that prevents the most common operational failure of PGP, which is a single message in cleartext that exposes everything the encrypted thread was supposed to protect.
Mail at rest: the forensic surface of mailbox storage
A message that has been delivered and stored in the recipient’s mailbox sits at rest on the mailhost’s disk. The mailhost’s disk is encrypted at the LUKS layer (full-disk encryption at rest is the default operator posture for a civil-liberties VPS); the message contents are unreadable to anyone who does not hold the LUKS passphrase. The IMAP server, however, holds the LUKS key while it is running — it has to, in order to serve mail to the user’s client — so the operating mailhost’s memory contains the key, and a compromise of the running mailhost recovers the on-disk corpus.
The discipline that compounds: at-rest PGP for the mailbox itself. The customer’s IMAP client downloads PGP-encrypted messages and the on-disk image at the mailhost stays as PGP ciphertext; even a compromise of the running mailhost recovers PGP-ciphertext, not cleartext. The cost is operational: the customer’s mail client and the customer’s correspondents must both be PGP-disciplined for the protection to attach. The benefit is that the mailhost’s at-rest forensic surface narrows to envelope metadata plus PGP-ciphertext bodies, which is the smallest residual surface SMTP permits.
The IMAP retention behaviour is the customer’s choice. The default IMAP retains every message until the user deletes it; the expunge operation moves a deleted message to a trash folder; the trash folder retains the message for 30 days by default and then deletes it permanently. The customer who runs a tighter retention policy — every message older than 90 days is expunged automatically — narrows the at-rest forensic surface further. The discipline is the customer’s; the mailhost executes the customer’s policy without comment.
Mail-server jurisprudence
Two cases anchor the editorial-register customer’s understanding of mail-server jurisprudence in the jurisdictions OffshorePress operates from. In Switzerland, the Federal Administrative Tribunal’s 2019 decision in ProtonMail AG v. Federal Department of Environment, Transport, Energy and Communications (A-550/2019) set the procedural threshold a foreign-jurisdiction request must clear before a Swiss mailhost is compelled to disclose. The decision, which sided with the mailhost on the procedural question, established that a domestic Swiss legal vehicle is required to compel a Swiss mailhost — a foreign request that does not produce that vehicle is operationally unenforceable. The case is the canonical reference for Switzerland’s mail-server posture.
In Iceland, the framework is statutory rather than case-law-anchored: the Icelandic Modern Media Initiative (Resolution 23/138 of the Althingi, 2010) and the Whistleblower Protection Act of 2020 extend source-protection obligations to the mail layer. An Icelandic mailhost compelled to disclose by a foreign request must clear the same domestic-vehicle threshold that the Swiss case established, and the Icelandic statutory framework adds an explicit source-protection layer that applies regardless of the request’s domestic vehicle. The combination produces a mail-server posture that resists fishing-expedition disclosure as a matter of established legal frame; the Iceland dossier covers the statutory detail.
The practical implication for an editorial-register customer is that the choice between Iceland and Switzerland for a mail deployment reduces to the adversary profile. Where the adversary is an EU domestic prosecutor with bilateral cooperation channels, Iceland’s geographical and treaty distance is the more conservative answer; where the adversary is more diffuse and the latency to the team’s most-frequent correspondents matters, Switzerland’s central-European location is the working choice. Both jurisdictions reject the fishing-expedition disclosure that the editorial-register adversary most often deploys.
Disclosure order shapes
A disclosure order arriving at a Swiss or Icelandic mailhost is not a single legal instrument; it is a category of instruments with different scopes. The narrowest instrument requests envelope metadata for a specific account over a specific date range. The broader instrument requests the at-rest mailbox contents for a specific account. The broadest instrument requests both plus a continuing surveillance authority (a wiretap on future correspondence). Each shape has a different threshold under the destination jurisdiction’s procedural law and a different operational response from the mailhost.
The editorial-register customer’s posture against the narrow instrument is that the envelope metadata exists; the discipline is to keep correspondence patterns sober. The posture against the at-rest instrument is PGP — encrypted bodies are unreadable regardless of disclosure. The posture against the continuing-surveillance instrument is that both jurisdictions require domestic legal vehicles for prospective surveillance and the threshold is meaningful; the customer’s documentation discipline (a warrant canary, per the standard editorial-register posture) signals to readers when the customer’s operator has received an order of any shape.
Practical posture for the editorial-register customer
The working posture for an editorial-register customer running offshore mail is layered. The mailhost is in a civil-liberties jurisdiction (Iceland or Switzerland); the customer’s MTA-STS policy is published in enforce mode; the customer’s domain runs DKIM/SPF/DMARC managed by the mailhost; PGP is set up for any correspondence whose body matters; the customer’s IMAP retention policy expunges messages older than the working window the editorial workflow requires. The customer’s Mail Solo, Mail Team, or Mail Unlimited tier carries the operational footprint at the operator side; the customer’s discipline carries the rest.
The discipline that compounds across the layers: write less, encrypt more, retain less, and treat email as the introduction channel rather than the substantive-correspondence channel for sensitive work. The migration runbook covers the move from a domestic mailhost to an offshore one; the payment-rails comparative covers the financial-surface decoupling that should accompany the move.
Closing
Email is forensic evidence whether or not the customer wants it to be. The discipline that narrows the surface — choice of jurisdiction, MTA-STS, PGP, retention policy, correspondence pattern — narrows it materially but does not eliminate it. The editorial-register customer who treats email as the introduction channel and moves to a non-email medium for substantive correspondence is operating against the actual threat model of email; the customer who trusts email past its protocol-layer guarantees is operating against an imagined threat model. The brief is to be honest about what email is, and to layer the discipline that compounds with offshore hosting on top of that honest reading.
Payment in Monero, Lightning, on-chain Bitcoin, or cash by post. The financial-surface decoupling matters for mail too — a card-processor relationship that funds the mail account is a forensic surface attached to the mail account, and the discipline of decoupling extends to the mail tier in the same way it extends to the hosting tier.