Zusammenfassung

  • l= begrenzt den DKIM-Body-Hash auf ein Anfangspräfix nach der Kanonisierung. Alle folgenden Bytes bleiben für diese Signatur ungeprüft, auch wenn die Verifikation erfolgreich endet.
  • h= zieht eine zweite Grenze um geordnete Header-Instanzen. Bei mehrfach vorkommenden Feldern entscheidet die Auswahlregel, welcher From-, Subject- oder MIME-Wert tatsächlich signiert ist.
  • Ein reproduzierbarer Beleg bewahrt Rohmail, ausgewählte Signatur, Kanonisierung, Headerkarte, Längen und Hashes von Präfix und Suffix, beobachteten DNS-Schlüssel, Verifizierer und die Vertrauensgrenze von Authentication-Results.

Der Prüfer war fertig, die Nachricht nicht

In einem Prüfbericht stehen dkim=pass, 18.900 kanonisierte Body-Oktette und l=14.500. Der erste Wert wirkt wie ein Urteil. Die beiden anderen machen daraus eine begrenzte Messung: 4.400 Oktette lagen hinter dem Hash-Ende.

Diese Bytes können ein üblicher Mailinglisten-Footer, ein Archivhinweis, eine veränderte MIME-Fortsetzung oder eine gezielte Einfügung sein. Der Pass klassifiziert sie nicht. Sie sind auch nicht kryptografisch fehlgeschlagen; sie wurden von dieser Signatur gar nicht validiert.

RFC 6376 beschreibt genau diesen Vertrag. Ohne l= wird der gesamte kanonisierte Body einbezogen. Mit l= fließt nur die angegebene Anzahl von Oktetten ab Body-Anfang ein. Daten dahinter sind nicht DKIM-validiert. l=0 lässt den Body vollständig unsigniert.

Ein Verifier darf nach lokaler Policy streng reagieren und partielle Abdeckung ablehnen. Deshalb gehören Berechnung und Disposition in getrennte Felder. Sonst sieht eine Policy-Änderung wie ein Kryptografiefehler aus oder ein mathematischer Erfolg wie eine Inhaltsfreigabe.

Murray Kucherawys Rolle bleibt dokumentbezogen. RFC 6376 nennt Dave Crocker, Tony Hansen und Murray S. Kucherawy gemeinsam. RFC 8601 führt Kucherawy als Autor. Sein offizielles IETF-Profil zeigte bei der Erfassung am 2. September 2026 in der RFC-Tabelle 34 Einträge, während die selbst verfasste Biografie noch 33 nannte. Weder gemeinsame Autorenschaft noch eine veränderliche Profilzahl belegen Kontrolle über eine konkrete Signatur oder Mailanlage.

Zählen beginnt erst nach der Kanonisierung

l= ist kein Offset in der rohen .eml-Datei. Zuerst wendet DKIM die in c= angegebene Body-Kanonisierung an. simple und relaxed behandeln Leerzeichen, Zeilenenden und abschließende Leerzeilen unterschiedlich. Rohgröße minus l= kann daher den falschen Suffix liefern.

Die Reproduktion hält die Reihenfolge fest: Originalnachricht speichern; eine konkrete DKIM-Signature auswählen; a=, c=, d=, s=, h=, l= und bh= auslesen; Body kanonisieren und messen; bei vorhandenem l= das Präfix abschneiden; Body-Hash vergleichen; anschließend die Header-Signatur mit dem beobachteten Schlüssel prüfen.

Der Beleg enthält Länge und Hash des vollständigen kanonisierten Bodys, des signierten Präfixes und des unsignierten Suffixes. Ein positiver Suffixwert beweist nur eine Scope-Differenz. Ohne l= wird vollständige Body-Abdeckung protokolliert, nicht ein erfundener Zahlenwert.

Auch der Schlüssel hat eine Beobachtungszeit. d= benennt die Signing Domain, s= den DNS-Selector. Rotation und Widerruf können spätere Antworten ändern. Für eine alte Entscheidung zählen Schlüsselmaterial, Lookup-Zeit, Resolverantwort und Fehler von damals; DNSSEC gehört nur hinein, wenn es tatsächlich geprüft wurde.

Nützliche Robustheit schafft zugleich Einfügungsraum

Mailinglisten sind der praktische Grund für l=. Sie hängen Abmeldehinweise oder Listeninformationen an. Eine Vollbody-Signatur würde dadurch brechen. Das Präfixmodell lässt den ursprünglichen Teil erkennbar und übergibt die Zusatzbehandlung an lokale Policy.

Die Grenze erkennt aber keinen guten Betreiber. RFC 6376 warnt, dass ein böswilliger Vermittler Inhalt zu seinem Vorteil anhängen kann. Veränderte MIME-Struktur, tolerantes HTML-Parsing oder beeinflusste Duplikaterkennung können den Suffix in der Nutzeransicht vor den Ursprung drängen.

