Sender Policy Framework

Da Wikipedia, l'enciclopedia libera.
Vai alla navigazione Vai alla ricerca
Grammatica da correggere!
Questa voce o sezione sull'argomento informatica contiene errori ortografici o sintattici oppure è scritta in una forma migliorabile.
Commento: Per favore aiuta a chiarire i passaggi poco chiari, probabilmente frutto di una traduzione da revisionare
Contribuisci a correggerla secondo le convenzioni della lingua italiana e del manuale di stile di Wikipedia. Segui i suggerimenti del progetto di riferimento.

Il Sender Policy Framework (SPF) è uno standard di autenticazione email utilizzato per prevenire la falsificazione degli indirizzi email durante l'invio di messaggi. Lo scopo principale di SPF è fornire un meccanismo per verificare l'autenticità dell'origine di un'email, contribuendo così a combattere lo spam e il phishing. SPF consente ai proprietari di domini di specificare quali server sono autorizzati a inviare email a nome del loro dominio, riducendo il rischio di email contraffatte. Quando un server di posta riceve un'email, verifica l'indirizzo IP del server mittente con il record SPF associato al dominio del mittente. Se l'indirizzo IP del server non è autorizzato dal record SPF, il messaggio potrebbe essere considerato sospetto o respinto. SPF supporta istruzioni di controllo, come "SOFTFAIL" (ammesso con avvertimento) o "FAIL" (rifiutato), in base alla corrispondenza tra l'indirizzo IP del mittente e il record SPF. SPF è uno strumento utile per ridurre la falsificazione degli indirizzi email, ma è spesso utilizzato in combinazione con altri metodi di autenticazione, come DomainKeys Identified Mail (DKIM) e Domain-based Message Authentication, Reporting, and Conformance (DMARC), per migliorare la sicurezza delle email.

Storia[modifica | modifica wikitesto]

Il concetto alla base di SPF fu menzionato per la prima volta nel 2000,[1] ma divenne realtà solo nel 2002, quando Dana Valerie Lank pubblicò indipendentemente dalla prima menzione un abbozzo di specifica SPF nella mailing list “namedroppers” della IETF. Il giorno successivo, Paul Vixie pubblicò la propria versione di specifica SPF sulla stessa lista. Queste pubblicazioni suscitarono molto interesse, finendo con il portare alla costituzione del Gruppo di Ricerca Anti-Spam (Anti-Spam Research Group, ASRG) e della corrispondente mailing list, dove l'idea di SPF venne discussa da un gruppo di iscritti che sembrava crescere esponenzialmente di giorno in giorno. Tra le proposte presentate all'ASGR ci furono quelle del “Reverse MX” di Hadmut Danisch e del “Designated Mailer Protocol” di Gordon Fecyk.[2]

Nel giugno del 2003, Meng Weng Wong unì le specifiche RMX e DMP[3] alle modifiche suggerite da altri programmatori. Nei successivi sei mesi vennero apportati un gran numero di cambiamenti e una numerosa community si mise a lavorare su SPF.[4]

In origine l'acronimo SPF doveva significare Sender Permitted From e a volte veniva anche chiamato SMTP+SPF, ma nel febbraio 2004 il suo nome venne cambiato nell'attuale Sender Policy Framework.

All'inizio del 2004, IETF creò il gruppo di lavoro MARID e mise insieme le proposte SPF di ASRG e CallerID di Microsoft, utilizzandole come basi per ciò che è oggi conosciuto come Sender ID. Dopo il fallimento di MARID, la comunità SPF ritornò alla versione originale di SPF e, nel luglio del 2005, la prima versione della specifica venne approvata dall'IESG come un esperimento IETF: la community venne invitata a osservare e studiare SPF nei due anni successivi alla pubblicazione. Il 28 aprile 2006 l'RFC SPF venne pubblicato come RFC 4408 sperimentale.

Principi di funzionamento[modifica | modifica wikitesto]

Il Simple Mail Transfer Protocol permette a ogni computer di inviare e-mail senza verifica del mittente: il messaggio può dichiarare di provenire da un qualsiasi indirizzo di origine. Ciò consente agli spammer l'uso di indirizzi e-mail falsi, rendendo più difficoltosa la tracciatura dell'origine di un messaggio e più facile nascondere la loro vera identità, allo scopo di sottrarsi alle loro responsabilità. L'uso di indirizzi mittente contraffatti consente ai messaggi di phishing di indurre i destinatari a rivelare informazioni private in risposta a un'e-mail apparentemente inviata da una organizzazione affidabile come una banca o un altro fornitore di servizi legittimi.

