Vai al contenuto

Sender Policy Framework

Da Wikipedia, l'enciclopedia libera.
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 progettato per prevenire la falsificazione degli indirizzi email durante l'invio di messaggi.

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-ceve 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) [1], 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

[modifica | modifica wikitesto]

Il concetto alla base di SPF fu menzionato per la prima volta nel 2000,[2] ma divenne realtà solo nel 2002, quando Dana Valerie Lank [3] 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” [4] di Hadmut Danisch e del “Designated Mailer Protocol” [5] di Gordon Fecyk.[6]

Nel giugno del 2003, Meng Weng Wong unì le specifiche RMX e DMP [7] alle modifiche suggerite da altri programmatori. Nei sei mesi successivi, vennero apportati numerosi cambiamenti e una vasta community si mise a lavorare su SPF.[8]

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 [9]e mise insieme le proposte SPF dell'ASRG e CallerID di Microsoft, utilizzandole come basi per ciò che è oggi conosciuto come Sender ID [10]. 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'RFC SPF venne pubblicato come RFC 4408 [11] sperimentale.

Principi di funzionamento

[modifica | modifica wikitesto]

Il Simple Mail Transfer Protocol consente a ogni computer di inviare e-mail senza alcuna verifica del mittente: il messaggio può dichiarare di provenire da un qualsiasi indirizzo di origine. Questo aspetto facilita l'operato degli spammer, poiché possono utilizzare indirizzi e-mail falsi, rendendo più difficile la tracciabilità dell'origine di un messaggio e più semplice nascondere la loro vera identità per sottrarsi alle responsabilità. L'uso di indirizzi mittente contraffatti permette ai messaggi di phishing di indurre i destinatari a rivelare informazioni private in risposta a un'e-mail apparentemente inviata da un'organizzazione affidabile, come una banca o un altro fornitore di servizi legittimi.

Il Sender Policy Framework (SPF) consente al proprietario di un dominio di definire le regole per identificare i server autorizzati a inviare e-mail con un indirizzo del mittente appartenente a quel dominio, utilizzando opportuni record TXT del Domain Name System (DNS). I destinatari possono confrontare la provenienza del messaggio con le regole SPF e, in caso di incongruenze, decidere di rifiutare i messaggi in arrivo da origini non autorizzate prima ancora di ricevere il contenuto del messaggio. I principi di funzionamento sono quindi simili a quelli delle "DNS-based blackhole lists" (DNSBL), con l'eccezione che SPF utilizza il sistema di delegazione dell'autorità del Domain Name System. La prassi attuale richiede l'uso di record in formato TXT,[12] proprio come nelle prime implementazioni. Nelle fasi iniziali della definizione, è stato registrato e reso disponibile un nuovo tipo di record (SPF, tipo 99), e l'uso dei record in formato TXT per SPF è stato proposto come meccanismo alternativo di compatibilità per i software DNS che non lo supportavano. L'RFC sperimentale RFC 4408 [11] stabiliva, nella sezione 3.1.1, che "un nome di dominio conforme a SPF dovrebbe avere i record SPF di entrambi i tipi RR".[13] La proposta di standard RFC 7208 [14] afferma che “l'uso di tipi RR alternativi del DNS era supportato nella fase sperimentale di SPF ma è stato successivamente deprecato”.[12]

L'indirizzo del mittente viene inviato all'inizio della comunicazione SMTP, all'interno delle informazioni di consegna del messaggio, detto tecnicamente envelope. Se il mail server verifica che tale dominio non può provenire da quel client, può comunicare un messaggio di rifiuto, facendogli generare un bounce message detto “messaggio di rimbalzo” verso l'indirizzo del mittente originale. L'SPF non previene però la falsificazione dell'indirizzo del mittente indicato nel corpo del messaggio. Gli spammer possono quindi inviare 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 vantaggio di SPF è che i possessori di indirizzi email utilizzati come mittenti falsificati non ricevono un numero elevato di messaggi di errore indesiderati e risposte automatiche. Quando i destinatari implementano SPF per specificare le fonti legittime dei loro messaggi, i ricevitori possono rifiutare immediatamente le email non autorizzate, riducendo così il fenomeno del backscatter.

