# 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.