Encryption and sealed data

Mailcycle’s server cannot read your mail. Content is sealed with keys derived from your recovery phrase, and no key that opens it is ever stored on the server.

Sealed

These come back from the API as sealed blobs:

• Message content: sender, subject, body and attachment details.
• Attachment bodies.
• Address labels, in meta.
• Device names, tags and notes, in profile.
• API key names, in meta.

Incoming mail is sealed by the mail server to the address’s public key as soon as it arrives. Only the matching private key opens it, and that key is derived from the recovery phrase on a device. Labels and names are sealed on the device with a key only the account’s devices hold.

In the clear

Some things cannot be sealed, because the service has to act on them:

• Email addresses, because a mail server has to read the envelope to deliver.
• When a message arrived, how big it is, and whether it has been read.
• Retention settings, because the server enforces deletion.
• A device’s platform and when it was last active, to the hour.
• Plans, dates and payment records.

What this means for your code

• There is no server-side search over message content and no ?q= parameter. Search in your client, after decrypting.
• Opening sealed content needs keys derived from the recovery phrase. The sealed formats are not documented yet, so today a script can manage addresses, devices and metadata, while reading message content happens in the Mailcycle apps. An SDK that decrypts is planned.
• The server cannot help if the recovery phrase is lost. Nothing it stores can recover the keys.