Sender Policy Framework: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
Distribuzione: Segue revisioni editoriali-
Etichette: Modifica da mobile Modifica da web per mobile Modifica da mobile avanzata
Gestione dell'errore: Segue revisioni editoriali-
Etichette: Modifica da mobile Modifica da web per mobile Modifica da mobile avanzata
Riga 98:
 
== Gestione dell'errore ==
Non appena le implementazioni SPF individuano degli errori di sintassi in una sender policy (politica del mittente) devono interrompere la valutazione restituendo come risultato PERMERROR. SaltandoDevono anche saltare i meccanismi errati che non possono funzionare come previsto, e di conseguenza anche <kbd>include:bad.example</kbd> e <kbd>redirect=bad.example</kbd> causano un PERMERROR.
 
Un'altra tutela èutilizza ilun massimo di dieci meccanismi di interrogazioneverifica DNS, cioè ogni meccanismo eccetto IP4, IP6 e ALL. Le implementazioniapplicazioni possono interrompere la valutazione con esito SOFTERROR quando ci vuole troppoun tempo omaggiore di una prefissata soglia, oppure una queryverifica DNS scade (vaandando in time out), ma essi devono ritornarecomunque restituire PERMERROR sequando la politica haprocedura bisognorichiede, direttamente o indirettamente, di piùdmpiù di dieci query per i meccanismiverifiche. Ogni <kbd>redirect=</kbd> conta anche nei confronti di questo limite di elaborazione.
 
Una tipica politica SPF HELO <kbd>v=spf1 a -all</kbd> può eseguire fino a tre queryrichieste DNS: (1) TXT, (2) SPF (reso obsoleto dal [[RFC 7208]]), e (3) A o AAAA. Questa ultima queryrichiesta conta come il primo meccanismovalore verso il limite di 10. In questo esempio è anche l'ultima, perché ALL non ha bisogno di ricerca DNS.
 
== Controversie ==