5. Mechanism Definitions (Mechanismusdefinitionen)

Dieser Abschnitt definiert zwei Arten von Mechanismen: Grundlegende Sprachrahmen-Mechanismen und Absender-spezifizierende Mechanismen.

Die grundlegenden Mechanismen erleichtern den Sprachrahmen. Sie spezifizieren keine bestimmte Art von Autorisierungsschema. Die grundlegenden Mechanismen sind wie folgt:

all
include

Die Absender-spezifizierenden Mechanismen werden verwendet, um einen Satz von <ip>-Adressen zu identifizieren, die berechtigt oder nicht berechtigt sind, E-Mails mit <domain> zu senden. Die Absender-spezifizierenden Mechanismen sind wie folgt:

a
mx
ptr (do not use)
ip4
ip6
exists

Die folgenden Konventionen gelten für alle Mechanismen, die jederzeit einen Vergleich zwischen <target-name> und einer IP-Adresse durchführen:

Wenn im Direktiv keine CIDR-Präfixlänge angegeben ist, wird <target-name> auf Gleichheit mit der IP-Adresse verglichen. (Hier ist CIDR Classless Inter-Domain Routing, beschrieben in [RFC4632].)

Wenn eine CIDR-Präfixlänge angegeben ist, wird nur die angegebene Anzahl von High-Order-Bits von <target-name> auf Gleichheit mit der IP-Adresse verglichen.

Wenn ein Mechanismus Host-Adressen abruft, um sie mit <ip> zu vergleichen, werden "A"-Einträge abgerufen, wenn <ip> IPv4 ist, und "AAAA"-Einträge werden abgerufen, wenn <ip> eine IPv6-Adresse ist. SPF-Implementierungen auf IPv6-Servern müssen sowohl "AAAA"- als auch "A"-Einträge für Clients auf IPv4-mapped IPv6-Adressen [RFC4291] verarbeiten. IPv4-Adressen werden nur im SPF-Eintrag mit dem "ip4"-Mechanismus aufgeführt.

Mehrere Mechanismen hängen von Informationen ab, die aus DNS abgerufen werden. Für diese DNS-Abfragen, sofern nicht anders angegeben, wenn der DNS-Server einen Fehler zurückgibt (RCODE nicht 0 oder 3) oder wenn die Abfrage eine Zeitüberschreitung hat, stoppt der Mechanismus und die oberste check_host() gibt "temperror" zurück. Wenn der Server "Name Error" (RCODE 3) zurückgibt, fährt die Bewertung des Mechanismus fort, als ob der Server ohne Fehler (RCODE 0) und null Antworteinträge zurückgegeben hätte.

5.1 "all"

all = "all"

Der "all"-Mechanismus ist ein Test, der immer übereinstimmt. Er wird als rechtester Mechanismus im Eintrag verwendet, um einen expliziten Standardwert bereitzustellen.

Beispiel:

v=spf1 a mx -all

Mechanismen nach "all" werden niemals getestet. Nach "all" aufgeführte Mechanismen müssen ignoriert werden. Wenn ein "all"-Mechanismus im Eintrag vorhanden ist, muss jeder "redirect"-Modifikator (Abschnitt 6.1) ignoriert werden, unabhängig von der relativen Reihenfolge der Terme.

5.2 "include"

include = "include" ":" domain-spec

Der "include"-Mechanismus löst eine rekursive Auswertung von check_host() aus.

<domain-spec> wird gemäß Abschnitt 7 erweitert.
check_host() wird mit der resultierenden Zeichenkette als <domain> bewertet. Die <ip>- und <sender>-Parameter bleiben dieselben wie in der aktuellen Bewertung von check_host().
Die rekursive Auswertung gibt Übereinstimmung, Nicht-Übereinstimmung oder Fehler zurück.
Wenn sie Übereinstimmung zurückgibt, verwendet der "include"-Mechanismus das entsprechende Ergebnis (z.B. erzeugt include oder +include ein "pass"-Ergebnis, -include erzeugt "fail").
Wenn sie Nicht-Übereinstimmung oder Fehler zurückgibt, setzt die übergeordnete check_host() die Verarbeitung gemäß der folgenden Tabelle fort und stellt den vorherigen <domain>-Wert wieder her.

Im Nachhinein war der Name "include" eine schlechte Wahl. Nur das Bewertungsergebnis des referenzierten SPF-Eintrags wird verwendet, anstatt die Mechanismen des referenzierten Eintrags im ersten Eintrag wörtlich einzuschließen. Beispielsweise beendet die Auswertung eines "-all"-Direktivs im referenzierten Eintrag nicht die Gesamtverarbeitung und führt nicht notwendigerweise zu einem allgemeinen "fail". (Bessere Namen für diesen Mechanismus wären "if-match", "on-match" usw. gewesen.)

Der "include"-Mechanismus ermöglicht es einer Domain, mehrere administrativ unabhängige Domains anzugeben. Zum Beispiel könnte die Vanity-Domain "example.net" E-Mails mit den Servern der administrativ unabhängigen Domains example.com und example.org senden.

