Where your data is and who can see it

• The service and its database run on a server rented from Hetzner, a German company, in Helsinki, Finland. Attachments, original messages and files are stored encrypted on a server we run ourselves in Sweden, with the keys in Helsinki. No US company stores your data.
• Message text, original messages, attachments and files are encrypted with AES-256-GCM before they are written to disk. Subjects, addresses, dates, file names, calendars and contacts are not.
• Connections are encrypted with TLS: between your browser or mail app and us, and between mail servers when the other server supports it.
• Amazon are US companies that content passes on its way. They do not store it, but US law can in principle require them to hand over what they process. The table below shows exactly what passes whom.
• Mail is not end-to-end encrypted. We hold the key on our server, so PineMail can technically read what is stored. The data processing agreement allows us to process it only to provide the service.

The same list, with the agreements, is on the sub-processor page.

The application encrypts each item with AES-256-GCM and a fresh random nonce before it is written: the text of every message, the original message as it arrived or was sent, attachments, files you upload, large files you send, the working state of documents being edited together, and file thumbnails.

Search works without storing your words: the search index holds a keyed hash of each word instead of the word. Someone with a copy of the database can see that two messages share a word, not which word it is.

Not encrypted, because the service sorts, shows and searches them on the server: subjects, sender and recipient addresses, dates, folder and label names, file names and sizes, calendar events and contacts.

It protects against someone who gets a copy of the database or the stored files without the key: a stolen backup, a leaked database dump, a disk read on its own.

It does not protect against someone who controls the running server, because the application holds the key there in order to show you your mail. The server's disks are not encrypted as a whole, and the key is kept on the server in Helsinki, apart from the database; the server in Sweden holds only encrypted data and never the key. The database is backed up every six hours to Sweden, encrypted with a separate password, and the backups are at present kept without an end date. Attachments and files are kept once, on two mirrored disks in Sweden with snapshots every hour (kept a day) and every day (kept two weeks), so a file deleted by mistake can be restored within that time. Legally, a Swedish court or authority can order us to hand over data, as it can any Swedish company.

The web app, the API, IMAP and SMTP submission require TLS. For the web and the API, TLS ends on our server in Helsinki. IMAP and SMTP go straight to our server.

Mail between different services travels server to server. Each hop is encrypted with TLS when both servers support it, which the large providers do, but each server along the way handles the message in readable form. This is how email works for every provider. Only encryption done by sender and recipient themselves, such as PGP or S/MIME, hides the content from the servers in between, and PineMail does not offer that today.

Incoming mail is checked on our server before it is delivered: SPF, DKIM and DMARC, the spam filter Rspamd, and the virus scanner ClamAV for attachments. Mail with a virus, and mail from domains whose DMARC policy says to reject it, is refused. Other spam goes to the Spam folder.

The only thing that leaves the server for this is DNS look-ups of the sending server's IP address and of domain names in the message, against public blocklists (Mailspike, SpamEatingMonkey, DNSWL, VirusFree, blocklist.de, SURBL, URIBL and the Rspamd project). No content, address or hash of content is sent anywhere.

The mail server limits how many connections each address may open, how fast, and how many unknown recipients it may try, and refuses to pass mail on to other servers. For the web: Hetzner filters large floods in its network; our server limits how many connections and requests each address may make, and sign-ins more tightly; requests probing for software we do not run are refused at the door; and the forms that create accounts or make us send mail carry a small proof-of-work check (ALTCHA) that your browser solves in about a second, run entirely on our server. Should a larger attack come, the web can be put behind Cloudflare again within minutes.

US companies can be required under US law, such as the CLOUD Act and section 702 of FISA, to hand over data they hold or process, wherever their servers are. That applies to Amazon, for outgoing mail. The transfers rest on standard contractual clauses and the EU-US Data Privacy Framework, the mechanisms the GDPR provides for this. The stored data is on a server run by a German company and is not held by a US company.

Passwords are stored as salted scrypt hashes. Sign-in can require a code from an authenticator app, sign-in attempts are rate limited, and sessions end after at most seven days. Administration of the service requires a fresh authenticator code and every action is logged. Mail apps can use a generated app password, which is required when the login has two-step verification.

Write to contact@pinemail.app. The details are part of the data processing agreement.