Do not open a public issue for security problems. Report privately via GitHub Security Advisories. You'll get an acknowledgement within 72 hours and a remediation plan or assessment within 14 days. Coordinated disclosure is appreciated; we'll credit you unless you prefer otherwise.

Pre-1.0: only the latest release receives security fixes.

Sabit is a client/server system: the sabitd server daemon parses untrusted input (addresses, lists, bounce messages, ARF reports), opens network connections to untrusted MX hosts, and can be driven by untrusted (LLM-generated) tool calls relayed by the thin sabit-mcp and sabit clients over the HTTP API. All probing happens on the operator's own sabitd host. Areas treated as security surfaces:

• The probe must never deliver mail. The single most important invariant: no code path transmits SMTP DATA. The prober reaches RCPT TO, reads the reply, and QUITs. This is enforced in the core and asserted in CI; a change that could send DATA is a security regression.
• Untrusted MX responses. Reply lines, greeting banners, and capability lists from a remote MX are untrusted: bounded read sizes, line-length and total-response caps, and strict timeouts prevent a hostile or buggy server from hanging or exhausting the prober. STARTTLS is detected from the EHLO capability list but not upgraded in this build (no bundled TLS); the RCPT runs on the plaintext session, with no credentials and no DATA sent, so nothing confidential is exposed. A real STARTTLS upgrade is on the roadmap.
• Untrusted bounce / ARF parsing. DSN and ARF messages are MIME from the open internet: the parser caps part count, nesting depth, and total size, never expands external entities, and never fetches remote content while parsing.
• Input/list injection. Addresses and CSV/JSONL inputs are validated before use; CSV is parsed without formula evaluation; an address can never be coerced into a shell argument or a second network target.
• API authentication and transport. sabitd speaks plain HTTP bound to loopback and is meant to sit behind a TLS-terminating reverse proxy. When server.api_key_file is set, the API requires a bearer token; each token carries per-token controls (allow_smtp, allow_jobs, rate_limit, daily_quota) so a client cannot probe, queue jobs, or exceed quota beyond what its token grants.
• Tool-call / path confinement. Over the HTTP API (reached by the thin sabit/sabit-mcp clients), file paths from callers are confined to configured roots (SABIT_ROOT); batch inputs/outputs never follow arbitrary filesystem paths in server deployments.
• Optional enrichment is off by default. Gravatar and HIBP queries leave your host and are privacy-sensitive; they are opt-in, rate-limited, and documented. They are never enabled implicitly.
• Secret and PII handling. Probed addresses are personal data: full addresses are never logged at default log levels, results are retained only as long as the cache TTL, and API keys (HIBP, FBL credentials) are read from the environment, never persisted in results.
• Resource exhaustion / abuse. Per-domain concurrency caps, global pool limits, response-size caps, and per-request timeouts double as DoS bounds. A 553 5.7.1 from a destination trips an automatic volume cut.

Sabit is dual-use. It is built for cleaning lists you already hold and validating addresses at capture, not for harvesting. It ships no address-generation, dictionary-attack, or scraping feature, and the responsible-probing defaults (FCrDNS, real MAIL FROM, caps, backoff, caching, no DATA) are on out of the box. Disabling them is explicit and discouraged; see Responsible probing and Ethics & compliance.

In scope: the sabitd server daemon (the engine, HTTP API, and task worker), the thin sabit CLI and sabit-mcp clients, and the conformance/accuracy harnesses in this repository. Out of scope: vulnerabilities in hickory-dns, the headless-browser engine, or downstream agent frameworks themselves (report upstream, but tell us if Sabit's defaults make exploitation easier).