Wie Mail zwischen Servern abgesichert wird, von DNSSEC bis DANE, und warum jede einzelne Einstellung stimmen muss. Umgesetzt mit Postfix, Microsoft 365 und Stalwart.
E-Mail zwischen zwei Servern wurde gebaut, um zugestellt zu werden, nicht um privat zu bleiben.
Standardmäßig geht sie im Klartext raus, oder verschlüsselt nur, solange niemand eingreift.
Die Einstellungen, die das beheben, liegen alle im DNS. Jede schließt eine andere Lücke. Ist eine falsch, wird die Mail trotzdem zugestellt, und nichts sagt dir Bescheid.
Diese Beiträge behandeln:
Was jede Einstellung schützt: SPF, DKIM, DMARC, MTA-STS, TLS-Reporting und DANE.
Warum DANE DNSSEC darunter braucht, und was schiefgeht, wenn ein Zertifikat erneuert wird.
Wie man all das mit Postfix einrichtet und nachweist, dass es funktioniert.
Was Microsoft 365 dich kontrollieren lässt und was nicht.
Wie Stalwart dieselben Einstellungen umsetzt, eingebaut statt nachgerüstet.
Jede Prüfung in diesen Beiträgen lässt sich gegen jede Domain ausführen, deine oder die von jemand anderem.
Warum jede Mail-Einstellung stimmen muss
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.
Postfix, DANE und jede Einstellung richtig gemacht
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.
Microsoft 365: Die Fisher-Price-IT-Edition
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: DANE und der Rest, eingebaut
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.
