Warum jede Mail-Einstellung stimmen muss

Jeden Namen, den deine Maschine heute nachgeschlagen hat, hat sie geglaubt, und darüber habe ich einen ganzen Beitrag geschrieben. In diesem hier geht es darum, was mit der Mail nach der Namensauflösung passiert. Die Kurzfassung: Sie geht an einen Server, den DNS ausgewählt hat, über einen Kanal, der nur verschlüsselt ist, wenn niemand widerspricht, und trägt eine Nachricht, die jeder auf dem Weg lesen und verändern kann, und fast keine der Schutzmaßnahmen, die genau das verhindern sollten, ist eingeschaltet.

Das ist nicht eine kaputte Sache. Es sind sieben, jede so gebaut, dass die Mail trotzdem durchgeht, wenn sie falsch steht. Kein Fehler. Die Rechnung kommt an. Das Passwort-Reset kommt an. Sie kommen nur zusätzlich bei jemandem an, oder laufen durch jemanden, der sie nie hätte sehen dürfen, und nirgendwo sagt irgendetwas Bescheid.

Dieser Beitrag ist das Plädoyer dafür, jede einzelne dieser Einstellungen richtig zu setzen, mit dem Beleg dafür, was jede wert ist. Die drei Beiträge danach bauen das auf echten Servern auf: Postfix, Microsoft 365 und Stalwart. Dieser hier ist das Warum.

Der Angriff, den der Standard beschreibt und dann verbietet

Fang mit der Leitung zwischen zwei Mailservern an, denn das ist die, die die meisten für längst gelöst halten. STARTTLS ist der Befehl, der eine SMTP-Verbindung auf TLS hochstuft. Die meisten Mailserver unterstützen es, die meiste Mail ist auf dem Transport verschlüsselt, und das klingt nach einem gelösten Problem, bis du liest, wie das Hochstufen angeboten wird.

Der empfangende Server kündigt STARTTLS in seiner Begrüßung an. Der sendende Server sieht das Angebot und nimmt es an. Nichts signiert dieses Angebot, und nichts schützt es. Also kann eine Maschine auf dem Weg dazwischen die Zeile löschen, und hier ist das Ergebnis, im Labor von einem Sender aufgezeichnet, der auf die gewöhnliche opportunistische Voreinstellung gesetzt ist:

 ~> EHLO client.test
[stripped] STARTTLS removed from the greeting
*** Host did not advertise STARTTLS
 -> MAIL FROM:<carol@sender.test>
 -> Please pay invoice 1042 to sort code 20-00-00, account 12345678.
<-  250 2.0.0 Ok: queued as D6A84132069C

Der Sender hat kein STARTTLS-Angebot gesehen, also hat er getan, was opportunistisch bedeutet: Er hat trotzdem gesendet, im Klartext. Die Maschine in der Mitte hat alles mitgelesen, Rechnung und Bankverbindung inklusive. Die Mail wurde zugestellt. Kein Fehler erreichte irgendwen.

Diesen Angriff habe ich nicht erfunden. RFC 3207, der Standard, der STARTTLS definiert, beschreibt ihn genau in seinen eigenen Security Considerations:

A man-in-the-middle attack can be launched by deleting the “250 STARTTLS” response from the server. This would cause the client not to try to start a TLS session.¹

Derselbe Abschnitt nennt die Verteidigung, und es ist die naheliegende: TLS verlangen zu können. „both clients and servers MUST be able to be configured to require successful TLS negotiation … for selected hosts before messages can be successfully transferred.“¹ Also konfigurierst du den Empfänger so, dass er es verlangt, und die gestrippte Sitzung wird abgelehnt:

[stripped] STARTTLS removed from the greeting
*** Host did not advertise STARTTLS
 -> MAIL FROM:<carol@sender.test>
<** 530 5.7.0 Must issue a STARTTLS command first

