Dkim

Every layer of email security is designed to fall back to working rather than fail safely. Strip the STARTTLS line out of a greeting and an opportunistic sender carries on in the clear, which RFC 3207 both describes as an attack and, on a public server, forbids you to defend against. This post captures that man-in-the-middle in a lab, then walks the seven settings that protect a message in transit, showing for each one what it protects, what it does not, and how it fails open when it is wrong. From there to DANE: why a TLSA record is worthless without DNSSEC under it, why 3 1 1 and key reuse matter, and how a stale record is the one failure that closes rather than opens. Then a read-only census of UK banks, the big mail providers and the certificate authorities, counting how many actually do any of it.

Stalwart is a whole mail server in one binary: SMTP and IMAP and JMAP, SPF, DKIM, DMARC, ARC, DANE, MTA-STS, TLS reporting, a spam filter and the mail store, with no milter to wire up and no policy daemon to run beside it. This post holds it to the same house rules as the Postfix build and captures every reply in the lab. The rules all go on, but the story is in the detail: the settings live in a database rather than a file, the defaults as shipped accept plaintext and a tampered invoice, each rule lands in a different one of four configuration mechanisms, DKIM-fail rejection needs a Sieve script because the built-in check reports a tampered body as neutral, the unknown-sender check runs only after the whole message is in and fails open on a DNS error, and the MTA-STS sender bounces on the first attempt where the standard says it should defer. Built in is genuinely less to wire together. It is not the same as safe by default.