Ein sicheres E-Mail-Gateway und DMARC lösen sich überschneidende betriebliche Probleme, sind aber nicht austauschbar. Ein Gateway kann Nachrichten prüfen, weiterleiten, unter Quarantäne stellen oder ändern. DMARC wertet die abgestimmte Authentifizierung aus und stellt den Empfängern Informationen zur Domänenrichtlinie bereit. Die wichtige Frage ist, wie sich Ihre gesamte Route verhält, einschließlich Transformationen nach der Erstellung einer Signatur.
Zeichnen Sie den tatsächlichen Nachrichtenpfad
Zeichnen Sie die Einreichung, das Signieren, die Gateway-Verarbeitung und den endgültigen Empfang in der richtigen Reihenfolge auf. Identifizieren Sie, welche Komponenten Sie kontrollieren und welche Identitäten jeweils signiert werden dürfen. Ein Diagramm, das besagt, dass nur das Gateway aktiviert ist, kann nicht feststellen, ob ein Downstream-Empfänger eine intakte ausgerichtete Signatur erhält. Erhalten Sie ursprüngliche und endgültige Rohnachrichten von einer autorisierten Testroute unter Beibehaltung von Nachrichtenkennungen und -zeiten.
DKIM deckt ausgewählte Header und einen kanonisierten Text ab. Durch das Umschreiben des Textkörpers kann eine vorhandene Signatur ungültig gemacht werden, selbst wenn der geänderte Link Teil einer legitimen Sicherheitsfunktion ist. RFC 6376 definiert das Signatur- und Verifizierungsverhalten. DKIM -Spezifikation. Behalten Sie die Liste der signierten Header bei. Kanonisierung Auswahlmöglichkeiten und alle Körperlängenparameter bei der Erklärung eines bestimmten Fehlers.
Platzieren Sie die Verifizierung und Unterzeichnung bewusst
Ein eingehendes Gateway kann eine Nachricht vor der Änderung überprüfen, aber dieses interne Ergebnis ist nicht automatisch für jeden nachgeschalteten Empfänger vertrauenswürdig. Definieren Sie, wie das nächste System vertrauenswürdige Ergebnisse erkennt und was es mit nicht vertrauenswürdigen Header-Assertionen tut. RFC 8601. Ein späterer Verifizierer, der geänderte Bytes überprüft, kann aus berechtigtem Grund zu einem anderen Ergebnis kommen.
Bei einer von Ihnen verwalteten ausgehenden Route kann durch das Signieren nach genehmigten Transformationen eine Beschädigung der endgültigen Signatur vermieden werden. Der Unterzeichner muss für seine Domäne autorisiert sein und Ausrichtung muss noch evaluiert werden. Das Hinzufügen einer gültigen Signatur von einer unabhängigen Gateway-Domäne führt nicht unbedingt zu einem abgestimmten DMARC Ergebnis. Entfernen Sie die Sicherheitsüberprüfung nicht einfach, um eine Signatur zu bewahren, ohne das umfassendere Kontrolldesign zu überprüfen.
Verfolgen Sie eine hypothetische Umschreibung
Angenommen, ein autorisierter brand.test-Unterzeichner signiert einen Nachrichtentext, der eine URL enthält. Ein Gateway ändert dann die abgedeckte URL, ohne anschließend eine autorisierte, ausgerichtete Signatur hinzuzufügen. Wenn sich die kanonisierten signierten Bytes ändern, wird die frühere Signatur nicht anhand des geänderten Hauptteils validiert. Eine Transformation, die die relevanten kanonisierten signierten Bytes unverändert lässt, muss die Signatur nicht zerstören. Überprüfen Sie die Kanonisierung, ausgewählte Header und alle l=-Grenzwerte, anstatt davon auszugehen, dass jedes Umschreiben den gleichen Effekt hat.
Wenn ein separater autorisierter Unterzeichner die endgültige transformierte Nachricht signiert, kann diese neue Signatur auch dann überprüft werden, wenn die alte Signatur fehlschlägt. Es stellt keine Reparatur der alten Signatur dar und beweist nicht, dass der neue Unterzeichner über die Geschäftsberechtigung verfügt. Bewerten Sie die Ausrichtung der neuen d=-Domäne und das vertrauenswürdige Endergebnis des Empfängers. Hierbei handelt es sich um protokollbasierte hypothetische Ergebnisse, nicht um Rohnachrichtenproben, generierte Schlüssel, Dkimpy-Ausgaben oder ein ausgeführtes Gateway-Experiment.
Übersetzen Sie das Ergebnis in einen Routentest
Reproduzieren Sie in der Produktion die relevante autorisierte Transformation mithilfe kontrollierter Empfänger und der unterstützten Konfiguration des Anbieters. Erfassen Sie die vertrauenswürdigen Ergebnisse des Endempfängers, anstatt den Erfolg von der Gateway-Konsole abzuleiten. Vergleichen Sie dieselbe Inhaltsrevision auf der gesamten Route und beachten Sie andere Änderungen wie Betreffpräfixe oder Haftungsausschlüsse. Eine bestandene neue Signatur beweist nicht, dass die frühere Authentifizierung überlebt hat.
Behandlung von Testfehlern ebenfalls. Wenn ein Signaturschritt nicht verfügbar ist, ermitteln Sie, ob E-Mails in die Warteschlange gestellt werden, fehlschlagen oder ohne die erwartete Signatur verlassen werden. Halten Sie die Wiederherstellungsanweisungen an den tatsächlichen Dienst gebunden. Vermeiden Sie eine Notfallumgehung, die ein eingedämmtes Authentifizierungsproblem in eine uneingeschränkte Weiterleitung oder ungeprüfte Zustellung umwandelt.
Im Abnahmeprotokoll sollten die getestete Route, die Transformation, die Platzierung des Unterzeichners, die endgültigen Identitäten und das Ergebnis des Empfängers aufgeführt sein. Führen Sie separate Prüfungen für die Malware-Filterung durch. Phishing Erkennung und Domänenauthentifizierung. Das Bestehen eines Tests ist ein nützlicher Beweis für diese Fähigkeit und kein Zertifikat dafür, dass die gesamte Nachricht oder das Gateway sicher ist.
Quell- und Ausführungsgrenze
RFC 9989 Abschnitte 4.4, 5.3.5 und 5.4 Authentifizierung, Ausrichtung und Handhabung unterscheiden; Ein Pass bestätigt den Nachrichteninhalt nicht. Bei den operativen Entscheidungen handelt es sich hier um abgegrenzte Empfehlungen und explizit hypothetische Beispiele, nicht um neue Tests eines Kunden, Anbieters oder einer historischen Anlage. Jede tatsächliche Änderung erfordert einen eigenen autorisierten Umfang, aufbewahrte Beweise und eine rechenschaftspflichtige Entscheidung.