DKIM Kanonisierung Definiert, wie Nachrichtenbytes für das Hashing und die Signaturüberprüfung vorbereitet werden. Es ermöglicht spezifische Normalisierungen; Es macht die willkürliche Bearbeitung von Nachrichten nicht unschädlich. Diagnostizieren Sie die Einstellungen und den Rohinhalt der tatsächlichen Signatur, bevor Sie die Konfiguration des Absenders ändern.
Lesen Sie die beiden Einstellungen separat
Die Unterschrift c= Tag-Namen, Header- und Body-Kanonisierung in dieser Reihenfolge. Zum Beispiel, entspannt/einfach Verwendet eine entspannte Verarbeitung für Header und eine einfache Verarbeitung für den Text. RFC 6376 §3.5 definiert „simple/simple“ als Standard, wenn das Tag fehlt; Wenn nur der Header-Algorithmus angegeben ist, ist der Body-Algorithmus standardmäßig auf „einfach“ eingestellt.
Aufzeichnen c=, die Liste der signierten Header h=, Die Körper-Hash bh= und jegliche Körperlängenbeschränkung l= neben d= Und s=. Eine Body-Hash-Diskrepanz, eine Header-Signatur-Diskrepanz und ein fehlender öffentlicher Schlüssel erfordern unterschiedliche Untersuchungen. Leiten Sie die Kanonisierungseinstellung nicht aus der Anzeige des E-Mail-Clients ab.
Verstehen Sie die zulässige Normalisierung
Bei der einfachen Header-Kanonisierung bleiben die Header-Felder so erhalten, wie sie dem Algorithmus präsentiert werden. Die entspannte Header-Verarbeitung schreibt Feldnamen in Kleinbuchstaben, entfaltet Fortsetzungszeilen und normalisiert angegebene Leerzeichen. Feldwerte werden nicht in Kleinbuchstaben geschrieben und es ist nicht gestattet, die Wörter eines Betreffs zu ändern.
Durch die einfache Kanonisierung des Textkörpers werden leere Zeilen am Ende entfernt und die erforderliche endgültige CRLF sichergestellt, während andere Textinhalte erhalten bleiben. Die entspannte Verarbeitung des Textkörpers reduziert außerdem Leerzeichen- und Tabulatorfolgen innerhalb einer Zeile und entfernt Leerzeichen an Zeilenenden, bevor nachgestellte Leerzeilen verarbeitet werden. Es kombiniert keine beliebigen Zeilen, schreibt keine URLs um, entfernt keine MIME Grenzen und ignoriert keinen hinzugefügten Text. RFC 6376 §3.4 Gibt die genaue Reihenfolge und Randfälle an, einschließlich der unterschiedlichen Behandlung eines leeren Körpers.
Für exakte Tests verwenden Sie eine konforme Implementierung. Eine von Hand bearbeitete Näherung, die Zeilenenden vor der Überprüfung ändert, kann zu dem Fehler führen, den sie untersuchen soll.
Wenden Sie ein kontrolliertes Beispiel an
Betrachten Sie die synthetische Körperlinie Zahlen Sie<SP><SP>jetzt<SP><CRLF>, wobei die Beschriftungen in Klammern Bytes und keinen wörtlichen Text bezeichnen. Entspannte Körperkanonisierung erzeugt Zahlen Sie<SP>jetzt<CRLF> für diese Zeile. Bei der einfachen Textverarbeitung bleiben die internen und nachfolgenden Leerzeichen erhalten. Eine solche Änderung, die nur auf Leerzeichen beschränkt ist, kann daher unter den beiden Hauptalgorithmen zu unterschiedlichen Ergebnissen führen.
Fügen Sie nun nach der signierten Nachricht einen neuen Satz hinzu. Durch die entspannte Bearbeitung wird dieser inhaltliche Zusatz nicht verworfen. Unter der Annahme einer Ganzkörperabdeckung und keiner weiteren Änderung im Test unterscheidet sich der kanonisierte Körper und auch sein erwarteter Körper-Hash. Eine Fußzeilenregel kann nicht allein deshalb als sicher erklärt werden, weil der Absender „relaxed/relaxed“ verwendet.
Das Beispiel erklärt die erwartete Normalisierung, nicht einen erfassten Vorfall oder einen ausgeführten Test. Berücksichtigen Sie in der Produktion MIME -Codierung, signierte Header und die tatsächliche Längenbehandlung der Signatur. Zwei Nachrichten können identisch wiedergegeben werden, während sich ihre vorzeichenbehafteten Bytes unterscheiden.
Lokalisieren Sie die Transformation, bevor Sie die Richtlinie ändern
Bewahren Sie die ursprüngliche Rohnachricht auf und erhalten Sie dann autorisierte Vergleichsbeispiele vor und nach vermuteten Modifikatoren. Verwenden Sie Kopien zur Analyse. Vergleichen Sie einen ansonsten gleichwertigen Test mit und ohne die verdächtige Fußzeile, Link-Umschreibung oder Neukodierung und behalten Sie dabei den gleichen Transportweg bei.
Wenn die unterstützte Architektur dies zulässt, führen Sie erforderliche Inhaltsänderungen vor der entsprechenden endgültigen Signierungsphase durch. Wenn ein Vermittler erneut unterschreibt, bewerten Sie seine neue Identität und Ausrichtung. Deaktivieren Sie nicht die schützende Gateway-Verarbeitung und schwächen Sie die Domänenrichtlinie nicht, nur um einen Diagnosetest grün zu machen.
Als RFC 6376 §8.2 warnt, eine Körperlänge l= limit ändert, wie viel kanonisierter Körper abgedeckt wird. Es handelt sich nicht um eine allgemeine Problemumgehung für Änderungen nach dem Signieren und es kann dazu kommen, dass angehängte Inhalte außerhalb des signierten Teils verbleiben. Überprüfen Sie die Sicherheitsauswirkungen und die Anbieterunterstützung, anstatt sie hinzuzufügen, um einen Fehler zu unterdrücken.
Beweisen Sie den Fix auf Byte- und Routenebene
Behalten Sie den ursprünglichen Fehler, die Kanonisierungseinstellungen, den kontrollierten Vergleich und ein empfangenes Ergebnis der korrigierten Route bei. Wenn die Änderung der Kanonisierung die gewählte unterstützte Lösung ist, bestätigen Sie, dass der tatsächliche Änderungsvorgang innerhalb der zulässigen Transformationen liegt. Eine neue entspannte Signatur kann einige Leerzeichenänderungen tolerieren, bleibt aber anfällig für die ursprüngliche inhaltliche Neufassung. Schließen Sie das Problem nur, wenn die beobachtete Änderung und das Überprüfungsergebnis übereinstimmen.
Überprüfen Sie den Leerkörper-Randfall
Unter RFC 6376 §3.4.3, wird ein vollständig leerer oder fehlender Körper bei der einfachen Körperkanonisierung zu einem CRLF oder zwei Oktetten. Unter RFC 6376 §3.4.4Die Kanonisierung entspannter Körper erzeugt null Oktette für einen leeren Körper. Ein Tool, das CRLF in beiden Fällen hasht, stimmt nicht mit dem Standard überein, auch wenn beide Nachrichten leer erscheinen. Dies ist ein Spezifikationsbeispiel, keine vollständige DKIM Verifizierung oder ein ausgeführter Mail-Test.
Verwandte Lektüre
DKIM Public-Key-Syntax: Identifizieren Sie abgeschnittene oder fehlerhafte DNS Werte · Mehrere DKIM -Signaturen: Finden Sie die ausgerichtete Passsignatur.