Der existierende Mechanismus kann machen SPF Die Richtlinie hängt von einem DNS Namen ab, der aus den SMTP Eingaben der Nachricht zusammengestellt wird. Dies ermöglicht feinkörnige Richtlinien, macht diese aber sichtbar TXT Eintrag eine schlechte Beschreibung der eigentlichen Anfrage oder ihrer Auswirkungen auf den Datenschutz.
Genehmigen Sie keine Makrorichtlinie, weil sie Ihnen bekannt vorkommt. Erweitern Sie es für repräsentative Eingaben, identifizieren Sie den DNS Betreiber, der die Anfrage erhält, und stellen Sie fest, was eine positive Antwort bedeutet.
Verstehen Sie den Existed-Test
exist erweitert seine Domänenspezifikation und führt eine A-Record-Abfrage durch. Dies geschieht sogar für eine IPv6 SMTP Verbindung. Wenn überhaupt Ein Rekord zurückgegeben wird, stimmt der Mechanismus überein; Die zurückgegebene Adresse wird nicht mit der Verbindungs-IP verglichen. Eine reine AAAA-Antwort erfüllt die A-Suche nicht. Sehen RFC 7208 Abschnitt 5.7.
Unter dem normalen +-Qualifikationsmerkmal führt ein Match zu einem Pass. Ein fehlender Name oder eine leere Antwort. Eine Antwort stimmt nicht überein. Temporäre DNS Fehler müssen gemäß den Fehlerregeln von SPF behandelt werden und dürfen nicht stillschweigend in eine Autorisierungsentscheidung umgewandelt werden.
Erweitern Sie eine synthetische Abfrage manuell
Gehen Sie von einem gültigen Einzeleintrag, erfolgreichen DNS -Antworten und keiner Überschreitung der Grenzwerte aus. In Betracht ziehen v=spf1 exists:%{ir}._permit.%{d} -all bei example.com für eine IPv4 -Verbindung von 192.0.2.9 . Das i-Makro repräsentiert die Eingabeadresse. Der r-Transformator kehrt die Teile um und d ist der aktuelle Bewertungsbereich. Die erweiterte Abfrage lautet 9.2.0.192._permit.example.com.
Wenn dieser Name einen A-Datensatz zurückgibt, beispielsweise den beispielhaften Wert 127.0.0.2 , gibt es Übereinstimmungen, auch wenn sich diese Adresse von 192.0.2.9 unterscheidet. Wenn kein A-Datensatz vorhanden ist und kein Fehler die Auswertung verhindert, stimmt der Mechanismus nicht überein und die Richtlinie erreicht -all .
Der A-Wert ist hier nur ein positiver Antwortmarker. Die Sicherheitsbedeutung ergibt sich aus der Kontrolle des abgefragten DNS Namespace und seiner Regel für die Rückgabe von Antworten. Ein Platzhalter, der jede mögliche Anfrage beantwortet, kann unbeabsichtigt jede Eingabe autorisieren, die ihn erreicht.
Unterscheiden Sie Makroidentitäten
Das d-Makro ist die aktuell ausgewertete Domäne. Das o-Makro stammt aus der Domäne des Absenders, während sich l auf den lokalen Teil des Absenders bezieht. Einschließen oder Umleiten kann den Auswertungskontext ändern. Gehen Sie daher nicht davon aus, dass d und o innerhalb einer Abhängigkeit austauschbar bleiben.
Makrotransformatoren können Teile auswählen, umkehren und Trennzeichen ändern. IPv6 Erweiterung ist nicht dieselbe punktierte Dezimalzeichenfolge wie IPv4 . Verwenden RFC 7208 §7.2 Und RFC 7208 §7.3 und eine Implementierungsverfolgung für die tatsächliche Form, anstatt anhand eines IPv4 Beispiels zu raten.
Bei fehlerhaften erweiterten Namen und überlangen Beschriftungen ist besondere Vorsicht geboten. Unter RFC 7208 §4.8, weist die Spezifikation auf Implementierungsunterschiede für einige ungültige Domänenspezifikationsergebnisse hin. Halten Sie die Fixtures innerhalb der gültigen DNS Syntax und testen Sie den in Ihrer Umgebung verwendeten Evaluator. Behaupten Sie nicht, dass alle Empfänger jede fehlerhafte Eingabe gleich behandeln.
Überprüfen Sie Datenschutz und Verfügbarkeit
Wie beschrieben in RFC 7208 §11.6kann ein Makro, das lokale Teil- oder vollständige Absenderdaten verwendet, nachrichtenbezogene Identitätsinformationen über DNS Abfragen an den Namespace-Betreiber und die relevante DNS Infrastruktur offenlegen. Überprüfen Sie die erforderlichen Mindestdaten, bevor Sie ein solches Design verwenden, insbesondere bei einem Drittanbieter-Richtliniendienst.
Die Richtlinie hängt auch von der Verfügbarkeit und Integrität des antwortenden DNS Systems ab. Erfassen Sie, wer es betreibt, wie positive Antworten generiert werden, wie Änderungen überprüft werden und was bei Ausfällen passiert. Unter RFC 7208 §4.6.4, DNS-Abfrage verursachende Begriffe und Leere Suchvorgänge unterliegen weiterhin den SPF Grenzwerten; Existiert bietet keine unbegrenzten externen Richtlinienaufrufe.
Bauen Sie nützliche Abnahmevorrichtungen
Testen Sie eine autorisierte Eingabe, eine nicht autorisierte Eingabe, IPv6 (falls verwendet), einen DNS Ausfall und einen gültigen, aber ungewöhnlichen lokalen Absenderteil, wenn dieser die Abfrage beeinträchtigt. Speichern Sie den genauen erweiterten Namen, den Abfragetyp, DNS Antwort und das Terminal SPF -Ergebnis für jedes Gerät.
Testen Sie außerdem das Wildcard-Verhalten und Änderungen an der Zielzone. Ein Datensatz kann syntaktisch korrekt bleiben, während der Anrufbeantworter seine Berechtigungslogik ändert. Schließen Sie die Überprüfung erst ab, wenn die DNS Entscheidung erklärt und reproduziert werden kann.
Der praktische Imbiss
Für vorhanden ist die erweiterte DNS Frage der Richtlinienbeweis. Überprüfen Sie die Eingaben, die Antwortsemantik, die Gefährdung der Privatsphäre und das Fehlerverhalten, bevor Sie sich auf den resultierenden Durchgang verlassen.
Notieren Sie die Entscheidung und ihre Grenzen
Unterscheiden Sie für die gleiche 192.0.2.9 -Eingabe drei Spielpaarungen: A= 127.0.0.2 ergibt ein Match und einen standardmäßig qualifizierten Pass; eine erfolgreiche leere A-Antwort ergibt keine Übereinstimmung und erreicht -all ; Ein vorübergehender DNS Fehler beendet die Auswertung als temperror anstatt zu scheitern. Die Fehlerregel lautet RFC 7208 §5 Und RFC 7208 §4.6.2. Dabei handelt es sich um erwartete Ergebnisse, nicht um beobachtete DNS oder Evaluator-Läufe.