SPF Redirect delegiert die verbleibende Autorisierungsentscheidung an eine andere Richtlinie. Es ist für Situationen konzipiert, in denen mehrere Domänen zentral verwaltete Berechtigungen und Richtlinien gemeinsam nutzen sollen, häufig innerhalb einer Verwaltungsorganisation.
Es ist kein Alias für include und auch kein Backup -all . Vor der Konsolidierung von Datensätzen ist es wichtig zu verstehen, wann die Umleitung ausgeführt wird. RFC 7208 Abschnitt 6.1 definiert sein Verhalten.
Legen Sie die Delegationsbedingung fest
Wenn kein Mechanismus übereinstimmt, kein früherer Fehler die Auswertung beendet hat und eine Umleitung vorhanden ist, wertet SPF das Umleitungsziel aus. Die Verbindungs-IP und der Absender bleiben gleich, während die zu bewertende Domäne zum Ziel wird. Die daraus resultierende Auswertung liefert das Ergebnis, bei fehlendem SPF am Zielwert permerror eher als keine.
Wenn im äußeren Datensatz ein All-Mechanismus vorhanden ist, wird die Umleitung ignoriert. Die Platzierung der Weiterleitung vor allem rettet es nicht. Schreiben Sie der Übersichtlichkeit halber die Umleitung am Ende, aber denken Sie daran, dass es sich um einen Modifikator und nicht um einen Links-nach-rechts-Zuordnungsmechanismus handelt.
Der Delegation kann ein lokaler Mechanismus vorangehen. Beispielsweise kann eine explizite IP4-Berechtigung übereinstimmen, bevor die gemeinsame Richtlinie konsultiert wird. Entscheiden Sie, ob solche Ausnahmen beabsichtigt sind; andernfalls ist eine vermeintlich zentrale Richtlinie möglicherweise nicht die ganze Autorisierungsgeschichte.
Ausgearbeitetes Beispiel: zwei Domänen, eine verwaltete Richtlinie
Eine gültige Syntax vorausgesetzt, wurde eine ausgewählt SPF Eintrag pro Name und erfolgreichem DNS Abruf veröffentlichen in dieser synthetischen Vorrichtung jeweils east.example.com und west.example.com v=spf1 redirect=policy.example.com. Das freigegebene Ziel veröffentlicht v=spf1 ip4:192.0.2.30 -all.
Für 192.0.2.30 stimmt jede äußere Richtlinie mit der Ziel-IP4 überein und das Ergebnis ist „bestanden“. Für 192.0.2.31 erreicht das Ziel -all und das delegierte Ergebnis ist fehlgeschlagen. Wenn das Ziel TXT Eintrag verschwindet, Auswertungen, die die Umleitung erfordern, erzeugen permerror .
Ändern Sie nun die Ostpolitik in v=spf1 ip4:198.51.100.8 redirect=policy.example.com. Diese zusätzliche Adresse wird lokal weitergegeben, auch wenn das gemeinsame Ziel sie nicht autorisiert. Eine zentrale Richtlinienprüfung muss daher jeden delegierenden Datensatz lesen und nicht nur das Ziel überprüfen.
Vergleichen Sie dasselbe Ziel unter „Einschließen“.
Wenn die äußere Richtlinie stattdessen enthält v=spf1 include:policy.example.com ~all, ein Kinderpass entspricht dem Include. Ein untergeordneter Fehler liefert nicht das Endergebnis; Die Verarbeitung wird fortgesetzt und der äußere ~all erzeugt softfail .
Die Umleitung überträgt beim Aufruf das Ergebnis der Zielrichtlinie. Include fragt, ob das Ziel erfolgreich ist, und fährt dann mit der äußeren Richtlinie fort, wenn dies nicht der Fall ist. Wählen Sie die Konstruktion, die zum Eigentumsmodell passt, anstatt mechanisch zwischen ihnen zu wechseln.
Überwachen Sie kontextsensitive Regeln
Die Umleitung ändert die aktuelle Bewertungsdomäne und behält dabei die Absendereingabe bei. Makros und domänenbezogene Mechanismen können daher davon abhängen, welche Domäne oder welchen Absenderwert sie verwenden. Eine Richtlinie, die für eine Domäne funktioniert, ist nicht automatisch auch für eine andere sicher.
Verwenden Sie für einen Sendedienst eines Drittanbieters den Integrationsmechanismus, der in der aktuellen Dokumentation unterstützt wird. RFC 7208 weist darauf hin, dass die Weiterleitung über Verwaltungsgrenzen hinweg möglicherweise nicht zuverlässig funktioniert, insbesondere wenn die Zielrichtlinie von lokalen Teilen abhängt. Ersetzen Sie ein dokumentiertes Include nicht durch eine Umleitung, nur um den sichtbaren Datensatz zu kürzen.
Betreiben Sie die gemeinsame Richtlinie sicher
Inventarisieren Sie alle abhängigen Domänen und lokalen Ausnahmen. Weisen Sie dem gemeinsamen Ziel einen verantwortlichen Eigentümer zu. Bevor Sie es ändern, testen Sie einen zulässigen und einen unzulässigen Absender für jeden einzelnen Richtlinienkontext, einschließlich IPv6 , sofern verwendet. Bewahren Sie die ursprünglichen delegierenden und freigegebenen Datensätze zusammen auf.
Unter RFC 7208 §4.1 Und RFC 7208 §4.6.4, Umleitung und erreichte verschachtelte Begriffe verbrauchen das SPF DNS Begriffsbudget. Erkennen Sie Schleifen und Abhängigkeitswachstum durch Auswertung, anstatt sich auf die kurze Länge jedes lokalen Datensatzes zu verlassen. Überprüfen Sie nach einer Änderung maßgebliche und rekursive Antworten und erhaltene E-Mails des Testmitarbeiters.
Der praktische Imbiss
Umleitung ist eine nützliche Zentralisierung, wenn Sie wirklich gemeinsame Richtlinien wünschen. Halten Sie alles aus dem delegierenden Datensatz heraus, prüfen Sie lokale Ausnahmen und testen Sie den Absenderkontext, der die Delegation überlebt.
Halten Sie die Entscheidung reproduzierbar
Für east.example.com wird die lokale Ausnahme 198.51.100.8 bestanden, ohne das gemeinsame Ziel aufzurufen. Ein Ausfall eines gemeinsamen Ziels muss sich daher nicht unbedingt auf genau diesen Pfad auswirken. Bei einer anderen Quelle, die eine Umleitung erfordert, kann der Zielfehler auftreten. Notieren Sie den äußeren Datensatz, die Eingabe des Absenders, das erreichte Ziel und das erwartete Ergebnis zusammen, bevor Sie die Zentralisierung genehmigen. Es wurde kein Shared-Policy-Änderungs- oder Ausfalltest durchgeführt.