SPF consente al proprietario di un dominio di definire le regole per identificare i server autorizzati a mandare e-mail con un indirizzo del mittente in quel dominio, utilizzando opportuni record TXT del Domain Name System (DNS). I destinatari sono in grado di confrontare la provenienza del messaggio con le regole SPF e, in caso di problemi, possono decidere di rifiutare i messaggi in arrivo da origini non autorizzate già prima di ricevere il contenuto del messaggio. I principi di funzionamento sono perciò similari a quelli delle "DNS-based blackhole lists" (DNSBL), ad eccezione del fatto che SPF utilizza lo schema di delegazione dell'autorità appartenente al Domain Name System. La pratica corrente richiede l'uso di record TXT,[5] proprio come nelle prime implementazioni. Nelle fasi iniziali di definizione venne registrato e reso disponibile un nuovo tipo di record (SPF, tipo 99) e l'uso di record TXT per SPF venne proposto come meccanismo alternativo di compatibilità per i software DNS che non lo supportavano. L'RFC sperimentale RFC 4408 stabiliva, nella sezione 3.1.1, che "un nome di dominio conforme a SPF dovrebbe avere i record SPF di entrambi i tipi RR".[6] La proposta di standard RFC 7208 afferma che “l'uso di tipi RR alternativi del DNS era supportato nella fase sperimentale di SPF ma è stato successivamente deprecato”.[5]

L'indirizzo del mittente viene trasmesso all'inizio del dialogo SMTP, nell'envelope. Se il mail server verifica che tale dominio non può provenire da quel client, può comunicare un messaggio di rifiuto, facendogli generare un “messaggio di rimbalzo” (bounce message) verso l'indirizzo del mittente originale. SPF non previene però la falsificazione dell'indirizzo del mittente indicato nel corpo del messaggio. Gli spammer possono quindi mandare e-mail che possono superare il controllo SPF, se hanno un account in un dominio con una sender policy valida oppure approfittare di un sistema compromesso. Tuttavia, fare ciò rende lo spam più difficile da identificare.

Il principale beneficio di SPF è che possessori di indirizzi e-mail che sono stati usati come mittenti falsificati non ricevono grandi quantità di messaggi di errore indesiderati e altre risposte automatiche. Se tali destinatari usano SPF per specificare quali sono le sorgenti legittime dei loro messaggi, i ricevitori possono rifiutare immediatamente i messaggi falsi, così da ridurre o eliminare il backscatter.

SPF ha potenzialmente altri vantaggi, al di là del fatto di aiutare l'identificazione di mail indesiderata. In particolare, se un mittente fornisce le informazioni SPF, i ricevitori possono usare i risultati SPF positivi in combinazione con una whitelist per identificare i mittenti affidabili conosciuti. Scenari tipo sistemi compromessi e/o utenti che inviano mail condivise limitano questo tipo di utilizzo.

Ragioni di implementazione[modifica | modifica wikitesto]

Se un dominio pubblica un record SPF, è meno probabile che spammer e phisher possano inviare e-mail fingendo che provengano da quel dominio, perché le email falsificate vengono catturate dai filtri antispam con più probabilità. Perciò un dominio protetto da SPF è meno interessante per spammer e phisher come “spoofed address” (falso indirizzo). Questo comporta che è meno probabile che l'indirizzo venga inserito in una blacklist dai filtri anti-spam e perciò, in ultima analisi, aumenta la probabilità che una e-mail legittima venga consegnata e non sia vittima di falsi positivi dei filtri.[7]

FAIL e l'inoltro[modifica | modifica wikitesto]

SPF impedisce l'inoltro di messaggi (plain message forwarding). Quando un dominio pubblica una politica SPF restrittiva, i messaggi legittimi inviati ai destinatari inoltrando la loro mail a terzi possono essere respinti o rimbalzati se tutte le condizioni che seguono si verificano:

  1. colui che inoltra il messaggio non riscrive il return-path (cammino di ritorno).
  2. l'hop successivo non ha nella sua whitelist colui che inoltra il messaggio.
  3. l'hop esegue un controllo SPF.

Questa è una necessaria e ovvia caratteristica di SPF: i controlli dietro il “confine” MTA (MX) del destinatario possono funzionare solo in modo diretto.

Chi pubblica una policy SPF deve accettare il rischio che le e-mail legittime possano essere respinte se non sono conformi alla policy definita. Per questo è opportuno fare dei test, finché non si è soddisfatti dei risultati.