Jeden Footer als Angriff zu bezeichnen wäre falsch. Ihn wegen des Präfix-Passes als authentisch zu behandeln ebenso. Die Untersuchung identifiziert den Intermediär, vergleicht seine deklarierte Transformation, baut den MIME-Baum nach und erfasst die tatsächlich gerenderte Part-Auswahl.

Heng Lus Running-Code-Perspektive trennt Norm und Ausführung. Der RFC beschreibt die Byte-Operation. Erst Nachricht, Verifier-Version und Renderer-Spur zeigen, was die konkrete Software berechnet und angezeigt hat.

h= ist eine geordnete Abdeckung

Vollständiger Body bedeutet nicht vollständige Header. h= ist eine geordnete Liste von Feldnamen. Bei Wiederholungen ordnet DKIM die Instanzen von unten nach oben zu. Eine bloße Namensmenge verliert, welcher Subject- oder From-Wert ausgewählt wurde.

From muss enthalten sein. RFC 6376 empfiehlt Date, Subject, Reply-To, Sender und MIME-Felder, die Anzeige oder Verarbeitung beeinflussen. Bei l= ist Content-Type besonders wichtig: Eine unsignierte Änderung kann dasselbe Präfix völlig anders rendern.

Eine Coverage Map listet alle Rohheader in Reihenfolge, markiert die aufgelösten Instanzen und nennt anzeigerelevante Felder außerhalb des Scopes. Auch Oversigning nicht vorhandener Feldnamen ist sichtbar zu machen, weil es spätere Einfügungen erschweren kann. Jede Signatur — Ursprung, Liste, Gateway — erhält eine eigene Karte.

Eine Domain-Signatur bestätigt nicht die ganze Erzählung

Ein Pass sagt, dass eine ausgewählte Signatur mit einem unter Domain und Selector veröffentlichten Schlüssel über ihr Material verifiziert wurde. Er beweist weder den menschlichen Autor noch interne Nutzungsberechtigung des Schlüssels, Wahrheit, Anhangssicherheit oder Zustellung.

RFC 5585 begrenzt die Aussage auf Unverändertheit der signierten Nachricht oder Portion. RFC 5863 fordert, nur Material im Scope als authentisch zu betrachten, und nennt l= ausdrücklich. RFC 8301 aktualisiert Algorithmen und Schlüsselgrößen. Ein starker Schlüssel erweitert kein kurzes Präfix.

DMARC prüft Identitätsausrichtung mit dem sichtbaren From-Domain und gibt ein Policy-Signal. Es verändert weder h= noch l=. Kryptografische Gültigkeit, Alignment, Reputation, Sicherheit, Disposition und Anzeige bleiben getrennte Messgrößen.

Authentication-Results braucht einen vertrauenswürdigen Urheber

Viele nachgelagerte Systeme lesen Authentication-Results, statt DKIM erneut auszuführen. RFC 8601 definiert diesen Transfer in einer administrativen Vertrauensumgebung. Das Feld ist im Regelfall nicht selbstbeweisend.

Der Consumer akzeptiert konfigurierte authserv-id-Werte. Am Rand müssen von außen kommende Felder, die sich als interne Ergebnisse ausgeben, entfernt oder neutralisiert werden. Jeder Sender kann dkim=pass schreiben; erst die Architektur des Empfängers macht daraus eine Messung.

Gespeichert werden Rohfeld, Position, Produzent, Vertrauensregel und exakte Zielsignatur. Fasst ein Gateway mehrere Signaturen zu einem anonymen Pass zusammen, gehen Domain, Selector, Headerliste und Bodygrenze verloren. Methodenergebnis und lokale Behandlung werden ebenfalls getrennt bewahrt.

Das minimale Scope-Ledger

Der Kern enthält die gehashte Rohmail und jede DKIM-Signature in Originalreihenfolge, samt d=, s=, optionalem i=, a=, c=, h=, l=, bh=, Signaturwert und vorhandenen Zeiten.

Danach folgen beobachteter DNS-Schlüssel und Zeitpunkt, reproduzierbare Kanonisierung, aufgelöste Header-Instanzen, Längen und Hashes der drei Body-Bereiche, Verifier-Software, Ergebnis und Grund. Ein eigener Block dokumentiert Authentication-Results-Produzent und Grenze. Der Darstellungsblock hält MIME-Baum, gewählte Parts, Renderer-Version und Einfluss von Bytes hinter l= fest.

Heng Lus Agency-Prinzip weist jede Aussage ihrem Akteur zu: Standardautoren definieren Syntax; Schlüsselverwalter wählen Scope; Intermediäre verändern; Verifier berechnen; administrative Domains sichern den Ergebnisweg; Clients rendern. Keiner kann für alle anderen sprechen.

Der belastbare Satz lautet: Diese Signatur deckte mit diesem beobachteten Schlüssel diese geordneten Header-Instanzen und die ersten N kanonisierten Body-Oktette; dieser Suffix blieb ungeprüft; dieser vertrauenswürdige Verifier meldete das Ergebnis; dieser Client zeigte diese Parts. Autorenschaft, Sicherheit und Absicht erfordern eigene Belege.

Quellen