Dane

Jede Schicht der E-Mail-Sicherheit ist darauf ausgelegt, auf Funktionieren zurückzufallen, statt sicher zu versagen. Strippe die STARTTLS-Zeile aus einer Begrüßung, und ein opportunistischer Sender macht im Klartext weiter, was RFC 3207 zugleich als Angriff beschreibt und, auf einem öffentlichen Server, zu verteidigen verbietet. Dieser Beitrag zeichnet diesen Man-in-the-Middle in einem Labor auf und geht dann die sieben Einstellungen durch, die eine Nachricht auf dem Transport schützen, und zeigt für jede, was sie schützt, was nicht, und wie sie offen versagt, wenn sie falsch steht. Von dort zu DANE: warum ein TLSA-Eintrag ohne DNSSEC darunter wertlos ist, warum 3 1 1 und Schlüsselwiederverwendung zählen, und wie ein veralteter Eintrag der eine Fehlschlag ist, der schließt statt öffnet. Dann eine rein lesende Erhebung über britische Banken, die großen Mailprovider und die Zertifizierungsstellen, die zählt, wie viele davon überhaupt irgendetwas davon tun.

Ab Werk sendet Postfix im Klartext, wenn die Gegenseite kein TLS anbietet, und nimmt Mail von jedem an, der behauptet, irgendwer zu sein. Das ist der andere Aufbau: Postfix 3.10.13 mit Dovecot für Logins, Rspamd für SPF, DKIM und DMARC und postfix-tlspol für DANE und MTA-STS. Kein Klartext rein oder raus, Port 25 relayed nie, ein Login besitzt seine Adressen im Envelope und im From-Header, Absenderdomains, die nicht existieren, werden abgelehnt, und eine manipulierte oder gefälschte Nachricht kommt nie an DATA vorbei. Jede Antwort wurde in einem Labor über IPv4 und IPv6 mitgeschnitten, samt der fünf Einstellungen, die stillschweigend nichts tun, bis auch etwas anderes gesetzt ist, der certbot-Voreinstellung, die DANE bei der Erneuerung bricht, und was das alles dich bei weitergeleiteter Mail kostet.

Die meisten Organisationen betreiben keinen eigenen Mailserver. Sie bezahlen Microsoft, und Exchange Online erledigt die Arbeit. Also hält dieser Beitrag Microsoft 365 an genau die Hausregeln, die die Postfix- und Stalwart-Aufbauten erfüllt haben, und zwar mit nichts als Microsofts eigener Dokumentation und Read-only-DNS gegen echte Mandanten. Einige Regeln erfüllt es gut: DANE ausgehend und MTA-STS sind standardmäßig an, und DANE eingehend mit DNSSEC ist endlich GA geworden. Mehrere kann es gar nicht erfüllen. Es gibt keinen dokumentierten Weg, eingehendes TLS von jedem Absender zu verlangen, keinen Weg, einen SPF-Hard-Fail an der Tür abzulehnen, nichts, das allein wegen einer fehlgeschlagenen DKIM-Signatur ablehnt, und keine Kontrolle, die Mail von einer nicht existierenden Absenderdomain verwirft. DNSSEC ist für den Mail-Host, den jeder Mandant tatsächlich nutzt, ausdrücklich nicht geplant. Der IPv6-Rollout, der sechs Monate dauern sollte, hat das Postfach des NCSC zwei Jahre später über IPv6 unerreichbar gelassen. Und die Dokumentation widerspricht sich selbst bei Wildcards, bei SPF und bei DNSSEC. Das ist die Plattform, auf der der Großteil der Mail des Landes läuft, und das ist es, was sie dich tun lässt und was nicht.

Stalwart ist ein ganzer Mailserver in einem Binary: SMTP und IMAP und JMAP, SPF, DKIM, DMARC, ARC, DANE, MTA-STS, TLS-Reporting, ein Spamfilter und der Mailspeicher, ohne Milter zum Verdrahten und ohne Policy-Daemon daneben. Dieser Beitrag hält es an dieselben Hausregeln wie den Postfix-Aufbau und fängt jede Antwort im Labor ein. Die Regeln gehen alle an, aber die Geschichte steckt im Detail: die Einstellungen liegen in einer Datenbank statt in einer Datei, die Standardeinstellungen ab Werk akzeptieren Klartext und eine manipulierte Rechnung, jede Regel landet in einem anderen von vier Konfigurationsmechanismen, die Ablehnung bei DKIM-Fehler braucht ein Sieve-Skript, weil die eingebaute Prüfung einen manipulierten Body als neutral meldet, die Unbekannter-Absender-Prüfung läuft erst, wenn die ganze Nachricht da ist, und versagt offen bei einem DNS-Fehler, und der MTA-STS-Sender bounct beim ersten Versuch, wo der Standard eine Zurückstellung verlangt. Eingebaut ist wirklich weniger zusammenzudrahten. Es ist nicht dasselbe wie sicher per Standard.