Trennen Sie eine gültige Unterschrift von einer beabsichtigten Zustellung
Eine Wiedergabe ist möglich, wenn signiertes Material in einem Übermittlungskontext wiederverwendet wird, den der ursprüngliche Unterzeichner nicht beabsichtigt hatte. Die Signatur kann mathematisch gültig bleiben, da sich die abgedeckten Bytes nicht geändert haben. Das bedeutet nicht, dass der Unterzeichner eine unbegrenzte Weiterverbreitung autorisiert hat, und es macht nicht jede wiederholte Nachricht zu einem Angriff. Eine sinnvolle Analyse fragt, welcher Kontext authentifiziert wird, welche Partei die Weiterlieferung durchgeführt hat und was ein Empfänger tatsächlich beobachten kann.
RFC 6376 Abschnitt 8.6 erörtert Wiedergabe und Spam als Einschränkungen, die eine operative Beurteilung erfordern. Die DKIM2 Arbeit schlägt zusätzlichen Routen- und Empfängerkontext vor, anstatt einen stärkeren Signaturalgorithmus als gesamte Antwort zu behandeln. Dieser Artikel verwendet Kernentwurf -09vom 1. November 2026. Es handelt sich um eine noch in Arbeit befindliche Datei, es handelt sich nicht um eine veröffentlichte Anti-Replay-Garantie.
Vergleichen Sie zwei fiktive Lieferkontexte
In einem klassischen DKIM-Unterrichtsfall signiert ein Dienst eine Nachricht, die an ein einzelnes vorgesehenes Postfach gesendet wird. Ein Dritter erhält die Nachricht und sendet unveränderte signierte Inhalte an andere Empfänger. Unter der Annahme, dass das signierte Material und die Verifizierungsbedingungen intakt bleiben, kann die Signatur weiterhin verifiziert werden. Das Problem liegt in der Wiederverwendung dieses signierten Artefakts, nicht unbedingt in der Änderung seines Körpers oder der Kompromittierung des Signaturschlüssels.
Nehmen wir für den DKIM2 Vergleich an, dass die neueste Originalsignatur die Lieferung an eine fiktive Adresse unter birch.example beschreibt. Die Wiederverwendung derselben signierten Umschlaginformationen bei der Zustellung an eine andere Adresse sollte beim Empfängervergleich des Entwurfs mit dem neuesten Hop scheitern. Abschnitt 14.4 erfordert, dass jede tatsächliche RCPT TO-Adresse im signierten RT-Wert erscheint, obwohl RT zusätzliche Empfänger enthalten kann. Beim Vergleich von Domänen wird die Groß- und Kleinschreibung nicht beachtet. Lokale Teile erfordern eine exakte Übereinstimmung gemäß den angegebenen Regeln.
Hierbei handelt es sich um einen vorgeschriebenen Vergleich, nicht um eine Abschrift von einem Mailserver. Es isoliert den zusätzlichen Kontext, den der Vorschlag prüft. Es wird nicht behauptet, dass die bloße Veröffentlichung eines DKIM2 Schlüssels dazu führt, dass ein bestehender Empfänger diese Vergleiche durchführt, oder dass ein älterer Empfänger die wiederverwendete Nachricht ablehnt.
Folgen Sie der Verantwortung, wenn ein Vermittler einen Hop hinzufügt
Ein Wiedergabesystem könnte stattdessen einen neuen gültigen Hop hinzufügen. Die vorgeschlagene Kette zeichnet dann eine mit der Weiterverarbeitung verbundene Signaturidentität auf, vorbehaltlich aller Kettenprüfungen. Das ist zwar eine sinnvolle Zuordnung, aber sie kennzeichnet die Aktion nicht automatisch als böswillig. Ein legitimer Spediteur übernimmt auch die Lieferverantwortung. Der Empfänger muss noch die Routenerwartungen und den Ruf oder die Rolle des Vermittlers bewerten.
Abschnitt 15.1 beschreibt die Verwendung wiederholter Beobachtungen des ursprünglichen m=1 Headers und -Body-Hashes der Nachrichteninstanz zusammen mit der Zwischenpräsenz und dem explodierten Flag. Es definiert keine universelle globale Datenbank oder einen festen Volumenschwellenwert, den jede Implementierung verwenden muss. Ein Empfänger mit nur einer beobachteten Nachricht kann durch Zählen nicht gesehener Kopien keine wiederholte Zustellung feststellen.
Die explodierte Flagge meldet, dass ein System an mehrere Adressen sendet. Es hilft zu erkennen, wo Fan-out behauptet wird; Es ist kein Beweis dafür, dass die Auffächerung willkommen war. Behalten Sie bei, welche Signatur sie trägt und ob dieses Verhalten für die Route erwartet wurde. Ein Dashboard, das die Flagge auf „Wiedergabesicher“ reduziert, würde den Entscheidungskontext verwerfen, den der Entwurf offenlegen möchte.
Behalten Sie im Vergleich legitime Duplikate bei
Ein großer Empfangsdienst kann bei der normalen Massenverteilung auf identische Nachrichten stoßen. Es ist auch möglich, dass mehrere Empfänger Kopien weiterleiten, die bei demselben Dienst wieder zusammenlaufen. Protokollwiederholungen können gelegentlich zu Duplikaten führen. Der Entwurf geht ausdrücklich auf diese Unterscheidungen ein. Das Zählen gleicher Hashes ist daher ein Input für die Bewertung und kein eigenständiges Urteil, dass jede zweite Kopie blockiert werden muss.
Ein ursprünglicher Laborplan sollte mindestens vier Fälle enthalten: direkte beabsichtigte Verteilung, Weiterverteilung mit nicht deklariertem Empfängerwechsel, ordnungsgemäß deklarierter zwischengeschalteter Fan-Out und legitime Rekonvergenz. Halten Sie den Nachrichteninhalt nach Möglichkeit unverändert, damit die Erklärung den Routenkontext isoliert. Dann variieren Sie die Sichtbarkeit des Empfängers: eine Kopie, mehrere Kopien und unvollständige historische Beobachtungen. Hierbei handelt es sich um vorgeschlagene Fälle, nicht um Experimente, die für diesen Artikel abgeschlossen wurden.
Behalten Sie den ursprünglichen Uhrkontext bei
Abschnitt 14.3 lehnt die Berechtigung zur vollständigen Überprüfung ab, wenn eine Signatur mehr als vierzehn Tage älter als SMTP Akzeptanz ist oder mehr als einen Tag in der Zukunft im Verhältnis zur Akzeptanz liegt. Der Entwurf erfordert eine genaue Kenntnis dieses Annahmezeitpunkts. Eine erneute Überprüfung einer archivierten Nachricht anhand der heutigen Zeit kann eine andere Frage beantworten als die Überprüfung, was bei ihrem Eintreffen gültig war.
Für eine retrospektive Untersuchung sind daher die ursprünglichen Eingangsmetadaten erforderlich, nicht nur eine gespeicherte Nachrichtendatei. Behalten Sie die beobachtete Zeitquelle, die Zeitstempelwerte, den relevanten DNS /Schlüsselkontext und die Verifiziererversion bei. Auch ein später fehlender Schlüssel oder ein geänderter Datensatz gibt keinen Aufschluss darüber, was der ursprüngliche Prüfer gesehen hat. Trennen Sie „historische Überprüfung kann nicht reproduziert werden“ von „Die Originalunterschrift war ungültig“, es sei denn, die Beweise stützen die stärkere Schlussfolgerung.
Vermeiden Sie spekulative Wiederholungskontrollen
Die optionale Nonce des Entwurfs steht für die Verwendung durch einen Ersteller zur Verfügung, beispielsweise zum Korrelieren späterer Lieferstatusinformationen. Es handelt sich an sich nicht um einen standardisierten, einmaligen Durchsetzungsdienst. Ebenso früher auth= sender-policy discussion betrifft einen separaten Vorschlag und gemischte Bereitstellungsfragen. Es darf nicht als festgelegte Core-09-Syntax oder als Beweis dafür dargestellt werden, dass jeder Forwarder kompatibles Verhalten ankündigt.
Behandeln Sie den Wiedergabeanspruch einer Implementierung als eine begrenzte Frage: Welche Eingaben werden wie lange über welche Empfangsknoten hinweg mit welchen falsch-positiven Kontrollen beibehalten? Bitten Sie um Beweise für wiederholte Beobachtungen und Routenanalysen, nicht nur um eine erfolgreiche kryptografische Prüfung. Datenschutz- und Speicherauswirkungen gehören in diese Überprüfung, da der Erkennungskontext Zustellungsmetadaten über Nachrichten hinweg ansammeln kann.
Geben Sie an, was dieser Vergleich bewirkt und was nicht
Die genaue Provision lautet: Vergleichen Sie einen Klassiker DKIM Wiederholungsszenario mit dem im Entwurf vorgeschlagenen spezifischen Erkennungsmodell. Der obige fiktive Vergleich erklärt die Umschlagbindung, die Zwischenzuordnung, wiederholte Originalbeobachtungen, den Zeitpunkt und die Sichtbarkeitsgrenzen. Es handelt sich um eine dokumentarische Analyse, nicht um eine gemessene Erkennungsrate, einen reproduzierten Angriff oder ein Ergebnis der Empfängerinteroperabilität.
Aktuelle Fälle, versionierte Implementierungen, beibehaltene Verifiziererausgaben und Fachakzeptanz bleiben offen. Ein Sicherheitseigentümer muss jedes zukünftige kontrollierte Experiment ohne unaufgeforderte Änderungen der Datenverkehrs- oder Produktionsrichtlinien genehmigen. Auch Site-, Visual- und Publication-Gates bleiben hervorragend. Die vertretbare Schlussfolgerung ist, dass der Vorschlag Kontext für die Erkennung und Zuordnung der Wiederverwendung hinzufügt, während die tatsächliche Wirksamkeit von der Umsetzung, Beobachtungen und der Beurteilung des Empfängers abhängt.