A DKIM Eine Diagnose ohne Schlüssel bedeutet im Allgemeinen, dass der Prüfer den erforderlichen Prüfschlüssel für eine Signatur nicht finden konnte. Der nützliche Ausgangspunkt ist der eigentliche Inhalt der Nachricht Wähler and signing domain. Das Erraten eines gemeinsamen Selektors oder das Abfragen der sichtbaren Absenderdomäne kann zu einer vollkommen genauen Antwort auf die falsche DNS Frage führen.
Behalten Sie die ursprünglich empfangene Nachricht und ihr vertrauenswürdiges Authentifizierungsergebnis bei. Notieren Sie sich den Beobachtungszeitpunkt, da sich der Schlüssel seit der Lieferung möglicherweise geändert hat. Untersuchen Sie dann die im Ergebnis genannte genaue Signatur; Nachrichten können mehrere Signaturen mit unterschiedlichen Suchnamen und Ergebnissen tragen.
Leiten Sie die genaue DNS -Frage ab
Read s and d from DKIM-Signature. Mit s=campaign7 und d=mailer.example, lautet die Suche campaign7._domainkey.mailer.example . Der Selektor ist kein universeller Anbietername und die signierende Domäne muss nicht mit der sichtbaren Absenderdomäne identisch sein. RFC 6376 §3.1, RFC 6376 §3.5 Und RFC 6376 §3.6.2.1 define these elements.
Fragen Sie den von der unterstützten Konfiguration erwarteten Namen und Datensatztyp ab. Unter RFC 1034 §3.6.2, if the service uses a CNAME, folgen Sie ihm zu den Verifizierungsdaten und erfassen Sie das Zwischenziel. Suchen Sie nach Fehlern im DNS-Editor, z. B. einem doppelt angehängten Suffix. ein Rekord in der falschen Zone veröffentlicht oder ein Selektor von einem anderen Mandanten kopiert.
Unterscheiden Sie Abwesenheit von Nichtverfügbarkeit
Eine negative Antwort, die keinen entsprechenden Schlüssel festlegt, unterscheidet sich von einer Abfrage, bei der eine Zeitüberschreitung auftritt. RFC 6376 §6.1.2 erfordert PERMFAIL für einen fehlenden Schlüssel und lässt TEMPFAIL zu, wenn die Schlüsselabfrage nicht antwortet. Hierbei handelt es sich um Ergebnisse der Verifiziererverarbeitung. Das genaue angezeigte Etikett in einem Diagnoseprodukt kann unterschiedlich sein.
Erfassen Sie den DNS -Antwortcode und die Antwort, nicht nur einen roten Indikator. Vergleichen Sie maßgebliche Antworten mit der rekursiven Ansicht, die für den ausfallenden Empfänger relevant ist, sofern Beweise verfügbar sind. Eine spätere erfolgreiche Suche von Ihrem Laptop aus beweist nicht, dass der Schlüssel zum ursprünglichen Bewertungszeitpunkt erreichbar war.
Verwenden Sie einen Diagnosebaum mit drei Zweigen
Wenn die Nachricht keine DKIM-Signature enthält, untersuchen Sie zunächst die Signaturkonfiguration und nicht eine Selektorsuche. Es gibt kein nachrichtenspezifisches s- und d-Paar zum Abrufen. Zweitens: Wenn eine Signatur vorhanden ist und ihr Schlüssel fehlt, überprüfen Sie den Veröffentlichungs-, Migrations- und Ruhestandsverlauf. Drittens, wenn der Schlüssel verfügbar ist, aber der Körper-Hash oder die Signatur fehlschlägt, wechseln Sie zu Inhalts-, Schlüsselübereinstimmungs- oder kryptografischen Prüfungen.
Illustrativer Fall: Ein Nachrichtennamensselektor old7, während DNS nur new8 enthält. Durch die ordnungsgemäße Veröffentlichung von new8 kann die Signatur von old7 nicht überprüft werden. Wenn old7 absichtlich deaktiviert wurde, ist der Fehler möglicherweise bei verzögerter oder archivierter E-Mail zu erwarten. Wenn old7 versehentlich entfernt wurde und sein Schlüssel immer noch vertrauenswürdig ist, kann die Wiederherstellung der korrekten Verifizierungsdaten eine angemessene genehmigte Reparatur sein. Hierbei handelt es sich um Diagnoseszenarien, nicht um ausgeführte Mandantentests.
Überprüfen Sie nach der Entnahme die Gültigkeit des Schlüssels
Das Finden einer TXT Antwort schließt die Überprüfung nicht ab; RFC 6376 §3.6.1 Und RFC 6376 §6.1.2 Definieren Sie die Schlüsselsyntax und -validierung. Ein fehlerhafter Schlüssel, ein leerer p-Wert, der auf einen Widerruf hinweist, oder inkompatibles Schlüsselmaterial sind kein verwendbarer Verifizierungsschlüssel. Unter RFC 4592 §3.3.3, a wildcard TXT Eintrag kann auch eine Antwort liefern, die für DKIM irrelevant ist. Kennzeichnen Sie nicht jede unbrauchbare Antwort als fehlenden Selektor.
Verwenden Sie den genauen aktuellen Datensatzwert des Anbieters oder eine bekannte, autorisierte Konfigurationssicherung. Generieren Sie niemals einen zufälligen öffentlichen Schlüssel, um die Suche zu erfüllen: Er stimmt nicht mit dem privaten Schlüssel überein, der die Signatur erstellt hat. Vermeiden Sie das Ersetzen von Datensätzen bei einer gemeinsamen Suche, ohne andere Absender und verzögerte Nachrichten zu überprüfen.
Überprüfen Sie die Lösung anhand neuer Beweise
Überprüfen Sie nach einer autorisierten Reparatur DNS und senden Sie neue kontrollierte E-Mails über die betroffene Route. Bewahren Sie das empfangene Ergebnis, die Signaturidentität usw. auf Ausrichtung Bewertung. Wenn die ursprüngliche Stichprobe jetzt verifiziert wird, notieren Sie dies als eine spätere erneute Prüfung, anstatt das historische Empfängerergebnis neu zu schreiben.
Schließen Sie den Vorfall mit dem fehlenden Namen, der fehlenden Ursache, der wiederhergestellten Abhängigkeit und der Präventionsmaßnahme ab. Eine Selektorinventur und eine Checkliste für die Löschung reduzieren Wiederholungen effektiver als das wiederholte Hinzufügen von Datensätzen, wenn ein Prüfer Rot meldet.
Behalten Sie eine begrenzte Schlussfolgerung bei
Behalten Sie für old7 im Vergleich zu new8 die Suche der alten Signatur bei, anstatt den aktuellen Selektor in den Vorfalldatensatz zu kopieren. Ein fehlender old7-Schlüssel, ein Timeout und ein Empty-P-Widerruf sind unterschiedliche Beobachtungen. Eine spätere erfolgreiche Nachprüfung muss ihren späteren Zeitpunkt behalten. Für das Unterrichtsszenario wurde keine Reparatur oder Signaturprüfung durchgeführt.