E-mail

Elke laag van e-mailbeveiliging is ontworpen om terug te vallen op werken in plaats van veilig te falen. Strip de STARTTLS-regel uit een begroeting en een opportunistische verzender gaat door in leesbare tekst, iets wat RFC 3207 zowel als aanval beschrijft als, op een publieke server, verbiedt je ertegen te verdedigen. Deze post legt die man-in-the-middle vast in een lab, en loopt dan de zeven instellingen langs die een bericht onderweg beschermen, en toont voor elk wat het beschermt, wat niet, en hoe het open faalt als het fout staat. Van daar naar DANE: waarom een TLSA-record niets waard is zonder DNSSEC eronder, waarom 3 1 1 en hergebruik van de sleutel ertoe doen, en hoe een verouderd record de enige mislukking is die sluit in plaats van opent. Daarna een alleen-lezen telling van Britse banken, de grote mailproviders en de certificaatautoriteiten, met de telling van hoeveel er werkelijk iets van doen.

Standaard verstuurt Postfix onversleuteld wanneer de andere kant geen TLS aanbiedt en neemt het post aan van iedereen die beweert iemand te zijn. Dit is de andere build: Postfix 3.10.13 met Dovecot voor logins, Rspamd voor SPF, DKIM en DMARC, en postfix-tlspol voor DANE en MTA-STS. Geen platte tekst in of uit, poort 25 relayt nooit, een login bezit zijn adressen in de envelop en de From-header, afzenderdomeinen die niet bestaan worden geweigerd, en een gemanipuleerd of vervalst bericht komt nooit voorbij DATA. Elk antwoord is opgevangen in een lab over IPv4 en IPv6, samen met de vijf instellingen die stil niets doen totdat er ook iets anders is gezet, de certbot-standaard die DANE bij vernieuwing breekt, en wat dat alles je kost aan doorgestuurde post.

De meeste organisaties draaien hun eigen mailserver niet. Ze betalen Microsoft, en Exchange Online doet het werk. Dus houdt deze post Microsoft 365 aan precies dezelfde huisregels die de Postfix- en Stalwart-builds haalden, met niets dan Microsofts eigen documentatie en read-only DNS tegen echte tenants. Sommige regels haalt het goed: uitgaande DANE en MTA-STS staan standaard aan, en inkomende DANE met DNSSEC werd eindelijk GA. Verscheidene kan het helemaal niet halen. Er is geen gedocumenteerde manier om inkomende TLS van elke afzender te eisen, geen manier om een SPF-hard-fail aan de deur te weigeren, niets dat weigert op een mislukte DKIM-handtekening alleen, en geen regeling die mail weigert van een afzenderdomein dat niet bestaat. DNSSEC is uitdrukkelijk niet gepland voor de mailhost die elke tenant werkelijk gebruikt. De IPv6-uitrol die zes maanden had moeten duren, heeft de eigen mailbox van de NCSC twee jaar later onbereikbaar over IPv6 gelaten. En de documentatie spreekt zichzelf tegen over wildcards, over SPF, en over DNSSEC. Dit is het platform waarop de mail van vrijwel het hele land draait, en dit is wat het je wel en niet laat doen.

Stalwart is een complete mailserver in één binary: SMTP en IMAP en JMAP, SPF, DKIM, DMARC, ARC, DANE, MTA-STS, TLS-rapportage, een spamfilter en de mailopslag, zonder milter om aan te sluiten en zonder policy-daemon die ernaast moet draaien. Dit stuk houdt het aan dezelfde huisregels als de Postfix-build en legt elk antwoord in het lab vast. De regels gaan er allemaal op, maar het verhaal zit in het detail: de instellingen zitten in een database in plaats van een bestand, de standaardinstellingen zoals het komt accepteren platte tekst en een gewijzigde factuur, elke regel landt in een ander van vier configuratiemechanismen, afwijzen op een DKIM-fout vraagt om een Sieve-script omdat de ingebouwde controle een gewijzigde body als neutral rapporteert, de controle op een onbekende afzender draait pas als het hele bericht binnen is en faalt open bij een DNS-fout, en de MTA-STS-verzender bounced bij de eerste poging waar de standaard zegt dat hij moet uitstellen. Ingebouwd is echt minder om aan elkaar te knopen. Het is niet hetzelfde als veilig standaard.