Das Symptom und die falsche Fährte

Der Anfang war eine beiläufige Beobachtung: Mails der eigenen Domain landeten bei Empfängern im Spam. Dazu ein Prüfbericht eines Online-Dienstes, der die Domain von außen abklopft und zwei rote Punkte zeigte, nämlich einen fehlgeschlagenen Verbindungsversuch zum Mailserver und einen zur Webseite.

Beide roten Punkte waren falsch. Die Ports antworteten von außen einwandfrei, der Mailserver meldete sich mit seinem Begrüßungsbanner, die Webseite leitete korrekt auf HTTPS um. Erklären lässt sich das mit der eigenen Abwehr: Auf dem Server läuft eine verhaltensbasierte Sperrliste, die zu diesem Zeitpunkt mehrere tausend Adressen blockierte. Der Prüfdienst war mit einiger Wahrscheinlichkeit darunter.

Das ist der erste lehrreiche Punkt: Ein Prüfbericht von außen sieht nur, was er erreicht. Wer Scanner blockiert, bekommt Fehlalarme geliefert, und die eigentliche Ursache stand in diesem Bericht überhaupt nicht.

Was „gesendet" wirklich bedeutet

Die nächste naheliegende Spur führt ins Mailprotokoll. Dort standen für die zurückliegende Woche 31 ausgehende Nachrichten, alle mit dem Status „gesendet", keine einzige Rückweisung. Große Anbieter hatten jede davon angenommen.

Genau hier liegt die Falle. „Gesendet" heißt, dass der empfangende Server die Nachricht entgegengenommen hat. Ob er sie anschließend in den Posteingang oder in den Spamordner legt, entscheidet er danach, und darüber erfährt der sendende Server nichts. Ein Mailserver kann also monatelang perfekt aussehen, während seine Nachrichten beim Empfänger ungelesen im Spam liegen.

Die üblichen Verdächtigen waren schnell abgehakt und alle in Ordnung: SPF mit striktem Abschluss, DMARC auf Zurückweisung gestellt, Reverse-DNS für IPv4 und IPv6 mit bestandener Vorwärts-Rückwärts-Prüfung, kein Eintrag auf einer der geprüften Sperrlisten.

Der Fund: signiert wurde nie

Der Filterdienst des Mailservers schrieb bei jeder ausgehenden Nachricht dieselbe Zeile ins Protokoll:

signing failure: cannot make request to load DKIM selector for domain ...

Die Schlüssel für die DKIM-Signatur fehlten vollständig. Sie liegen bei dieser Mailserver-Software ausschließlich in einem Key-Value-Speicher und in keiner Konfigurationsdatei. Der Speicher selbst war intakt, gut gefüllt und sicherte planmäßig auf die Platte. Nur die drei Einträge für die Signatur waren weg.

Dazu kommt der Umstand, der die Sache von außen unauffällig macht: Im DNS stand weiterhin ein gültiger öffentlicher Schlüssel. Für jeden Betrachter sah die Domain damit signierfähig aus. Nur den privaten Gegenpart, ohne den keine Signatur entsteht, gab es nicht mehr.

Wiederherstellen ließ er sich nicht. Alle sieben vorgehaltenen Sicherungen enthielten weder die Schlüssel noch einen privaten Schlüssel. Bei sieben Tagen Aufbewahrung ließ sich damit auch nicht sagen, wann sie verschwunden sind.

Warum dieser Ausfall unsichtbar ist

Ein fehlender Signaturschlüssel bringt nichts zum Absturz. Es gibt keinen Container, der neu startet, keinen Gesundheitscheck, der umschlägt, keine Fehlermeldung an den Absender. Die Mail geht raus, sie kommt an, sie wird angenommen. Es fehlt lediglich eine Kopfzeile.

Für den Empfänger ändert diese fehlende Kopfzeile allerdings die Bewertung. Die Prüfung nach DMARC gilt schon dann als bestanden, wenn entweder SPF oder DKIM stimmen. SPF stimmte, deshalb wurde keine Nachricht abgewiesen. Aber ein Absender mit geringem Aufkommen und ohne Signatur ist für einen Spamfilter ein schwächeres Signal als einer mit beidem.