Example.net könnte sagen

IN TXT "v=spf1 include:example.com include:example.org -all"

Dies würde check_host() anweisen, die Einträge von example.com und example.org effektiv auf ein "pass"-Ergebnis zu überprüfen. Nur wenn der Host von keiner dieser beiden Domains erlaubt ist, wäre das Ergebnis "fail".

Ob dieser Mechanismus übereinstimmt, nicht übereinstimmt oder eine Ausnahme zurückgibt, hängt vom Ergebnis der rekursiven Auswertung von check_host() ab:

+---------------------------------+---------------------------------+
| A recursive check_host() result | Causes the "include" mechanism |
| of:                             | to:                            |
+---------------------------------+---------------------------------+
| pass                            | match                          |
|                                 |                                |
| fail                            | not match                      |
|                                 |                                |
| softfail                        | not match                      |
|                                 |                                |
| neutral                         | not match                      |
|                                 |                                |
| temperror                       | return temperror               |
|                                 |                                |
| permerror                       | return permerror               |
|                                 |                                |
| none                            | return permerror               |
+---------------------------------+---------------------------------+

Der "include"-Mechanismus ist dazu gedacht, administrative Grenzen zu überschreiten. Wenn man innerhalb einer einzelnen administrativen Autorität bleibt, ist "include" in der Regel nicht die beste Wahl. Wenn zum Beispiel example.com und example.org von derselben Entität verwaltet werden und wenn der Satz erlaubter Hosts für beide Domains "mx:example.com" ist, könnte example.org "include:example.com" spezifizieren, aber es wäre besser, "redirect=example.com" oder sogar "mx:example.com" zu spezifizieren.

Mit dem "include"-Mechanismus ist es möglich, einen administrativ externen Satz von Hosts zu autorisieren, aber die Bestimmung der Absenderrichtlinie bleibt eine Funktion des SPF-Eintrags der ursprünglichen Domain (bestimmt durch den "all"-Mechanismus in diesem Eintrag). Der "redirect"-Modifikator eignet sich besser, um Autorisierung und Richtlinie in einen gemeinsamen Satz zu konsolidieren, der innerhalb eines ADMD geteilt werden soll. Redirect ist eher wie ein gemeinsames Code-Element, das zwischen Einträgen 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.

5.3 "a"

Dieser Mechanismus stimmt überein, wenn <ip> eine der IP-Adressen von <target-name> ist. Zur Klarstellung bedeutet dies, dass der "a"-Mechanismus auch mit AAAA-Einträgen übereinstimmt.

a = "a" [ ":" domain-spec ] [ dual-cidr-length ]

Es wird eine Adressabfrage für <target-name> durchgeführt, wobei der Abfragetyp (A oder AAAA) verwendet wird, der für den Verbindungstyp (IPv4 oder IPv6) geeignet ist. <ip> wird mit den zurückgegebenen Adressen verglichen. Wenn eine Adresse übereinstimmt, stimmt der Mechanismus überein.

5.4 "mx"

Dieser Mechanismus stimmt überein, wenn <ip> einer der MX-Hosts des Domainnamens ist.

mx = "mx" [ ":" domain-spec ] [ dual-cidr-length ]

check_host() führt zuerst eine MX-Abfrage für <target-name> durch. Dann führt es eine Adressabfrage für jeden zurückgegebenen MX-Namen durch. <ip> wird mit jeder zurückgegebenen IP-Adresse verglichen. Um Denial-of-Service (DoS)-Angriffe zu verhindern, müssen die in Abschnitt 4.6.4 definierten Verarbeitungsgrenzen eingehalten werden. Wenn das MX-Abfragelimit überschritten wird, wird "permerror" zurückgegeben und die Bewertung wird beendet. Wenn eine Adresse übereinstimmt, stimmt der Mechanismus überein.

Hinweis zu impliziten MX-Einträgen: Wenn <target-name> keine MX-Einträge hat, darf check_host() die implizite MX-Regel von [RFC5321] nicht anwenden, d.h. A- oder AAAA-Einträge für denselben Namen abfragen.

5.5 "ptr" (do not use) ("ptr" (nicht verwenden))

Dieser Mechanismus testet, ob die DNS-Umkehrabbildung von <ip> existiert und korrekt auf einen Domainnamen innerhalb einer bestimmten Domain zeigt. Dieser Mechanismus sollte nicht veröffentlicht werden. Weitere Informationen finden Sie in den Hinweisen am Ende dieses Abschnitts.

ptr = "ptr" [ ":" domain-spec ]

Der Name für <ip> wird mithilfe des folgenden Verfahrens nachgeschlagen:

