5. Mechanism Definitions (Definizioni dei meccanismi)

Questa sezione definisce due tipi di meccanismi: meccanismi di struttura del linguaggio di base e meccanismi di specifica del mittente.

I meccanismi di base facilitano la struttura del linguaggio. Non specificano un particolare tipo di schema di autorizzazione. I meccanismi di base sono i seguenti:

all
include

I meccanismi di specifica del mittente sono utilizzati per identificare un insieme di indirizzi <ip> che sono autorizzati o non autorizzati a inviare messaggi con <domain>. I meccanismi di specifica del mittente sono i seguenti:

a
mx
ptr (do not use)
ip4
ip6
exists

Le seguenti convenzioni si applicano a tutti i meccanismi che eseguono in qualsiasi momento un confronto tra <target-name> e un indirizzo IP:

Se non viene fornita alcuna lunghezza del prefisso CIDR nella direttiva, <target-name> viene confrontato con l'indirizzo IP per l'uguaglianza. (Qui, CIDR è il routing tra domini senza classi, descritto in [RFC4632].)

Se viene specificata una lunghezza del prefisso CIDR, solo il numero specificato di bit di ordine superiore di <target-name> viene confrontato con l'indirizzo IP per l'uguaglianza.

Quando un meccanismo recupera indirizzi host da confrontare con <ip>, vengono recuperati record "A" quando <ip> è IPv4 e vengono recuperati record "AAAA" quando <ip> è un indirizzo IPv6. Le implementazioni SPF su server IPv6 devono gestire sia i record "AAAA" che "A" per i client su indirizzi IPv6 mappati IPv4 [RFC4291]. Gli indirizzi IPv4 sono elencati solo nel record SPF con il meccanismo "ip4".

Diversi meccanismi dipendono da informazioni recuperate dal DNS. Per queste query DNS, se non diversamente specificato, se il server DNS restituisce un errore (RCODE né 0 né 3) o se la query scade, il meccanismo si arresta e il check_host() di livello superiore restituisce "temperror". Se il server restituisce "Name Error" (RCODE 3), la valutazione del meccanismo continua come se il server restituisse senza errori (RCODE 0) e zero record di risposta.

5.1 "all"

all = "all"

Il meccanismo "all" è un test che corrisponde sempre. Viene utilizzato come meccanismo più a destra nel record per fornire un valore predefinito esplicito.

Esempio:

v=spf1 a mx -all

I meccanismi dopo "all" non vengono mai testati. I meccanismi elencati dopo "all" devono essere ignorati. Quando un meccanismo "all" è presente nel record, qualsiasi modificatore "redirect" (Sezione 6.1) deve essere ignorato, indipendentemente dall'ordine relativo dei termini.

5.2 "include"

include = "include" ":" domain-spec

Il meccanismo "include" innesca una valutazione ricorsiva di check_host().

<domain-spec> viene espanso secondo la Sezione 7.
check_host() viene valutato con la stringa risultante come <domain>. I parametri <ip> e <sender> rimangono gli stessi della valutazione corrente di check_host().
La valutazione ricorsiva restituisce corrispondenza, non corrispondenza o errore.
Se restituisce corrispondenza, il meccanismo "include" utilizza il risultato appropriato (ad esempio, include o +include produce un risultato "pass", -include produce "fail").
Se restituisce non corrispondenza o errore, il check_host() genitore riprende l'elaborazione secondo la tabella seguente e ripristina il valore <domain> precedente.

Retrospettivamente, il nome "include" è stata una scelta sbagliata. Viene utilizzato solo il risultato di valutazione del record SPF riferito, piuttosto che includere letteralmente i meccanismi del record riferito nel primo record. Ad esempio, la valutazione di una direttiva "-all" nel record riferito non termina l'elaborazione complessiva e non porta necessariamente a un "fail" complessivo. (Nomi migliori per questo meccanismo sarebbero stati "if-match", "on-match", ecc.)

Il meccanismo "include" consente a un dominio di specificare più domini amministrativamente indipendenti. Ad esempio, il dominio di vanità "example.net" potrebbe inviare messaggi utilizzando i server dei domini amministrativamente indipendenti example.com ed example.org.

Example.net potrebbe dire

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

Questo indicherebbe a check_host() di verificare efficacemente i record di example.com ed example.org per un risultato "pass". Solo se l'host non è autorizzato da nessuno di questi due domini il risultato sarebbe "fail".

Se questo meccanismo corrisponde, non corrisponde o restituisce un'eccezione dipende dal risultato della valutazione ricorsiva di check_host():

+---------------------------------+---------------------------------+
| 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               |
+---------------------------------+---------------------------------+

Il meccanismo "include" è destinato a attraversare i confini amministrativi. Quando si rimane all'interno di una singola autorità amministrativa, "include" di solito non è la scelta migliore. Ad esempio, se example.com ed example.org sono gestiti dalla stessa entità e se l'insieme degli host autorizzati per entrambi i domini è "mx:example.com", allora example.org potrebbe specificare "include:example.com", ma sarebbe meglio specificare "redirect=example.com" o anche "mx:example.com".

Con il meccanismo "include", è possibile autorizzare un insieme amministrativamente esterno di host, ma la determinazione della politica del mittente rimane una funzione del record SPF del dominio originale (determinato dal meccanismo "all" in quel record). Il modificatore "redirect" è più appropriato per consolidare l'autorizzazione e la politica in un insieme comune da condividere all'interno di un ADMD. Redirect è più simile a un elemento di codice comune da condividere tra i record all'interno di un singolo ADMD. Gli host autorizzati e le politiche di un numero qualsiasi di domini possono essere controllati da un singolo record.

