Sender Policy Framework

Da Wikipedia, l'enciclopedia libera.

Sender Policy Framework (SPF) è un semplice sistema di validazione delle email progettato per individuare tentativi di email spoofing, fornendo un meccanismo tale da consentire a coloro che ricevono una mail di verificare che la mail in arrivo da un determinato dominio provenga da un host autorizzato dagli amministratori di dominio.[1] La lista degli host autorizzati ad inviare email per un determinato dominio è pubblicata nei record del Domain Name System (DNS) per quel dominio, sotto forma di record TXT appositamente formattato. Lo spam e il phishing spesso usano indirizzi del mittente falsi, di conseguenza la pubblicazione e la verifica di record SPF puo essere considerata una tecnica anti-spam. La pubblicazione RFC 7208 della IETF definisce la Sender Policy Framework.

Storia[modifica | modifica wikitesto]

Il concetto di SPF fu menzionato per la prima volta nel 2000 ma passò per lo più inosservato.[2] Il concetto non venne più menzionato, fino al 2002, quando Dana Valerie Lank (nata Green), ignara della menzione di due anni prima, pubblicò un primo tentativo 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, e alla fine condussero alla costituzione del Gruppo di Ricerca Anti-Spam (Anti-Spam Research Group, ASRG) e della loro mailing list, dove l'idea di SPF venne discussa da una base di abbonati che sembrava crescere esponenzialmente giorno dopo giorno. Tra le proposte presentate all' ASGR ci furono “Reverse MX” di Hadmut Danisch e “Designated Mailer Protocol” di Gordon Fecyk.[3]

Nel Giugno del 2003, Meng Weng Wong unì le specifiche RMX e DMP[4] e suggerimenti richiesti da altri programmatori. Nel corso dei successivi sei mesi un grosso numero di cambiamenti vennero fatti e una larga community cominciò a lavorare sulla SPF.[5]

Originariamente SPF stava per Sender Permitted From e a volte veniva anche chiamato SMTP+SPF, ma il suo nome venne cambiato con Sender Policy Framework nel Febbraio del 2004.

All'inizio del 2004, lo IETF creò il gruppo di lavoro MARID e provò a usare SPF e la proposta CallerID di Microsoft come basi per ciò che è oggi conosciuto come Sender ID.

Dopo il crollo del MARID, la comunità SPF ritornò alla versione “classica” originale di SPF. Nel Luglio del 2005, questa versione della secifica venne approvata dall' IESG come un esperimento IETF, invitando la community ad osservare e studiare SPF nei due anni successivi alla pubblicazione. Il 28 Aprile 2006, l' RFC SPF venne pubblicato come RFC 4408 sperimentale.

Principles of operation[modifica | modifica wikitesto]

Il Simple Mail Transfer Protocol permette ad ogni computer di inviare email sostenendo di provenire da un qualsiasi indirizzo di origine. Ciò viene sfruttato dagli spammers i quali spesso usano indirizzi email falsi, rendendo più difficoltosa la possibilità di tracciare l'origine di un messaggio, e più facile la possibilità di nascondere la loro vera identità, allo scopo di evitare responsabilità. Viene anche utilizzato per dar vita a tecniche di phishing, attraverso le quali gli utenti possono venire indotti a rivelare informazioni private in risposta a una falsa mail presumibilmente inviata da una organizzazione come una banca.

SPF consente al proprietario di un dominio Internet di specificare quali computer sono autorizzati a mandare mail con, come indirizzo del mittente, uno degli indirizzi in quel dominio, utilizzando i record del Domain Name System (DNS). I riceventi, verificando l'informazione SPF in record TXT, possono rifiutare i messaggi in arrivo da origini non autorizzate prima di ricevere il corpo 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,[6] proprio come nelle prime implementazioni. Per un po' un nuovo tipo di record (SPF, tipo 99) venne registrato e reso disponibile nei comuni software DNS. L'uso di record TXT per SPF venne ai tempi proposto come meccanismo tradizionale. L' RFC sperimentale, RFC 4408, sezione 3.1.1, indicò che "un nome di dominio conforme a SPF dovrebbe avere i record SPF di entrambi i tipi RR".[7] Lo standard proposto, RFC 7208, afferma che “l'uso di tipi RR alternativi del DNS era supportato nella fase sperimetale di SPF ma è stato successivamente interrotto”.[6]

L’indirizzo del mittente viene trasmesso all’inizio del dialogo SMTP. Se il server rifiuta il dominio, il client non autorizzato dovrebbe ricevere un messaggio di rifiuto, e se tale client era un mail server (message transfer agent, MTA) di inoltro, un “messaggio di rimbalzo” (bounce message) all’indirizzo del mittente originale può venire generato. Se il server accetta il dominio, e successivamente anche i destinatari e il corpo del messaggio, dovrebbe inserire un campo “Return-Path” (cammino di ritorno) nell’header del messaggio, in modo da salvare l’indirizzo del mittente. Mentre l’indirizzo nel Return-Path spesso accompagna gli altri indirizzi originatori nell’header della mail (come ad esempio quello del mittente), questo non è necessariamente il caso di tutti gli indirizzi, e infatti SPF non previene la falsificazione di questi altri indirizzi, come ad esempio quello del destinatario.

Gli spammer possono mandare email con come risultato un SPF PASS, se hanno un account in un dominio con una sender policy, o approfittare di un sistema compromesso in quel dominio. Tuttavia, fare ciò rende lo spammer più facile da tracciare.

