Zusammenfassung

  • draft-gondwana-dkim2-debug-header-01 vereinheitlicht die X-DKIM2-Info-Spur für frühe DKIM2-Tests; ein neues Prüfergebnis führt der Entwurf nicht ein.
  • Das Feld bleibt absichtlich außerhalb von Hashes und Signaturen. Es kann Menschen zu Belegen führen, authentifiziert aber weder Emittent noch Aktion, Snapshot oder Vollständigkeit.

Die fehlerhafte Nachricht wirkt auf den ersten Blick ungewöhnlich gut dokumentiert. Eine Zeile nennt DKIM2-Entwurf, Repository und Programm des Eingangsfilters. Eine zweite behauptet, die Mailinglisten-Software habe Message-Instance m=2 erzeugt, zählt gehashte Header auf und verweist auf eine frühere Kopie. Der Ausgangsfilter meldet schließlich, wegen einer unterbrochenen Kette nicht signiert zu haben.

Für einen Ingenieur, der zwei Implementierungen vergleicht, ist das ein wertvoller Wegweiser. Für ein System, das zustellt, isoliert oder Verantwortung zuschreibt, ist es kein Beweis. Jede Zeile lässt sich einfügen, umschreiben, verschieben oder löschen, während die von DKIM2 geschützten Teile weiter erfolgreich verifiziert werden.

Genau diese Trennung entwirft A Diagnostic Header Field for DKIM2 Implementations. Revision 01 wurde am 30. September 2026 nach Pazifikzeit registriert, in Shanghai und UTC bereits am 1. Oktober. Sie ist ein individueller Internet-Draft mit vorgesehenem Status Informational und dem Datatracker-Status I-D Exists. Weder hat die DKIM-Arbeitsgruppe ihn angenommen, noch ist er RFC, IANA-Registrierung oder normative DKIM2-Abhängigkeit. Der Text richtet sich an frühe Tests und hält eine spätere Veröffentlichung für unwahrscheinlich.

Gemeinsame Begriffe für unterschiedliche Laufzeitfehler

DKIM2 soll eine prüfbare Kette erhalten, obwohl Mailinglisten und andere Zwischenstellen Nachrichten verändern. Message-Instance-Felder enthalten Hashes und Recipes zur Rekonstruktion früherer Zustände; DKIM2-Signature-Felder verbinden die geschützten Datensätze. Wenn zwei Prototypen zu verschiedenen Ergebnissen kommen, sagt ein abschließendes Erfolg oder Fehler zu wenig über den ersten abweichenden Schritt.

X-DKIM2-Info gibt den Hinweisen einen wiederholbaren Ort. Jedes Feld trägt fünf Pflicht-Tags in dieser Reihenfolge: draft, repo, date, sw, action. Das erste benennt die implementierte DKIM2-Fassung. Repository und Programm unterscheiden Komponenten oder Forks. Das Datum soll wechseln, sobald sich das DKIM2-Verhalten des Emittenten ändert. Ein Feld beschreibt eine Aktion; mehrere Aktionen brauchen mehrere Felder.

Das Vokabular umfasst Verifikation, eine neue Message-Instance, eine Signatur und die Ablehnung einer Signatur. verify=pass oder verify=fail darf freien Erklärungstext tragen. mi-m=<N> kann Zahl und Reihenfolge der gehashten Header sowie Kennungen des gelesenen und gespeicherten Snapshots nennen. sign führt Domain und Algorithmus auf. not-signed erhält einen implementierungsgewählten Grund wie broken-mi-chain.

Revision 01 beseitigt unnötige Unterschiede zur Revision 00: Sie übernimmt die Erweiterungs-Tag-Syntax von DKIM2, verlangt hinter jedem Tag ein Semikolon und ändert mi-m<N> in mi-m=<N>. Das erleichtert den syntaktischen Vergleich. Beglaubigt wird dadurch nichts.

Beweglich bleibt das Feld nur, weil der Beweis es auslässt

Der zugrunde liegende DKIM2-Entwurf nimmt Headernamen mit X- vom Message-Instance-Headerhash aus. Der Diagnoseentwurf verbietet zusätzlich, X-DKIM2-Info in eine Signatur oder einen Hash des Emittenten aufzunehmen. Deshalb kann eine Komponente ihre Notiz neben den beschriebenen Header setzen, ohne die geschützte Message-Instance zu verändern oder eine DKIM2-Signatur ungültig zu machen.

Dieselbe Eigenschaft verhindert, dass die Notiz ihre Geschichte belegt. Der Text bezeichnet sie nicht als Prüfergebnis; das autoritative Ergebnis gehört in Authentication-Results. Das Feld hält nur fest, was der Emittent nach eigener Aussage getan hat, und Software darf keine Entscheidung über die Nachricht darauf stützen. Jede Station kann eine Zeile unbemerkt hinzufügen, ändern oder entfernen.

