Shipped a /security page for MailKite, and the section I…

https://mailkite.dev/security Most security pages are a badge wall. We don't hold SOC 2 or ISO 27001, so this one can't be. Instead it is built to be re-verified rather than believed: a per-surface TLS table (HTTPS-only API, STARTTLS on 587, implicit TLS on 465, STARTTLS at the MX, IMAPS on 993), the three at-rest modes side by side (default retention that expires, encryption to a public key only you hold via PGP/MIME or S/MIME, or zero-retention passthrough that stores nothing), how webhook signing works (HMAC-SHA256 over the raw body, per-route secret, five-minute replay window), and the MX, submission and IMAP edges open source at github.com/mailkite/server. Then "What we don't have yet", linked straight from the hero: no SOC 2 or ISO report, the v1 at-rest envelope has had no external crypto review, account API keys are not show-once yet, no orgs or per-user roles, inbound TLS is opportunistic. A reviewer finds all of that anyway. Better in five minutes than in week three. Also added an RFC 9116 security.txt pointing at the disclosure policy.

Reactions

0

Comments

1

Shares

0

Browse more founder updates