A DKIM Ein Body-Hash-Fehler bedeutet, dass der Verifizierer den nicht reproduziert hat Körper-Hash in der Signatur nach Anwendung der für die Signatur geltenden Regeln übernommen werden. Es lässt sich nicht identifizieren, welches System die Nachricht geändert hat, und es handelt sich nicht um die gleiche Diagnose wie bei einem fehlenden öffentlichen Schlüssel.
Bewahren Sie zunächst die ursprünglich empfangene Nachricht auf. Durch das Kopieren des sichtbaren Textes aus einem E-Mail-Client gehen MIME Struktur, Kodierung und andere für die Überprüfung wichtige Bytes verloren.
Bestätigen Sie den genauen Fehler
Überprüfen Sie das Ergebnis des vertrauenswürdigen Empfängers und die zu bewertende Signatur. Eine Nachricht kann mehrere haben DKIM Signatur, und jeder kann eine andere Signaturdomäne oder ein anderes Signaturergebnis haben.
Notieren Sie d=, s=, den Algorithmus, den c= Kanonisierungseinstellung und ein beliebiges l=-Tag mit Körperlänge. Behalten Sie den genauen Verifizierungsgrund bei. Eine Zeitüberschreitung bei der Schlüsselsuche, ein nicht unterstützter Algorithmus, eine Header-Signatur-Nichtübereinstimmung und eine Body-Hash-Nichtübereinstimmung erfordern unterschiedliche Untersuchungen.
In RFC 6376 §3.5, der bh=-Wert ist der codierte Hash des kanonisierten Körpers, vorbehaltlich der definierten Längenbehandlung. Der b=-Wert gehört zur Signaturberechnung. Wenn man diese als austauschbar behandelt, wird unklar, welche Prüfung fehlgeschlagen ist.
Bewahren Sie Beweise auf, die das Ergebnis reproduzieren können
Speichern Sie die Rohnachricht über einen genehmigten Exportpfad und beschränken Sie den Zugriff entsprechend ihrem Inhalt. Behalten Sie das erhaltene Original bei, mit Hash und Erfassungszeit, wenn der Untersuchungsprozess dies unterstützt.
Analysekopien separat erstellen. Durch das Schwärzen einer Adresse, das Ändern eines Anhangs oder das Speichern einer rekonstruierten Nachricht können verifizierungsrelevante Inhalte verändert werden. Eine Safe-Sharing-Kopie kann nützlich sein, sie entspricht jedoch nicht automatisch dem erhaltenen Original.
Notieren Sie die Quelle aller Verifizierungsausgaben. Ein Tool, das Zeilenenden beim Import normalisiert, wertet möglicherweise nicht dieselben Bytes aus wie der empfangende Server. Wenn zwei Tools nicht übereinstimmen, ermitteln Sie zunächst deren Eingaben und unterstütztes Verhalten.
Vergleichen Sie die Nachricht vor und nach wahrscheinlichen Modifikatoren
Ordnen Sie die tatsächliche Route vom Absender über Gateways, Relays, Mailinglisten und Empfangsdienste zu. Suchen Sie nach kontrollierten Aufnahmen unmittelbar vor und nach einer vermuteten Transformation.
Zu den häufigsten Untersuchungskandidaten gehören das Einfügen einer Fußzeile nach dem Signieren, das Umschreiben von URLs, die Neucodierung MIME , die Verarbeitung von Anhängen und die Reparatur fehlerhafter Inhalte. Dabei handelt es sich um Hypothesen, bis Beweise eine relevante Änderung auf einen Schlag belegen.
Verwenden Sie einen kontrollierten Test, der dem gleichen Weg folgt und die vermutete Funktion ausübt. Vergleichen Sie beispielsweise eine ansonsten gleichwertige Nachricht mit und ohne die Fußzeilenregel des Gateways. Verallgemeinern Sie nicht einen direkten Test, der das Produktions-Gateway umgeht.
In einem synthetischen Fall wird die gespeicherte Ausgabe des Absenders erfolgreich überprüft, während die erfasste Nachricht nach einem Haftungsausschluss-Gateway eine Nichtübereinstimmung von Text und Hash aufweist. Das Gateway fügt eine Fußzeile hinzu, nachdem der Absender signiert hat. Diesen hypothetischen Beobachtungen zufolge identifiziert dies eher eine Konfigurationsabhängigkeit, die behoben werden muss, als einen Grund, den öffentlichen DKIM -Schlüssel zu ersetzen.
Verstehen Sie, was Kanonisierung tolerieren kann
Kanonisierungsregeln von DKIM bestimmte Normalisierungen zulassen. Sie machen die willkürliche Bearbeitung von Inhalten nicht sicher. Bei der entspannten Kanonisierung des Textkörpers handelt es sich nicht um die Erlaubnis, Links neu zu schreiben oder nach dem Signieren einen Absatz hinzuzufügen.
Überprüfen Sie den durch die Signatur angegebenen Algorithmus und verwenden Sie einen Verifizierer, der ihn korrekt implementiert. Führen Sie keine Diagnose anhand einer visuell identischen Darstellung durch: Zwei angezeigte Nachrichten können unterschiedliche signierte Oktette enthalten.
Unter RFC 6376 §3.5, ein l=-Wert begrenzt die kanonisierten Körperoktette, die von der definierten Berechnung abgedeckt werden. Es handelt sich nicht um eine allgemeine Lösung für ein sich änderndes Gateway, und wenn Inhalte absichtlich außerhalb des Schutzes bleiben, ändert sich die Sicherheitsbewertung. Verwenden Sie unterstützte Konfigurationen und prüfen Sie die Auswirkungen, anstatt eine Längenbeschränkung hinzuzufügen, um ein Symptom zu unterdrücken.
Korrigieren Sie die geänderte Route und bewerten Sie dann die Ausrichtung neu
Wenn die Organisation die Route kontrolliert, veranlassen Sie die erforderlichen Änderungen vor der endgültigen entsprechenden Unterzeichnungsphase. Wenn ein Dienst E-Mails neu signiert, überprüfen Sie die neue Signaturidentität und was sie beweist. Eine vorübergehende Signatur eines unabhängigen Vermittlers stimmt nicht automatisch mit der ursprünglich sichtbaren Von-Domäne überein; RFC 9989 §4.4.1 erfordert die Ausrichtung der authentifizierten Signaturidentität.
Für legitime indirekte Routen, die außerhalb der Kontrolle des Absenders liegen, prüfen Sie die geltenden Interoperabilitätsrichtlinien. Deaktivieren Sie die Sicherheitsverarbeitung nicht und schwächen Sie eine Domänenrichtlinie nicht nur deshalb, weil ein Test fehlschlägt.
Wiederholen Sie den betroffenen Geschäftsablauf und bewahren Sie Vorher-Nachher-Beweise auf. Dann verwenden DMARC -Ausrichtungsdiagnose um festzustellen, ob ein vorbeiführender ausgerichteter Pfad verbleibt. Der Vorfall wird abgeschlossen, wenn die relevante Transformation und ihre Wirkung verstanden und die beabsichtigte Route überprüft wurde.
Wählen Sie den nächsten Diagnoseschritt
Verwenden Sie diese vorgeschlagene Entscheidungssequenz. es zeichnet keinen ausgeführten Test auf:
- Kein verwendbarer Schlüssel oder Zeitüberschreitung bei der Schlüsselabfrage: Folgen Sie dem Suchergebnis unten RFC 6376 §6.1.2 anstatt eine Fußzeile zu diagnostizieren.
- Der neu berechnete Körper-Hash unterscheidet sich vom BH: Vergleichen Sie die Körperdarstellung, die tatsächlichen C/L-Einstellungen und den aufgezeichneten BH-Wert unten RFC 6376 §6.1.3. Ein beschädigter oder falsch generierter BH oder ein Implementierungsfehler des Unterzeichners/Prüfers ist ebenfalls eine mögliche Ursache; Die Nichtübereinstimmung allein beweist keine Körpermodifikation.
- Body-Hash stimmt überein, aber die Signatur schlägt fehl: Untersuchen Sie signierte Header, die Signaturberechnung und die Schlüssel-zu-Signatur-Beziehung. Der passende BH allein ist kein DKIM Pass.
- Mehrere Signaturen stimmen nicht überein: Halten Sie jedes Ergebnis an seine eigenen d und s gebunden, bevor Sie entscheiden, ob ein vorbeigehender ausgerichteter Pfad verbleibt.