Ein ausgehender Sicherheitsgateway oder ein Unternehmenssignaturdienst kann E-Mails überprüfen und ändern, nachdem die Anwendung sie bereits signiert hat. Ein Stall DKIM design platziert den letzten Schritt der autorisierten Signatur nach erforderlichen Inhaltsänderungen und überprüft die gesamte Route. Die wichtige Frage ist, welche Komponente die letzte Nachricht ausgibt und nicht, welches Produkt zuerst eine aktivierte DKIM Einstellung anzeigt.
Zeichnen Sie die tatsächliche Bearbeitungsreihenfolge ein
Kartenübermittlung, Inhaltsprüfung, Einfügen von Haftungsausschlüssen oder Signaturen, MIME Serialisierung, DKIM Signatur und externe Übermittlung. Beziehen Sie alternative Routen ein, die von Anwendungen und Notfall-Failover verwendet werden. Gehen Sie nicht davon aus, dass Mitarbeiterpostfach- und Bewerbungsmails den gleichen Weg nehmen.
Notieren Sie für jede Komponente, ob sie den Hauptteil, die ausgewählten Header, die Umschlagidentität oder nur die Routing-Metadaten ändert. Ein Signaturblock für Unternehmens-E-Mails ist der Hauptinhalt; es hat nichts mit der Kryptografie zu tun DKIM-Signature Header trotz des gemeinsamen Wortes „Signatur“. Auch das Umschreiben von URLs, die Handhabung von Anhängen und die HTML-Neuerstellung können sich auf abgedeckte Inhalte auswirken.
RFC 6376 §5.3 Und RFC 6376 §5.5 verlangen, dass der Unterzeichner die beabsichtigte übertragene Darstellung bearbeitet und die Neuunterzeichner vor dem erneuten Unterzeichnen Änderungen vornimmt. Das Design sollte diese Reihenfolge sichtbar und überprüfbar machen.
Wählen Sie die Domäne und den Schlüsselbesitzer aus
Ein Gateway kann eine gültige Signatur unter seiner eigenen Domäne hinzufügen. Das genügt DKIM nicht automatisch Ausrichtung für Ihre Autorendomain unter RFC 9989 §4.4.1. Wenn das erforderliche Design eine benutzerdefinierte Domänensignierung verwendet, überprüfen Sie die dokumentierte Leistungsfähigkeit des Produkts, die generierten DNS Werte und die Aufbewahrung des privaten Schlüssels. Nicht erfinden Wähler Namen hinzufügen oder die Konfiguration eines anderen Mandanten kopieren.
Entscheiden Sie, wer die Signaturkonfiguration ändern, Schlüssel rotieren und die endgültige Inhaltspipeline ändern kann. Schützen Sie private Schlüssel vor dem Export in Vorfallnotizen oder Testpakete. Das Veröffentlichen eines öffentlichen Schlüssels ist nur ein Teil der Einrichtung. Echte ausgehende Nachrichten müssen eine passende Signatur tragen, die nach der endgültigen Verarbeitung erstellt wird.
Testen Sie die Pipeline mit zwei Steuerelementen
Illustratives Design: A unterschreibt zuerst und hängt dann einen Unternehmenskontaktblock an. Die ursprüngliche Ganzkörpersignatur kann fehlschlagen. Design B fügt den Block ein, schließt MIME Serialisierung ab und signiert dann mit einer autorisierten ausgerichteten Domäne. Die beabsichtigte Signatur kann bestehen bleiben, wenn bei der späteren Verarbeitung die abgedeckten Daten intakt bleiben. Hierbei handelt es sich um Testerwartungen, nicht um eine Aussage über einen namentlich genannten Anbieter.
Senden Sie Klartext, HTML, Nicht-ASCII-Inhalte und einen Anhang über die vorgesehene Route. Fügen Sie gegebenenfalls von der Anwendung generierte Nachrichten und eine unterstützte Failover-Route hinzu. Erfassen Sie die Nachricht nach dem letzten Prozessor und bei einem vertrauenswürdigen externen Empfänger. Verknüpfen Sie jedes Ergebnis mit d und s, anstatt eine undifferenzierte Bestehensbezeichnung zu akzeptieren.
Behalten Sie Sicherheitskontrollen im Design bei
Durch die spätere Verschiebung des Signierens sollte die Inspektion nicht stillschweigend aus dem geschützten Arbeitsablauf verschoben oder das erforderliche Scannen umgangen werden. Wenn der endgültige Unterzeichner nach einem obligatorischen Umschreibungsdienst nicht ausgeführt werden kann, prüfen Sie unterstützte Integrationen oder eine andere Grenze für autorisierte Signaturen. Vermeiden Sie die Verwendung von l, um spätere Inhalte auszuschließen, nur um eine Erfolgszahl zu ermitteln. RFC 6376 §8.2 erklärt die Risiken nicht signierter Inhalte.
Eine nachgeschaltete neue Signatur kann mit einer früheren fehlgeschlagenen Signatur koexistieren. Bestätigen Sie, welche Signatur die beabsichtigte Ausrichtung liefert und wie der empfangende Dienst dies meldet. Löschen Sie keine Beweise für den früheren Fehler aus den Testaufzeichnungen.
Betreiben Sie die Grenze als änderungsgesteuerten Dienst
Behalten Sie das Routendiagramm, die verantwortlichen Eigentümer, den Schlüsselaufbewahrungsplan und die Formattestsuite bei. Führen Sie nach Gateway-Upgrades, Branding-Vorlagenänderungen, Routing-Änderungen und Failover-Aktivierung erneut Tests durch. Für den Erfolg sind der beabsichtigte Inhalt, ein gültiger abgestimmter Authentifizierungspfad und eine korrekte Zustellung erforderlich, wobei die menschliche Genehmigung immer noch vom technischen Ergebnis getrennt ist.
Notieren Sie die nächste Entscheidung
Notieren Sie für eine hypothetische Nachricht die Prozessorreihenfolge, die erwarteten Inhaltsänderungen, jedes D/S-Paar, das Empfängerurteil und die Ausrichtung. Wenn das Gateway nur als unabhängige Anbieterdomäne signiert, markieren Sie ausgerichtetes DKIM als ungelöst, auch wenn seine Signatur erfolgreich ist. Wenn das Verschieben des Unterzeichners die Prüfung umgehen würde, stoppen Sie diese Designänderung und suchen Sie nach einer unterstützten Integration. Dabei handelt es sich um Planungskriterien, nicht um durchgeführte Streckentests.