Aus der Praxis

DKIM: die Stolperfallen

Der Schlüssel stimmt, der Dienst läuft, das Prüfwerkzeug meldet „key OK" — und signiert wird trotzdem nicht. Eine Fehlersuche zum Mitlesen, mit allen Sackgassen, die dabei tatsächlich betreten wurden.

Ausgangslage

Eine Domain verschickt Anmeldelinks und Bestätigungen. SPF passt, DMARC steht auf „quarantäne". Was fehlt, ist die Signatur — und ohne sie überlebt keine Nachricht eine Weiterleitung.

Auf dem Server war die Signiersoftware bereits installiert, und der Mailserver hatte sie in seiner Konfiguration stehen. Es sah nach zwanzig Minuten Arbeit aus.

Falle 1: Der Dienst gilt als tot und läuft trotzdem

$ systemctl status opendkim
× opendkim.service - OpenDKIM Milter
     Active: failed (Result: exit-code)
    Main PID: 1144719 (code=exited, status=69)

$ ss -lntp | grep 12301
LISTEN 0 128 127.0.0.1:12301 users:(("opendkim",pid=16866))

Beides stimmte gleichzeitig. Der Prozess mit der Nummer 16866 lief seit dem Vorjahr, gestartet außerhalb der Dienstverwaltung und mit einer anderen Konfigurationsdatei als der, die inzwischen gepflegt wurde. Der Mailserver redete die ganze Zeit mit diesem Altprozess.

Der Startfehler status=69 bedeutete schlicht „Adresse belegt" — eine Meldung, die nach einem Netzwerkproblem klingt und in Wahrheit auf einen Untoten zeigte.

Merke: Bei einem Dienst, der nicht startet, zuerst nachsehen, ob er vielleicht schon läuft. Und wenn ja: mit welcher Konfigurationsdatei.

Falle 2: Läuft, prüft, signiert aber nicht

Nach dem Aufräumen lief der Dienst sauber, der Schlüssel passte nachweislich zum veröffentlichten DNS-Eintrag. Mails gingen weiterhin unsigniert hinaus — und im Protokoll stand dazu nichts.

Die Ursache war eine fehlende Zeile. Ohne ausdrückliche Angabe des Betriebsmodus prüfte der Dienst nur eingehende Signaturen, statt ausgehende zu erzeugen. Und weil an einer ausgehenden Mail nichts zu prüfen ist, tat er gar nichts — und schrieb dazu auch nichts, denn die Standardeinstellung protokolliert Erfolge, nicht das Ausbleiben von Arbeit.

Merke: Ein Protokoll, in dem nichts steht, ist kein Beweis dafür, dass nichts passiert ist. Es kann auch heißen, dass niemand gefragt wurde.

Falle 3: Ein Sternchen, zwei Bedeutungen

Mit eingeschalteter Begründungsprotokollierung war die nächste Ursache in einer Zeile sichtbar:

opendkim[1160093]: 666ACC09CA: no signing table match for 'no-reply@mailv2.com'
opendkim[1160093]: 666ACC09CA: no signature data

In der Zuordnungstabelle stand *@mailv2.com — die Schreibweise, die in praktisch jeder Anleitung im Netz steht. Sie gilt allerdings für Tabellen, die als regulärer Ausdruck gelesen werden; dort übersetzt die Software das Sternchen selbst.

Die Tabelle war als einfache Tabelle eingebunden, und dort wird wörtlich verglichen: erst die vollständige Absenderadresse, dann die Domain. *@mailv2.com ist keines von beidem und trifft deshalb nichts. Der Dienst lief einwandfrei und signierte nichts.

Bitter daran: Ein Suchmuster, das in der einen Tabellenart alles trifft und in der anderen nichts, erzeugt keinen Fehler. Es erzeugt Stille.

Merke: Beim Kopieren einer Konfigurationszeile aus einer Anleitung gehört die Zeile darüber mitkopiert — die entscheidet, wie die Zeile darunter gelesen wird.

Falle 4: Der Name des Schlüssels ist nicht frei wählbar

Der öffentliche Schlüssel muss unter einem selbst gewählten Namen im DNS stehen. Die Verwaltungsoberfläche des Anbieters erlaubte jedoch keine freien Einträge, sondern nur Vorlagen für bekannte Versanddienstleister — und die Vorlage vergibt den Namen selbst.

Die Wahl bestand also zwischen „gar kein DKIM" und „ein Name, der nach einem Dienstleister klingt, mit dem die Domain nichts zu tun hat". Es wurde der Name. Funktional einwandfrei, inhaltlich Unsinn — und ein Beispiel dafür, wie ein technisch offenes System an Oberflächen scheitert, die nur die üblichen Fälle kennen.

Was am Ende half

Eine einzige Einstellung, die es in den meisten Signierprogrammen gibt und die standardmäßig aus ist: die Protokollierung des Grundes, warum eine Nachricht nicht signiert wurde.

Sie hat beide verbleibenden Ursachen in Sekunden sichtbar gemacht, nachdem Stunden mit Vermutungen vergangen waren. Wer DKIM einrichtet, sollte sie vom ersten Moment an einschalten und erst wieder ausschalten, wenn der Betrieb länger stabil läuft.

Die Prüfung, die etwas beweist

Dass der Schlüssel zum DNS-Eintrag passt, sagt wenig — es beweist nur, dass zwei Zahlen zusammengehören. Aussagekräftig ist nur der vollständige Weg: eine echte Nachricht durch die eigene Anwendung schicken, das Ergebnis am Ziel aufheben und die Signatur mit einem unabhängigen Werkzeug gegen den veröffentlichten Schlüssel prüfen.

Das ist der Unterschied zwischen „der Header ist da" und „die Signatur ist gültig". Im beschriebenen Fall lagen dazwischen zwei Fehler.

Das Muster

Vier Stolperfallen, und drei davon haben sich nicht bemerkbar gemacht. Kein Fehler, keine Warnung, keine auffällige Zeile im Protokoll — die Mails gingen weiter hinaus, nur eben unsigniert.

Dasselbe Muster beschreibt die Seite über die tatsächlichen Kosten eines eigenen Mailservers. DKIM ist dafür nur das schärfste Beispiel: ein Verfahren, dessen Ausfall vollständig unsichtbar ist, weil es nichts blockiert, wenn es fehlt.