How to Use CodaMail in the Most Secure Fashion Possible

Minimizing trust by keeping your private key where it belongs: with you

We've written extensively about why no email provider can claim to be zero knowledge or zero trust and why you should never let a provider generate or store your private key. Those articles explain the theory. This one explains the practice.

If you want to use email as securely as possible while minimizing the trust you place in any provider, including us, here's exactly how to do it.

The goal: Remove the provider from the cryptographic code path entirely. Never give them your private key. Use software they don't control for decryption.

The Four-Step Setup

Step 1: Create Your Own PGP Key Pair Using Your Own Software

Do not let any provider generate your keys. Use software you control on hardware you control:

  • GnuPG (GPG) - The gold standard, available on Linux, macOS, and Windows
  • Kleopatra - A graphical frontend for GPG on Windows and Linux
  • GPG Suite - A macOS integration for GPG
  • OpenKeychain - For Android devices

Generate your key pair locally. Choose a strong passphrase. Back up your private key securely (encrypted USB drive, hardware security module, or air-gapped machine). The private key never leaves your possession.

Step 2: Import Only Your Public Key to CodaMail

Upload only your public key to your CodaMail account. Never upload, paste, or transmit your private key to any provider for any reason.

Your public key allows CodaMail to encrypt incoming mail to you. Your private key, which only you possess, is required to decrypt it. By uploading only the public key, you create a one-way cryptographic door: we can encrypt mail for you, but we can never decrypt it. Any mail you receive that is already PGP encrypted, is even safer.

Step 3: Enable Automatic PGP Encryption

Once your public key is imported, enable automatic PGP encryption in your CodaMail settings (See Automatic Encryption Setup section on our support page). This tells our system to encrypt incoming mail to your public key before storage.

Step 4: Use a Third-Party Client with PGP Support

Access your mail using a client you control that has native PGP support:

  • Thunderbird with built-in OpenPGP support (recommended)
  • K-9 Mail with OpenKeychain on Android
  • Mutt or NeoMutt with GPG integration
  • Evolution on Linux
  • Any IMAP client paired with a local GPG installation

By using a third-party client, you remove CodaMail completely from the decryption code path. We deliver the encrypted blob; your local software decrypts it using your locally-stored private key. We never see the plaintext after encryption, and we have no ability to influence the decryption process.

How the System Works

Understanding the mail flow helps you understand where trust is required and where it isn't.

When Plaintext Mail Arrives

Most email arrives in plaintext. This is the reality of SMTP. When plaintext mail arrives at CodaMail:

  1. The message is received via SMTP (encrypted in transit via TLS, we require TLS)
  2. It passes through SpamAssassin for spam filtering (you can disable this if you prefer)
  3. It is piped to GnuPG and encrypted using your public key
  4. It passes through your Sieve filters
  5. Prior to being written to disk, all mail is AES-256-GCM encrypted, headers and all
  6. The encrypted message is stored

Note: Even without automatic PGP encryption enabled, all mail at CodaMail is individually AES-256-GCM encrypted before being written to disk. However, the server stores the key for this. Automatic PGP adds an additional layer that only you can decrypt.

When Pre-Encrypted Mail Arrives

When a sender has already encrypted their message with your public PGP key before sending:

  1. The already-encrypted message arrives
  2. We store it (with our additional AES-256-GCM layer)
  3. We have no ability to read it because we have never possessed your private key

In this scenario, we are nothing more than a dumb encrypted blob store-and-forward. The message was encrypted before it reached us, and we have no key to decrypt it. This is as close to zero-knowledge as email can get.

Why This Is the Safest Approach

We Never Touch Your Private Key

Because you generate your keys locally and only upload the public key, your private key never exists on our systems. Not during generation, not during storage, not ever. We cannot decrypt your mail because we do not have the means to do so.

We Are Removed from the Code Path

When you use a third-party client like Thunderbird, you are running software we did not write, did not compile, and cannot update. We have no ability to:

  • Modify the decryption code
  • Inject key-logging routines
  • Push silent updates
  • Weaken cryptographic parameters
  • Capture your passphrase
  • Access decrypted plaintext

The decryption happens entirely on your machine, using software from a completely independent source, with keys only you possess.

After-the-Fact Decryption Is Impossible

Even if we were compromised, coerced, or compelled, we cannot retroactively decrypt mail that was encrypted to your public key. We do not have the private key. The math doesn't allow it. This protection applies to all mail encrypted with your public key, whether by us automatically or by the sender before transmission.

What This Setup Cannot Do

We believe in being honest about limitations. This setup is the most secure way to use email, but it is not zero-knowledge in the strict cryptographic sense. Here's why:

Plaintext Mail Exists Briefly

When plaintext mail arrives, it exists in plaintext in memory during processing before it is encrypted with your public key. This is unavoidable with email as a protocol. SMTP delivers plaintext; we encrypt it before it hits the disk, but there is a window.

This means:

  • You must trust that we operate as we describe during this brief processing window
  • You must trust that our systems are not compromised at the moment of mail receipt
  • You must trust that we do not copy plaintext before encryption

This is trust-based privacy, not trustless privacy.

Metadata Is Visible

We can see email metadata: sender addresses, recipient addresses, message ID, timestamps, message sizes, and routing information. This is inherent to SMTP. We encrypt headers at rest, but we must process them to deliver mail. We have this metadata for five days.

Pre-Encrypted Mail

When someone sends you mail that is already PGP-encrypted before it reaches us, we never see the plaintext at all. We are just storing and forwarding an encrypted blob. We will never even have the slightest access to your private key if you don't upload it. This is why encouraging your correspondents to encrypt before sending provides the strongest protection.

Practical Recommendations

For Maximum Security

  • Generate a 4096-bit RSA key or use Curve25519 (ed25519/cv25519)
  • Use a strong, unique passphrase for your private key
  • Store your private key on an encrypted drive or hardware token
  • Never export your private key to cloud storage or email it to yourself
  • Use Thunderbird or another auditable open-source client
  • Publish your public key so correspondents can encrypt before sending
  • Verify key fingerprints out-of-band when possible

For Sensitive Communications

Ask your correspondents to encrypt their messages with your public key before sending. When they do, we never see plaintext. We're just a dumb pipe carrying ciphertext we cannot read.

For Convenience with Strong Security

Even if your correspondents don't encrypt before sending, automatic PGP encryption ensures that stored mail can only be decrypted by you. Combined with a third-party client, this removes us from the decryption path entirely while still allowing you to receive mail from anyone.

The Bottom Line

This setup represents the most secure way to use email while minimizing the trust you must place in any provider:

  • You generate your own keys - We never influence key creation or entropy
  • You keep your private key - We never possess the ability to decrypt
  • You use independent software - We cannot influence decryption code
  • Pre-encrypted mail is untouchable - We're just a blob store

Is this zero-knowledge? No, because email cannot be zero-knowledge when plaintext mail arrives via SMTP. Is this the minimum possible trust? Yes. We are removed from key generation, key storage, and the decryption code path. For mail that arrives pre-encrypted, we are removed from the entire cryptographic process.

This is as secure as email gets. Not because we say so, but because the architecture leaves us with nothing to betray even if we wanted to.
← Back to Blog Posts