Test HELO[modifica | modifica wikitesto]

Per un Return-Path vuoto usato nei messaggi di errore e in altre risposte automatiche, un controllo SPF della identità HELO è obbligatorio.

Con una finta identità HELO il risultato NONE non aiuta, ma per nomi di host SPF validi protegge la identità HELO. Questa caratteristica SPF è sempre stata supportata come opzione per i destinatari, e successivi schemi SPF, inclusa la specifica finale, raccomandano di verificare sempre l'HELO.

Questo consente ai destinatari di mettere in una white list determinati mittenti, basandosi su un HELO PASS, oppure di respingere tutte le mail dopo un HELO FAIL. Questo meccanismo può essere utilizzato anche in “sistemi di reputazione” (reputation system, qualsiasi white o black list è un caso semplice di reputation system).

Implementazione[modifica | modifica wikitesto]

La conformità con SPF si compone di 3 task correlati:

  • Pubblicare una politica (policy): Domini e host identificano le macchine autorizzate a spedire email per loro conto. Fanno ciò aggiungendo record addizionali alle loro informazioni DNS già esistenti: ogni nome di dominio o host che ha un record di tipo A (A record) o di tipo MX (MX record) dovrebbe avere un record SPF specificandone la politica se esso è utilizzato in un indirizzo email e/o come argomento HELO/EHLO. Gli host che non inviano mail dovrebbero avere un record SPF pubblicato che indichi una cosa del genere ("v=spf1 –all"). Questo è altamente raccomandato allo scopo di validare il record SPF usando degli strumenti (tool) di testing dei record tipo quelli forniti sulla pagina web del progetto SPF.
  • Controllare e utilizzare le informazioni SPF: I destinatari usano query DNS ordinarie, semplici, che sono tipicamente presenti nella memoria cache per accrescere la performance. I destinatari quindi interpretano le informazioni SPF come sono specificate e agiscono sul risultato ottenuto.
  • Rivedere ed eventualmente correggere l'inoltro della posta: l'inoltro di mail non "formattate" non è consentito da SPF. Le alternative sono:
    • Remailing (cioè rimpiazzare il mittente originario con uno appartenente al dominio locale);
    • Refusing (rifiutare, cioè rispondere 551 User not local; please try <user@example.com>);
    • Whitelisting, cioè mettere in una white list il server bersaglio, in modo tale che in futuro non rifiuti più un messaggio inoltrato;
    • Sender Rewriting Scheme, "schema di riscrittura del mittente", un meccanismo che manipola il mittente, ad esempio per risolvere alcuni problemi legati ai reindirizzamenti[8]

Quindi, la questione chiave in SPF sta nelle specifiche relative alle nuove informazioni DNS che i set di domini e destinatari usano. I record qui di seguito sono scritti utilizzando la sintassi tipica dei DNS: 

example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all"

"v=" definisce la versione di SPF utilizzata. Le parole che la seguono forniscono i meccanismi da usare per determinare se un dominio è idoneo a spedire le email. "ip4" e "a" specificano i sistemi che hanno il permesso di spedire messaggi per il dominio dato. L'"-all" alla fine specifica che, se il meccanismo appena definito non ha prodotto risultati, il messaggio dovrebbe venire respinto.

Meccanismi[modifica | modifica wikitesto]

Sono definiti otto meccanismi:

ALL fa sempre il match degli indirizzi; usato per I risultati di default come -all per tutti gli IP che non hanno fatto il match attraverso meccanismi precedenti.
A Se il nome di dominio ha un record di indirizzo (A o AAAA) che può essere 'risolto' verso l’indirizzo del mittente, fa il match.
IP4 Se il mittente è in un range di indirizzi IPV4 dato, fa il match.
IP6 Se il mittente è in un range di indirizzi IPV6 dato, fa il match.
MX Se il nome di dominio ha un record MX nella risoluzione dell’indirizzo del mittente, fa il match (cioè la mail arriva da uno dei mail server in entrata del dominio)
PTR Se il nome di dominio (PRT record) per l’indirizzo del client è presente nel dominio dato, e tale nome di dominio si ‘risolve’ verso l’indirizzo del client (forward-confirmed reverse DNS), fa il match. Questo meccanismo è stato deprecato e non dovrebbe più venir usato.[5]
EXISTS Se il nome di dominio dato si 'risolve' verso qualsiasi indirizzo, fa il match (indipendentemente dall’indirizzo verso cui si risolve). Questo meccanismo viene utilizzato raramente. Assieme al macro linguaggio SPF, esso offre dei match più complessi come per esempio le query DNSBL.
INCLUDE Fa riferimento alla politica di un altro dominio. Se la politica di questo altro dominio è accettabile, il meccanismo è approvato/accettabile anch’esso. Tuttavia, se la nuova politica, appena inclusa, fallisce, l’elaborazione continua. Per delegare completamente il meccanismo a un’altra politica di dominio,si deve utilizzare l’estensione di reindirizzamento ('redirect' extension).