L'SPF offre anche ulteriori benefici oltre all'identificazione delle email indesiderate. In particolare, se un mittente fornisce informazioni SPF valide, i ricevitori possono utilizzare risultati SPF positivi insieme a una whitelist per riconoscere i mittenti affidabili. Tuttavia, situazioni come sistemi compromessi o utenti che inviano email condivise possono limitare l'efficacia di questo approccio.

Le ragioni dell' implementazione

[modifica | modifica wikitesto]

Se un dominio pubblica un record SPF, è meno probabile che spammer e phisher riescano a inviare email fingendo che provengano da quel dominio, poiché le email falsificate vengono catturate con maggiore efficacia dai filtri antispam. Di conseguenza, un dominio protetto da SPF diventa meno attraente per spammer e phisher come indirizzo spoofed (falsificato). Questo riduce la probabilità che l'indirizzo venga inserito in una blacklist dai filtri antispam e, di conseguenza, aumenta le possibilità che le email legittime vengano consegnate correttamente, evitando così falsi positivi nei filtri. [15]

FAIL e l'inoltro

[modifica | modifica wikitesto]

Lo standard SPF impedisce l'inoltro di messaggi (plain message forwarding). Quando un dominio adotta una politica SPF restrittiva, i messaggi legittimi inviati a destinatari che inoltrano le loro email a terzi possono essere respinti o rimbalzati se si verificano tutte le seguenti condizioni:

  1. Chi inoltra il messaggio non modifica il return-path (cammino di ritorno).
  2. L'hop [16] successivo non include chi inoltra il messaggio nella propria whitelist.
  3. L'hop esegue un controllo SPF.

Questa è una caratteristica necessaria e fondamentale di SPF: i controlli effettuati oltre il "confine" del Mail Transfer Agent (MX) del destinatario possono funzionare solo in modo diretto.Chi pubblica una policy SPF deve essere consapevole del rischio che le email legittime possano essere respinte se non conformi alla policy definita. Pertanto, è consigliabile effettuare dei test fino a ottenere risultati soddisfacenti.

Test HELO

[modifica | modifica wikitesto]

L'identità HELO è un comando utilizzato nel protocollo 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

  1. Invio dell'email: Tu invii la stessa email a "cliente@example.com".
  2. Errore di consegna: Il server non riesce a consegnare l'email perché l'indirizzo è errato.
  3. Return-Path vuoto: In questo caso, il server non ha un Return-Path specificato, di solito contiene l'email del mittente al a cui vengono inviate le notifiche relative agli errori di consegna. Questo indirizzo è utilizzato dai server di posta per restituire messaggi di errore quando un'email non può essere consegnata, ad esempio a causa di un indirizzo errato o di un account bloccato (ad esempio, potrebbe essere configurato male o non impostato affatto).
  4. Messaggio di errore: Poiché il Return-Path è vuoto, il server non sa dove inviare il messaggio di errore e quindi non ti informa della mancata consegna.

Questo controllo è importante per garantire che l'identità del server che invia il messaggio sia autentica.Se viene utilizzata un'identità HELO falsificata, il risultato del controllo SPF sarà "NONE", il che non fornisce alcuna protezione.

Tuttavia, se l'identità HELO è associata a nomi di host validi nel record SPF, allora il controllo può effettivamente proteggere l'identità HELO. Questa funzionalità è stata sempre supportata come opzione per i destinatari e le specifiche più recenti di SPF raccomandano di verificare sempre l'HELO.

Questa verifica consente ai destinatari di inserire determinati mittenti in una whitelist se il risultato del controllo HELO è "PASS", oppure di respingere tutte le email se il risultato è "FAIL". Inoltre, questo meccanismo può essere integrato in sistemi di reputazione, poiché sia le whitelist che le blacklist sono esempi di sistemi di reputazione. Questa versione mantiene i concetti originali ma li presenta in modo più diretto e comprensibile.

