Eine Fußzeile kann aus einer korrekt signierten ausgehenden Nachricht eine machen DKIM Versagen. Die Reparatur beginnt mit der Verarbeitungssequenz: Identifizieren Sie, welches System die Nachricht signiert hat, welches System die Fußzeile eingefügt hat und welche Signatur der Empfänger ausgewertet hat. Durch das Veröffentlichen eines anderen DNS Schlüssels kann kein Signatur-Covertext hinzugefügt werden, nachdem dieser erstellt wurde.
Beweisen Sie, welche Bytes sich geändert haben
Speichern Sie eine kontrollierte Nachricht unmittelbar nach dem Signieren und eine weitere nach dem Gateway, indem Sie den Rohnachrichtenexport anstelle von kopiertem Text aus einem E-Mail-Client verwenden. Bewahren Sie die Originaldateien auf. Notieren Sie die d-, s-, c-, h- und alle l-Tags jeder Signatur. Eine Nachricht kann mehrere Signaturen mit unterschiedlichem Umfang und unterschiedlichen Ergebnissen haben.
DKIM berechnet einen Hash des kanonisierten Körpers. Bei einer normalen Ganzkörperberichterstattung fügt eine neue Fußzeile inhaltlichen Inhalt hinzu und ändert den Hash. Entspannter Körper Kanonisierung entfernt bestimmte Leerzeichenunterschiede; Es werden kein Haftungsausschluss, kein HTML-Block oder kein neuer MIME Teil entfernt. Eine Body-Hash-Nichtübereinstimmung betrifft die verglichenen Body-Hash-Eingaben und -Werte: die Body-Darstellung, die C/L-Einstellungen und den BH-Wert. Ein beschädigter oder falsch generierter BH oder ein Implementierungsfehler des Unterzeichners/Prüfers können ebenfalls eine Nichtübereinstimmung erklären. Der Vergleich in RFC 6376 Abschnitt 6.1.3 beweist allein nicht, dass ein Gateway den Körper verändert hat. Ein allgemeiner Signaturfehler kann stattdessen einen signierten Header, eine Schlüsselsuche oder eine Signatursyntax betreffen. RFC 6376 §3.4, RFC 6376 §3.7 Und RFC 6376 §6.1 Beschreiben Sie diese separaten Prüfungen.
Vergleichen Sie die Beispiele an der Grenze, an der die Fußzeile angewendet wird. Überprüfen Sie sowohl Text/Plain- als auch Text/HTML-Teile, MIME Grenzen und Übertragungskodierung. Eine scheinbar identische sichtbare Fußzeile kann unterschiedlich serialisiert werden. Wenn das Gateway auch den Betreff ändert, prüfen Sie, ob der Betreff in h aufgeführt ist: Durch die Reparatur des Hauptteils allein wird keine Signatur über einen geänderten Header wiederhergestellt.
Testen Sie die Reihenfolge, anstatt zu raten
Beispielszenario: Eine Anwendung erstellt eine Rechnung, der Ausgangsserver signiert sie und ein Gateway hängt dann einen rechtlichen Hinweis an. Der Empfänger meldet eine Body-Hash-Nichtübereinstimmung für die Signatur der Anwendung. In einer kontrollierten Alternative hängt das Gateway die Mitteilung zuerst an und ein autorisierter Unterzeichner signiert die endgültige serialisierte Nachricht. Ein positives Ergebnis auf diesem zweiten Pfad unterstützt die Bestelldiagnose. Hierbei handelt es sich um vorgeschlagene Testbeobachtungen, nicht um Ergebnisse eines echten Mieters.
Verwenden Sie über beide Pfade dieselben Nachrichtenvarianten, einschließlich HTML, Nur-Text und Anhang. Zeichnen Sie die Ergebnisse der Empfängerauthentifizierung von einer vertrauenswürdigen Grenze, der Signaturdomäne und der sichtbaren Von-Domäne auf. DKIM Pass allein reicht nicht aus DMARC wenn die übergebene Signatur nicht mit der Autorendomäne übereinstimmt. Eine unabhängige Gateway-Signatur kann korrekt überprüft werden, ohne diesen ausgerichteten Pfad bereitzustellen.
Wählen Sie eine eigene Signaturgrenze
Das übliche dauerhafte Design besteht darin, erforderliche Inhaltsänderungen vor dem endgültigen autorisierten Signaturvorgang durchzuführen. Das kann bedeuten, dass der Unterzeichner später verschoben wird, die Fußzeile früher eingefügt wird oder das Gateway so konfiguriert wird, dass die endgültige Nachricht mithilfe einer Domäne signiert wird, die von der Organisation kontrolliert wird. Bestätigen Sie das unterstützte Verhalten und den Schlüsselbesitz, bevor Sie ein Design auswählen. Gehen Sie nicht davon aus, dass jedes Gateway das Signieren benutzerdefinierter Domänen unterstützt.
Wenn eine vorhandene Signatur beschädigt ist, wird durch das Hinzufügen einer neuen gültigen Signatur die frühere Signatur nicht repariert. Bewerten Sie die neue Signatur anhand ihrer eigenen Vorzüge und überprüfen Sie sie Ausrichtung separat. Aktivieren Sie das Body-Length-L-Tag nicht nur, um Fußzeilen aus der Hash-Berechnung verschwinden zu lassen: Es hinterlässt ein vorzeichenloses Suffix und führt zu dem in beschriebenen Sicherheitskompromiss RFC 6376 §8.2.
Schließen Sie mit einer Regressionsprüfung ab
Bewahren Sie ein Routendiagramm auf, das die letzte körperverändernde Komponente und den Unterzeichner unmittelbar danach zeigt. Führen Sie einen erneuten Test durch, wenn sich Haftungsausschlussregeln, Antiviren-Umschreibungen oder ausgehendes Routing ändern. Erfolg bedeutet, dass die erforderliche Fußzeile vorhanden ist, die beabsichtigte Signatur überprüft wird, die Domäne die beabsichtigte Ausrichtungsrichtlinie erfüllt und kritische Nachrichten weiterhin über die erwartete Route eingehen. Behalten Sie einen Rollback-Plan für die Konfigurationsänderung bei, ohne die Entfernung eines erforderlichen rechtlichen Hinweises als automatische Abhilfe zu betrachten.
Verwenden Sie einen Regressionsakzeptanzdatensatz
Notieren Sie für jede synthetische Klartext-, HTML- und Anhangsvariante Folgendes: Fußzeile vorhanden; letzter körperverändernder Sprung; Endunterzeichner d/s; ausgewähltes c/h/l; Ergebnis des vertrauenswürdigen Empfängers; Autorendomäne und Ausrichtung; und das Geschäftsergebnis. Fehlt die Fußzeile, ist die Hinweispflicht auch bei Bestehen DKIM nicht erfüllt. Wenn die Fußzeile vorhanden ist, aber nur eine nicht verwandte Gateway-Domäne übergeben wird, ist die beabsichtigte DKIM-Ausrichtungsanforderung nicht erfüllt. Hierbei handelt es sich um Akzeptanzkriterien, nicht um abgeschlossene Prüfungen.