DKIM-Signatur ungültig: Unterwegs wurde etwas verändert
Der Empfänger meldet eine ungültige DKIM-Signatur? Dann wurde die Nachricht auf dem Weg verändert. Warum Mailinglisten der häufigste Grund sind.
Aufwand:
ca. 25 Min.
Voraussetzung:
Zugriff auf die DNS-Zone der eigenen Domain, Terminal oder Eingabeaufforderung, Ein Testpostfach bei einem fremden Anbieter
Gilt für:
DKIM nach RFC 6376
Das Symptom
Der Empfänger meldet, die Mail sei im Spam gelandet, und im Kopf der Nachricht
steht bei DKIM ein fail. Das Verwirrende: Beim direkten Versand
an dieselbe Person funktioniert alles. Kaputt ist es nur, wenn die Nachricht über
den Vereinsverteiler, eine Mailingliste oder eine Weiterleitung gelaufen ist. Am
Text der Mail hat niemand etwas geändert — jedenfalls niemand, den man kennt.
Die „Layer 8“-Wahrheit
DKIM ist kein Schloss, sondern ein Siegel. Der versendende Server berechnet aus
dem Textkörper und einer Auswahl von Kopffeldern einen Prüfwert, unterschreibt ihn
mit einem privaten Schlüssel und hängt das Ergebnis als eigenes Kopffeld an. Den
passenden öffentlichen Schlüssel holt sich der Empfänger direkt aus dem DNS der
signierenden Domain. Passt beides zusammen, weiß er: Dieser Inhalt ist seit dem
Signieren unverändert. Mehr behauptet das Verfahren ausdrücklich nicht — der
Standard sagt selbst, dass die Prüfung nichts über einen Ende-zu-Ende-Schutz der
Nachricht aussagt. Verschlüsselt ist die Mail dadurch kein bisschen.
Und genau daraus folgt das Problem. Ein Siegel geht kaputt, wenn jemand das
Kuvert öffnet — auch wenn er es in bester Absicht tut. Eine Mailingliste, die
höflich eine Fußzeile mit dem Abmeldehinweis anhängt, ein Verteiler, der ein
Kürzel in die Betreffzeile schreibt, ein Zwischenserver, der lange Zeilen anders
umbricht: Jeder dieser Eingriffe verändert genau die Bytes, über die der Prüfwert
gebildet wurde. Der Standard kennt dieses Verhalten, benennt es beim Namen und
bietet zwei Auswege an — eine tolerantere Kanonisierung, die übliche
Leerraum-Änderungen verzeiht, und die Möglichkeit, dass der Verteiler selbst
signiert. Was er nicht bietet, ist ein Siegel, das ein Umschreiben übersteht. Das
wäre auch ziemlich sinnlos.
Für den Vereinsvorstand heißt das nüchtern: Eine kaputte DKIM-Signatur ist selten
ein Angriff und fast immer eine Station auf dem Weg. Der Reflex, das Problem beim
eigenen Mailserver zu suchen, führt in die Irre, solange der Direktversand
funktioniert. Ärgerlich wird die Sache erst im Zusammenspiel mit DMARC: Dort ist
DKIM der einzige Nachweis, der eine Weiterleitung überhaupt überleben kann. Bricht
er, bleibt nichts übrig — und aus „landet im Spam“ wird „wird abgelehnt“.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Den Signaturkopf einer betroffenen Mail ansehen
Im Mailprogramm die Quelltextansicht der Nachricht öffnen und das Kopffeld DKIM-Signature suchen. Laut RFC 6376 wird die Signatur der E-Mail im Kopffeld DKIM-Signature abgelegt; dieses Kopffeld enthält sämtliche Signatur- und Schlüsselabrufdaten. Zwei Angaben brauchst du daraus: d= nennt laut RFC die Domain, die die Verantwortung für die Einbringung der Nachricht in den Mailstrom beansprucht, und s= den Selektor, der den Namensraum für die Domain aus d= unterteilt. Beide sind Pflichtangaben.
2.
Den öffentlichen Schlüssel im DNS abfragen
Der Empfänger holt den Schlüssel selbst aus dem DNS — an einer Stelle, die sich aus d= und s= zusammensetzt. Der RFC beschreibt das so: Alle DKIM-Schlüssel werden in einer Unterdomain namens _domainkey abgelegt; bei einem DKIM-Signature-Feld mit einem d=-Wert von example.com und einem s=-Wert von foo.bar lautet die DNS-Abfrage foo.bar._domainkey.example.com. Kommt keine Antwort, kann keine Signatur der Welt gültig sein. Selektor und Domain unten durch die eigenen Werte ersetzen:
Prüfen, ob der Fehler nur auf einem bestimmten Weg auftritt
Dieselbe Nachricht dreimal verschicken: einmal direkt an ein Testpostfach bei einem fremden Anbieter, einmal über die Mailingliste beziehungsweise den Verteiler, einmal über eine Weiterleitung. Ist die Signatur nur auf dem Weg über den Verteiler kaputt, liegt es nicht an deinem Schlüssel, sondern an dem, was der Verteiler mit der Nachricht macht. Ist sie überall kaputt, stimmt etwas am Schlüssel, am Selektor oder am signierenden Server nicht.
4.
Die Kanonisierung als Ursache prüfen
Kanonisierung ist die Frage, wie pingelig die Signatur ist. RFC 6376 definiert für Kopfteil und Textkörper je zwei Verfahren: einen simple-Algorithmus, der fast keine Veränderung toleriert, und einen relaxed-Algorithmus, der übliche Veränderungen wie das Ersetzen von Leerraum und das Umbrechen von Kopffeldzeilen toleriert. Wird kein Verfahren angegeben, gilt laut RFC für Kopfteil und Textkörper standardmäßig simple — die strengste Variante. Wer ein Mailsystem betreibt, das noch mit dieser Vorgabe signiert, produziert bei jedem harmlosen Umbruch unterwegs eine ungültige Signatur. Nachzulesen ist es im c=-Feld des Signaturkopfes: Es nennt laut RFC die verwendete Kanonisierung, besteht aus zwei durch einen Schrägstrich getrennten Namen für Kopfteil und Textkörper und hat den Vorgabewert simple/simple.
5.
Nachrichten vor dem Signieren in die Form bringen, in der sie ankommen
Ein unterschätzter Auslöser sind Umwandlungen auf dem Transportweg. Der RFC schreibt dazu: Manche Nachrichten, besonders solche mit 8-Bit-Zeichen, unterliegen der Veränderung während des Transports, vor allem der Umwandlung in 7-Bit-Form, und solche Umwandlungen zerstören DKIM-Signaturen. Um das Risiko zu senken, SOLLTEN Signierende die Nachricht vor dem Signieren in eine geeignete MIME-Übertragungskodierung wie quoted-printable oder base64 umwandeln. Und allgemein gilt laut RFC: Der Signierende MUSS die Nachricht in der Form signieren, in der sie beim Prüfer erwartungsgemäß ankommt, nicht in einer lokalen oder internen Form.
6.
Den Verteiler selbst signieren lassen
Wenn der Verteiler die Nachricht verändert, ist die saubere Lösung nicht, ihm das zu verbieten, sondern ihn selbst signieren zu lassen. Der RFC empfiehlt genau das: Weiterleiter, die eine Nachricht so verändern, dass eine bestehende Signatur ungültig werden könnte, sind besonders gute Kandidaten dafür, eine eigene Signatur hinzuzufügen. Verbreitet ist dabei laut RFC, ein Sender-Kopffeld zu ergänzen, das die zum Signieren verwendete Adresse angibt. Eine Mail darf mehrere Signaturen tragen — der RFC weist ausdrücklich darauf hin, dass Nachrichten mit ungültigen und zusätzlich einer gültigen Signatur funktionieren sollen.
Häufige Fragen (FAQ)
?Was macht DKIM überhaupt — verschlüsselt das meine Mail?
Nein, es verschlüsselt nichts. DKIM klebt ein Siegel auf. RFC 6376 formuliert den Zweck so: DKIM erlaubt es einer Person, Rolle oder Organisation, die die signierende Domain besitzt, eine gewisse Verantwortung für eine Nachricht zu übernehmen, indem die Domain mit der Nachricht verknüpft wird. Und zur Wirkung: Eine DKIM-Signatur verknüpft den Namen aus dem d=-Feld mit dem berechneten Prüfwert eines Teils oder der gesamten Nachricht, um die Wiederverwendung der Signatur mit anderen Nachrichten zu verhindern. Das Überprüfen der Signatur sagt aus, dass sich der geprüfte Inhalt seit dem Signieren nicht geändert hat — und sagt sonst nichts über den Schutz der Ende-zu-Ende-Integrität der Nachricht aus. Lesen kann die Mail unterwegs also weiterhin jeder. Was DKIM leistet, ist der Nachweis, dass niemand sie unbemerkt umgeschrieben hat.
?Warum zerstört ausgerechnet unsere Mailingliste die Signatur?
Weil eine Mailingliste die Nachricht in aller Regel anfasst. RFC 6376 beschreibt genau dieses Verhalten im Anhang: Es gibt eine große Bandbreite von Diensten, die eine Nachricht entgegennehmen und erneut einliefern — von solchen, die außer einem Received-Kopffeld und geänderten Umschlagangaben nichts verändern, bis zu solchen, die Kopffelder ergänzen, das Subject-Kopffeld ändern, Inhalt am Ende des Textkörpers anhängen oder den Textkörper umformatieren. Der Klassiker ist die angehängte Fußzeile mit dem Abmeldehinweis. Der RFC nennt das ausdrücklich als Begründung für die optionale Längenangabe: Es sei sehr verbreitet, dass Mailinglisten Anhängsel an Nachrichten ergänzen, etwa Anleitungen zum Verlassen der Liste. Ein Weiterleiter, der Textkörper oder signierte Kopffelder nicht verändert, hält die vorhandene Signatur laut RFC dagegen wahrscheinlich gültig.
?Ist eine kaputte DKIM-Signatur schlimmer als gar keine?
Nach dem Standard nicht. RFC 6376 stellt fest, dass das Überleben von Signaturen nach dem Transport nicht garantiert ist und Signaturen ohne Verschulden des Signierenden fehlschlagen können. Deshalb SOLLTE ein Prüfer eine Nachricht, die eine oder mehrere ungültige und keine gültige Signatur trägt, NICHT anders behandeln als eine Nachricht ganz ohne Signatur. In der Praxis wird das trotzdem zum Problem — nicht wegen DKIM selbst, sondern wegen DMARC: Wenn die Domain eine strenge DMARC-Richtlinie veröffentlicht hat und die DKIM-Signatur unterwegs zerbricht, fehlt der einzige Nachweis, der eine Weiterleitung überstanden hätte. Dann kippt die Mail nicht in den Spam-Ordner, sondern wird abgelehnt.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
Der eigene Mailserver kann nicht senden, empfangen geht? Viele Anbieter sperren den ausgehenden Port 25 gegen Spam — der Versand braucht einen anderen Weg.