6. Modifier Definitions (Modifikator-Definitionen)

Modifikatoren sind Name/Wert-Paare, die zusätzliche Informationen liefern. Modifikatoren haben immer ein "=" das Name und Wert trennt.

Die in diesem Dokument definierten Modifikatoren ("redirect" und "exp") sollten am Ende des Eintrags erscheinen, nach allen Mechanismen, obwohl sie syntaktisch an jeder Stelle im Eintrag erscheinen können. Die Reihenfolge dieser beiden Modifikatoren ist irrelevant. Diese beiden Modifikatoren dürfen in einem Eintrag absolut nicht mehr als einmal erscheinen. Wenn sie es tun, beendet check_host() mit einem "permerror"-Ergebnis.

Nicht erkannte Modifikatoren müssen ignoriert werden, unabhängig davon wo oder wie oft sie erscheinen. Dies ermöglicht es Implementierungen, die diesem Dokument entsprechen, Einträge mit Modifikatoren, die in anderen Spezifikationen definiert sind, angemessen zu handhaben.

6.1 redirect: Redirected Query (redirect: Umgeleitete Abfrage)

Der "redirect"-Modifikator ist dazu gedacht, Autorisierung und Richtlinie in einen gemeinsamen Satz zu konsolidieren, der innerhalb eines einzelnen ADMD geteilt werden soll. Die autorisierten Hosts und Richtlinien einer beliebigen Anzahl von Domains können von einem einzelnen Eintrag aus gesteuert werden.

redirect = "redirect" "=" domain-spec

Wenn alle Mechanismen nicht übereinstimmen und ein "redirect"-Modifikator vorhanden ist, erfolgt die Verarbeitung wie folgt:

Der <domain-spec>-Teil des redirect-Teils wird gemäß den Makroregeln in Abschnitt 7 erweitert. Dann wird check_host() mit der resultierenden Zeichenkette als <domain> bewertet. Die <ip>- und <sender>-Parameter bleiben dieselben wie in der aktuellen Bewertung von check_host().

Das Ergebnis dieser neuen Bewertung von check_host() wird dann als Ergebnis der aktuellen Bewertung behandelt, außer dass wenn kein SPF-Eintrag gefunden wird oder wenn <target-name> fehlerhaft formatiert ist, das Ergebnis "permerror" anstatt "none" ist.

Beachten Sie, dass die Domain der neuen Abfrage selbst eine Redirect-Verarbeitung spezifizieren kann.

Dieses Tool ist für Organisationen gedacht, die denselben Eintrag auf mehrere Domains anwenden möchten. Zum Beispiel:

la.example.com. TXT "v=spf1 redirect=_spf.example.com"
ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
_spf.example.com. TXT "v=spf1 mx:example.com -all"

In diesem Beispiel werden E-Mails von einer dieser drei Domains durch denselben Eintrag beschrieben. Dies kann administrativ vorteilhaft sein.

Hinweis: Im Allgemeinen kann Domain "A" nicht zuverlässig eine Umleitung zu einer anderen Domain "B" verwenden, die nicht unter derselben administrativen Kontrolle steht. Da <domain> unverändert bleibt, gibt es keine Garantie, dass der Eintrag bei Domain "B" für Mailboxen in Domain "A" korrekt funktioniert, insbesondere wenn Domain "B" Mechanismen verwendet, die den local-part einbeziehen. Die "include"-Direktive wäre im Allgemeinen angemessener.

Zur Klarheit sollte jeder "redirect"-Modifikator als letzter Term im Eintrag erscheinen. Wenn irgendwo im Eintrag ein "all"-Mechanismus vorhanden ist, muss jeder "redirect"-Modifikator ignoriert werden.

6.2 exp: Explanation (exp: Erklärung)

explanation = "exp" "=" domain-spec

Wenn check_host() aufgrund eines übereinstimmenden Mechanismus (wie z.B. "-all") zu "fail" führt und ein "exp"-Modifikator vorhanden ist, wird die zurückgegebene Erklärungszeichenkette wie unten beschrieben berechnet. Wenn kein "exp"-Modifikator vorhanden ist, muss entweder eine Standard-Erklärungszeichenkette oder eine leere Erklärungszeichenkette an die aufrufende Anwendung zurückgegeben werden.

<domain-spec> wird einer Makroerweiterung unterzogen (siehe Abschnitt 7) und wird zu <target-name>. Das DNS TXT RRset für <target-name> wird abgerufen.

Wenn es irgendwelche DNS-Verarbeitungsfehler gibt (beliebiger RCODE nicht 0), oder wenn keine Einträge zurückgegeben werden, oder wenn mehr als ein Eintrag zurückgegeben wird, oder wenn es Syntaxfehler in der Erklärungszeichenkette gibt, wird fortgefahren, als ob kein "exp"-Modifikator gegeben worden wäre.

Die Zeichenketten des abgerufenen TXT-Eintrags werden ohne Leerzeichen verkettet und dann als explain-string verarbeitet, der einer Makroerweiterung unterzogen wird. Dieses Endergebnis ist die Erklärungszeichenkette. Implementierungen können die Länge der resultierenden Erklärungszeichenkette begrenzen, um andere Protokollbeschränkungen und/oder vernünftige Verarbeitungsgrenzen zu berücksichtigen. Da die Erklärungszeichenkette für die Verwendung in SMTP-Antworten gedacht ist und Abschnitt 2.4 von [RFC5321] besagt, dass Antworten [US-ASCII] sind, muss die Erklärungszeichenkette auf [US-ASCII] beschränkt sein.

Software, die check_host() bewertet, kann diese Zeichenkette verwenden, um Informationen von der veröffentlichenden Domain in Form einer kurzen Nachricht oder URL zu kommunizieren. Software sollte deutlich machen, dass die Erklärungszeichenkette von einem Dritten stammt. Sie könnte beispielsweise die Makrozeichenkette "%\{o} explains: " der Erklärung voranstellen, wie im Beispiel in Abschnitt 8.4 gezeigt.

Angenommen, example.com hat diesen Eintrag:

v=spf1 mx -all exp=explain._spf.%\{d}

Hier sind einige Beispiele für mögliche Erklärungs-TXT-Einträge bei explain._spf.example.com:

"Mail from example.com should only be sent by its own servers."

-- eine einfache, konstante Nachricht

"%\{i} is not one of %\{d}'s designated mail servers."

-- eine Nachricht, die mehr Informationen enthält, einschließlich der IP-Adresse, die die Prüfung nicht bestanden hat

"See http://%\{d}/why.html?s=%\{S}&i=%\{I}"

-- ein komplexes Beispiel, das die Parameter von check_host() verwendet, um eine URL zu konstruieren, sodass eine Webseite mit detaillierten, benutzerdefinierten Anweisungen generiert werden kann

Hinweis: Während der Rekursion in einen "include"-Mechanismus darf der "exp"-Modifikator aus <target-name> absolut nicht verwendet werden. Umgekehrt darf bei der Ausführung eines "redirect"-Modifikators der "exp"-Modifikator aus der ursprünglichen Domain absolut nicht verwendet werden. Dies liegt daran, dass "include" dazu gedacht ist, administrative Grenzen zu überschreiten, und die zu liefernde Erklärung sollte die vom empfangenden ADMD sein, während "redirect" als Werkzeug zur Konsolidierung von Richtlinieneinträgen innerhalb eines ADMD gedacht ist und daher die umgeleitete Erklärung diejenige ist, die Vorrang haben sollte.