Investigate inbound spam architecture; evaluate Unbound revisit
openScope
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/stalwartcheckout; 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.