Gefährlicher ist der Fall, der in diesen zwei Monaten glücklicherweise nicht eintrat. Sobald eine Nachricht weitergeleitet wird, bricht SPF, weil der weiterleitende Server nicht der ursprüngliche Absender ist. Normalerweise fängt DKIM das auf, denn eine Signatur übersteht die Weiterleitung. Ohne Signatur fällt DMARC in diesem Moment komplett durch, und bei einer Richtlinie, die auf Zurückweisung steht, verschwindet die Nachricht dann nicht im Spam, sondern ganz.

Die Berichte, die niemand liest

Datieren ließ sich der Ausfall am Ende doch, und zwar über ein Signal, das die ganze Zeit im eigenen Postfach lag. Wer in seinem DMARC-Eintrag eine Adresse für Sammelberichte hinterlegt, bekommt von großen Anbietern regelmäßig eine XML-Datei. Darin steht pro Absende-Adresse, wie viele Nachrichten eingingen und ob SPF und DKIM aus Sicht des Empfängers bestanden haben.

Diese Berichte kommen seit Januar. Gelesen hatte sie nie jemand. Ausgewertet ergaben 18 Berichte ein eindeutiges Bild: Bis zum 21. Juni steht dort für DKIM durchgehend „pass", ab dem 10. August durchgehend „fail", von zwei großen Anbietern unabhängig voneinander gemeldet. Der Ausfall lief also rund zwei Monate und nicht, wie die Sicherungen vermuten ließen, eine Woche.

Diese Berichte sind die einzige Quelle, die zeigt, wie Empfänger die eigenen Mails bewerten. Der eigene Server kann das prinzipiell nicht wissen. Ein kleines Auswerteskript, das die Anhänge entpackt und die Ergebnisse zusammenzählt, ist schnell geschrieben und beantwortet eine Frage, die sonst offen bleibt.

Nebenbei zeigten dieselben Berichte etwas, das im Alltag unsichtbar ist: An einem Tag im Juni schlug bei mehreren Nachrichten über IPv6 die SPF-Prüfung fehl. Damals trug die DKIM-Signatur das Ergebnis. Genau diese Konstellation wäre in den zwei Monaten danach der beschriebene Totalverlust gewesen.

Reparieren, ohne es schlimmer zu machen

Ein neuer Schlüssel ist schnell erzeugt, und genau da lauert der nächste Fehler. Sobald der Server mit einem neuen Schlüssel signiert, der DNS-Eintrag aber noch den alten öffentlichen Teil trägt, prüft jeder Empfänger die Signatur und stellt fest, dass sie nicht passt. Das Ergebnis heißt dann nicht mehr „keine Signatur", sondern „Signatur fehlgeschlagen", und das wird schlechter bewertet.

Vermeiden lässt sich dieses Fenster mit einem zweistufigen Vorgehen. Bei dieser Mailserver-Software entscheidet ein eigener Eintrag, der sogenannte Selector, darüber, ob überhaupt signiert wird. Fehlt er, passiert nichts, und genau das war ja der Ist-Zustand. Also zuerst das neue Schlüsselpaar ablegen und den Selector bewusst weglassen. Am Verhalten ändert sich dadurch nichts, es wird weiterhin nicht signiert und nichts schlägt fehl.

Erst wenn der neue öffentliche Schlüssel im DNS steht und sichtbar ist, kommt der Selector dazu. Vor dem Umlegen lohnt ein Vergleich Zeichen für Zeichen zwischen dem veröffentlichten Wert und dem Schlüssel auf dem Server. Danach beginnt die Signierung in dem Moment, in dem sie auch verifizierbar ist.

Für die Abnahme reicht der Blick ins eigene Protokoll nicht. Es gibt frei zugängliche Prüfadressen, die eine eingehende Testmail auswerten und einen Bericht zurückschicken. Der bestätigte, was vorher niemand belegen konnte: SPF bestanden, Reverse-DNS bestanden, DKIM bestanden.

