Abflachung SPF ist eine Möglichkeit, einige DNS-abhängige Autorisierungen durch explizite Adressbereiche zu ersetzen. Dadurch kann eine Auswertung weniger abhängig von verschachtelten Suchvorgängen werden. Es kann auch dazu führen, dass Sie eine Kopie des sich ändernden Netzwerks einer anderen Person verwalten. Eine sinnvolle Entscheidung ist daher der Vergleich der vorgeschlagenen Aufzeichnung und des Prozesses, der sie korrekt hält.
Stellen Sie die tatsächliche Einschränkung her
Beginnen Sie mit der genauen Umschlagdomäne, die von der betroffenen Anwendung verwendet wird, und nicht einfach mit der Website-Domäne des Unternehmens. Erfassen Sie den aktuellen Datensatz, seine Abhängigkeiten und repräsentativen Absenderadressen. Führen Sie mit diesen Eingaben eine standardgerechte Auswertung durch und behalten Sie die Ablaufverfolgung bei. Ein Etikett mit der Aufschrift „zu viele Suchvorgänge“ reicht nicht aus, um zu entscheiden, was ersetzt werden soll.
RFC 7208 Abschnitt 4.6.4 begrenzt die global ausgewerteten DNS-abhängigen Begriffe über die Rekursion hinweg. Explizite IP4- und IP6-Mechanismen liegen außerhalb dieses Budgets. Dies ist der potenzielle Vorteil der Suche; Es ist kein Versprechen, dass jeder abgeflachte Datensatz klein, korrekt oder schnell ist.
Entfernen Sie zunächst Berechtigungen, deren Geschäftsinhaber bestätigen, dass sie veraltet sind. Prüfen Sie, ob eine bestimmte Anwendung eine entsprechend konfigurierte Umschlag-Subdomäne verwenden kann. Weder die Bereinigung noch die Segmentierung sollten blind durchgeführt werden: Listen Sie die betroffenen Nachrichten auf und bestätigen Sie, dass der Anbieter die vorgeschlagene Identität unterstützt. Benutzen Sie die Absenderbestand verbinden ein Rekord Zugang zu einem echten Dienst.
Vergleichen Sie Bedeutungen, nicht nur Adresslisten
Unter RFC 7208 §5.2ist ein Include eine Auswertung einer anderen Richtlinie und keine Textdatei mit zu kopierenden Netzwerken. Qualifizierer, Reihenfolge, verschachtelte Includes, Umleitungen und Makros können das Ergebnis beeinflussen. Ein Konverter muss die beabsichtigte Autorisierung für die unterstützten Eingaben beibehalten oder explizit angeben, was er nicht darstellen kann. Lehnen Sie eine Konvertierung ab, die einfach jeden IP-ähnlichen Wert aus einem Baum sammelt.
Fragen Sie bei jedem vorgeschlagenen Ersatz nach, welche Upstream-Richtlinie er darstellt, welche Eingaben getestet wurden, ob IPv6 abgedeckt ist und wie Änderungen erkannt werden. Bewahren Sie die Originaldokumentation zu Abhängigkeiten und Anbietern neben der generierten Ausgabe auf. Vermeiden Sie die Erweiterung benachbarter Netzwerke auf einen größeren Bereich, nur um den Text zu kürzen, es sei denn, dieser gesamte Bereich ist unabhängig autorisiert.
Machen Sie die Wartungskosten sichtbar
Dies ist eine beispielhafte Entscheidung, keine getestete Bereitstellung. Ein Abrechnungssender verweist auf eine Anbieterrichtlinie, die derzeit zwei Bereiche zulässt. Eine reduzierte Kopie enthält diese Bereiche. Morgen fügt der Anbieter einen dritten hinzu. Die ursprüngliche Abhängigkeit kann die neue Autorisierung über DNS offenlegen; Die Kopie wird es erst enthalten, wenn eine erfolgreiche Aktualisierung ein Update veröffentlicht. Das umgekehrte Problem tritt auf, wenn der Anbieter einen Bereich zurückzieht, die Kopie ihn jedoch behält.
Weisen Sie jemanden zu, der sich um die Aktualisierung, fehlgeschlagene Aktualisierungen, unerwartete große Änderungen und die Notfallwiederherstellung kümmert. Fordern Sie eine Benachrichtigung an, wenn der Generierungsprozess stoppt, und nicht nur, wenn der veröffentlichte Datensatz syntaktisch gültig ist. Ein gültiger veralteter Datensatz kann immer noch der falsche Datensatz sein.
Testen Sie einen Kandidaten, bevor Sie ihn ersetzen
Behalten Sie den vorherigen Datensatz bei und erstellen Sie einen expliziten Vorher-Nachher-Diff. Testen Sie bekannte Absender, eine nicht autorisierte Adresse, jede relevante IP-Familie und das endgültige Ergebnis der Nichtübereinstimmung. Überprüfen Sie die tatsächliche TXT Antwort, einschließlich ihrer Größe und Zeichenfolgengrenzen. RFC 7208 §3.3 Und RFC 7208 §3.4 Erklären Sie, warum die Aufteilung eines TXT Werts in Zeichenfolgen die Verwaltung der gesamten DNS Antwort nicht überflüssig macht.
Führen Sie nach der genehmigten Veröffentlichung einen kontrollierten Sendetest durch. Notieren Sie das Authentifizierungsergebnis des empfangenden Systems und die von ihm ausgewertete Umschlagidentität. Setzen Sie ein nicht gleich SPF Verbesserung mit DMARC Ausrichtung oder garantierte Platzierung im Posteingang.
Wählen Sie ein Betriebsmodell, das Sie aufrechterhalten können
Behalten Sie die abhängigkeitsbasierte Richtlinie bei, wenn ihre Bewertung akzeptabel ist und ihre fortlaufende Eigentümerschaft klarer ist. Erwägen Sie eine Reduzierung nur mit nachgewiesener semantischer Abdeckung, einem zuverlässigen Aktualisierungsmechanismus, Warnungen und einem Ausstiegsplan. Eine geringere Suchzahl ist ein nützlicher Beweis, aber nicht die gesamte Akzeptanzentscheidung. Für die Wartung nach der Einführung fahren Sie fort mit abgestandener abgeflachter SPF.
Notieren Sie die nächste Entscheidung
Listen Sie für eine hypothetische Konvertierung die unterstützten Upstream-Konstrukte, die Quell-Snapshot-Zeit, die getesteten Identitäten/IPs, die erwarteten Terminalergebnisse und die Person auf, die hinzugefügte oder zurückgezogene Bereiche erkennt. Wenn eine makroabhängige Autorisierung für die vorgesehenen Eingaben nicht dargestellt werden kann, ist der Kandidat nicht bereit, nur weil seine Suchanzahl geringer ist. Für diesen Artikel wurde keine Konvertierung, DNS Änderung oder Sendetest durchgeführt.