Zwei Nachrichten können in einem E-Mail-Client identisch aussehen und dennoch unterschiedlich sein DKIM Körper-Hashes. DKIM überprüft die übermittelte Darstellung nach ihrer Angabe Kanonisierung, nicht die entschlüsselte Sicht des Lesers. MIME Neuaufbau, Content-Transfer-Konvertierung und Grenzänderungen gehören daher früh in die Untersuchung, wenn eine Nachricht erst nach einem Verarbeitungsdienst fehlschlägt.
Trennen Sie das Erscheinungsbild von der Repräsentation
Eine MIME -Nachricht kann einfachen Text, HTML, Anhänge und verschachtelte mehrteilige Strukturen enthalten. RFC 2046 §5.1.1 Platziert MIME Teilkopfzeilen und Grenztrennlinien innerhalb des mehrteiligen Hauptteils. Durch die Neukodierung eines Textteils von quoted-printable in base64 kann das, was ein Benutzer liest, erhalten bleiben, während die an DKIM übermittelten Bytes geändert werden. Durch das Umbrechen codierter Zeilen können diese Bytes ebenfalls geändert werden. Entspannte Kanonisierung ist eine definierte Leerraumtransformation, kein MIME Decoder oder ein Äquivalenztest für gerenderte Inhalte.
RFC 6376 §5.3 empfiehlt die Konvertierung in eine geeignete MIME -Übertragungskodierung vor dem Signieren, um Transportkonvertierungen zu reduzieren. Es erfordert insbesondere, dass lokale Darstellungen, die sich vor der Übertragung ändern, vor dem Signieren normalisiert werden. Das Prinzip ist einfach: Unterschreiben Sie das Formular, das der Empfänger sehen soll.
Suchen Sie die Serialisierungsänderung
Erhalten Sie Rohnachrichten am Ausgang des Unterzeichners, am Ausgang des vermuteten Gateways und am Endempfänger. Speichern Sie Originale, ohne sie zu öffnen, und speichern Sie sie mit einem Editor, der Zeilenenden normalisiert. Beachten Sie die Erfassungsmethode, da ein Exporttool selbst die Darstellung ändern kann.
Vergleichen Sie die Felder „Content-Type“ und „Content-Transfer-Encoding“ in der äußeren Nachricht und jedem relevanten MIME Teil. Überprüfen Sie Grenzzeichenfolgen, Anhangskodierung, gefaltete Linien und Zeichensatzkonvertierung. Bestimmen Sie, ob ein geänderter äußerer Header in h enthalten war und ob geänderte Teilheader innerhalb des signierten Körpers aufgetreten sind. Behandeln Sie die beiden Speicherorte getrennt: Ein äußerer Header kann zu einem Fehler bei der Signaturüberprüfung führen, während ein MIME Teilheader normalerweise daran beteiligt ist Körper-Hash.
Arbeiten Sie ein Codierungsbeispiel durch
Illustrative Testspezifikation: Ein Textteil, der ein Nicht-ASCII-Zeichen enthält, wird mithilfe von quoted-printable vorbereitet, bevor die Anwendung die Nachricht signiert. Ein Downstream-Dienst dekodiert diesen Teil und serialisiert ihn als Base64. Der angezeigte Satz bleibt derselbe, der kanonisierte Textkörper kann jedoch abweichen und die Originalsignatur kann fehlschlagen. Führen Sie dies nur mit kontrolliertem Inhalt aus und überprüfen Sie die tatsächlichen Byteunterschiede, anstatt davon auszugehen, dass jeder Dienst diese Konvertierung durchführt.
Erstellen Sie einen kleinen Testsatz mit reinem ASCII-Text, Nicht-ASCII-Text, mehrteiligem HTML und einem kleinen Anhang. Senden Sie sie jeweils über einen direkten Steuerungspfad und den produktionsäquivalenten Verarbeitungspfad. Wenn nur letztere die Darstellung ändert, identifiziert der Grenzvergleich die zu untersuchende Komponente. Wenn beides fehlschlägt, prüfen Sie zunächst die eigene Serialisierung und Normalisierung des Unterzeichners.
Reparieren Sie die Grenze
Bevorzugen Sie die endgültige MIME Konstruktion und Auswahl der Übertragungskodierung vor dem Signieren. Wenn ein Sicherheitsdienst Inhalte neu schreiben muss, vereinbaren Sie nach der endgültigen Serialisierung einen autorisierten Signaturschritt. Bestätigen Sie die Unterstützung und das Eigentumsmodell für benutzerdefinierte Domänen. Eine Signatur unter einer nicht verwandten Dienstdomäne kann DKIM ohne Anpassung bestehen DMARC unter RFC 9989 §4.4.1.
Reparieren Sie ein Muster nicht an Ort und Stelle und legen Sie es als Beweis dafür vor, dass die Produktion repariert wurde. Eine modifizierte Stichprobe testet lediglich eine Hypothese. Ändern Sie die verantwortliche Konfiguration, senden Sie neue kontrollierte Nachrichten und erfassen Sie deren ursprüngliche Empfängerergebnisse. Vermeiden Sie weitreichende Umgehungen der Inhaltsprüfung, nur um eine Signatur zu bewahren, ohne die Auswirkungen auf die Sicherheit zu prüfen.
Bewahren Sie eine nützliche Vorfallaufzeichnung auf
Notieren Sie die erste Grenze, an der serialisierte Inhalte abweichen, das MIME Feld oder den betroffenen Teil, den Unterzeichner und Wählerund Ergebnisse für jede Testvariante. Halten Sie die Testnachrichten frei von Kundendaten. Führen Sie die Suite nach Gateway-Upgrades und Änderungen bei der Anhangsverarbeitung erneut aus. Der abgeschlossene Fix erklärt, warum die alte Darstellung fehlgeschlagen ist, und zeigt, dass neu ausgegebene E-Mails die vollständig unterstützte Route überstehen.
Vergleichen Sie eine konkrete codierte Darstellung
Für die UTF-8-Bytes C3 A9, die é darstellen, ist eine in Anführungszeichen druckbare Darstellung =C3=A9; Eine Base64-Darstellung ist w6k=. Mit geeigneten MIME Headern dekodieren beide das gleiche Zeichen, die kodierten Zeichenfolgen unterscheiden sich jedoch. RFC 2045 §6.7 Und RFC 2045 §6.8 Definieren Sie die Kodierungen. RFC 6376 §3.7 erfordert Hashing nach der Übertragungskodierung und vor der Dekodierung während der Überprüfung. Bei diesem isolierten Darstellungsbeispiel handelt es sich nicht um eine vollständige MIME Nachricht oder einen ausgeführten Signaturtest. Wenn eine Körperlängenbeschränkung verwendet wird, ermitteln Sie, ob die geänderten Bytes innerhalb der Abdeckung liegen, anstatt davon auszugehen, dass jeder Teil geschützt ist.