Damit unterscheidet sich das Thema von der früheren BTW-Analyse zu Authentication-Results. Dort ging es um das lokal vertraute authserv-id innerhalb einer administrativen Domäne und einer SMTP-Transaktion. X-DKIM2-Info liegt noch unter dieser lokalen Urteilsschicht. Es soll einem Menschen die nächste Frage liefern, nicht einem Filter die Antwort.

Nachbarschaft ist keine signierte Kausalität

Laut Entwurf fügt ein Emittent zunächst den geschützten oder operativen Header ein und setzt unmittelbar darüber das beschreibende Debugfeld. Ein konformer Emittent soll bereits vorhandene Felder weder verändern noch entfernen. So entsteht im Headerblock eine gut lesbare Chronologie.

Doch die Position ist nicht authentifiziert. Ein späterer Handler kann ein überzeugendes action=sign voranstellen, eine Zeile neben eine andere Message-Instance verschieben oder die Erklärung eines Fehlers löschen. Repositorypfad und Programmname sind Selbstbeschreibungen statt Binärattestierung. Das Verhaltensdatum ist kein Commit-Hash. Ereignis-ID, Instanzschlüssel, Sequenznummer, Empfangsbestätigung und Vollständigkeitserklärung fehlen.

Auch Schweigen bleibt mehrdeutig. Passt die oberste Message-Instance weiterhin und fügt der Emittent nichts hinzu, verzeichnet das Format keine Aktion. Ein fehlendes mi-m=<N> belegt weder die Durchführung einer Prüfung noch das Ausbleiben einer Änderung oder die lückenlose Übertragung der Spur.

Der Snapshot-Zeiger ist nicht der Snapshot

snapf bezeichnet die frühere gespeicherte Nachricht, aus der eine Recipe berechnet wurde. snaps bezeichnet die aktuelle Kopie für einen späteren Vergleich. Diese Tags sind besonders nützlich im Betrieb, doch ihre Bedeutung beschränkt sich laut Entwurf auf den Emittenten. Ein Beispiel sieht wie Datenbankschlüssel oder Speicherpfad aus.

Mit dem Token kann der Support den Betreiber gezielt nach Bytes, Protokollen und Aufbewahrung fragen. Außerhalb dieses Systems beweist er weder Inhalt noch Verwahrung, Haltedauer oder Verfügbarkeit. Ohne getrennten Inhaltsdigest und Abrufbeleg ist die kopierte Kennung kein portables Beweisobjekt.

Die Diagnose verrät möglicherweise mehr als beabsichtigt: Repository, Programm, Entwurfsstand, Speicherstruktur, Headerinventar und Parserdetails in Freitext. Der Betreiber darf das Feld an der Ausgangsgrenze entfernen, ohne die DKIM2-Prüfung zu stören. Damit schützt er Architekturinformationen, nimmt aber dem entfernten Tester die Spur. Interne Aufbewahrung und externe Offenlegung gehören in eine gemeinsame Regelung.

Eine Parserkante bleibt ebenfalls. RFC 5322 erlaubt Semikolons in Headerfeldnamen; das neue Format verwendet sie ohne Quotierungsmechanismus als Tagabschluss. Der Entwurf verlangt, unsichere Namen aus hn wegzulassen, seine Länge zu begrenzen und Semikolons in eingesetzten Werten zu ersetzen oder zu entfernen. Das mindert Mehrdeutigkeit, beweist jedoch keine einheitliche Umsetzung in frühen Implementierungen.

RFC 6648 beschreibt das allgemeinere Risiko von X--Namen: Private Erweiterungen entweichen, werden faktische Schnittstellen und erschweren spätere Migration. Hier ist das Präfix ein bewusster Kompromiss, der Diagnose von DKIM2-Semantik und Kryptografie fernhält. Eine saubere Protokollgrenze ist noch keine Garantie für organisatorische Eindämmung.

Den Hinweis zum überprüfbaren Beleg weiterverfolgen

Eine belastbare Untersuchung trennt behauptete Softwareidentität, behauptete Aktion, tatsächlich empfangenes Feld, empfangende oder entfernende Grenze, reale DKIM2-Prüfung, lokales Authentication-Results, Build und Logs, referenzierte Snapshots, Ursachenurteil, Reparatur und beobachtetes Zustellergebnis. Wer eine Stufe überspringt, macht aus Supportkomfort eine unbelegte Schlussfolgerung.

Heng Lus Lehre einer minimalen Anfangsspezifikation unterstützt diese Aufteilung. Ein gemeinsames Format erleichtert unabhängige Tests, ohne lokale Laufzeitwahrheit vorzutäuschen. Der Vorrang laufenden Codes verlangt danach Beobachtung, Abruf, Reproduktion und eine erneute Messung nach der Reparatur.

X-DKIM2-Info ist nützlich, weil es lesbare Fingerabdrücke nahe der Störung hinterlässt. Gefährlich wird es erst, wenn diese Hilfe zu Herkunftsnachweis, Richtlinie oder Urteil befördert wird. Gute Automatisierung entscheidet nicht anhand des Hinweises, sondern findet damit überprüfbare Belege.

Quellen