Il principale beneficio di SPF appartiene ai possessori di indirizzi email che sono stati alterati/falsificati nel Return-Path. Essi ricevono grandi quantità di messaggi di errore indesiderati e altre risposte automatiche. Se destinatari del genere usano SPF per specificare i loro indirizzi IP sorgente come legittimi e indicare un risultato FAIL per tutti gli altri indirizzi, i ricevitori, verificando SPF, possono rifiutare i documenti falsi, così da ridurre o eliminare l’ammontare di 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 PASS in combinazione con una lista bianca 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 spammers e phishers riescano a falsificare le email fingendo che provengano da quel dominio, questo perché le email falsificate sono più probabili da catturare nei filtri spam che verificano il record SPF. Perciò un dominio SPF protetto è meno attrattivo per spammers e phishers. Dato che un dominio SPF protetto è meno attrattivo come “spoofed address” (falso indirizzo), è meno probabile che venga inserito in una blacklist dai filtri spam e perciò, in ultima analisi, la email legittima proveniente dal dominio in questione è più probabile da ottenere attraverso esso.[8]

FAIL and forwarding[modifica | modifica wikitesto]

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

  1. colui che inoltra il messaggio non riscrive il return-path (cammino di ritorno), a differenza delle mailing list.
  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 non possono funzionare in modo diretto.

Gli editori delle politiche di SPF FAIL devono accettare il rischio che le loro email legittime verranno respinte e/o rimbalzate. Dovrebbero fare test (per esempio attraverso una politica SOFTFAIL) finché non sono soddisfatti dei risultati. Vedi sotto per una lista di alternative al “plain message forwarding”.

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 più complicato che manipola le notifiche di routing di non-consegna al server originario.

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

Un'altra tutela è il massimo di dieci meccanismi di interrogazione DNS, cioè ogni meccanismo eccetto IP4, IP6 e ALL. Le implementazioni possono interrompere la valutazione con esito SOFTERROR quando ci vuole troppo tempo o una query DNS scade (va in time out), ma essi devono ritornare PERMERROR se la politica ha bisogno, direttamente o indirettamente, di più di dieci query per i meccanismi. 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 query DNS: (1) TXT, (2) SPF (reso obsoleto dal RFC 7208), e (3) A o AAAA. Questa ultima query conta come il primo meccanismo 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] Alcune di queste includono:

  • SPF originariamente utilizzava record TXT nel DNS, che si suppone siano testo in formato libero, senza semantica allegata. I sostenitori SPF ammisero tranquillamente 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, è ancora necessario utilizzare i record TXT .[6]
  • Al momento in cui ha scritto il suo messaggio non c'era consenso sul fatto che SPF era la strada giusta da percorrere. Alcuni dei principali provider di servizi e-mail non l’hanno portato all’interno di questo schema. Salvo e finché non lo facciano, non aiuterà molto, 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). Vale la pena far notare che, poiché questa preoccupazione è stata sollevata, Google Mail e AOL, tra gli altri, hanno abbracciato 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 quello di 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 "portable" 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, ecc (Per 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 feroci puristi DNS). Un progetto indipendente è stato proposto più tardi, il quale 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 pubblicano politiche SPF FAIL -all .[18]

Nell'agosto del 2005 si è appreso che EarthLink non avrebbe consentito ai domini ospitati l'abilità di inserire record SPF. [19]

In un sondaggio pubblicato nel 2007, il 5% dei domini .com e .net ha avuto un qualche tipo di politica SPF. Nel 2009, una indagine, per un periodo ininterrotto, a Nokia Research, riporta che il 51% dei domini testati specifica una politica SPF. [20] Questi risultati possono includere politiche banali 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 dichiara: "Per lo meno, i mittenti dovrebbero incorporare record SPF per i propri domini di mail". [24]

Note[modifica | modifica wikitesto]

  1. ^ Sender Policy Framework: Introduction, openspf.org.
  2. ^ SPF: First Public Mention 2000, openspf.org. URL consultato il 28 agosto 2014.
  3. ^ SPF: History/Pre-SPF, openspf.org. URL consultato il 16 maggio 2009.
  4. ^ For a comparison among RMX, DMP and SPF, see RMX and DMP compared on the historical openspf site.
  5. ^ SPF: History/SPF-2003, openspf.org. URL consultato il 16 maggio 2009.
  6. ^ a b c d Template:Cite IETF
  7. ^ Wong, M., and W. Schlitt. RFC 4408. April 2006 <http://tools.ietf.org/html/rfc4408>
  8. ^ Why should I implement a SPF record on my domain?, Email Manual, May 2009. URL consultato il 1º gennaio 2010 (archiviato dall'url originale il 29 gennaio 2010).
  9. ^ Steve Bellovin expresses doubts (Jan 2004)
  10. ^ SPF Information, AOL Postmaster. URL consultato il 4 ottobre 2007 (archiviato dall'url originale l'8 luglio 2007).
  11. ^ Problems with Designated Sender, Taughannock Networks. URL consultato il 16 dicembre 2009.
  12. ^ Template:Cite IETF
  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. ^ Template:Cite IETF
  17. ^ Qpsmtpd SPF plugin, github.com, 2013.
  18. ^ SPF -all Domain Survey, spf-all.com, 2013. URL consultato il 23 aprile 2013.
  19. ^ SPF Loses Mindshare, 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, ONLamp, January 2007. URL consultato il 4 ottobre 2007.
  22. ^ BITS Email Security Toolkit (PDF), BITS, April 2007. URL consultato il 13 giugno 2008.
  23. ^ Dave Crocker, Trust in Email Begins with Authentication (PDF), MAAWG, March 2008. URL consultato il 28 luglio 2011.
  24. ^ MAAWG Sender Best Communications Practices Executive Summary (PDF), MAAWG, 7 ottobre 2011. URL consultato il 27 aprile 2012.

Collegamenti esterni[modifica | modifica wikitesto]