5.3 "a"

Questo meccanismo corrisponde quando <ip> è uno degli indirizzi IP di <target-name>. Per chiarire, questo significa che il meccanismo "a" corrisponde anche ai record AAAA.

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

Viene eseguita una query di indirizzo per <target-name> utilizzando il tipo di query (A o AAAA) appropriato per il tipo di connessione (IPv4 o IPv6). <ip> viene confrontato con gli indirizzi restituiti. Se un indirizzo corrisponde, il meccanismo corrisponde.

5.4 "mx"

Questo meccanismo corrisponde quando <ip> è uno degli host MX del nome di dominio.

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

check_host() esegue prima una query MX per <target-name>. Quindi esegue una query di indirizzo per ciascun nome MX restituito. <ip> viene confrontato con ogni indirizzo IP restituito. Per prevenire attacchi di negazione del servizio (DoS), devono essere rispettati i limiti di elaborazione definiti nella Sezione 4.6.4. Se viene superato il limite di query MX, viene restituito "permerror" e la valutazione termina. Se un indirizzo corrisponde, il meccanismo corrisponde.

Nota sugli MX impliciti: Se <target-name> non ha record MX, check_host() non deve assolutamente applicare la regola MX implicita di [RFC5321], cioè interrogare i record A o AAAA per lo stesso nome.

5.5 "ptr" (do not use) ("ptr" (non utilizzare))

Questo meccanismo testa se il mapping inverso DNS di <ip> esiste e punta correttamente a un nome di dominio all'interno di un dominio particolare. Questo meccanismo non dovrebbe essere pubblicato. Vedere le note alla fine di questa sezione per ulteriori informazioni.

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

Il nome per <ip> viene cercato utilizzando la seguente procedura:

Eseguire un mapping inverso DNS per <ip>: cercare il record PTR corrispondente in "in-addr.arpa.", se l'indirizzo è IPv4, o in "ip6.arpa.", se è IPv6.
Per ogni record restituito, validare il nome di dominio cercando il suo indirizzo IP. Per prevenire attacchi DoS, devono essere applicati i limiti di elaborazione PTR definiti nella Sezione 4.6.4. Se i limiti vengono superati, terminare l'elaborazione e il meccanismo non corrisponde.
Se <ip> è tra gli indirizzi IP restituiti, questo nome di dominio è validato.

Verificare tutti i nomi di dominio validati per vedere se corrispondono a <target-name> o sono sottodomini di <target-name>. Se ci sono corrispondenze, questo meccanismo corrisponde. Se non possono essere trovati nomi di dominio validati, o se nessun nome di dominio validato corrisponde o è un sottodominio di <target-name>, questo meccanismo non può corrispondere. Se si verifica un errore DNS durante l'esecuzione della query PTR RR, questo meccanismo non può corrispondere. Se si verifica un errore DNS durante l'esecuzione di una query A RR, questo nome di dominio viene saltato e la ricerca continua.

Questo meccanismo corrisponde quando:

<target-name> è un sottodominio del nome di dominio validato, o
<target-name> e il nome di dominio validato sono identici.

Ad esempio, "mail.example.com" è all'interno del dominio "example.com", ma "mail.bad-example.com" non lo è.

Nota: Questo meccanismo è lento, non affidabile come altri meccanismi in caso di errori DNS e impone un carico pesante sui server dei nomi .arpa. Se utilizzato, devono essere configurati record PTR appropriati per gli host del dominio e il meccanismo "ptr" dovrebbe essere uno degli ultimi meccanismi verificati. Dopo diversi anni di esperienza di distribuzione SPF, si è concluso che è inutile e dovrebbero essere utilizzate alternative più affidabili. Tuttavia, rimane parte del protocollo SPF, quindi le implementazioni check_host() conformi devono supportarlo.

5.6 "ip4" and "ip6" ("ip4" e "ip6")

Questi meccanismi testano se <ip> è contenuto in una rete IP data.

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

Confrontare <ip> con la rete data. Se i bit di ordine superiore della lunghezza del prefisso CIDR corrispondono, il meccanismo corrisponde.

Se ip4-cidr-length viene omessa, viene trattata come "/32". Se ip6-cidr-length viene omessa, viene trattata come "/128". Non è consentito omettere parti dell'indirizzo IP invece di utilizzare la notazione CIDR. Cioè, utilizzare 192.0.2.0/24 invece di 192.0.2.

5.7 "exists"

Questo meccanismo è utilizzato per costruire un nome di dominio arbitrario per una query di record DNS A. Consente schemi complessi che coinvolgono parti arbitrarie della busta del messaggio per determinare cosa è consentito.

exists = "exists" ":" domain-spec

<domain-spec> viene espanso secondo la Sezione 7. Il nome di dominio risultante viene utilizzato per una query DNS A RR (anche se il tipo di connessione è IPv6). Se vengono restituiti record A, questo meccanismo corrisponde.

I domini possono utilizzare questo meccanismo per specificare query arbitrariamente complesse. Ad esempio, supponiamo che example.com pubblichi il record:

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

<target-name> potrebbe espandersi a "1.2.0.192.someuser._spf.example.com". Ciò consente di prendere decisioni granulari a livello di utente e indirizzo IP del client.