Eine verzögerte Nachricht kann zeitbedingt fehlschlagen DKIM überprüfen, auch wenn niemand seinen Inhalt geändert hat. Diagnostizieren Sie die Zeitfelder der Signatur und die Entscheidung des Prüfers, bevor Sie Schlüssel vertauschen oder einem Gateway die Schuld geben. Der Datumskopf der Nachricht, die Signaturerstellungszeit und die Ankunftszeit des Empfängers beschreiben verschiedene Ereignisse.
Lesen Sie t und x richtig
In einem DKIM-Signature Header, t ist der Zeitstempel für die Signaturerstellung und x ist der absolute Ablaufzeitstempel, beide ausgedrückt in Sekunden seit der Unix-Epoche in UTC. RFC 6376 Abschnitt 3.5 markiert beide Tags offiziell als EMPFOHLEN. Sie können fehlen, diese Zulage sollte jedoch nicht mit einer OPTIONALEN Anforderungsstufe verwechselt werden. Der x-Wert ist keine Dauer, die zur aktuellen Zeit addiert werden kann. Wenn beide vorhanden sind, muss x größer als t sein. Fehlendes t bedeutet einen unbekannten Erstellungszeitpunkt; Das Fehlen von x bedeutet, dass durch dieses Tag kein Signaturablauf angegeben wird. DNS TTL ist ein anderes Konzept und legt x nicht fest. Das t-Tag in einem DNS DKIM -Schlüsseleintrag ist eine Reihe von Flags, nicht dieser Signaturzeitstempel.
RFC 6376 Abschnitt 3.5 Ermöglicht Implementierungen, eine Signatur mit einem zukünftigen Zeitstempel zu ignorieren. Es ermöglicht auch, dass eine Signatur als ungültig betrachtet wird, wenn die Verifizierung abgelaufen ist. Für den Vergleich sollte der Verifizierungszeitpunkt der Zeitpunkt sein, an dem die Verwaltungsdomäne des Verifizierers die Nachricht zum ersten Mal empfangen hat, sofern dies zuverlässig verfügbar ist, andernfalls der aktuelle Zeitpunkt. Dadurch bleiben Implementierungsoptionen übrig, die ein Vorfalldatensatz von einer universellen Ablehnungsregel unterscheiden muss.
Erstellen Sie eine Drei-Uhr-Zeitleiste
Erfassen Sie die genaue Unterschrift und den Rohbeweis des Empfängers. Konvertieren Sie t und x in lesbare UTC und behalten Sie dabei die ursprünglichen Ganzzahlen bei. Notieren Sie die Uhr des Unterzeichners, den Zeitpunkt des ersten zuverlässigen Empfangs in der verifizierenden Verwaltungsdomäne und den Zeitpunkt der erneuten Diagnoseprüfung. Fügen Sie relevante Warteschlangenverzögerungen hinzu. Verwenden Sie keinen nicht vertrauenswürdigen Datumsheader als Beweis dafür, wann ein System eine Nachricht empfangen hat.
Anschauliches Szenario: Eine Signatur wird um 10:00 UTC erstellt und läuft um 12:00 UTC ab. Die Nachricht erreicht den Empfänger um 11:50 Uhr, wird aber um 12:15 Uhr erneut geprüft. Ein Prüfer mit zuverlässigen Ersteingangsinformationen kann 11:50 verwenden; Ein späteres eigenständiges Tool hat möglicherweise nur die aktuelle Zeit. Unterschiedliche Ergebnisse allein zeigen keinen beschädigten Inhalt. Das Beispiel beschreibt die zeitliche Unterscheidung des Protokolls, nicht ein Versprechen über einen bestimmten Anbieter.
Unterscheiden Sie den Uhrversatz von einem engen Fenster
Wenn neu ausgegebene Signaturen scheinbar aus der Zukunft stammen, überprüfen Sie die Uhrensynchronisation und die Zeitstempelgenerierung des Unterzeichners. Wenn die Werte sinnvoll sind, E-Mails jedoch regelmäßig nach x eintreffen, überprüfen Sie die Warteschlange, die Wiederholungsrouten und das ausgewählte Gültigkeitsintervall. RFC 6376 schreibt keine universelle ideale Lebensdauer vor. Legen Sie eine unter Verwendung Ihrer tatsächlichen Zustellungsanforderungen und unterstützten Unterzeichnereinstellungen fest.
Ein kurzer Ablauf ist keine vollständige Wiederholungsverteidigung. RFC 6376 Abschnitt 3.5 sagt ausdrücklich, dass x nicht für diesen Zweck gedacht ist. Es ersetzt auch nicht den Schlüsselschutz oder die Missbrauchsüberwachung. Das Entfernen eines alten öffentlichen Schlüssels kann eine verzögerte Überprüfung unabhängig von x unmöglich machen. Koordinieren Sie daher die Ablaufrichtlinie mit der Schlüsselaufbewahrung.
Testen Sie die Reparatur und behalten Sie den Unterschied bei
Senden Sie nach der Korrektur der Uhr- oder Richtlinienkonfiguration neue kontrollierte Nachrichten über den langsamen und den normalen Pfad. Überprüfen Sie ihre Zeitstempel und Empfängerergebnisse. Bewahren Sie Beweise auf, die zeigen, ob der vorherige Fehler Zeit, Schlüsselverfügbarkeit usw. betraf. Körper-Hash oder Signaturprüfung. Bearbeiten Sie t oder x nicht in einer vorhandenen signierten Nachricht: Diese Werte werden von der Signatur abgedeckt und eine Änderung stellt keine Reparatur dar.
Arbeiten Sie ein Epochenbeispiel
Die synthetischen Werte t=1794132000 und x=1794139200 entsprechen dem 8. November 2026 um 10:00 UTC und 12:00 UTC. Ihr Unterschied beträgt 7.200 Sekunden oder zwei Stunden, x selbst bleibt jedoch ein absoluter Zeitstempel. Ein zuverlässiger Ersteingang um 11:50 Uhr liegt vor Ablauf; Danach folgt eine eigenständige erneute Überprüfung um 12:15 Uhr. Die vom Prüfer gewählte Referenzzeit und die zulässige Ablaufbehandlung erklären den möglichen Unterschied. Im Gegensatz dazu verstößt x=t gegen die erforderliche Reihenfolge, wenn beide Tags vorhanden sind. Diese Werte veranschaulichen Rechen- und Protokollregeln, keinen ausgeführten Mailtest.
Führen Sie ein kompaktes Ermittlungsprotokoll
Verwenden Sie dieses vorgeschlagene Arbeitsblatt für die zu prüfende Route. Es handelt sich um eine Planungshilfe, nicht um den Nachweis einer durchgeführten Prüfung.
- Signatur: ursprüngliche t- und x-Werte, ihre UTC-Konvertierungen, d und Wähler.
- Zeitleiste: Uhr des Unterzeichners, erster zuverlässiger Empfang und später erneute Prüfung, mit Zeitzonen.
- Befund: zukünftiger Zeitstempel, abgelaufene Signatur, nicht verfügbarer Schlüssel oder ein anderer Verifizierungsfehler.
- Reparatur: Unterstützte Uhr- oder Lebensdaueränderung und Ergebnisse neu gesendeter normaler und verzögerter Pfadtests.