Qualificatori[modifica | modifica wikitesto]

Ogni meccanismo può essere combinato con uno dei quattro qualificatori:

  • + per un risultato PASS (test superato). Può essere omesso; per esempio +mx equivale a mx.
  • ? per un risultato NEUTRAL (neutrale), che viene interpretato come NONE (nessuna politica).
  • ~ (tilde) per un risultato SOFTFAIL, inteso come un aiuto per il debugging, un risultato intermedio tra il NEUTRAL e il FAIL (fallimento). Tipicamente, i messaggi che ritornano un SOFTFAIL come risultato vengono accettati ma taggati.
  • - (meno) per un risultato FAIL (fallimento), la mail dovrebbe venire respinta (vedi sotto).

Modificatori[modifica | modifica wikitesto]

I modificatori hanno lo scopo di consentire future estensioni al framework. Ad oggi solo due modificatori definiti nel RFC 4408 sono stati ampiamente distribuiti:

  • exp=some.example.com restituisce il nome di un dominio con un record TXT del DNS (interpretato usando il macro linguaggio SPF) allo scopo di ottenere una spiegazione per I risultati FAIL—tipicamente si tratta di un URL che viene aggiunto al codice di errore SMTP. Questa feature è usata raramente.
  • redirect=some.example.com può essere utilizzato al posto del meccanismo ALL per collegarsi al policy record di un altro dominio. Questo modificatore è più facile da capire piuttosto che il similare meccanismo INCLUDE.

Gestione dell'errore[modifica | modifica wikitesto]

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. Devono anche saltare i meccanismi errati che non possono funzionare come previsto, e di conseguenza anche include:bad.example e redirect=bad.example causano un PERMERROR.

Un'altra tutela utilizza un massimo di dieci meccanismi di verifica DNS, cioè ogni meccanismo eccetto IP4, IP6 e ALL. Le applicazioni possono interrompere la valutazione con esito SOFTERROR quando ci vuole un tempo maggiore di una prefissata soglia, oppure una verifica DNS scade (andando in time out), ma essi devono comunque restituire PERMERROR quando la procedura richiede, direttamente o indirettamente, dmpiù di dieci verifiche. Ogni redirect= conta anche nei confronti di questo limite di elaborazione.

Una tipica politica SPF HELO v=spf1 a -all può eseguire fino a tre richieste DNS: (1) TXT, (2) SPF (reso obsoleto dal RFC 7208), e (3) A o AAAA. Questa ultima richiesta conta come primo valore verso il limite di 10. In questo esempio è anche l'ultima, perché ALL non ha bisogno di ricerca DNS.

Controversie[modifica | modifica wikitesto]

Nel 2004, Steven M. Bellovin scrisse una e-mail che trattava delle sue preoccupazioni relative a SPF.[9] Le più significative sono:

  • SPF originariamente utilizzava record TXT nel DNS, che si suppone siano testo in formato libero, senza semantica allegata. I sostenitori SPF ammisero che sarebbe stato meglio avere record specificamente designati per SPF, ma questa scelta è stata fatta per consentire una rapida implementazione di SPF. Nel luglio del 2005, IANA assegnò il Return Record di tipo 99 a SPF. Più tardi, l'uso di record SPF è stato interrotto, ed a partire da 2016, risulta ancora necessario utilizzare i record TXT .[5]
  • Al momento in cui ha scritto il suo messaggio non c'era consenso sul fatto che SPF fosse la strada giusta da percorrere. Alcuni dei principali provider di servizi e-mail non l'hanno inserito all'interno di questo schema. Finché non lo sarà fatto, non servirà di aiuto, né per i loro clienti (che costituiscono una parte consistente della popolazione di utenti) che per qualsiasi altro (perché i loro indirizzi potrebbero essere contraffatti). Fa notare che, poiché questa preoccupazione è stata evidenziata, Google Mail e AOL, tra gli altri, hanno abbracciato la politica SPF.[10]
  • Le forti preoccupazioni di Bellowin riguardavano le ipotesi alla base di SPF (il suo "modello semantico"). Quando si utilizza SPF, i record DNS SPF determinano come ad un mittente è consentito inviare messaggi, il che significa che è compito del proprietario del dominio il controllare come i mittenti sono autorizzati a inviare i messaggi. Le persone che fanno uso di indirizzi di posta elettronica "portatile" (come ad esempio indirizzi di posta elettronica creati da organizzazioni professionali) saranno tenuti a utilizzare il mittente SMTP del dominio del proprietario, che può anche non esistere. Le organizzazioni che forniscono questi indirizzi "portatili" potrebbero tuttavia creare i propri agenti di invio della posta (mail submission agents, MSAS) (RFC 6409) o offrire VPN o semplicemente non pubblicare un record SPF. Inoltre, SPF lega solo l'SMTP Return-Path a MSA consentiti; gli utenti sono ancora liberi di utilizzare i loro indirizzi RFC 5322 altrove.

