Security and privacy, precisely.
What Letterpier protects, how it does it, and where the edges are. This page describes the system as it runs on .
Contents (12)
Where your data lives.
| Provider | What it does for Letterpier | Where | Headquarters |
|---|---|---|---|
| OVH | Server for the web app, worker, Postal, MariaDB and the encrypted attachment volume | EU data centre (Limburg, Germany) | France |
| Neon (Databricks, Inc.) | Application PostgreSQL database | AWS eu-central-1, Frankfurt | USA |
| Vercel | Domain registration and DNS for letterpier.com; no message data | None | USA |
| Cloudflare R2 | Supported, not in use | None | USA |
Providers
OVH
- What it does for Letterpier
- Server for the web app, worker, Postal, MariaDB and the encrypted attachment volume
- Where
- EU data centre (Limburg, Germany)
- Headquarters
- France
Neon (Databricks, Inc.)
- What it does for Letterpier
- Application PostgreSQL database
- Where
- AWS eu-central-1, Frankfurt
- Headquarters
- USA
Vercel
- What it does for Letterpier
- Domain registration and DNS for letterpier.com; no message data
- Where
- None
- Headquarters
- USA
Cloudflare R2
- What it does for Letterpier
- Supported, not in use
- Where
- None
- Headquarters
- USA
Neon (part of Databricks, Inc.) and Vercel are US-headquartered. Data is stored in EU data centres, but EU hosting on its own doesn’t mean EU-only access. Mail you send travels to your recipients’ mail servers, wherever they are.
What’s encrypted, and what isn’t.
| Data | At rest | Why |
|---|---|---|
| Message bodies and outbound attachments | Encrypted, with keys the application manages | |
| Received attachments and original .eml files | Encrypted, on a private volume | |
| DKIM private keys (Letterpier’s copy) | Encrypted | Postal keeps its own copy in plaintext to sign mail. |
| Webhook signing secrets | Encrypted | Shown once. |
| API keys | Stored as SHA-256 hashes | Shown once. |
| Subjects, addresses, event metadata | Plaintext | So you can search your logs and we can route mail. |
| Mail inside Postal, our mail server | Plaintext, in its private database | Postal needs it to queue, sign and deliver. Raw mail is kept 7 days, metadata 30 days. |
Data at rest
Message bodies and outbound attachments
- At rest
- Encrypted, with keys the application manages
Received attachments and original .eml files
- At rest
- Encrypted, on a private volume
DKIM private keys (Letterpier’s copy)
- At rest
- Encrypted
- Why
- Postal keeps its own copy in plaintext to sign mail.
Webhook signing secrets
- At rest
- Encrypted
- Why
- Shown once.
API keys
- At rest
- Stored as SHA-256 hashes
- Why
- Shown once.
Subjects, addresses, event metadata
- At rest
- Plaintext
- Why
- So you can search your logs and we can route mail.
Mail inside Postal, our mail server
- At rest
- Plaintext, in its private database
- Why
- Postal needs it to queue, sign and deliver. Raw mail is kept 7 days, metadata 30 days.
Encryption uses AES-256-GCM with the data’s context bound in, and the keys live with the application on our OVH server, not at Neon.
This is encryption at rest with keys the application manages. It is not end-to-end encryption.
In transit.
The app and API use HTTPS with TLS 1.2 or 1.3 and HSTS. Between mail servers, Letterpier uses STARTTLS when the other server supports it. That’s opportunistic, so we can’t promise every hop is encrypted. Our public SMTP service requires STARTTLS before authentication.
Signing in.
Sign-in uses a single-use, six-letter code sent to your email address. Codes expire after 10 minutes and allow five attempts, and requests are throttled. Sessions last 7 days and are re-checked on every request. There are no passwords, and there’s no multi-factor authentication or account recovery screen yet, so access depends on the security of your email account.
Keys and isolation.
Organisations hold projects, and every message, domain, key, webhook and suppression belongs to exactly one project. Each project has its own Postal server and credentials. API keys are random, stored as SHA-256 hashes, shown once, and split into sandbox or live and sending-only or full access. Dashboard actions are protected against cross-site requests.
Webhooks.
Events are signed with HMAC-SHA256 in the Svix format. Endpoints must be public HTTPS on port 443; Letterpier validates and pins the resolved address, refuses private networks and never follows redirects.
Receiving.
Incoming mail is routed by the SMTP envelope recipient. Postal’s callbacks to Letterpier are verified with RSA-SHA256 over the original bytes, and duplicates are dropped. Previews block scripts, forms and remote content, and download links expire after 15 minutes. Attachments aren’t virus-scanned yet, so treat them as untrusted. Postal doesn’t send failure bounces for inbound mail, to avoid backscatter.
Retention and deletion.
Each project keeps message content for 1 to 90 days (30 by default). Lowering retention applies to existing messages. Deleting a message removes Letterpier’s copy, its attachments and events, and the matching records in Postal.
Postal independently keeps raw mail for 7 days and metadata for 30 days. Backups keep seven daily recovery points, so deleted content leaves them as they expire. One exception: a copy of the backup repository made on 29 September 2026 is kept on the operator’s own computer. It doesn’t expire automatically, so it keeps the data of that day until it is deleted or replaced. Neon’s restore history follows its own setting (the restore window configured for our Neon project). Content-free fingerprints of received mail remain, so deleted mail can’t be replayed.
Operations.
Backups run nightly around 03:15 UTC, encrypted, with a short pause while they’re staged. A restore check passed on : both databases were restored into isolated containers and the encrypted attachments were decrypted. A full disaster-recovery restore onto a new server hasn’t been rehearsed yet. An emergency switch stops all live sending. A health endpoint reports database connectivity and the worker’s heartbeat. Letterpier runs on a single OVH server, shared with other workloads.
What we don’t claim.
- No uptime percentage or SLA.
- No certifications and no independent security audit yet.
- No guaranteed inbox placement. Nobody can promise the inbox.
- EU hosting on its own doesn't make anything GDPR compliant, and we don't claim it does.
Current limitations (29 September 2026).
- No independent security audit or penetration test yet.
- No multi-factor authentication or account recovery yet.
- No antivirus scanning of attachments.
- No mailbox-provider complaint feedback loop; complaint events are synthetic.
- Backups are stored on the same server as the data, plus one copy from 29 September 2026 on the operator’s own computer; off-server replication is being set up.
- There is no independent alerting yet.
Report a vulnerability.
Email mail@michael-ketzer.com. Please read our responsible disclosure policy first. Our machine-readable contact is at /.well-known/security.txt.