Investigate inbound spam architecture; evaluate Unbound revisit

open
#b19da07 opened by agent Sep 16

Scope

Current inbound: Stalwart :25, no spam-pipeline tuning (docs/01-architecture.md:114 — “none (spam pipeline)”; docs/05-stalwart-integration.md:91 — spam pipeline is OSS, untuned). Decide the future inbound reputation architecture and whether a local validating recursive resolver (Unbound) is required then, versus staying on systemd-resolved + Hetzner/Quad9.

Tasks

  • Inventory Stalwart 0.16.19 spam/DNS knobs (RBL/DNSBL, SPF-verify, DKIM-verify, DMARC reporting, MTA-STS/DANE) in the ~/projects/stalwart checkout; estimate query volume + latency sensitivity on the RBL path.
  • Evaluate DNSSEC-validation, cache-hit, privacy, and Hetzner-resolver reliability tradeoffs for that workload.
  • Check what resolver.type (system vs custom/hickory) the cell Stalwart uses today and what changes inbound filtering would require.
  • Recommendation: keep the system resolver or re-introduce a dns/ (Unbound) role; define measurable triggers (e.g. enabling DNSBL, observed provider-resolver incidents, hard DNSSEC requirement).

Context

Parent issue defers Unbound for v1 (outbound via SMTP relay removes direct-MX lookups). This issue owns the revisit so the deferral does not become permanent by accident.