Führen Sie eine DNS-Umkehrabbildung für <ip> durch: Suchen Sie den entsprechenden PTR-Eintrag in "in-addr.arpa.", wenn die Adresse IPv4 ist, oder in "ip6.arpa.", wenn sie IPv6 ist.
Überprüfen Sie für jeden zurückgegebenen Eintrag den Domainnamen, indem Sie seine IP-Adresse nachschlagen. Um DoS-Angriffe zu verhindern, müssen die in Abschnitt 4.6.4 definierten PTR-Verarbeitungsgrenzen angewendet werden. Wenn die Grenzen überschritten werden, beenden Sie die Verarbeitung, und der Mechanismus stimmt nicht überein.
Wenn <ip> in den zurückgegebenen IP-Adressen enthalten ist, ist dieser Domainname validiert.

Überprüfen Sie alle validierten Domainnamen, um festzustellen, ob sie mit <target-name> übereinstimmen oder Subdomains von <target-name> sind. Wenn es Übereinstimmungen gibt, stimmt dieser Mechanismus überein. Wenn keine validierten Domainnamen gefunden werden können oder wenn keine validierten Domainnamen mit <target-name> übereinstimmen oder Subdomains davon sind, kann dieser Mechanismus nicht übereinstimmen. Wenn bei der Ausführung der PTR-RR-Abfrage ein DNS-Fehler auftritt, kann dieser Mechanismus nicht übereinstimmen. Wenn bei der Ausführung einer A-RR-Abfrage ein DNS-Fehler auftritt, wird dieser Domainname übersprungen und die Suche fortgesetzt.

Dieser Mechanismus stimmt überein, wenn:

<target-name> eine Subdomain des validierten Domainnamens ist, oder
<target-name> und der validierte Domainname identisch sind.

Zum Beispiel ist "mail.example.com" innerhalb der Domain "example.com", aber "mail.bad-example.com" nicht.

Hinweis: Dieser Mechanismus ist langsam, bei DNS-Fehlern nicht so zuverlässig wie andere Mechanismen und belastet die .arpa-Nameserver stark. Bei Verwendung müssen entsprechende PTR-Einträge für die Hosts der Domain eingerichtet werden, und der "ptr"-Mechanismus sollte einer der zuletzt überprüften Mechanismen sein. Nach mehreren Jahren Erfahrung mit der SPF-Bereitstellung wurde der Schluss gezogen, dass er unnötig ist und zuverlässigere Alternativen verwendet werden sollten. Er bleibt jedoch Teil des SPF-Protokolls, sodass konforme check_host()-Implementierungen ihn unterstützen müssen.

5.6 "ip4" and "ip6" ("ip4" und "ip6")

Diese Mechanismen testen, ob <ip> in einem gegebenen IP-Netzwerk enthalten ist.

ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ]

ip4-cidr-length = "/" ("0" / %x31-39 0*1DIGIT) ; value range 0-32
ip6-cidr-length = "/" ("0" / %x31-39 0*2DIGIT) ; value range 0-128
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]

ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT                      ; 0-9
     / %x31-39 DIGIT              ; 10-99
     / "1" 2DIGIT                 ; 100-199
     / "2" %x30-34 DIGIT          ; 200-249
     / "25" %x30-35               ; 250-255
     ; as per conventional dotted-quad notation, e.g., 192.0.2.0

ip6-network = &lt;as per [RFC5952], Section 4>
            ; e.g., 2001:db8::cd30

Vergleichen Sie <ip> mit dem gegebenen Netzwerk. Wenn die High-Order-Bits der CIDR-Präfixlänge übereinstimmen, stimmt der Mechanismus überein.

Wenn ip4-cidr-length weggelassen wird, wird es als "/32" behandelt. Wenn ip6-cidr-length weggelassen wird, wird es als "/128" behandelt. Es ist nicht erlaubt, Teile der IP-Adresse wegzulassen, anstatt die CIDR-Notation zu verwenden. Das heißt, verwenden Sie 192.0.2.0/24 anstatt 192.0.2.

5.7 "exists"

Dieser Mechanismus wird verwendet, um einen beliebigen Domainnamen für eine DNS-A-Eintragsabfrage zu konstruieren. Er ermöglicht komplexe Schemata, die beliebige Teile des Mail-Envelopes einbeziehen, um zu bestimmen, was erlaubt ist.

exists = "exists" ":" domain-spec

<domain-spec> wird gemäß Abschnitt 7 erweitert. Der resultierende Domainname wird für eine DNS-A-RR-Abfrage verwendet (auch wenn der Verbindungstyp IPv6 ist). Wenn A-Einträge zurückgegeben werden, stimmt dieser Mechanismus überein.

Domains können diesen Mechanismus verwenden, um beliebig komplexe Abfragen anzugeben. Angenommen, example.com veröffentlicht den Eintrag:

v=spf1 exists:%\{ir}.%\{l1r+-}._spf.%\{d} -all

<target-name> könnte sich zu "1.2.0.192.someuser._spf.example.com" erweitern. Dies ermöglicht es, feingranulare Entscheidungen auf Benutzer- und Client-IP-Adressebene zu treffen.