Nur kannst du das nicht, nicht auf einem öffentlichen MX, denn derselbe Standard verbietet es:

A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally.²

Lies die beiden Zitate zusammen. Der Standard beschreibt einen Man-in-the-Middle-Angriff, sagt dir, die Verteidigung sei, TLS zu verlangen, und sagt dir dann, dass dein öffentlicher Mailserver es nicht verlangen darf. Lies das zweimal. Diese Regel wurde 2002 geschrieben, um die Mail zwischen Servern am Laufen zu halten, die noch nicht alle TLS konnten. Sie gilt bis heute, und sie ist der Grund, warum der Großteil des Internets Mail nach wie vor im Klartext annimmt, und warum das Strippen von STARTTLS heute noch funktioniert.

Es gibt auch die kompetente Variante des Angreifers. Ein Empfänger, der TLS verlangt, rettet dich nicht, denn der Angreifer muss die Sitzung nicht im Klartext weiterreichen. Er kann den herabgestuften Klartext des Senders mitlesen und seine eigene, vollkommen gültige TLS-Verbindung zum Empfänger aufbauen, der ein gutes Zertifikat sieht und zufrieden ist. Ich habe beide Hälften im Labor gezeigt: das Strippen, das den Sender bloßstellt, und einen schlichten TLS-Client, den der strenge Empfänger ohne Murren akzeptiert. Die Richtlinie des Empfängers kann das nicht aufhalten. Nur der Sender, der sich weigert, ohne authentifiziertes TLS zu senden, hält es auf, und das ist das ganze Argument für DANE³ und MTA-STS,⁴ die später in diesem Beitrag kommen.

Sieben Einstellungen, und wie jede davon offen versagt

Die Leitung ist eines von zwei Problemen. Das andere ist die Identität: Eine Nachricht, die verschlüsselt ankommt, behauptet immer noch nur, von dem zu sein, von dem sie zu sein vorgibt. Es sind also sieben Einstellungen im Spiel, aufgeteilt auf diese beiden Aufgaben, und das, was sie gemeinsam haben, lernt man am besten zuerst.

Hier jede für sich: was sie schützt und was sie tut, wenn sie falsch gesetzt ist. Achte auf die letzte Spalte. Fast immer steht da, dass die Mail trotzdem durchgeht.

Sechs dieser sieben stellen die Mail auch falsch gesetzt noch zu. DANE ist die Ausnahme. Es ist die einzige Einstellung in der ganzen Liste, die geschlossen versagt: Mach sie falsch, und deine Mail bleibt stehen, statt zu lecken. Merk dir das, denn es ist zugleich der Grund, warum die Leute Angst davor haben, und der Grund, warum es die wertvollste ist.

Ein Wort zu jedem der drei Identitäts-Teile, denn der Rest dieser Reihe stützt sich darauf. SPF listet die Server auf, die für eine Domain senden dürfen, und endet mit einer Regel: -all heißt „niemand sonst“, ~all heißt „niemand sonst, aber stell es trotzdem zu“. DKIM fügt eine kryptografische Signatur über die Nachricht hinzu, so dass jede Änderung sichtbar wird, sofern die Domain überhaupt einen Schlüssel veröffentlicht hat, gegen den man prüfen kann. DMARC verknüpft die beiden und sagt dem Empfänger, was zu tun ist, wenn sie scheitern, und ob sie zur From:-Adresse passen, die der Leser tatsächlich sieht. Das sind die RFCs 7208, 6376 und 7489, und jedes davon wäre einen eigenen Beitrag wert.^{6 7 8}

DMARC allein lässt eine manipulierte Rechnung durch

Die Identitätsschicht hat eine Lücke genau dort, wo sie am meisten kostet, und die lohnt sich zu zeigen, denn „wir haben DMARC auf reject“ ist das, was die Leute sagen, wenn sie sich für abgesichert halten.