Ci sono altre preoccupazioni circa l'impatto di un uso diffuso di SPF, in particolare l'impatto sulle varie forme legittime di email spoofing,[11] come i servizi di spedizione, l'uso del SMTP da parte di persone con identità multiple, e altro (come esempio, una persona che utilizza i server SMTP del proprio ISP a casa per inviare la posta con la loro e-mail del lavoro come indirizzo). D'altra parte, molti di questi usi possono essere "previsti" ma non "legittimi". In una certa misura questa è più una questione di proprietà e aspettative che una questione tecnica.

Il gruppo di lavoro IETF spfbis, con il compito di rielaborare le specifiche SPF puntando per lo stato "Proposta di standard" in una nuova RFC, durante l'aprile 2013 sembrava aver raggiunto un consenso per quanto riguarda il fatto di deprecare l'SPF tipo 99 a favore di un utilizzo continuo di record TXT.[12] Le persone del gruppo di lavoro DNSEXT si opposero fortemente a questo in una serie di discussioni email che riguardavano spfbis, dnsext e la discussione IETF in generale.[13][14] Il capo del gruppo di lavoro spfbis, richiese di porre fine a quel torrente di proteste, dal momento che la discussione sul tipo di record (RRTYPE), nel gruppo di lavoro, era già stata risolta molto tempo fa[15] (una mossa che è stata vista come un tentativo di mettere a tacere le proteste da parte di alcuni puristi DNS). Un progetto indipendente è stato proposto più tardi, e documenta come la ricorsione spuria di record TXT caratterizza l'attuale Internet.[16]

Distribuzione[modifica | modifica wikitesto]

Software anti-spam come SpamAssassin versione 3.0.0 e ASSP implementano SPF. Molti mail transfer agent (MTA) supportano direttamente SPF, come Courier, CommuniGate Pro, Wildcat, MDaemon, e Microsoft Exchange; o hanno patch o plug-ins disponibili che supportano SPF, compresi Postfix, Sendmail, Exim, qmail, e Qpsmtpd.[17] A partire dal 2013, più di sette milioni di domini adottano politiche SPF FAIL -all .[18]

Nell'agosto del 2005 è stato comunicato che EarthLink non avrebbe consentito ai domini ospitati la possibilità di inserire record SPF.[19]

In un sondaggio pubblicato nel 2007, il 5% dei domini .com e .net è risultato avere qualche tipo di politica SPF. Nel 2009, una indagine effettuata da Nokia Research, ha riportato che il 51% dei domini testati specificava una politica SPF.[20] Questi risultati includevano anche politiche semplici come v=spf1 ?all.[21] Nell'aprile 2007, BITS, una divisione del Financial Services Roundtable, pubblicò le raccomandazioni di sicurezza delle e-mail per i suoi membri, tra cui la distribuzione SPF.[22]

Nel 2008, il Messaging Anti-Abuse Working Group (MAAWG) pubblicò un documento relativo all'autenticazione delle email, coprendo anche la parte relativa a SPF, l'ID del mittente, e DomainKeys Identified Mail (DKIM).[23] Nel proprio documento "Sender Best Communication Practices", il MAAWG dichiarava: "Per lo meno, i mittenti dovrebbero incorporare record SPF per i propri domini di mail".[24]