Implementazione

[modifica | modifica wikitesto]

La conformità agli standard SPF comprende tre attività correlateː

  • Pubblicare una politica (policy): I domini e gli host specificano quali server possono inviare email a loro nome, assicurando che le comunicazioni siano riconosciute come legittime e provenienti da fonti autorizzate. Fanno ciò aggiungendo record addizionali alle loro informazioni DNS già esistenti: Ogni nome di dominio o host che possiede un record di tipo A (A record) o un record di tipo MX (MX record) è in grado di gestire la posta elettronica e dovrebbe avere anche un record SPF. Il record A serve a mappare un nome di dominio a un indirizzo IP, permettendo ai browser di localizzare il server web associato al dominio. D'altra parte, il record MX è fondamentale per l'instradamento delle email, poiché indica ai server di posta come e dove inviare i messaggi per quel dominio, garantendo così la corretta consegna delle email.
  • Questo è particolarmente importante se il dominio viene utilizzato per inviare email o come parte dell'argomento HELO/EHLO durante la comunicazione con i server di posta. Il record SPF definisce quali server sono autorizzati a inviare email per quel dominio, contribuendo a prevenire la falsificazione dell'indirizzo del mittente.
  • Record SPF per host non utilizzati per l'invio di email: Gli host che non inviano email dovrebbero pubblicare un record SPF che indichi qualcosa come "v=spf1 -all". Questa configurazione è altamente raccomandata per validare il record SPF tramite strumenti di testing disponibili sul sito del progetto SPF.
  • Utilizzo delle informazioni SPF da parte dei destinatari: I destinatari delle email eseguono query DNS semplici e ordinarie, che sono spesso memorizzate nella cache per migliorare le prestazioni. Interpretano le informazioni SPF come specificato nel record e agiscono in base al risultato ottenuto.
  • Gestione dell'inoltro delle email: L'inoltro di email non formattate non è consentito da SPF. Le alternative per gestire l'inoltro includono:
    • Remailing: Sostituire il mittente originale con uno appartenente al dominio locale.
    • Refusing: Rifiutare l'email, restituendo un messaggio di errore come "551 User not local; please try user@example.com".
    • Whitelisting: Aggiungere il server di destinazione a una lista bianca per evitare rifiuti futuri di messaggi inoltrati.
    • Sender Rewriting Scheme (SRS): Utilizzare un meccanismo che modifica l'indirizzo del mittente per risolvere problemi legati ai reindirizzamenti[17]

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 ː 

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 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 -all , che indica che tutti gli IP non autorizzati sono considerati non validi per l'invio di email per quel dominio.
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.
IP4 Se il mittente è in un range di indirizzi IPV4 dato, fa il match, ovvero che c'è una corrispondenza tra l'indirizzo IP del mittente e quelli autorizzati, confermando così che il mittente è legittimo.
IP6 Se il mittente è in un range di indirizzi IPV6 dato, fa il match, ovvero che c'è una corrispondenza tra l'indirizzo IP del mittente e quelli autorizzati, confermando così che il mittente è legittimo.
MX Se il nome di dominio ha un record MX che corrisponde all'indirizzo IP del mittente, significa che l'email proviene da uno dei server di posta autorizzati per quel dominio. In questo contesto, "fare il match" indica che c'è una corrispondenza tra l'indirizzo IP del mittente e i server di posta specificati nel record MX del dominio, confermando così la legittimità dell'email in arrivo.
PTR Se il nome di dominio ha un record PTR per l'indirizzo del client, significa che il server DNS può risolvere l'indirizzo IP del client in un nome di dominio. Se questo nome di dominio corrisponde a quello specificato nel record SPF, si verifica un "match", ovvero una corrispondenza, che indica che l'email proviene da una fonte autorizzata. Tuttavia, questo meccanismo è stato abbandonato a causa della sua lentezza e inaffidabilità, e non dovrebbe più essere utilizzato.[12]
EXISTS Se il nome di dominio si "risolve" verso qualsiasi indirizzo, significa che il server DNS è in grado di trovare un indirizzo IP associato a quel dominio. Se l'indirizzo IP del mittente corrisponde a quello ottenuto, si verifica un "match", ovvero una corrispondenza, che indica che l'email proviene da una fonte autorizzata. Questo meccanismo è utilizzato raramente. Insieme alle macro di parametri SPF, consente di creare match più complessi, come ad esempio le query DNSBL (DNS-based Blackhole List), che aiutano a identificare indirizzi IP noti per inviare spam.
INCLUDE Il meccanismo SPF consente di fare riferimento alla politica di un altro dominio attraverso la direttiva include. Quando un dominio include un altro dominio nel suo record SPF, significa che accetta le regole di autenticazione di quel dominio. Se la politica del dominio incluso è valida e accettabile, allora anche il meccanismo di inclusione viene considerato valido.Tuttavia, se la politica del dominio incluso non supera il controllo (ad esempio, se fallisce), il processo di verifica continua con gli altri meccanismi definiti nel record SPF originale. Questo approccio permette una certa flessibilità nella gestione delle politiche di invio delle email tra domini diversi.Per delegare completamente l'autenticazione a un'altra politica di dominio, si utilizza l'estensione di reindirizzamento (redirect). Questa estensione consente al dominio originale di delegare completamente la responsabilità dell'autenticazione a un altro dominio, rendendo quest'ultimo il principale punto di riferimento per le verifiche SPF. In questo modo, se il dominio reindirizzato ha una politica valida, tutte le email inviate da quel dominio saranno automaticamente considerate legittime.