DMARC besteht, wenn entweder SPF oder DKIM besteht und zur From:-Domain passt. Eines, nicht beide. Nimm also eine echte, signierte Nachricht von einer Domain, ändere die Bankverbindung im Text und schick sie von derselben Stelle weiter:

SPF besteht weiterhin, weil es von einem autorisierten Server kam. Die DKIM-Signatur scheitert jetzt, weil der Text geändert wurde. Aber DMARC braucht nur einen passenden Treffer, und SPF hat ihm einen geliefert, also besteht DMARC, und die Nachricht mit der neuen Kontonummer wird zugestellt und sieht exakt aus wie das Original. Ich habe das im Labor aufgezeichnet: Rspamd bewertete sie mit R_SPF_ALLOW, R_DKIM_REJECT und DMARC_POLICY_ALLOW, und für sich allein hätte sie zugestellt. Das Einzige, was sie aufhielt, war eine Regel, die bei einer kaputten Signatur rundheraus ablehnt. Eine Domain auf p=reject ist gegen genau die Manipulation nicht geschützt, die diese Signatur abfangen sollte. Das ist gut zu wissen, bevor du die Aufgabe für erledigt erklärst.

DANE ist nur so gut wie das DNSSEC darunter

Jetzt zu den Transport-Einstellungen, die den kompetenten Angreifer tatsächlich aufhalten, weil sie die Entscheidung zum Sender verlagern. DANE ist die stärkste davon. Es erlaubt einer Domain, im DNS einen Fingerabdruck des Schlüssels zu veröffentlichen, den ihr Mailserver vorlegen wird, in einem TLSA-Eintrag, so dass ein sendender Server alles ablehnen kann, was nicht passt.⁹ Keine Zertifizierungsstelle beteiligt, kein Vertrauen darauf, wer auch immer den TLS-Handshake beantwortet hat. Der Domaininhaber sagt „das ist mein Schlüssel“, und damit hat sich die Sache.

Nur sind DNS-Antworten fälschbar, also ist ein im blanken DNS veröffentlichter Fingerabdruck nichts wert: Derselbe Angreifer, der STARTTLS strippt, kann dir einen gefälschten Fingerabdruck reichen, der zu einem gefälschten Schlüssel passt. DANE bedeutet erst dann etwas, wenn das DNS, in dem es lebt, mit DNSSEC signiert ist, so dass der Fingerabdruck selbst nicht gefälscht werden kann. Das ist die ganze Kette, und genau deshalb steht dieser Beitrag in einer Reihe, die mit DNSSEC begann. Falls du dem noch nicht begegnet bist, die Grundlagen stehen in /de/dns/dnssec-the-root-is-signed-you-are-not/, und die Einzeiler-Fassung lautet: Die Root ist signiert, jede nennenswerte TLD ist signiert, und dann ist bei den Namen, die die Leute tatsächlich benutzen, schlagartig Schluss.

Das Diagramm zeigt zwei Domains, die beide einen TLSA-Eintrag veröffentlichen. Die eine liegt in einer signierten Zone, mit einer ununterbrochenen Signaturkette von der Root bis hinunter zum Fingerabdruck, also kann ein Sender ihr vertrauen. Die andere liegt in einer unsignierten Zone, also ist ihr Fingerabdruck bloß ein paar Bytes, die jeder geschrieben haben könnte, und ein korrekter Sender ignoriert ihn vollständig und erhält gar keinen DANE-Schutz. Derselbe Eintrag, auf zwei Arten veröffentlicht. Nur einer von beiden kann beweisen, dass er echt ist.

