atmosphere-mail
Cooperative email for PDS operators
Star
Fork
Watch
atmosphere-mail SECURITY.md
5.5 kB
Markdown
at main

Security Policy #

comail is a cooperative email reputation layer for the atproto ecosystem. Because the project ships software that handles SMTP credentials, OAuth tokens, signing keys, and DNS records on behalf of members, security reports are taken seriously and given priority over feature work.

This policy covers how to report a vulnerability, what to expect in response, and what is in scope.

How to report #

Email security reports to security@comail.at.

Please do not open a public issue, post on a public chat, or disclose the vulnerability on social media before we have had a reasonable chance to investigate and ship a fix.

Include in the report:

  • A description of the vulnerability and the impact you believe it has (information disclosure, account takeover, deliverability abuse, etc.).
  • Steps to reproduce. A minimal proof-of-concept is appreciated but not required for the initial report.
  • The version, commit SHA, or deployment URL where you observed the issue.
  • Any conditions required to trigger the issue (specific account state, timing, network position, etc.).

If the report contains material you would prefer to encrypt, mention that in the initial email and we will arrange a transport. A project PGP key will be published before the public-source release; until then, plaintext reports to security@comail.at are acceptable.

What to expect #

We aim to:

  • Acknowledge every report within 72 hours.
  • Provide a status update or fix within 14 days of acknowledgement, or explain why more time is needed.
  • Credit the reporter in the eventual disclosure, if they wish to be credited.
  • Coordinate disclosure with the reporter so that a fix is in place before the issue is described publicly.

Reports about issues that turn out to be already known, already fixed, or out of scope will still get a reply explaining the disposition.

Scope #

The following components are in scope:

  • The relay binary (cmd/relay) and any code under internal/relay, internal/relaystore, internal/admin, internal/atpoauth, internal/marque.
  • The labeler binary (cmd/labeler) and any code under internal/labeler.
  • The web frontends served from this repository (web-frontend/, web/templates/).
  • The deployment scripts under infra/ and the CI workflows under .gitea/workflows/ insofar as they affect the security of operator deployments that follow the documented setup.
  • The official hosted instance at comail.at and its subdomains.

Out of scope:

  • Third-party deployments of the software. If you find an issue in someone else's instance, please contact that operator directly. We will help triage if the underlying bug is in our code.
  • Denial-of-service issues that require sustained or distributed attacker resources. We are interested in amplification and cheap-to-trigger DoS vectors (a single crafted request that takes down the relay), not raw bandwidth attacks.
  • Social engineering against project maintainers or members.
  • Physical attacks against operator infrastructure.
  • Reports from automated scanners without a clear, reproducible finding. "Your TLS supports TLS 1.2" is not a vulnerability.
  • Vulnerabilities in third-party dependencies that have a published CVE but no exploit path through our code. We track these via govulncheck and patch in the normal release cadence.

What we consider a vulnerability #

In addition to the obvious categories (RCE, SQL injection, auth bypass, secret disclosure, XSS, CSRF, SSRF), the following are explicitly in scope because they map to the project's threat model:

  • DID enumeration — any path that lets an unauthenticated caller determine whether a given DID is enrolled, including timing oracles.
  • Domain takeover — any path that lets a caller bind a domain they do not control to an account they do control.
  • Reputation forging — any path that lets a sender appear to have a different reputation, label, or warming phase than they earned.
  • Signing-key leakage or substitution — any path that exposes the relay's OAuth signing keys or DKIM keys, or allows them to be replaced by an attacker.
  • Inbound-rate-limit bypass — any path that lets an outside sender bypass abuse-prevention rate limits on inbound mail to a member's domain.
  • Cross-member data exposure — any path that lets one member see another member's mail, configuration, or statistics.

Safe-harbor #

We will not pursue legal action against researchers who:

  • Make a good-faith effort to follow this policy.
  • Avoid privacy violations, data destruction, and service disruption beyond what is strictly necessary to demonstrate the issue.
  • Give us reasonable time to investigate and fix before publicly disclosing.
  • Do not extract more data than necessary to demonstrate the issue, and delete any extracted data after the report is acknowledged.

This safe-harbor applies to research on the official hosted instance (comail.at) and on our public source code. It does not extend to third-party deployments, which are governed by the policy of the operator running them.

Bug bounty #

There is no monetary bug bounty at this time. Substantial reports will be credited in the changelog and on a security acknowledgements page once one exists. As the project grows we will revisit this.

Thanks for helping keep comail and its members safe.