Eine Lehre aus dem unwiederbringlichen Verlust: Das Schlüsselpaar liegt jetzt zusätzlich als Datei mit engen Rechten auf dem Server. Ein Schlüssel, der nur an einer einzigen Stelle existiert, zwingt bei Verlust immer zu einer DNS-Änderung.

Der zweite Fund: die Warnung lag im Spam

Beim Gegentest der neuen Überwachung kam ein Problem heraus, das schwerer wiegt als der Anlass. Die Wächter auf dem Server verschicken ihre kritischen Meldungen bewusst an der übrigen Infrastruktur vorbei, direkt über einen schlanken Mailclient an den Mailserver. So sollen sie auch dann noch durchkommen, wenn Reverse Proxy oder Monitoring selbst ausgefallen sind.

Diese Meldungen wurden zugestellt und anschließend von der Filterregel in den Junk-Ordner einsortiert. Der Spamfilter vergab 8 von 15 Punkten, und die Gründe standen im Protokoll: keine Message-ID, kein Zeichensatz angegeben, dazu deutsche Umlaute im Text bei einer Kodierung, die nur 7 Bit zulässt. Die Kopfzeilen waren von Hand zusammengesetzt und unvollständig.

Der Effekt ist heimtückisch, weil er nur manchmal auftritt. Meldungen ohne Umlaute blieben knapp unter der Schwelle und kamen im Posteingang an. Ob eine Warnung gelesen wird, hing damit davon ab, ob in ihrem Text zufällig ein Umlaut vorkam.

Die Reparatur war klein. Statt die Kopfzeilen von Hand zusammenzusetzen, baut ein kurzes Skript die Nachricht jetzt mit einer fertigen Bibliothek auf, die Message-ID, Datum, Zeichensatz und Kodierung korrekt setzt und einen Betreff mit Sonderzeichen sauber kodiert. Der Wert fiel von 8,00 auf 0,56, und die Meldungen landen seither im Posteingang.

Die Abnahme dafür ist nicht der Versandstatus, sondern der Zustellordner. Dass eine Mail „gesendet" wurde, war in diesem Fall die ganze Zeit wahr und trotzdem wertlos.

Prüfen, was da ist, nicht was passiert

Bleibt die Frage, wie so etwas beim nächsten Mal früher auffällt. Der naheliegende Weg wäre, das Protokoll nach der Fehlermeldung zu durchsuchen. Der greift zu kurz: Die Meldung entsteht nur, wenn jemand eine Mail verschickt. In einer ruhigen Woche gäbe es nichts zu finden, und die Prüfung meldete Ruhe, obwohl die Signierung tot ist.

Die Prüfung muss deshalb den Zustand ansehen und nicht das Ereignis. Für jede aktive Domain wird abgefragt, ob Selector, privater und öffentlicher Schlüssel vorhanden sind. Dazu kommt ein Abgleich des veröffentlichten DNS-Eintrags mit dem hinterlegten Schlüssel, der zusätzlich den Fall abdeckt, dass jemand den Schlüssel tauscht und das DNS vergisst. Das ist der Zustand, der schlechter ist als gar keine Signatur.

Getestet wird eine solche Prüfung sinnvollerweise gegen die echten Fehlerbilder, nicht gegen den gesunden Zustand. Nacheinander den Selector entfernen, den öffentlichen Schlüssel verfälschen und den privaten löschen, jedes Mal mit sofortigem Zurücksetzen: Wenn die Prüfung alle drei meldet, taugt sie etwas. Läuft sie nur im Normalbetrieb grün durch, weiß man nichts.

Diese Ausfallart ist die unangenehmste im Betrieb, weil jede Anzeige auf Grün steht. Der Prozess läuft, der Gesundheitscheck ist zufrieden, das Protokoll meldet Erfolg. Nur die Arbeit wird nicht getan. Wer solche Fälle finden will, muss Prüfungen bauen, die das erwartete Ergebnis kennen, und nicht nur solche, die nach Fehlern suchen.