There are no long-term-support branches — only the latest commit on main is supported. Always deploy from main (or the latest tagged image on GHCR).

Please do not open a public GitHub issue for security vulnerabilities.

Instead, use GitHub's private vulnerability reporting: go to this repository's Security tab → Report a vulnerability. This opens a private advisory with the maintainer instead of a public issue.

Expect an initial response within a few days. Once a fix is available, a new commit/tag will be published and the advisory disclosed.

This service is a stateless SMTP relay: clients supply SMTP credentials per-request via headers, and the server never stores mail-provider secrets. Reports particularly relevant to this design include:

• Any way to bypass the X-Api-Key gate or rate limiting
• Any way for SMTP credentials, headers, or request bodies to leak into logs, error messages, or cached idempotency responses
• Any way to relay mail without valid upstream SMTP credentials
• TLS certificate verification bypass for upstream SMTP connections (InsecureSkipVerify must never be used or reachable)
• Container escape or privilege escalation from the Docker image

Issues that only arise from a deliberately insecure deployment — e.g. API_KEY left unset on purpose, or rate limiting disabled via RATE_LIMIT_RPS=0 — are documented configuration trade-offs, not bugs. See the README's "Security notes" section.