|
Lo scopo principale dello SPF è fornire un meccanismo per verificare l'autenticità dell'origine di un'email, contribuendo così a combattere lo [[spam]] e il [[phishing]], inoltre lo SPF consente ai proprietari di domini di specificare, attraverso un record pubblicato nel DNS del loro dominio, quali [[server]] sono autorizzati a inviare email a nome del loro dominio.
Questo riduce significativamente il rischio di email contraffatte. Quando un server di posta ri-cevericeve un'email, esegue una ricerca DNS per recuperare il record SPF associato al dominio del mittente e verifica l'[[indirizzo IP]] del server mittente confrontandolo con le informazioni contenute in quel record. Se l'indirizzo IP del server non è autorizzato dal record SPF, il messaggio potrebbe essere considerato sospetto o addirittura rifiutato, a seconda delle politiche implementate dal server ricevente.
L'SPF supporta inoltre istruzioni di controllo come "SOFTFAIL" (ammesso con avvertimento) o "FAIL" (rifiutato), che determinano come gestire le email in base alla corrispondenza tra l'indirizzo IP del mittente e il record SPF. Sebbene SPF sia uno strumento utile per ridurre la falsificazione degli indirizzi email, è spesso utilizzato in combinazione con altri metodi di autenticazione, come [[DomainKeys Identified Mail]] (DKIM) e Domain-based Message Authentication, Reporting, and Conformance (DMARC)<ref>Il '''DMARC (Domain-based Message Authentication, Reporting, and Conformance)''' è un protocollo di autenticazione delle email che protegge contro la falsificazione degli indirizzi email (spoofing). Si basa su due standard preesistenti, SPF e DKIM, e richiede che il dominio nel campo "Da:" dell'email corrisponda a quello utilizzato nei controlli di autenticazione.
Funzionamento: Verifica: Controlla se l'email supera i test SPF e DKIM. Allineamento: Verifica la corrispondenza dei domini. Politica: Se non supera i controlli, si riferisce alla politica DMARC per decidere come gestire l'email (quarantena o rifiuto). Vantaggi: Protegge contro lo spoofing. Consente ai proprietari di domini di controllare la gestione delle email non autenticate. Fornisce report utili per monitorare tentativi di spoofing.In sintesi, DMARC migliora la sicurezza delle email e la reputazione dei domini. Fonte ːFonteː https://kinsta.com/it/knowledgebase/record-spf/</ref>, per migliorare ulteriormente la sicurezza delle email. Questa versione include dettagli aggiuntivi sul funzionamento di SPF e sul suo utilizzo nel contesto della sicurezza delle email.
== Storia ==
Il concetto alla base di SPF fu menzionato per la prima volta nel 2000,<ref>{{Cita web |url=http://www.openspf.org/History/Pre-SPF |titolo=SPF: First Public Mention 2000 |accesso=28 agosto 2014 |urlarchivio=https://web.archive.org/web/20150130122506/http://www.openspf.org/History/Pre-SPF |dataarchivio=30 gennaio 2015 |urlmorto=sì }}</ref> ma divenne realtà solo nel 2002, quando Dana Valerie Lank<ref>'''Dana Valerie Lank''' è una figura chiave nello sviluppo del Sender Policy Framework (SPF), uno standard di autenticazione per la posta elettronica. Nel 2002, Lank pubblicò un abbozzo della specifica SPF sulla mailing list "namedroppers" della IETF, contribuendo in modo significativo alla creazione di questo protocollo, che è progettato per prevenire la falsificazione degli indirizzi email e migliorare la sicurezza delle comunicazioni via email. .L'idea di SPF è emersa in risposta alla crescente problematica dello spam e del phishing. Attraverso SPF, i proprietari di domini possono 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 contro il record SPF pubblicato nel DNS del dominio per determinare se l'invio è autorizzato. .L'importanza del lavoro di Lank è evidenziata dal fatto che il suo contributo ha portato alla formazione del Gruppo di Ricerca Anti-Spam (ASRG), dove la specifica SPF è stata ulteriormente discussa e sviluppata. La sua iniziativa ha avuto un impatto duraturo sulle pratiche di autenticazione della posta elettronica e sulla sicurezza online.</ref> pubblicò, in modo indipendente, un abbozzo di specifica SPF nella [[mailing list]] “namedroppers” della [[IETF]]. Il giorno successivo, [[Paul Vixie]] pubblicò la propria versione della specifica SPF sulla stessa lista. Queste pubblicazioni suscitarono un grande interesse, portando 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'ASRG ci furono quelle del “Reverse MX”<ref>Il '''Reverse MX (RMX)''' è un metodo di autenticazione delle email sviluppato da Hadmut Danisch. Questo approccio si basa sull'idea di verificare l'autenticità degli indirizzi email attraverso l'uso di record DNS, consentendo di prevenire la falsificazione degli indirizzi dei mittenti nelle comunicazioni via SMTP. Principi Fondamentali del Reverse MX Autenticazione Basata su DNS: RMX utilizza record DNS per determinare se un server di posta è autorizzato a inviare email per un determinato dominio. Questo processo implica una serie di ricerche nel database, utilizzando sia l'indirizzo IP del mittente che l'indirizzo email fornito nel comando SMTP "MAIL FROM". Prevenzione della Falsificazione: A differenza di altri metodi anti-spam, RMX non analizza il contenuto del messaggio email, ma si concentra esclusivamente sull'indirizzo IP del server di invio e sull'indirizzo email del mittente. Ciò consente di rifiutare i messaggi non autorizzati prima della loro trasmissione. Semplicità e Velocità: RMX è progettato per essere veloce e preciso, rendendo il processo di autenticazione semplice da debug e implementare. Tuttavia, presenta limitazioni, come il fatto che non considera il contenuto dell'email stessa. Storia e Sviluppo Il Reverse MX è stato proposto nel contesto della ricerca anti-spam e ha contribuito alla creazione di standard più ampi come il Sender Policy Framework (SPF) e il Sender ID. Nel 2003, Meng Weng Wong ha combinato le specifiche del Reverse MX con quelle del Designated Mailer Protocol (DMP) per sviluppare una versione più completa dell'autenticazione delle email, che ha portato all'evoluzione dell'SPF come lo conosciamo oggi . In sintesi, il Reverse MX rappresenta un passo significativo nella lotta contro lo spam e la falsificazione delle email, fornendo un metodo diretto e efficace per autenticare i mittenti attraverso l'infrastruttura DNS. Fonte ːFonteː https://citizendium.org/wiki/Reverse_MX</ref> di Hadmut Danisch e del “Designated Mailer Protocol”<ref>Il '''Designated Mailer Protocol''' (DMP) è un metodo di autenticazione per la posta elettronica sviluppato da Gordon Fecyk. Questo protocollo è stato progettato per migliorare la sicurezza delle comunicazioni email, consentendo ai domini di specificare quali server sono autorizzati a inviare email a loro nome. Caratteristiche principali del DMP: '''Autenticazione''': Il DMP fornisce un meccanismo per autenticare l'origine delle email, riducendo il rischio di spoofing e phishing. Questo è particolarmente utile in un contesto in cui gli indirizzi email possono essere facilmente falsificati. '''Integrazione con altri protocolli''': Il DMP ha influenzato lo sviluppo di altri protocolli di autenticazione email, come il Sender Policy Framework (SPF) e DomainKeys Identified Mail (DKIM), che sono oggi ampiamente utilizzati per garantire la legittimità delle comunicazioni via email. '''Specifiche tecniche''': Il protocollo stabilisce regole chiare su come i server di posta devono gestire le email in uscita e come devono verificare l'autenticità dei mittenti, contribuendo a una gestione più sicura delle comunicazioni elettroniche. In sintesi, il Designated Mailer Protocol rappresenta un passo importante verso una maggiore sicurezza nelle comunicazioni via email, affrontando le vulnerabilità associate all'invio di messaggi falsificati. Fonte ːFonteː https://www.marcoalbasini.com/2021/07/livello-applicazione-il-protocollo-smtp/</ref> di Gordon Fecyk.<ref>{{Cita web |url=http://www.openspf.org/History/Pre-SPF |titolo=SPF: History/Pre-SPF |accesso=16 maggio 2009 |urlarchivio=https://web.archive.org/web/20110716065200/http://www.openspf.org/History/Pre-SPF |dataarchivio=16 luglio 2011 |urlmorto=sì }}</ref>
Nel giugno del 2003, Meng Weng Wong unì le specifiche RMX e DMP<ref>Per un confronto tra RMX, DMP e SPF, è possibile consultare [http://old.openspf.org/dmpvsrmx.html RMX and DMP compared] {{webarchive|url=https://web.archive.org/web/20080425222937/http://old.openspf.org/dmpvsrmx.html |data=25 aprile 2008 }} sul sito storico di openspf.</ref> alle modifiche suggerite da altri programmatori. Nei sei mesi successivi, vennero apportati numerosi cambiamenti e una vasta community si mise a lavorare su SPF.<ref>{{Cita web |url=http://www.openspf.org/History/SPF-2003 |titolo=SPF: History/SPF-2003 |accesso=16 maggio 2009 |urlarchivio=https://web.archive.org/web/20080118160547/http://www.openspf.org/History/SPF-2003 |dataarchivio=18 gennaio 2008 |urlmorto=sì }}</ref>
In origine, l'[[acronimo]] SPF doveva significare Sender Permitted From e a volte veniva anche chiamato SMTP+SPF; tuttavia, nel febbraio 2004 il suo nome venne cambiato nell'attuale Sender Policy Framework.
All'inizio del 2004, l'IETF creò il gruppo di lavoro MARID<ref>Il '''gruppo di lavoro MARID''' (MTA Authorization Records in DNS) è stato creato all'inizio del 2004 dall'Internet Engineering Task Force (IETF) con l'obiettivo di sviluppare specifiche per l'autenticazione dei mittenti di email. MARID ha cercato di combinare le proposte relative al Sender Policy Framework (SPF) provenienti dal Anti-Spam Research Group (ASRG) e il Caller ID proposto da Microsoft, utilizzandole come basi per un nuovo standard noto come Sender ID.Tuttavia, il gruppo MARID non ha raggiunto un consenso sufficiente e ha incontrato difficoltà nel definire uno standard accettabile, portando infine al suo fallimento. Dopo la chiusura di MARID, la comunità SPF è tornata a concentrarsi sulla versione originale di SPF, che ha continuato a evolversi e a essere adottata come standard nel settore della posta elettronica.Il lavoro del gruppo MARID ha avuto un impatto significativo nel promuovere la consapevolezza sull'importanza dell'autenticazione delle email, anche se non ha portato a uno standard ufficiale duraturo. Fonte ːFonteː https://www.ietf.org/</ref> e mise insieme le proposte SPF dell'ASRG e CallerID di [[Microsoft]], utilizzandole come basi per ciò che è oggi conosciuto come Sender ID<ref>Il '''Sender ID''' è una tecnologia di autenticazione delle email sviluppata da Microsoft, progettata per combattere lo spam e il phishing. Il suo obiettivo principale è verificare che le email inviate provengano effettivamente dal dominio dichiarato nel mittente, contribuendo così a garantire l'autenticità delle comunicazioni via email. Funzionamento di Sender ID. Sender ID utilizza un sistema di registrazione DNS simile a quello del Sender Policy Framework (SPF). I proprietari di domini possono pubblicare record DNS che specificano quali server sono autorizzati a inviare email per il loro dominio. Quando un server di posta riceve un'email, controlla il record DNS associato al dominio del mittente per verificare se l'indirizzo IP del server mittente è autorizzato. Se l'indirizzo non è autorizzato, il messaggio può essere considerato sospetto e potenzialmente rifiutato. Differenze rispetto a SPF. Sebbene Sender ID e SPF condividano obiettivi simili, ci sono differenze nel modo in cui operano e nel loro approccio. Mentre SPF si concentra principalmente sull'autenticazione dell'indirizzo IP del mittente, Sender ID si propone di verificare anche la corrispondenza tra l'indirizzo email e il dominio, migliorando ulteriormente la protezione contro le email contraffatte. Stato attualeattualeː ː Nonostantenonostante le sue potenzialità, Sender ID non ha raggiunto un'adozione universale come standard di autenticazione delle email. Molti provider di servizi email e organizzazioni continuano a utilizzare SPF come metodo principale per l'autenticazione delle email, anche se Sender ID rimane una tecnologia valida nel panorama della sicurezza delle comunicazioni elettroniche. Fonte ːFonteː https://www.brevo.com/it/blog/guida-deliverability/</ref>. Dopo il fallimento di MARID, la comunità SPF tornò alla versione originale di SPF e, nel luglio del 2005, la prima versione della specifica venne approvata dall'[[IESG]] come esperimento IETF: la [[community]] venne invitata a osservare e studiare SPF nei due anni successivi alla pubblicazione. Il 28 aprile 2006 l'[[Request for Comments|RFC]] SPF venne pubblicato come <nowiki>RFC 4408</nowiki><ref name=":0">L' '''<nowiki>RFC 4408</nowiki>''' è un documento che definisce la '''prima versione del Sender Policy Framework (SPF),''' un protocollo di autenticazione delle email. Pubblicato nell'aprile 2006, <nowiki>RFC 4408</nowiki> stabilisce le modalità attraverso cui un dominio può autorizzare esplicitamente gli host che sono permessi a inviare email per conto di quel dominio. Questo è particolarmente utile per prevenire lo spoofing delle email e migliorare la sicurezza delle comunicazioni via email. Principali Caratteristiche di <nowiki>RFC 4408</nowiki> Autenticazione: SPF consente ai server di posta di verificare se un'email proviene da un server autorizzato dal dominio dichiarato nel campo "MAIL FROM" dell'intestazione SMTP. Record DNS: I domini devono pubblicare record SPF nei loro DNS, specificando quali indirizzi IP o host sono autorizzati a inviare email per conto del dominio. Funzione di Controllo: La specifica include una funzione chiamata <code>check_host()</code>, utilizzata dai client SPF per verificare l'identità del mittente confrontando l'indirizzo IP con i record autorizzati. Obsolescenza e Aggiornamentiː <nowiki>RFC 4408</nowiki> è stato successivamente obsoleto da <nowiki>RFC 7208</nowiki>, che ha aggiornato e migliorato le specifiche originali di SPF. Tuttavia, <nowiki>RFC 4408</nowiki> rimane un documento importante nella storia dello sviluppo delle tecnologie di autenticazione delle email e ha influenzato la creazione di standard successivi.In sintesi, <nowiki>RFC 4408</nowiki> rappresenta una pietra miliare nel campo della sicurezza delle email, fornendo un framework per l'autenticazione dei mittenti e contribuendo a ridurre il rischio di frodi via email. Fonte ːFonteː https://datatracker.ietf.org/doc/html/rfc4408</ref> sperimentale.
== Principi di funzionamento ==
# Chi inoltra il messaggio non modifica il return-path (cammino di ritorno).
# L'hop<ref>Nel contesto della posta elettronica, il termine '''"hop"''' si riferisce a ogni passaggio che un messaggio di posta elettronica compie mentre viaggia da un server all'altro sulla rete. Ogni volta che un'email viene trasferita da un server di posta a un altro, si verifica un "hop". Fonte ːFonteː https://www.proofpoint.com/it/threat-reference/email-spoofing</ref> successivo non include chi inoltra il messaggio nella propria [[whitelist]].
# L'hop esegue un controllo SPF.
== Test HELO ==
L{{'}}'''identità HELO''' è un comando utilizzato nel protocollo [[Simple Mail Transfer Protocol|SMTP]] (Simple Mail Transfer Protocol) per avviare una sessione di invio email. Quando un client di posta elettronica si connette a un server di posta, invia il comando HELO seguito dal nome del dominio o dall'indirizzo IP del client stesso. Questo serve a identificare il mittente al server ricevente, stabilendo così una connessione tra i due. Quando un messaggio di errore o una risposta automatica utilizza un Return-Path vuoto , è necessario eseguire un controllo SPF sull'identità HELO.
'''Esempio di Return-Path vuoto'''
** '''Sender Rewriting Scheme (SRS)''': Utilizzare un meccanismo che modifica l'indirizzo del mittente per risolvere problemi legati ai reindirizzamenti<ref>{{Cita web|lingua=en|url=http://www.open-spf.org/SRS/|citazione=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.|accesso=27 ottobre 2022}}</ref>
Pertanto, la questione centrale nell'ambito dei record SPF riguarda le specifiche relative alle informazioni DNS che i set di domini e destinatari utilizzano. I record riportati di seguito sono formulati secondo la sintassi standard dei DNS ːDNSː
example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all"
Sono definiti otto ''meccanismi'':
{|
| valign="top" | ALL || Lo standard di autenticazione email SPF verifica sempre gli indirizzi IP dei server di posta in uscita. Quando un indirizzo non corrisponde a nessuno dei criteri precedentemente definiti, osia alle regole e alle autorizzazioni specificate nel record SPF di un dominio, viene applicato il risultato di default, come ad esempio <kbd>-all</kbd> , che indica che tutti gli IP non autorizzati sono considerati non validi per l'invio di email per quel dominio.
|-
| valign="top" | A - AAAA || Se il nome di dominio ha un record di indirizzo (A per IPV4 o AAAA per IV6) che corrisponde all'indirizzo IP del mittente, l'email è considerata valida. In altre parole, il sistema verifica se il server che ha inviato l'email è autorizzato a farlo controllando le informazioni DNS del dominio.
== Controversie ==
Nel 2004, quando il ricercatore nel campo della sicurezza informatica Steven Michael Bellovin<ref>'''Steven M. Bellovin''' è un importante ricercatore nel campo della sicurezza informatica e delle reti. È nato il 24 novembre 1955 a New York, negli Stati Uniti. Attualmente è professore nel dipartimento di informatica presso la Columbia University, ruolo che ricopre dal 2005. Prima di questo, ha lavorato come fellow presso AT&T Labs Research a Florham Park, New Jersey. Fonte ːFonteː https://datascience.columbia.edu/people/steven-m-bellovin/</ref> scrisse una e-mail che trattava delle sue preoccupazioni relative a SPF.<ref>[http://www.interesting-people.org/archives/interesting-people/200401/msg00037.html Steve Bellovin expresses doubts] {{webarchive|url=https://web.archive.org/web/20040413235149/http://www.interesting-people.org/archives/interesting-people/200401/msg00037.html |data=13 aprile 2004 }} (Jan 2004)</ref> Le più significative sono:
* La SPF (Sender Policy Framework) originariamente utilizzava record TXT nel DNS, progettati per contenere testo in formato libero, senza una specifica semantica. I sostenitori dell' SPF riconobbero che sarebbe stato preferibile avere record appositamente dedicati, ma questa scelta fu fatta per consentire una rapida implementazione del protocollo. Nel luglio del 2005, La [[Internet Assigned Numbers Authority|IANA]] (Internet Assigned Numbers Authority) assegnò il Return Record di tipo 99 a SPF. Tuttavia, l'uso di record SPF dedicati è stato successivamente abbandonato. A partire dal 2016, è ancora necessario utilizzare i record TXT per configurare le politiche SPF..<ref name="rfc7208-txt" />
* Quando Steve Michael Bellovin sollevò dubbi sull'adozione del Sender Policy Framework (SPF), non c'era ancora un generale consenso sulla sua efficacia come soluzione per l'autenticazione delle email. Alcuni dei principali provider di servizi email non avevano ancora implementato SPF nei loro sistemi. Finché questi provider non adotteranno SPF, il protocollo SPF non sarà utile né per i loro clienti, che rappresentano una parte significativa della popolazione di utentR, né per altri, poiché gli indirizzi email potrebbero continuare a essere contraffatti. È importante notare che, da quando questa preoccupazione è stata espressa, servizi come Google Mail e AOL hanno adottato la politica SPF..<ref>{{Cita web |url=https://postmaster.aol.com/spf/ |titolo=SPF Information |editore=AOL Postmaster |accesso=4 ottobre 2007 |urlarchivio=https://web.archive.org/web/20070708214600/http://www.postmaster.aol.com/spf/ |dataarchivio=8 luglio 2007 |urlmorto=sì }}</ref>
Utilizzo
Postfix è ampiamente utilizzato in molte distribuzioni Linux come MTA predefinito. È scelto da molti amministratori di sistema grazie alla sua facilità d'uso, configurabilità e robustezza. La sua architettura modulare e le funzionalità avanzate lo rendono adatto sia per piccole che grandi installazioni.In sintesi, Postfix rappresenta una soluzione affidabile e sicura per la gestione delle email, combinando prestazioni elevate con una configurabilità flessibile. Fonte ːFonteː https://www.extraordy.com/funzionamento-della-posta-elettronica-e-configurazione-di-postfix/</ref>, [[Sendmail]], Exim<ref>'''Exim''' è un mail transfer agent (MTA) open source altamente personalizzabile, progettato per il routing e la consegna delle email. È noto per la sua flessibilità e viene frequentemente utilizzato in ambienti aziendali grazie alle sue numerose funzionalità avanzate.
Caratteristiche principali di Exim
Gestione della coda di posta: Exim gestisce efficacemente le code di messaggi in arrivo e in uscita, permettendo la consegna immediata dei messaggi non appena vengono ricevuti, senza attendere la chiusura della connessione SMTP.
Supporto per domini virtuali: Exim può gestire più domini locali sulla stessa macchina, consentendo una gestione indipendente delle cassette postali per ciascun dominio. Fonte ːFonteː https://products.containerize.com/it/transactional-email/exim/</ref>, [[qmail]], e Qpsmtpd<ref>'''Qpsmtpd''' è un mail transfer agent (MTA) scritto in Perl, progettato per essere flessibile e facilmente estensibile. È noto per la sua architettura modulare che consente l'aggiunta di funzionalità tramite plugin, rendendolo altamente personalizzabile per soddisfare diverse esigenze di gestione della posta elettronica.
Caratteristiche principali di Qpsmtpd
Utilizzo
Qpsmtpd è utilizzato principalmente in ambienti dove è richiesta una gestione flessibile delle email, come nei server di posta per piccole e medie imprese. La sua capacità di essere esteso tramite plugin lo rende adatto a scenari specifici, dove le esigenze possono variare notevolmente.In sintesi, Qpsmtpd rappresenta una soluzione versatile per la gestione delle email, combinando un'architettura modulare con funzionalità avanzate per garantire una comunicazione sicura ed efficiente. Fonte ːFonteː https://github.com/smtpd/qpsmtpd</ref>, offrono patch o plug-in disponibili per il supporto di SPF.<ref>{{Cita web|url=https://github.com/qpsmtpd-dev/qpsmtpd-dev/blob/master/plugins/sender_permitted_from|titolo=Qpsmtpd SPF plugin|anno=2013|urlmorto=sì|accesso=14 giugno 2016|urlarchivio=https://archive.is/20130629083752/https://github.com/qpsmtpd-dev/qpsmtpd-dev/blob/master/plugins/sender_permitted_from#|dataarchivio=29 giugno 2013}}</ref> A partire dal 2013, oltre sette milioni di domini hanno adottato politiche SPF con il risultato FAIL <kbd>-all</kbd>.<ref>{{Cita web|url=http://spf-all.com/stats.html|titolo=SPF -all Domain Survey|anno=2013|accesso=23 aprile 2013}}</ref>
Nell'agosto del 2005, è stato annunciato che [[EarthLink]] non avrebbe consentito ai domini ospitati di inserire record SPF.<ref>{{Cita web|url=http://www.circleid.com/posts/spf_loses_mindshare/ |titolo=SPF Loses Mindshare |anno=2005|accesso=4 aprile 2011 }}</ref>
Incontri
MAAWG organizza incontri regolari in Nord America ed Europa per discutere questioni relative alla sicurezza della messaggistica e alle politiche pubbliche.In sintesi, il Messaging Anti-Abuse Working Group (MAAWG) è un'importante iniziativa collaborativa che mira a combattere l'abuso online attraverso l'innovazione, la cooperazione e la condivisione delle migliori pratiche tra i leader del settore. Fonte ːFonteː https://www.m3aawg.org/italian</ref> pubblicò un documento sull'autenticazione delle email, che trattava anche di SPF, ID del mittente e [[DomainKeys Identified Mail]] (DKIM).<ref>{{Cita web |url=https://www.maawg.org/sites/maawg/files/news/MAAWG_Email_Authentication_Paper_2008-07.pdf |titolo=Trust in Email Begins with Authentication |accesso=28 luglio 2011 |editore=[[MAAWG]] |nome=Dave |cognome=Crocker |data=maggio 2008 |formato=PDF |urlmorto=sì |urlarchivio=https://web.archive.org/web/20130129170525/http://www.maawg.org/sites/maawg/files/news/MAAWG_Email_Authentication_Paper_2008-07.pdf# |dataarchivio=29 gennaio 2013 }}</ref> Nel proprio documento "Sender Best Communication Practices", il MAAWG affermava: "Per lo meno, i mittenti dovrebbero incorporare record SPF per i propri domini di posta".<ref>{{Cita web|url=https://www.maawg.org/sites/maawg/files/news/MAAWG_Senders_BCP_Ver2a-updated.pdf |titolo=MAAWG Sender Best Communications Practices Executive Summary|accesso=27 aprile 2012 |editore=[[MAAWG]] |data=7 ottobre 2011 |formato=PDF }}</ref>
== Note ==
|