Qualificatori

[modifica | modifica wikitesto]

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

  • +: indica un risultato PASS (test superato). Questo qualificatore può essere omesso; ad esempio, +mx è equivalente a mx.
  • ?: indica un risultato NEUTRAL. Questo viene interpretato come NONE (nessuna politica), il che significa che non si può determinare se l'email è autorizzata o meno.
  • ~ (tilde): indica un risultato SOFTFAIL, che serve come aiuto per il debugging. Rappresenta un risultato intermedio tra NEUTRAL e FAIL. Tipicamente, i messaggi che ricevono un SOFTFAIL vengono accettati ma contrassegnati come potenzialmente sospetti.
  • - (meno): indica un risultato FAIL (fallimento). In questo caso, l'email dovrebbe essere respinta, poiché non proviene da una fonte autorizzata.

Modificatori

[modifica | modifica wikitesto]

I modificatori SPF sono progettati per consentire future estensioni al framework. Attualmente, solo due modificatori definiti nell'RFC 4408 [11] sono stati ampiamente adottati:

  • exp=some.example.com: Questo modificatore restituisce il nome di un dominio che contiene un record TXT nel DNS. Questo record viene interpretato utilizzando la macro parametrizzazione SPF fornendo una messaggio esplicativo per i risultati di tipo FAIL. Tipicamente, il record contiene un URL aggiunto al codice di errore SMTP per fornire ulteriori dettagli sul motivo del fallimento. Tuttavia, questa funzionalità è utilizzata raramente.
  • redirect=some.example.com: Questo modificatore può sostituire il meccanismo ALL e permette di collegarsi al record di policy di un altro dominio. Utilizzando redirectsi semplifica la comprensione rispetto all'uso del meccanismo INCLUDE, poiché consente di delegare completamente l'autenticazione a un altro dominio senza dover specificare ulteriori meccanismi.

Questi modificatori offrono flessibilità nella gestione delle politiche SPF, ma la loro implementazione deve essere effettuata con attenzione per garantire l'efficacia del sistema di autenticazione delle email.

Gestione dell'errore

[modifica | modifica wikitesto]

