Ein Zeilenendeproblem ist ein Problem auf Byteebene. Eine Nachricht in einen Editor zu kopieren, dieselben Zeilen zu sehen und zu dem Schluss zu kommen, dass sich nichts geändert hat, ist nicht zuverlässig DKIM Untersuchung. Bewahren Sie die Originaldarstellung auf und stellen Sie fest, ob die Umwandlung vor der Unterzeichnung, während des Transports oder erst während der Beweiserhebung erfolgt ist.
Legen Sie die erwartete Form fest
Internet-Mail verwendet CRLF-Zeilentrennzeichen. RFC 6376 §5.3 erfordert, dass ein Unterzeichner vor dem Signieren lokale Bare-CR- oder LF-Konventionen in die SMTP-Standard-CRLF-Sequenz konvertiert. Die Konvertierung sollte sich auf die übertragene Nachricht beziehen und nicht nur auf eine private Kopie, die an den Signaturalgorithmus übergeben wird. Das Unterzeichnen einer Erklärung und die Übermittlung einer anderen Erklärung führt zu Meinungsverschiedenheiten bei der Überprüfung.
Kanonisierung hat engere Regeln als die allgemeine Textnormalisierung. Einfache Kanonisierung des Körpers Ignoriert abschließende Leerzeilen und stellt die erforderliche endgültige CRLF bereit. Entspannte Körperkanonisierung Entfernt außerdem Leerzeichen am Zeilenende und komprimiert Leerzeichen- oder Tabulatorfolgen innerhalb einer Zeile. Im Allgemeinen werden keine sinnvollen Zeilenumbrüche gelöscht oder umbrochener Text verbunden. Die Header- und Body-Algorithmen können unterschiedlich sein. Lesen Sie daher beide Teile von c, anstatt einen einzigen Modus anzunehmen.
Schützen Sie zuerst die Beweise
Sammeln Sie Rohnachrichtendateien vom Unterzeichner und Empfänger mithilfe von Methoden, deren Transformationen Sie verstehen. Behalten Sie schreibgeschützte Originale und Hashes dieser Dateien. Untersuchen Sie in einer Arbeitskopie die CRLF-, Bare-LF- und Bare-CR-Anzahl mit einem bytebewussten Tool. Die Anzeige eines Textbetrachters reicht nicht aus: Viele Betrachter stellen jedes Formular als Zeilenumbruch dar.
Fragen Sie, wie die Probe gewonnen wurde. Eine Archiv-, Shell-Pipeline- oder Quellcodeverwaltungseinstellung kann Endungen nach der Übermittlung normalisieren. Ein Unterschied in den exportierten Dateien bedeutet nicht, dass sich die SMTP Nachricht selbst geändert hat. Vergleichen Sie nach Möglichkeit unabhängige Aufnahmen an derselben Grenze und behalten Sie das Exportverfahren mit den Beweisen bei.
Verwenden Sie einen kleinen kontrollierten Koffer
Illustrative Eingabe: Ein Körper besteht aus Alpha, ein CRLF, Betaund ein abschließendes CRLF. Das Hinzufügen einer leeren Nur-CRLF-Zeile am Ende wird durch die Standardkörperalgorithmen wegnormalisiert. Das Ersetzen des Zeilenumbruchs zwischen Alpha und Beta durch ein Leerzeichen ändert den Inhalt und ist nicht der gleiche Vorgang. Das Hinzufügen von Leerzeichen am Ende der Alphalinie unterscheidet sich bei der einfachen Körperkanonisierung, wird jedoch bei der entspannten Körperkanonisierung normalisiert.
Diese Beispiele erläutern die Regeln; Sie ersetzen nicht die Prüfung einer vollständigen Unterschrift. Eine gültige Körper-Hash ist nur ein Teil der DKIM Verifizierung. Die Header-Auswahl, der Abruf des öffentlichen Schlüssels und die kryptografische Signatur müssen ebenfalls erfolgreich sein.
Finden und korrigieren Sie die verantwortliche Phase
Wenn der Unterzeichner nur lokale LF-Daten empfängt, überprüfen Sie vor dem Signieren die Serialisierungsphase. Wenn die Ausgabe des Unterzeichners korrekt ist, eine spätere Roherfassung jedoch abweicht, untersuchen Sie das Konvertierungs- oder Wiederherstellungsverhalten dieses Hops. Wenn sich nur Ihre exportierten Beweise unterscheiden, reparieren Sie die Erfassungsmethode, anstatt den Produktions DNS oder die Schlüssel zu ändern.
Nehmen Sie eine eng begrenzte Änderung vor, die sicherstellt, dass der Unterzeichner und die übertragene Nachricht dieselbe normalisierte Darstellung verwenden. Erfinden Sie keinen benutzerdefinierten Prüfer, der beliebige Zeilentransformationen akzeptiert, damit die Probe erfolgreich ist. Ein solcher Prüfer würde die veröffentlichten DKIM Regeln nicht mehr testen.
Überprüfen Sie mehr als eine Nachricht
Senden Sie nach der Änderung eine kleine Suite mit reinem Text, leeren Schlusszeilen, HTML und Anhängen. Zeichnen Sie die ausgewählte Kanonisierung, die gesammelten Rohdatei-Hashes und das Verifizierungsergebnis des vertrauenswürdigen Empfängers auf. Behalten Sie die erwartete Ausgabedarstellung als Regressionsfixierung bei. Eine sinnvolle Auflösung identifiziert die verantwortliche Konvertierung und zeigt, dass neue Nachrichten den Empfänger in der vorgesehenen Form erreichen.
Halten Sie die Anzahl der Bytes getrennt von den Schlussfolgerungen
Für den Kunststoffkörper alpha<CRLF>beta<CRLF>, der Netzwerkformkörper besteht aus 13 Oktetten: fünf Buchstaben, zwei Trennoktette, vier Buchstaben und zwei letzte Trennoktette. Ein reiner LF-Export derselben sichtbaren Zeilen umfasst 11 Oktette. Dieser Zählunterschied ist ein Grund, die Erfassung oder Serialisierung zu untersuchen, kein Beweis dafür, dass die übertragene E-Mail beschädigt war. Behalten Sie die Originaldateien und Erfassungsmethoden bei und vergleichen Sie sie dann mit einer vertrauenswürdigen Erfassung an der relevanten Grenze. Die in Klammern gesetzte CRLF-Beschriftung stellt Bytes dar, keinen Literaltext.