Eine Nachricht kann einen gültigen Wert haben DKIM Signatur während seine Abmeldefelder nicht signiert sind. Das ist eine bedeutsame Lücke: Ein Empfänger, der die Nachricht überprüft, hat nicht unbedingt die angekündigte Opt-out-Aktion überprüft. Überprüfen Sie die Abdeckung der Signatur, nicht nur eine generische Signatur DKIM Pass-Label.
Suchen Sie die Signatur, die den Vorgang schützt
RFC 8058 erfordert mindestens eine gültige DKIM Signaturabdeckung List-Unsubscribe und List-Unsubscribe-Post . Beide Felder müssen im h=-Tag dieser gültigen Signatur erscheinen. Eine fehlende erforderliche Signatur ist für den Empfänger ein Grund, die One-Click-Abmeldung gemäß der Spezifikation nicht anzubieten. RFC 8058 Abschnitt 4.
Eine Nachricht kann mehrere Signaturen tragen. Kombinieren Sie nicht die Gültigkeit des einen mit der Header-Abdeckung eines anderen und bezeichnen Sie das Paar als ausreichend. Identifizieren Sie eine einzelne gültige Signatur, die die erforderlichen Felder abdeckt, und behalten Sie dann den Unterzeichner bei. Wähler und Verifizierungsergebnis. Dies ist unabhängig von der Prüfung, welche Signatur dazu beiträgt DMARC Ausrichtung.
Platzieren Sie die Kopfzeilen vor dem entsprechenden Signierschritt
Ordnen Sie die Nachrichtenkonstruktionspipeline zu: Anwendungsvorlage, Listenverarbeitung, Gateway-Transformationen, Unterzeichner und endgültige ausgehende Route. Wenn ein Dienst die Abmeldefelder nach dem Signieren hinzufügt, kann eine frühere Signatur gültig bleiben, ohne sie abzudecken. Die Lösung besteht darin, die Felder vor der entsprechenden Signatur zu platzieren oder sicherzustellen, dass sie von einer späteren gültigen Signatur abgedeckt werden.
Lesen Sie die zuletzt ausgegebene Nachricht. RFC 6376 definiert die h=-Listen- und Header-Auswahlregeln, einschließlich der Art und Weise, wie wiederholte Feldnamen gehandhabt werden. Eine Zeichenfolgensuche nach „list-unsubscribe“ an einer beliebigen Stelle in der Nachricht ist kein Abdeckungstest. Doppelte Felder und Transformationen erfordern eine sorgfältige Prüfung der tatsächlichen Signatureingabe. RFC 6376 Abschnitte 3.5 und 5.4.
Unterscheiden Sie signierte und nicht signierte Änderungen
Stellen Sie sich eine kontrollierte Testnachricht vor, deren ansonsten gültige Signatur beide Abmeldefelder abdeckt. Wenn Sie den signierten URI auf einen anderen Wert ändern, ändert sich die signierte Eingabe. Bei der normalen DKIM Überprüfung validiert die Originalsignatur die geänderte Eingabe nicht mehr. Im Gegensatz dazu kann eine Signatur, die beide Felder auslässt, gültig bleiben, nachdem sich diese vorzeichenlosen Werte geändert haben. Dies erklärt, warum ein generischer Durchgang nicht jedes Feld authentifizieren kann.
Hierbei handelt es sich um protokollbasierte Erwartungen, nicht um eine ausgeführte kryptografische Vorrichtung. Für einen tatsächlich autorisierten Mutationstest sind genaue Originalbytes, die ausgewählte Signatur und der korrekte Verifizierungsschlüssel erforderlich. Ein injizierter Testschlüssel zeigt nur die kryptografische Beziehung dieses Tests, nicht die öffentliche DNS Herkunft oder das historische Empfangsergebnis. Behalten Sie das Original und erstellen Sie eine separate Kopie.
Überprüfen Sie den gesamten signierten Pfad
Nachdem Sie die Abdeckung behoben haben, senden Sie eine autorisierte Testnachricht erneut über die vorgesehene Route und überprüfen Sie sie auf der Empfängerseite. Das Umschreiben von Links, Gateway-Änderungen oder ein späterer Listenprozessor können ein abgedecktes Feld ändern. Bewahren Sie nach Möglichkeit die Proben vor der Umwandlung und die Endproben auf, damit der Eigentümer die erste Phase lokalisieren kann, in der die Verifizierung voneinander abweicht.
Vermeiden Sie die Lösung des Problems, indem Sie einfach die Felder aus h=. Dies kann die Erhaltung der Signatur erleichtern, während die RFC 8058 Anforderung nicht erfüllt wird. Wenn ein Gateway die Aktion umwandeln muss, koordinieren Sie die endgültige Signaturgrenze und stellen Sie sicher, dass der umgewandelte URI weiterhin dem richtigen Empfänger und der richtigen Liste zugeordnet ist.
Führen Sie die Funktionsprüfung durch
Die Signaturabdeckung authentifiziert die angekündigten Felder. es beweist nicht, dass der Endpunkt die angeforderte Unterdrückung durchführt. Verwenden Sie ein kontrolliertes Abonnement, um den POST- und Downstream-Next-Send-Ausschluss separat zu testen. Umgekehrt repariert ein funktionierender Endpunkt keine fehlende Signaturabdeckung.
Der Abschlussdatensatz sollte die gültige Abdecksignatur, die genaue Endnachricht, den Endpunktbereich und das beobachtete Unterdrückungsergebnis angeben. Behalten Sie die Anzeige der Benutzeroberfläche des Anbieters als separate Beobachtung und nicht als versprochene Folge einer korrekten Signatur bei.
Behalten Sie einen signaturspezifischen Abschlussdatensatz
Notieren Sie die endgültige Nachricht, den Unterzeichner, den Selektor, die beiden abgedeckten Felder und das Überprüfungsergebnis für diese bestimmte Signatur. Endpunkt- und Unterdrückungsergebnisse separat aufzeichnen. Wenn ein späteres Gateway die Felder verändert, reparieren Sie die Signaturgrenze, anstatt die erforderliche Abdeckung zu verwerfen.