Non appena le implementazioni del Sender Policy Framework (SPF) individuano errori di sintassi in una sender policy (politica del mittente), devono interrompere la valutazione e restituire un risultato di PERMERROR. Questo significa che il record SPF non è valido e non può essere utilizzato. Inoltre, devono ignorare i meccanismi errati che non possono funzionare come previsto; per esempio, include:bad.example e redirect=bad.example generano anch'essi un PERMERROR.

Un'altra misura di protezione prevede un limite massimo di dieci meccanismi di verifica DNS. Questo limite si applica a tutti i meccanismi, ad eccezione di IP4, IP6 e ALL. Le applicazioni possono interrompere la valutazione restituendo un esito di SOFTERROR se il tempo necessario per completare la verifica supera una soglia prestabilita, oppure se una verifica DNS scade (timeout). Tuttavia, devono restituire un PERMERROR se la procedura richiede, direttamente o indirettamente, più di dieci verifiche DNS. Ogni uso di redirect= conta anche verso questo limite.

Una tipica politica SPF potrebbe essere scritta come v=spf1 a -all. Questa configurazione può eseguire fino a tre richieste DNS: (1) una richiesta per il record TXT, (2) una richiesta per il record SPF (che è stato reso obsoleto dall'RFC 7208), e (3) una richiesta per i record A o AAAA. Quest'ultima richiesta conta come primo valore verso il limite di dieci. In questo esempio, è anche l'ultima richiesta, poiché ALL non richiede ulteriori ricerche DNS.

Come abbiamo già illustrato in precedenza la Sender Policy Framework (SPF) è un sistema di autenticazione delle email progettato per prevenire la falsificazione degli indirizzi email. Il PERMERROR è un errore permanente che indica che il record SPF è sintatticamente errato o non valido. Il SOFTERROR è un errore temporaneo che indica problemi nella valutazione, ma non invalida il record SPF, il DNS (Domain Name System) è un sistema che traduce nomi di dominio in indirizzi IP. L'RFC (Request for Comments) sono documenti pubblicati da esperti del settore che definiscono standard e protocolli per Internet.

Controversie

[modifica | modifica wikitesto]

Nel 2004, quando il ricercatore nel campo della sicurezza informatica Steven Michael Bellovin [18] scrisse una e-mail che trattava delle sue preoccupazioni relative a SPF.[19] 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 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..[12]
  • 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..[20]
  • Le forti preoccupazioni di Bellowin riguardavano le ipotesi alla base di SPF, ovverosia al 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 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) [21] (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 [22] 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,[23] 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 piuttosto 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 eliminare l'SPF tipo 99 a favore di un utilizzo continuo di record TXT.[24] 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.[25][26] 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[27] (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.[28]

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.[29] A partire dal 2013, più di sette milioni di domini adottano politiche SPF FAIL -all .[30]

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

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.[32] Questi risultati includevano anche politiche semplici come v=spf1 ?all.[33] 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.[34]

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).[35] 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".[36]

Note