Note[modifica | modifica wikitesto]

  1. ^ SPF: First Public Mention 2000, su openspf.org. URL consultato il 28 agosto 2014 (archiviato dall'url originale il 30 gennaio 2015).
  2. ^ SPF: History/Pre-SPF, su openspf.org. URL consultato il 16 maggio 2009 (archiviato dall'url originale il 16 luglio 2011).
  3. ^ Per un confronto tra RMX, DMP e SPF, è possibile consultare RMX and DMP compared Archiviato il 25 aprile 2008 in Internet Archive. sul sito storico di openspf.
  4. ^ SPF: History/SPF-2003, su openspf.org. URL consultato il 16 maggio 2009 (archiviato dall'url originale il 18 gennaio 2008).
  5. ^ a b c d Scott Kitterman, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1, su tools.ietf.org, IETF, april 2014. URL consultato il 26 aprile 2014.
  6. ^ Wong, M., and W. Schlitt. RFC 4408, aprile 2006
  7. ^ Why should I implement a SPF record on my domain?, su emailmanual.co.uk, Email Manual, May 2009. URL consultato il 1º gennaio 2010 (archiviato dall'url originale il 29 gennaio 2010).
  8. ^ (EN) open-spf.org, http://www.open-spf.org/SRS/. URL consultato il 27 ottobre 2022.
    «SPF "breaks" email forwarding. SRS is a way to fix it. SRS is a simple way for forwarding MTAs to rewrite the sender address. The original concept was published in draft-mengwong-sender-rewrite and further expanded on in a paper by Shevek.»
  9. ^ Steve Bellovin expresses doubts Archiviato il 13 aprile 2004 in Internet Archive. (Jan 2004)
  10. ^ SPF Information, su postmaster.aol.com, AOL Postmaster. URL consultato il 4 ottobre 2007 (archiviato dall'url originale l'8 luglio 2007).
  11. ^ Problems with Designated Sender, su taugh.com, Taughannock Networks. URL consultato il 16 dicembre 2009.
  12. ^ Murray Kucherawy, Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments, su tools.ietf.org, IETF, luglio 2012. URL consultato il 16 dicembre 2013.
  13. ^ S. Moonesamy, Obsoleting SPF RRTYPE, su DNSEXT Discussion List, IETF, 23 aprile 2013. URL consultato il 16 dicembre 2013.
  14. ^ Dan Schlitt, Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard, su IETF Discussion List, IETF, 29 agosto 2013. URL consultato il 16 dicembre 2013.
  15. ^ Andrew Sullivan, The RRTYPE topic, su SPFBIS Discussion List, IETF, 29 maggio 2013. URL consultato il 16 dicembre 2013.
  16. ^ John Klensin, Andrew SUllivan e Patrik Fältström, An IANA Registry for Protocol Uses of Data with the DNS TXT RRTYPE, su tools.ietf.org, IETF, agosto 2013. URL consultato il 16 dicembre 2013.
  17. ^ Qpsmtpd SPF plugin, su github.com, 2013. URL consultato il 14 giugno 2016 (archiviato dall'url originale il 29 giugno 2013).
  18. ^ SPF -all Domain Survey, su spf-all.com, 2013. URL consultato il 23 aprile 2013.
  19. ^ SPF Loses Mindshare, su circleid.com, 2005. URL consultato il 4 aprile 2011.
  20. ^ Nokia Research Report on SPF Adoption, su Fit.Nokia.com, Nokia, 19 settembre 2011. URL consultato il 5 aprile 2016 (archiviato dall'url originale il 20 settembre 2011).
  21. ^ Cricket Liu, Handicapping New DNS Extensions and Applications, su onlamp.com, ONLamp, January 2007. URL consultato il 4 ottobre 2007 (archiviato dall'url originale il 26 settembre 2007).
  22. ^ BITS Email Security Toolkit (PDF), su bitsinfo.org, BITS, April 2007. URL consultato il 13 giugno 2008 (archiviato dall'url originale il 15 maggio 2008).
  23. ^ Dave Crocker, Trust in Email Begins with Authentication (PDF), su maawg.org, MAAWG, March 2008. URL consultato il 28 luglio 2011 (archiviato dall'url originale il 29 gennaio 2013).
  24. ^ MAAWG Sender Best Communications Practices Executive Summary (PDF), su maawg.org, MAAWG, 7 ottobre 2011. URL consultato il 27 aprile 2012.

Voci correlate[modifica | modifica wikitesto]

Collegamenti esterni[modifica | modifica wikitesto]

  Portale Sicurezza informatica
Estratto da "https://it.wikipedia.org/w/index.php?title=Sender_Policy_Framework&oldid=138677392"