Der zu veröffentlichende Eintrag ist 3 1 1: der eigene Schlüssel des Servers statt der einer CA, der öffentliche Schlüssel statt des ganzen Zertifikats, gehasht mit SHA-256. Die mittlere Zahl ist die, die sich im Betrieb auszahlt, denn den Schlüssel statt des Zertifikats zu fixieren heißt, dass der Eintrag jede Erneuerung überlebt, solange du denselben Schlüssel behältst. Der Postfix-Beitrag hat die vollständige Prozedur und die Falle, in die die Leute tappen, nämlich dass die übliche Art, Zertifikate zu erneuern, jedes Mal einen neuen Schlüssel erzeugt und den Eintrag stillschweigend zerstört. Für hier ist das Mitzunehmende: 3 1 1 plus Schlüsselwiederverwendung ist ein Eintrag, den du einmal veröffentlichst und dann in Ruhe lässt.

Die Hausregeln, und was jede davon kostet

Alles oben wird zu einer kurzen Liste von Regeln, und die nächsten drei Beiträge halten echte Server daran. Sie sind nicht abgemildert, und sie sind nicht umsonst. Hier sind sie, mit der Rechnung dabei, denn eine Regel, deren Kosten du versteckst, ist eine Regel, für die du dich nicht wirklich entschieden hast.

Die Weiterleitungskosten sind die, die wehtun, und sie sind real: Lehnst du allein wegen SPF ab, wird eine Nachricht, die von irgendwo weitergeleitet wird, das nicht im SPF-Eintrag des Absenders steht, abgewiesen, denn für den Empfänger sieht ein Weiterleiter genau aus wie ein Fälscher. Es gibt Abhilfen, SRS und ARC,¹⁰ und der Postfix-Beitrag zeigt den Fehlschlag. Die ehrliche Position ist, dass diese Regeln manche Mail zurückweisen, die ein laxerer Server zugestellt hätte. Genau darum geht es bei ihnen. Ein Teil dieser Mail hätte zurückgewiesen werden sollen, und der Rest erzählt dir von einem Weiterleitungs-Setup, das sich darauf verlassen hat, dass niemand prüft.

Es versagt offen, und hier ist der Beweis

Die Behauptung, auf der dieser ganze Beitrag ruht, ist, dass diese Einstellungen offen versagen, lautlos, so dass du eine funktionierende nicht von einer kaputten unterscheiden kannst, indem du hinschaust. Das ist keine theoretische Sorge. Beim Bau des Postfix-Servers für den nächsten Beitrag ist jeder einzelne dieser Fehlschläge passiert, und jeder war eine Einstellung, die konfiguriert aussah und nichts tat.

Sechs echte Einstellungen, jede davon aus dem Bau des Postfix-Servers für den nächsten Beitrag. Fünf versagten offen: Sie stellten die Mail zu, ohne Fehler, und sahen für alle Welt so aus, als funktionierten sie ordentlich. Die sechste, der veraltete DANE-Eintrag, versagte geschlossen. Es ist die, vor der alle Angst haben, und die einzige, die die Nachricht schützte, statt sie zu lecken. Die Lektion steht direkt da in der letzten Spalte des Diagramms: Die Einstellung, die die Leute meiden, weil sie ihre Mail aufhalten könnte, ist die einzige, die sich so verhält, wie eine Sicherheitskontrolle sich verhalten soll.

Jede Zeile davon ist eine Aufzeichnung, kein Nachlesen in einem Handbuch. Die Art, wie du eine funktionierende Einstellung von einer kaputten unterscheidest, ist, die Nachricht zu senden, die sie aufhalten soll, und zuzusehen, was zurückkommt, und ich sage es hier einmal und beweise es dreimal im Rest der Reihe.

Also, wer macht das überhaupt?

Es ist eine Sache zu sagen, dass die Einstellungen wichtig sind. Es ist eine andere zu fragen, ob die Organisationen, deren Mail am meisten zählt, sie eingeschaltet haben. Also habe ich das getan, mit nichts als lesendem DNS und einem validierenden Resolver, am 22. Oktober 2026: sechsundzwanzig Domains, die Mail empfangen, die Banken, die großen Provider, die deutschen Spezialisten und die Zertifizierungsstellen, jede auf die sieben Dinge in diesem Beitrag geprüft.¹¹