[modifica | modifica wikitesto]
  1. ^ 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 ː https://kinsta.com/it/knowledgebase/record-spf/
  2. ^ SPF: First Public Mention 2000, su openspf.org. URL consultato il 28 agosto 2014 (archiviato dall'url originale il 30 gennaio 2015).
  3. ^ 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.
  4. ^ 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 ː https://citizendium.org/wiki/Reverse_MX
  5. ^ 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 ː https://www.marcoalbasini.com/2021/07/livello-applicazione-il-protocollo-smtp/
  6. ^ SPF: History/Pre-SPF, su openspf.org. URL consultato il 16 maggio 2009 (archiviato dall'url originale il 16 luglio 2011).
  7. ^ 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.
  8. ^ SPF: History/SPF-2003, su openspf.org. URL consultato il 16 maggio 2009 (archiviato dall'url originale il 18 gennaio 2008).
  9. ^ 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 ː https://www.ietf.org/
  10. ^ 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 attuale ː Nonostante 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 ː https://www.brevo.com/it/blog/guida-deliverability/
  11. ^ a b c L' RFC 4408 è un documento che definisce la prima versione del Sender Policy Framework (SPF), un protocollo di autenticazione delle email. Pubblicato nell'aprile 2006, RFC 4408 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 RFC 4408 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 check_host(), utilizzata dai client SPF per verificare l'identità del mittente confrontando l'indirizzo IP con i record autorizzati. Obsolescenza e Aggiornamentiː RFC 4408 è stato successivamente obsoleto da RFC 7208, che ha aggiornato e migliorato le specifiche originali di SPF. Tuttavia, RFC 4408 rimane un documento importante nella storia dello sviluppo delle tecnologie di autenticazione delle email e ha influenzato la creazione di standard successivi.In sintesi, RFC 4408 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 ː https://datatracker.ietf.org/doc/html/rfc4408
  12. ^ a b c d Scott Kitterman, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1, su tools.ietf.org, IETF, aprile 2014. URL consultato il 26 aprile 2014.
  13. ^ Wong, M., and W. Schlitt. RFC 4408, aprile 2006
  14. ^ L' RFC 7208 definisce il Sender Policy Framework (SPF), un protocollo per l'autorizzazione dell'uso dei nomi di dominio nelle email. Questo documento stabilisce come i domini possono specificare quali server di posta sono autorizzati a inviare email per loro conto, contribuendo a ridurre lo spam e le email di spoofing.
  15. ^ 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).
  16. ^ 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 ː https://www.proofpoint.com/it/threat-reference/email-spoofing
  17. ^ (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.»
  18. ^ 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 ː https://datascience.columbia.edu/people/steven-m-bellovin/
  19. ^ Steve Bellovin expresses doubts Archiviato il 13 aprile 2004 in Internet Archive. (Jan 2004)
  20. ^ SPF Information, su postmaster.aol.com, AOL Postmaster. URL consultato il 4 ottobre 2007 (archiviato dall'url originale l'8 luglio 2007).
  21. ^ I Mail Submission Agents (MSA), o message submission agents, sono programmi o software progettati per ricevere messaggi di posta elettronica da un Mail User Agent (MUA), come un client di posta elettronica, e collaborare con un Mail Transfer Agent (MTA) per la consegna dei messaggi. Utilizzano l'Extended Simple Mail Transfer Protocol (ESMTP), una variante del protocollo SMTP, come specificato nell'RFC 6409.
  22. ^ L'RFC 5322, intitolata "Internet Message Format", è uno standard che definisce la sintassi per i messaggi di posta elettronica inviati tra utenti su Internet. Pubblicata nel gennaio 2008, RFC 5322 è una revisione della precedente RFC 2822 e sostituisce anche la RFC 822, che era la prima specifica per il formato dei messaggi di testo nell'ambito della posta elettronica.
  23. ^ Problems with Designated Sender, su taugh.com, Taughannock Networks. URL consultato il 16 dicembre 2009.
  24. ^ 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.
  25. ^ S. Moonesamy, Obsoleting SPF RRTYPE, su DNSEXT Discussion List, IETF, 23 aprile 2013. URL consultato il 16 dicembre 2013.
  26. ^ 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.
  27. ^ Andrew Sullivan, The RRTYPE topic, su SPFBIS Discussion List, IETF, 29 maggio 2013. URL consultato il 16 dicembre 2013.
  28. ^ 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.
  29. ^ Qpsmtpd SPF plugin, su github.com, 2013. URL consultato il 14 giugno 2016 (archiviato dall'url originale il 29 giugno 2013).
  30. ^ SPF -all Domain Survey, su spf-all.com, 2013. URL consultato il 23 aprile 2013.
  31. ^ SPF Loses Mindshare, su circleid.com, 2005. URL consultato il 4 aprile 2011.
  32. ^ 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).
  33. ^ 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).
  34. ^ 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).
  35. ^ 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).
  36. ^ 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=142575504"