2. Operational Overview (Panoramica operativa)

2.1 Publishing Authorization (Pubblicazione dell'autorizzazione)

I domini conformi SPF pubblicano record SPF validi come descritto nella sezione 3. Questi record autorizzano i MTA specificati ad utilizzare il nome di dominio associato nelle identità "HELO" e "MAIL FROM".

I risultati SPF possono essere utilizzati per effettuare determinazioni sia positive (la fonte è autorizzata) che negative (la fonte non è autorizzata). Se un ADMD sceglie di pubblicare un record SPF e desidera supportare i destinatari nelle decisioni di autorizzazione negativa, deve pubblicare un record che termina con "-all" o che reindirizza a un altro che lo fa; altrimenti, non può essere fatta alcuna determinazione definitiva sull'autorizzazione. La sezione 10 discute problemi potenziali e misure di mitigazione relative alle decisioni negative.

Gli ADMD che desiderano dichiarare che nessun host è autorizzato ad utilizzare il loro nome di dominio DNS nei comandi HELO o MAIL FROM durante le sessioni SMTP possono pubblicare un tale record SPF per i nomi di dominio che non sono né utilizzati nella parte dominio degli indirizzi e-mail né previsti per inviare e-mail.

Quando si apportano modifiche ai record SPF, bisogna prestare attenzione ad assicurare che vi sia un periodo di transizione durante il quale la vecchia politica rimane valida fino a quando tutte le e-mail legittime possano ragionevolmente essere supposte essere state verificate. La sezione 4.5.4.1 di [RFC5321] discute per quanto tempo i messaggi possono rimanere in transito. Sebbene le verifiche offline siano possibili, più la verifica è vicina al momento di trasmissione originale, più è probabile ottenere un risultato SPF corrispondente all'intento dell'ADMD mittente al momento dell'invio del messaggio.

2.2 Checking Authorization (Verifica dell'autorizzazione)

I destinatari di posta possono eseguire un insieme di verifiche SPF per ogni e-mail ricevuta. Una verifica SPF testa l'autorizzazione dell'host client a inviare posta con un'identità data. Tipicamente, tali verifiche sono eseguite dal MTA ricevente, ma possono essere eseguite altrove nella catena di elaborazione della posta finché le informazioni richieste sono disponibili e affidabili. Le identità "MAIL FROM" e "HELO" sono verificate rispettivamente secondo le sezioni 2.4 e 2.3.

Non è raccomandato verificare altre identità contro i record SPF versione 1 senza approvazione esplicita dell'ADMD pubblicante, poiché è noto che alcune situazioni danno risultati errati. Ad esempio, quasi tutte le mailing list riscrivono l'identità "MAIL FROM" (vedere sezione 10.3), ma alcune non modificano nessuna altra identità nel messaggio. I documenti che definiscono altre identità devono definire metodi di approvazione esplicita.

I destinatari di posta possono includere le verifiche SPF come parte di un insieme più ampio di test sulla posta in arrivo. I risultati di altri test possono influenzare se viene eseguita una particolare verifica SPF. Ad esempio, trovare l'indirizzo IP dell'host mittente in una whitelist locale può portare a saltare tutti gli altri test e accettare tutta la posta da quell'host.

Quando un destinatario di posta decide di eseguire una verifica SPF, deve utilizzare la funzione check_host() correttamente implementata (sezione 4) e valutare con i parametri corretti. Sebbene l'intero test sia opzionale, una volta presa la decisione di eseguirlo, deve essere eseguito come prescritto per preservare le semantiche corrette tra editori e destinatari.

Per eseguire il test, il destinatario di posta deve valutare la funzione check_host() con i parametri descritti nella sezione 4.1.

Sebbene domini non validi, mal formati o inesistenti portino le verifiche SPF a restituire "none" (poiché nessun record SPF viene trovato), la politica di molti MTA da tempo è di rifiutare le e-mail da tali domini, in particolare nel caso di "MAIL FROM" non valido. Rifiutare l'e-mail previene un modo per aggirare i record SPF.

Le implementazioni devono prestare attenzione ad estrarre correttamente il <domain> dai dati forniti con il comando SMTP MAIL FROM, poiché molti MTA accettano ancora cose come il source routing (vedere appendice C di [RFC5321]), il %-hack (vedere [RFC1123]) e i percorsi bang (vedere [RFC1983]). Queste caratteristiche obsolete sono state utilizzate in modo malevolo per aggirare i sistemi di sicurezza.

2.3 The "HELO" Identity (L'identità "HELO")

Si raccomanda che i verificatori SPF non solo verifichino l'identità "MAIL FROM" ma verifichino anche l'identità "HELO" separatamente applicando la funzione check_host() (sezione 4) all'identità "HELO" come <domain>. La verifica di "HELO" può favorire risultati coerenti e può ridurre l'uso delle risorse DNS. Se può essere fatta una determinazione definitiva su un messaggio sulla base della verifica di "HELO", le risorse DNS per elaborare il "MAIL FROM" normalmente più complesso possono essere evitate. Inoltre, poiché i record SPF pubblicati per l'identità "HELO" si riferiscono a un singolo host, quando disponibili, sono una fonte molto affidabile dello stato di autorizzazione dell'host. Se entrambi devono essere verificati, si raccomanda di verificare prima "HELO" e poi "MAIL FROM".

Si noti che i requisiti sul dominio presentato nel comando EHLO o HELO per i mittenti non sono sempre chiari, e i verificatori SPF devono essere preparati al fatto che l'identità sia un letterale di indirizzo IP (vedere sezione 4.1.3 di [RFC5321]) o semplicemente mal formata. Questa verifica SPF può essere eseguita solo se la stringa "HELO" è un nome di dominio multi-etichetta valido.

2.4 The "MAIL FROM" Identity (L'identità "MAIL FROM")

Se la verifica "HELO" non è stata eseguita o non ha raggiunto un risultato di politica definitivo, il verificatore SPF deve verificare l'identità "MAIL FROM" applicando la funzione check_host() all'identità "MAIL FROM" come <domain>.

[RFC5321] consente che il percorso inverso sia vuoto (vedere sezione 4.5.5 in [RFC5321]). In questo caso, non c'è una casella di posta del mittente esplicita, e tali messaggi possono essere assunti essere messaggi di notifica dal sistema di posta stesso. Quando il percorso inverso è vuoto, questo documento definisce l'identità "MAIL FROM" come la casella di posta composta dalla parte locale "postmaster" e dall'identità "HELO" (che può o non può essere stata verificata separatamente in precedenza).

2.5 Location of Checks (Posizione delle verifiche)

Le verifiche di autorizzazione dovrebbero essere eseguite durante l'elaborazione della transazione SMTP che riceve l'e-mail. Questo riduce la complessità nel determinare l'indirizzo IP corretto da utilizzare come input per check_host() e consente di restituire gli errori direttamente al MTA mittente tramite le risposte SMTP. L'appendice D di [RFC7001] offre una discussione più completa su questo argomento.

Le verifiche di autorizzazione sono eseguite durante la transazione SMTP al momento del comando MAIL e utilizzano il valore MAIL FROM e l'indirizzo IP del client. Eseguire verifiche in un momento successivo o con altri input può portare ai seguenti problemi:

Può essere difficile estrarre accuratamente le informazioni richieste da header potenzialmente falsificati.
Le e-mail legittime possono fallire la verifica di autorizzazione perché la politica del mittente è cambiata.

Generare notifiche di mancata consegna a identità falsificate che hanno fallito la verifica di autorizzazione costituisce normalmente backscatter, cioè notifiche di rifiuto moleste inutilizzabili. Gli operatori sono fortemente incoraggiati ad evitare tali pratiche. La sezione 2 di [RFC3834] descrive il backscatter e i problemi che causa.

2.6 Results of Evaluation (Risultati della valutazione)

La sezione 4 definisce check_host(), una definizione di funzione modello che utilizza gli input definiti sopra e la politica del mittente pubblicata nel DNS per arrivare a conclusioni sull'autorizzazione del client. I verificatori SPF implementano qualcosa di semanticamente equivalente alla funzione definita qui.

Questa sezione elenca e definisce brevemente le possibili uscite di questa funzione. Tuttavia, si noti che il protocollo non stabilisce requisiti normativi per il trattamento di un risultato particolare. Le opzioni di trattamento per ogni risultato sono discusse nella sezione 8.

2.6.1 None

Un risultato di "none" significa che (a) nessun nome di dominio DNS sintatticamente valido è stato estratto dalla sessione SMTP per essere utilizzato come <domain> da autorizzare, o (b) nessun record SPF è stato recuperato dal DNS.

2.6.2 Neutral (Neutrale)

Un risultato "neutral" significa che l'ADMD ha dichiarato esplicitamente di non affermare se l'indirizzo IP è autorizzato o meno.

2.6.3 Pass (Superato)

Un risultato "pass" è una dichiarazione esplicita che il client è autorizzato a iniettare posta con l'identità data.

2.6.4 Fail (Fallito)

Un risultato "fail" è una dichiarazione esplicita che il client non è autorizzato ad utilizzare il dominio nell'identità data.

2.6.5 Softfail (Fallimento morbido)

Un risultato "softfail" è una dichiarazione debole dell'ADMD pubblicante che l'host potrebbe non essere autorizzato. Non ha pubblicato una politica più forte e più esplicita che porterebbe a un "fail".

2.6.6 Temperror (Errore temporaneo)

Un risultato "temperror" significa che il verificatore SPF ha incontrato un errore transitorio (solitamente DNS) durante l'esecuzione della verifica. Un nuovo tentativo in un momento successivo può avere successo senza ulteriori azioni da parte dell'operatore DNS.

2.6.7 Permerror (Errore permanente)

Un risultato "permerror" significa che il record pubblicato del dominio non è stato interpretato correttamente. Questo indica una condizione di errore che richiede definitivamente l'intervento dell'operatore DNS per essere risolta.