Lies zuerst die DMARC-Spalte hinunter, denn das ist die, die meist ausgefüllt ist. Die meisten hier veröffentlichen eine DMARC-Richtlinie, und die meisten Banken stehen auf reject. DMARC ist die Einstellung, die gemacht wird, weil es die ist, nach der ein Prüfer fragt, und die, die dir ein Zulieferer verkaufen kann, und weil sie sichtbar ist: Du kannst sie nachschlagen und ein Häkchen setzen. Sie ist zugleich, für sich allein, die Einstellung, die weiter oben in diesem Beitrag eine manipulierte Rechnung durchgelassen hat.

Jetzt lies die DANE-Spalte, die eine Einstellung hier, die sich nicht herabstufen und nicht fälschen lässt. Fünf Domains von sechsundzwanzig. Jede einzelne davon ist ein deutscher Provider oder Proton. Keine einzige britische Bank. Keine einzige der Zertifizierungsstellen, der Firmen, deren gesamtes Geschäft darin besteht, für Schlüssel zu bürgen. Der stärkste Schutz gegen genau den Angriff, mit dem dieser Beitrag eröffnet hat, wird von einer Handvoll Leute gemacht, denen es wichtig ist, und von niemandem, der bloß compliant ist.

Die Banken sind die schärfste Zeile. Acht davon, jede einzelne auf DMARC reject, und untereinander: kein DANE, kein erzwungenes MTA-STS, und eine einzige, Monzo, über IPv6 erreichbar. Zwei der vier Zertifizierungsstellen veröffentlichen gar keinen SPF-Eintrag auf ihrem eigenen Apex. HMRC und NatWest haben auch keinen. Das sind keine kleinen Läden, die nie dazu gekommen sind. Das sind die Organisationen, die dir die Mail schicken, bei der du am meisten Angst hast, dass jemand sie fälscht, und der Schutz, den sie haben, ist das Abzeichen, das am stärksten aussieht und am wenigsten tut.

Die IPv6-Spalte ist ihr eigener kleiner Skandal. Zwanzig der sechsundzwanzig haben überhaupt keinen AAAA-Eintrag auf ihrem Mailserver, also kann ein Sender in einem IPv6-only-Netz sie nicht erreichen, und diese Zahl bewegt sich nur in eine Richtung. Ich habe /de/networking/we-never-ran-out-of-addresses/ über die Weigerung der Branche geschrieben, diese Aufgabe zu Ende zu bringen, und hier ist sie wieder, diesmal im Mailpfad. Es ist dieselbe Form wie die gov.uk-Erhebung in /de/dns/dnssec-the-root-is-signed-you-are-not/: Der schwere Teil war vor Jahren fertig, die Registries geben es umsonst her, und die Leute, die es am offensichtlichsten nutzen sollten, haben es nicht getan. Das zentrale gov.uk steht nicht einmal in der Tabelle, weil es gar keinen MX veröffentlicht. Es empfängt keine Mail. Das ist eine Art, den Test zu bestehen.

Wenn du das immer noch nicht tust, kannst du dich einen Profi nennen?

Jeder Standard, der in diesem Beitrag genannt wird, und die Erhebung darunter, zeigen in eine Richtung: Das ist kein Forschungsproblem, es ist ein Einschaltproblem, und das Einschalten wird nicht von den Leuten erledigt, die am besten dafür aufgestellt sind. Wenn die Belege so einseitig sind, hört die Frage auf, akademisch zu sein, und wird zu einer, die du über deine eigenen Server beantworten musst. Wenn du Mail für eine Organisation betreibst, die mit dem Geld anderer Leute oder der Gesundheit anderer Leute umgeht, und dein MX kein DANE macht, kein MTA-STS erzwingt und über IPv6 nicht erreichbar ist, kannst du das eine professionelle Arbeit nennen?

