Zusammenfassung

  • Revision 00 schlägt ein maschinenlesbares Gesamtergebnis für die DKIM2-Kette vor, ergänzt um die Ursprungsdomain und gegebenenfalls die Nummer der Signatur, der ein Fehler zugeordnet wird.
  • DKIM2 schützt den Ergebnis-Header nicht. Er ist nur innerhalb der erzeugenden ADMD vertrauenswürdig und darf nicht als Beleg an das nächste System weitergereicht werden.
  • Bei einem Ergebnis ungleich pass kann header.d diagnostisch nützlich sein, ohne eine authentisierte Identität zu bilden; der Hop-Kommentar ist nicht vertrauenswürdiger Freitext, keine Policy-Schnittstelle.

Ein Mailgateway kann eine DKIM2-Kette korrekt prüfen und dennoch einen gefährlichen Datensatz erzeugen: nicht weil das Ergebnis falsch ist, sondern weil später niemand mehr weiß, wo es galt. Wird dkim2=pass aus der internen Nachrichtenstrecke herausgelöst und an eine fremde Organisation übergeben, bleibt ein Befund ohne seine Vertrauensbeziehung zurück.

Der am 5. September 2026 angekündigte Erstentwurf schließt diese Lücke nicht mit neuer Kryptografie. Er definiert eine Darstellung. Die DKIM2-Kette ist nachprüfbare Evidenz; Authentication-Results ist der nach der Prüfung erzeugte Bericht für lokale Komponenten.

Der Datatracker-API-Eintrag weist das Dokument als individuellen Internet-Draft ohne formelle IETF-Geltung aus. Die XML-Quelle fixiert Revision 00, die I-D-Ankündigung Zeitpunkt, Autor und Umfang. Der angegebene Standards-Track-Status ist eine Absicht, keine erfolgte Standardisierung.

Der zugrunde liegende DKIM2-WG-Entwurf in Revision 06 kennt vier Ergebnisse einer versuchten Prüfung: PASS, FAIL, PERMERROR und TEMPERROR. Der neue Entwurf ordnet sie den kleingeschriebenen RFC-8601-Werten zu und ergänzt none, wenn keine DKIM2-Signatur vorhanden war und keine Prüfung stattfand. Die Datatracker-API-Metadaten des WG-Dokuments belegen dessen eigenen Prozess, nicht die Annahme des Berichtsentwurfs.

Gemeldet wird nur ein Ergebnis für die gesamte Nachricht. DKIM1 kann mehrere unabhängige Signaturen getrennt ausweisen. Bei DKIM2 lautet die Frage, ob die Chain of Custody als Ganzes hält. Der Prüfer beginnt mit der neuesten, höchstnummerierten Signatur und darf bei einem Fehler abbrechen. Ältere Signaturen erscheinen dann im Kommentar als skipped: weder bestanden noch durchgefallen, sondern ungeprüft.

Damit wird header.d zustandsabhängig. Es übernimmt die Signing Domain der Ursprungssignatur i=1 und darf auch bei Fehlern zur Diagnose erscheinen. Authentisierte Identität ist es jedoch nur bei einem Gesamtergebnis pass. Wer die Domain in eine Reputationsdatenbank übernimmt und fail oder temperror verwirft, vernichtet die Herkunftsbedingung des Werts.

Bei header.i droht ein Typfehler. Unter DKIM2 ist es die laufende Nummer der Signatur, der ein Fehler zugerechnet wird. Unter DKIM1 bezeichnet derselbe Property-Name einen Agent or User Identifier. Ohne Methodennamen vermischt ein gemeinsames Schema Fehlerposition und Identität.

Die Vertrauensarchitektur stammt aus RFC 8601. Authentication-Results transportiert Prüfresultate zwischen Validierungs- und Bewertungskomponenten innerhalb einer Administrative Management Domain. Das Feld besitzt meist keine eigene Integrität. Ein Border-MTA muss daher eingehende, nicht vertrauenswürdige Instanzen entfernen, die mit der eigenen authserv-id auftreten, bevor es lokale Ergebnisse hinzufügt.

Die authserv-id benennt den behaupteten Prüfdienst; sie beglaubigt sich nicht selbst. Zulässige Kennungen und interne Pfade sind lokale Konfiguration. DKIM2 nimmt Authentication-Results bewusst von der Signatur aus, weil das Feld nach der Prüfung entsteht und an Grenzen entfernt wird. Jeder Nachrichtenverarbeiter kann es ändern, ohne dass die DKIM2-Prüfung dies erkennt.

Auch ein ehrlicher Befund ist nicht übertragbar. Die neueste DKIM2-Signatur bindet die MAIL-FROM- und RCPT-TO-Werte einer konkreten SMTP-Transaktion. Das pass gilt bis zu dem Prüfer, der genau diese Übergabe sah. Eine Weiterleitung schafft eine neue Transaktion. Der Forwarder darf den alten Befund nicht für den nächsten Empfänger kopieren. Er fügt eine eigene DKIM2-Signatur hinzu; das nächste System prüft die erweiterte Kette und erzeugt seinen eigenen lokalen Bericht.

Der empfohlene Kommentar liefert Hop-Nummern, Domains, Einzelergebnisse und Diagnose. Ein konformer Parser darf ihn verwerfen. Seine Regelmäßigkeit dient Menschen bei der Fehlersuche, nicht Maschinen als stabile Grammatik. Automatisierung muss Ergebnis und definierte Properties verwenden.

Mehrere eingesetzte Werte—Selector, Domains, MAIL FROM und RCPT TO—können vom Absender oder einem Zwischenknoten beeinflusst werden. In RFC 5322 steuern Klammern und Backslash die Kommentarsyntax. Sie müssen escaped, Werte sollten längenbegrenzt und beim Anzeigen als unvertrauenswürdiger Text behandelt werden. Sonst kann ein Angreifer den Kommentar vorzeitig schließen und weitere angebliche Authentisierungsergebnisse einschleusen.

Die Diagnose kann außerdem durchlaufene Domains, Weiterleitungsbeziehungen und Empfängeradressen offenlegen. Eine grenzenlose Aufbewahrung erweitert die Exposition, ohne den Befund kryptografisch stärker zu machen.

Der Entwurf orientiert sich an ARC: wenige maschinenlesbare Properties, reichere Instanzdetails im Kommentar. DKIM erklärt die älteren Property-Bedeutungen; die Internet Mail Architecture ordnet die ADMD als Betriebsgrenze ein.

Im IANA-Register für E-Mail-Authentisierung stand dkim2 bei der Prüfung noch nicht. Revision 00 beantragt die Methode, zwei Properties und fünf Ergebnisse. Der Antrag ist kein vollzogener Registereintrag.

Heng Lus Minimum Initial Specification erlaubt ein gemeinsames Vokabular, ohne künftige lokale Entscheidungen zu enteignen. Reality Layers trennt Signatur, Prüfung, Bericht und Handlung. Running-Code Primacy fragt, ob der Border-MTA fremde Felder tatsächlich entfernte und das nächste System tatsächlich neu prüfte.

Interoperabel darf die Schreibweise sein. Übertragbar ist deshalb noch lange nicht ihr Vertrauen.