Eine Nachricht, die vor der Weiterleitung überprüft wird und danach fehlschlägt, erfordert einen Vergleich der signierten Bytes und des Signaturkontexts. Gehen Sie nicht davon aus, dass jeder hinzugefügte Header kaputt geht DKIM oder so entspannt Kanonisierung erlaubt beliebige Bearbeitung. Die Signatur identifiziert die geschützten Header-Felder, Kanonisierung und Körper-Hash. Rekonstruieren Sie diese Entscheidungen, bevor Sie entscheiden, welche Transformation wichtig ist.
Bewahren Sie vergleichbare Artefakte auf
Referenzen: RFC 6376 §3.5, RFC 6376 §3.7.
Behalten Sie die rohe ursprüngliche und endgültige Nachricht bei, ohne sie über einen Client zu öffnen und erneut zu speichern, der möglicherweise Zeilenenden normalisiert oder MIME neu codiert. Notieren Sie die Unterzeichnerdomäne. Wähler, Algorithmus, Liste signierter Header, Kanonisierung und beliebige Körperlängenbeschränkung. Bewahren Sie die Prüfausgabe und DNS Schlüsselbeobachtung mit dem Zeitstempel auf. Eine optisch identische Nachricht kann unterschiedliche codierte Bytes haben.
Suchen Sie den Unterzeichner in der Verarbeitungskette. Eine vor der endgültigen Signatur hinzugefügte Fußzeile ist Teil des signierten Inhalts; Die gleiche Fußzeile, die nach dem Signieren angehängt wird, kann den Body-Hash ungültig machen. Inventarisieren Sie Software, Gateways, Disclaimer-Engines, Antiviren-Rewriter und Archivpfade als mögliche Transformationspunkte. Nur Beweise aus der tatsächlichen Route können Aufschluss darüber geben, wer gehandelt hat.
Verstehen Sie, was die Kanonisierung ermöglicht
Referenzen: RFC 6376 §3.4, RFC 6376 §5.4, RFC 6376 §8.2.
RFC 6376, Abschnitt 3.4, definiert einfache und entspannte Kanonisierung. Durch die entspannte Textverarbeitung werden angegebene Leerzeichen und nachgestellte Leerzeilen normalisiert. Es führt nicht dazu, dass ein hinzugefügter Absatz oder ein geänderter Betrag verschwindet. Die Header-Kanonisierung hat ihre eigenen Regeln und sollte nicht durch Body-Regeln ersetzt werden.
Ein Betreff-Präfix wirkt sich auf eine Signatur aus, die das relevante Betreff-Feld abdeckt. Das bloße Hinzufügen eines unabhängigen, nicht signierten Headers ist ein anderer Fall. Doppelte signierte Felder und Header-Auswahl erfordern die Regeln des Verifizierers und keinen zufälligen visuellen Unterschied. Wenn eine Signatur eine Begrenzung der Textkörperlänge enthält, sollten Sie sich des Risikos des nicht abgedeckten Inhalts bewusst sein. Führen Sie diese Option nicht als bequeme Möglichkeit ein, beliebige Fußzeilen sicher zu machen.
Führen Sie einen echten Body-Hash-Vergleich durch
Referenzen: RFC 6376 §3.4.4.
Die lokale Vorrichtung wendet eine entspannte Körperkanonisierung auf drei synthetische Körper an. Es berechnet SHA-256 und Base64 für das Original, eine reine Leerzeichenvariante und eine Version mit angehängter Fußzeile. Die Original- und Leerzeichenfälle stimmen überein. Die Groß-/Kleinschreibung der Fußzeile ist unterschiedlich. Die generierten ursprünglichen und geänderten .eml-Dateien behalten die veranschaulichenden Textbytes zur Überprüfung bei.
Dies ist eine beobachtete Hash-Transformation, keine DKIM Signatur Überprüfung. Es ist kein privater Signaturschlüssel, keine DNS Schlüsselsuche, keine Header-Signatur oder ein vertrauenswürdiger Empfangsdienst beteiligt. Die erwartete Auswirkung auf eine vollständige Signatur bleibt davon abhängig, dass die tatsächliche Signatur die geänderten Bytes abdeckt. Die nachstehend aufbewahrten Beweise dokumentieren historische lokale Unterzeichnungen sowie Vorher- und Nachher-Überprüfungen. Beweise für den Produktionsweg werden nicht gesammelt.
Korrigieren Sie die Bestellung, bevor Sie die Abdeckung schwächen
Referenzen: RFC 9989 §4.4.1, RFC 9989 §5.3.5.
Wenden Sie nach Möglichkeit erforderliche Transformationen vor dem letzten Signierungsschritt der legitimen Domäne an. Für einen Vermittler, der nicht für den ursprünglichen Autor signieren kann, kann die Beibehaltung des ursprünglich signierten Inhalts einen ausgerichteten Pass beibehalten. Eine Ersatzsignatur des Vermittlers authentifiziert seine eigene Domäne und wird nicht automatisch mit der ursprünglichen Absenderadresse abgeglichen. RFC 9989 liefert diesen separaten Vergleich.
Testen Sie dieselbe Transformation erneut mit dem vollständigen Prüfer und repräsentativen MIME Inhalten. Schließen Sie Anhänge, mehrteilige Alternativen und Nicht-ASCII-Nachrichten ein, wenn sie im Gültigkeitsbereich liegen. Bewahren Sie Negativkontrollen auf, damit ein Test nicht erfolgreich sein kann, nur weil die Signatur verschwunden ist. Der Abschluss sollte angeben, welche Transformation sich geändert hat, welche Signatur jetzt validiert wird und ob diese Signatur eine abgestimmte Authentifizierung beim endgültigen Empfänger bietet.
Einbehaltene Laborbeweise
Referenzen: RFC 6376 §6.
Bei der Gefangennahme vom 7. November 2026 handelt es sich um eine vorübergehende 2048-Bit Der RSA-Schlüssel signierte die ursprünglichen Bytes vor der Weiterleitung mit dkimpy. Der öffentliche DNS Eintrag des Schlüssels bleibt erhalten und der private Schlüssel wird nach der Ausführung gelöscht. dkimpy überprüft die ursprünglichen und beibehaltenen Weiterleitungsnachrichten und lehnt den an die Fußzeile angehängten Text ab. Der Listenfall wendet Namensnennungs- und Fußzeilenänderungen an, bevor er seine Listendomänensignatur erstellt, die überprüft. Hierbei handelt es sich um echte vollständige DKIM Signaturtests, nicht um bereitgestellte boolesche Ergebnisse. Der Relaxed-Body-Helfer behandelt jetzt auch leere Eingaben als Null-Oktette.
Der zurückbehaltene Läufer und die Gefangennahme vom 7. November 2026 wurden inspiziert; Für diese Überprüfung wurde kein Netzwerkexperiment erneut durchgeführt. Das ursprüngliche Experiment verwendete nur Loopback und verschickte keine Internet-Mail. Sein Empfänger schafft Authentication-Results aus eigenen Kontrollen, wodurch die Herkunft dieser Felder im Labor bekannt ist. Authentifizierungsergebnis und Disposition bleiben getrennt: Alle sechs SMTP Beispiele erhalten 250 im Rahmen einer expliziten Erfassungsrichtlinie, einschließlich fehlgeschlagener Beispiele. Die Vertrauensgrenze ist dieses kontrollierte Labor, kein Produktionspostfachanbieter. Der DNS Adapter stellt gespeicherte Systemantworten bereit, anstatt öffentliche DNS abzufragen DMARC Der Evaluator verwendet ausschließlich strikte Domänengleichheit. Die vollständige Erkennung der Organisationsdomäne, die Analyse der Produktionsrichtlinien und die Ergebnisse der Live-Bereitstellung wurden noch nicht getestet.