Es gibt drei ehrliche Antworten, und nur die ersten beiden halten stand. Ja, mit einem aufgeschriebenen Grund und einem Datum daneben: Du bist auf einer Plattform, die DANE noch nicht anbietet, du hast es angesprochen, und es gibt eine Zeile im Plan fürs nächste Jahr. Das ist ein Profi, der eine echte Randbedingung handhabt, und das ist in Ordnung. Ja, weil du es nicht wusstest, und jetzt weißt du es, und du wirst noch diese Woche herausfinden, wie dein Server dasteht. Niemand hat das von Anfang an gewusst. Und nein: Du wusstest genug, um dich unwohl zu fühlen, du hast bis hierher gelesen, und du wirst den Tab schließen und nichts ändern, weil die Mail fließt und kein Fehler geworfen wird und niemand dich dazu zwingt. Das Letzte ist keine Wissenslücke. Es ist eine Entscheidung, etwas, für das du verantwortlich bist, kaputt zu lassen, weil kaputt leiser ist.

Der Standard zwingt dich nicht dazu. Das ist das ganze Problem, und es ist zugleich der ganze Sinn. Wissen ist nichts, was dir zustößt, und niemand wird kommen und dir sagen, dass dein Mailserver seit zwei Jahren klammheimlich im Klartext sendet. Sicherzustellen, dass du es weißt, ist als solches die Aufgabe, und sie ist die von niemandem sonst.

Ein Standard ist ein Versprechen, das du hältst, wenn niemand hinsieht

Die Teile davon waren alle vor Jahren fertig. STARTTLS ist von 2002, SPF und DKIM und DMARC sind ein Jahrzehnt alt oder älter, DANE für Mail wurde 2015 spezifiziert, MTA-STS 2018. Nichts davon steht hinter einer Lizenz, nichts davon braucht einen Anbieter, und die Registries, die die DNSSEC-Einträge tragen würden, geben sie umsonst her. Die schwere Ingenieursarbeit ist getan. Was bleibt, ist der leichte Teil, der Teil, der nur leicht ist, wenn sich jemand die Mühe macht: ihn einzuschalten, und zu prüfen, dass er wirklich an ist, und ihn an zu halten, wenn das Zertifikat erneuert wird und der Eintrag nachziehen muss.

Dieser letzte Teil ist eigentlich alles daran. Ein Standard ist nicht das Dokument. Das Dokument gibt es seit zwanzig Jahren, und die Mail geht immer noch im Klartext. Ein Standard ist etwas, das du hältst, wenn keine Fehlermeldung dich zwingt, es zu halten, wenn die Mail genauso fließen würde, wenn du es klammheimlich verfallen ließest, wenn der Einzige, der es je erführe, du bist. Jede einzelne dieser Einstellungen versagt offen, und zwar genau deshalb, damit niemand gezwungen ist, sich zu kümmern. Was heißt, dass das Kümmern die ganze Aufgabe ist.

Du bekommst keine Belohnung dafür. Die Rechnung, die nicht verändert wurde, sieht exakt aus wie die, die es wurde. Das Passwort-Reset, das unterwegs niemand mitgelesen hat, sieht exakt aus wie das, bei dem es jemand tat. Der einzige Unterschied liegt an den Tagen, an denen etwas versucht wurde, und an diesen Tagen erfährt die Person, die alles eingeschaltet und geprüft hat, dass es funktioniert, nie, dass sie angegriffen wurde, weil es nicht geklappt hat. So sieht es von außen aus, die Arbeit richtig zu machen: nichts passiert, aus Gründen, die niemand sehen kann.

Also setz trotzdem jede Einstellung richtig. Nicht weil irgendjemand prüft, denn niemand tut es. Tu es, weil du derjenige bist, der gesagt hat, die Mail sei sicher, und das zählt hier bei uns immer noch etwas.