Sender Policy Framework (SPF): La Chiave per Autenticare le Vostre Email e Combattere Spam e Phishing

L'invio di email è un pilastro fondamentale della comunicazione digitale, ma porta con sé anche significative vulnerabilità. Gli indirizzi dei mittenti vengono spesso falsificati o utilizzati in modo improprio dai truffatori per scopi di spam e phishing. Questo fenomeno, noto come "spoofing", mina la fiducia degli utenti e può avere conseguenze devastanti per le aziende, che rischiano di perdere la fiducia dei clienti e subire un danno alla reputazione del marchio che potrebbe essere irreparabile. La buona notizia è che il record di posta elettronica SPF, noto anche come Sender Policy Framework, può rappresentare la linea di difesa più forte.

Cos'è il Sender Policy Framework (SPF)?

Il Sender Policy Framework (SPF) è un protocollo di autenticazione delle email progettato per prevenire lo spoofing del mittente. In parole semplici, SPF consente al proprietario di un dominio di pubblicare un record nel proprio DNS (Domain Name System) che elenca quali server di posta elettronica, identificati tramite indirizzo IP o nome host, sono autorizzati a inviare messaggi per conto di quel dominio. Consideratelo come un elenco di mittenti approvati, un meccanismo che impedisce la falsificazione e l’utilizzo improprio dell’indirizzo del mittente.

Il criterio SPF, definito nel record DNS, elenca i server di posta autorizzati a inviare messaggi per conto del vostro dominio. Immaginate di ospitare un evento esclusivo a cui possono accedere solo gli invitati. Da un punto di vista tecnico, SPF è un tipo di record TXT che viene pubblicato nel DNS del vostro dominio. Questo record informa i server di posta elettronica riceventi sulle fonti affidabili, garantendo che l’identità del vostro dominio non possa essere facilmente falsificata.

Il protocollo SPF di un dominio definisce quali indirizzi IP sono autorizzati a inviare messaggi di posta elettronica usando come mittente caselle di quel determinato dominio. Se l'IP o l'host, invece, non è presente, il controllo SPF fallisce. Per tutti i domini che utilizzano il servizio di posta Aruba, è attivo un controllo SOFT sul dominio mittente per i messaggi in entrata.

Come Funziona SPF: Un Processo Passo Dopo Passo

L'implementazione di SPF si basa su una serie di passaggi chiave che coinvolgono il proprietario del dominio e i server di posta riceventi:

1. Pubblicare un Record SPF nel Proprio DNS: Le fondamenta dell'SPF iniziano con il Domain Name System (DNS). Il DNS è l'infrastruttura che mappa i nomi di dominio leggibili dall'uomo, come ad esempio example.com, agli indirizzi IP che computer e server utilizzano per comunicare. Affinché l'SPF funzioni, il proprietario del dominio deve pubblicare un record SPF nel DNS del proprio dominio. La pubblicazione del record SPF è un primo passo obbligatorio. Senza di esso, non esiste un punto di riferimento per i server di posta in ricezione, il che significa che i controlli SPF non possono essere eseguiti.

2. Invio di un Messaggio Email: Questo passaggio è l'evento scatenante dell'intero flusso di lavoro di verifica SPF. 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. Tuttavia, se l'identità HELO è associata a nomi di host validi nel record SPF, allora il controllo può effettivamente proteggere l'identità HELO. Senza l'atto di invio e la dichiarazione del dominio nel percorso di ritorno (Return-Path), il server ricevente non ha nulla da convalidare.

3. Verifica dell'Indirizzo Return-Path: Questo campo è importante perché specifica dove devono essere restituiti i messaggi rimbalzati o non recapitabili. È importante notare che i controlli SPF si basano sull'indirizzo tecnico Return-Path, non sull'indirizzo "Da" visibile che appare nella casella di posta dell'utente. Gli aggressori cercano spesso di sfruttare questa differenza falsificando il campo "Da" visualizzato per ingannare i destinatari.

4. Ricerca del Record SPF del Dominio: Per farlo, il server di posta ricevente cerca il record SPF del dominio nel DNS. Il DNS, o Domain Name System, funziona come la rubrica pubblica di Internet, traducendo i nomi di dominio in informazioni che i server possono leggere. Il server cerca in particolare un record TXT che inizia con v=spf1, che contiene l'elenco dei server di invio autorizzati. Il DNS è un sistema che traduce nomi di dominio in indirizzi IP. 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.

5. Verifica dell'Indirizzo IP del Mittente: Il server ricevente confronta l'indirizzo IP del server da cui proviene il messaggio con l'elenco degli indirizzi IP autorizzati specificati nel record SPF del dominio mittente. Se l'indirizzo IP del mittente è presente nell'elenco autorizzato, il controllo SPF passa.

6. Determinare il Risultato dell'Autenticazione SPF: Dopo aver controllato il record SPF, il server ricevente determina il risultato dell'autenticazione. I risultati possibili includono:

   • Pass: L'indirizzo IP di invio è elencato come mittente autorizzato.
   • Neutral: Non viene fatta alcuna affermazione specifica sull'indirizzo IP di invio.
   • None: Non esiste un record SPF per il dominio, quindi non è possibile effettuare alcuna verifica.
   • Fail: L'indirizzo IP di invio non è autorizzato a inviare messaggi per conto del dominio.
   • SoftFail: Un risultato intermedio tra Neutral e Fail, spesso utilizzato per scopi di debugging. Indica che l'indirizzo IP potrebbe non essere autorizzato.
   • Temperror: Si verifica un errore temporaneo durante la verifica DNS.
   • Permerror: Si verifica un errore permanente, solitamente a causa di una sintassi errata nel record SPF.

7. Intervenire in Base ai Risultati: Il server di posta elettronica del destinatario agisce in base al risultato del controllo SPF e alla politica DMARC del dominio (se esistente). In caso di incongruenze, i destinatari possono decidere di rifiutare i messaggi in arrivo da origini non autorizzate prima ancora di ricevere il contenuto del messaggio. L'invio di newsletter tramite un server di posta non autorizzato viene interrotto. Se l'indirizzo non è autorizzato, il messaggio può essere considerato sospetto e potenzialmente rifiutato. Altrimenti, restituisce un messaggio del genere: "Error 550 - Message rejected because SPF check failed". Oppure il server può comunque accettarlo ma poi lo recapita nella posta indesiderata. La finalità è comunque quella di evitare il phishing.

La Storia e lo Sviluppo di SPF

L'idea di SPF è emersa in risposta alla crescente problematica dello spam e del phishing. Dana Valerie Lank è una figura chiave nello sviluppo del Sender Policy Framework (SPF), uno standard di autenticazione per la posta elettronica. L'importanza del suo lavoro è 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.

Nel giugno del 2003, Meng Weng Wong unì le specifiche RMX (Reverse MX) e DMP (Domain Message Protocol) alle modifiche suggerite da altri programmatori. 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. RMX è progettato per essere veloce e preciso, rendendo il processo di autenticazione semplice da debug e implementare.

All'inizio del 2004, l'IETF creò il gruppo di lavoro MARID (Mail Abuse Prevention Working Group) e mise insieme le proposte SPF dell'ASRG e CallerID di Microsoft, utilizzandole come basi per ciò che è oggi conosciuto come Sender ID. 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 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 Sender Policy Framework è apparso ufficialmente come standard sperimentale nel 2006. RFC 4408 è stato successivamente obsoleto da RFC 7208, che ha aggiornato e migliorato le specifiche originali di SPF.

Sintassi e Componenti di un Record SPF

Un record SPF viene pubblicato come record TXT nel DNS del dominio e ha una struttura specifica che i server di posta elettronica riceventi utilizzano per verificare i mittenti autorizzati. Le parti principali di un record SPF comprendono:

• v=spf1: Specifica la versione SPF utilizzata. Dovete indicare solo una stringa con il valore v=spf1.

• Meccanismi: Definiscono le regole per la verifica degli indirizzi IP o dei nomi host. I meccanismi più comuni sono:

  • a: Definisce il record DNS A del dominio come autorizzato. Se non specificato, viene utilizzato il dominio corrente.
  • mx: Definisce il record DNS MX del dominio come autorizzato.
  • ip4: Definisce l'intervallo di rete IPv4. Può essere utilizzato con il prefisso, che indica la lunghezza dell'intervallo. Se non viene specificato alcun prefisso, /32 è il valore predefinito.
  • ip6: Definisce l'intervallo di rete IPv6. Può essere utilizzato con il prefisso, che indica la lunghezza dell'intervallo. Se non viene specificato alcun prefisso, /128 è il valore predefinito.
  • exists: Controlla la validità di un record A per un dominio fornito. Questo meccanismo è utilizzato raramente.
  • include: Permette 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. 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.
  • all: Definisce la politica per tutte le altre fonti.

• Qualificatori: Indicano il grado di severità con cui il meccanismo deve essere applicato. Sono simboli che precedono i meccanismi:

  • + (Pass): Indica un risultato PASS (test superato). L'host è autorizzato a inviare un messaggio.
  • - (Fail): Indica un risultato FAIL (fallimento). L'host non è autorizzato a inviare un messaggio.
  • ~ (tilde, SoftFail): Indica un risultato SOFTFAIL. Rappresenta un risultato intermedio tra NEUTRAL e FAIL, che serve come aiuto per il debugging. L'host non è autorizzato a inviare un messaggio ma è in transizione (il meccanismo è a scopo di test).
  • ? (Neutral): Indica un risultato NEUTRAL. Non viene fatta alcuna affermazione specifica sull'indirizzo IP di invio.

• Modificatori: Forniscono istruzioni aggiuntive o eccezioni alle regole. I modificatori SPF sono progettati per consentire future estensioni al framework.

  • redirect=some.example.com: Questo modificatore può sostituire il meccanismo ALL e permette di collegarsi al record di policy di un altro dominio.
  • 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 un 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.

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.

La stringa di un record SPF non può superare i 255 caratteri. Per questo motivo, puoi dividerlo in diversi record che saranno inclusi nel record SPF principale tramite il meccanismo include.

SPF, DKIM e DMARC: Un Trio per la Sicurezza delle Email

Sebbene SPF sia uno strumento potente, spesso viene utilizzato in combinazione con altri protocolli di autenticazione per una protezione completa:

• DKIM (DomainKeys Identified Mail): Questo protocollo confronta, per ciascun invio, due chiavi (codici DKIM). DKIM utilizza firme crittografiche per verificare che il contenuto del messaggio non sia stato alterato durante il transito.
• DMARC (Domain-based Message Authentication, Reporting & Conformance): DMARC si basa su DKIM e SPF. Indica a un server di posta elettronica ricevente cosa fare in base ai risultati dopo aver controllato SPF e DKIM. Almeno uno di questi due metodi di autenticazione deve essere configurato affinché DMARC funzioni. I criteri DMARC sono archiviati nei record DMARC.

L'uso combinato di SPF, DKIM e DMARC è la risposta migliore allo spoofing. Insieme, questi protocolli creano un sistema robusto che autentica l'origine dell'email, verifica l'integrità del contenuto e fornisce indicazioni su come gestire i messaggi non autenticati.

Implementazione di SPF: Considerazioni e Best Practice

La creazione e la pubblicazione di un record SPF nel DNS del vostro dominio sono passaggi cruciali per l'implementazione. Potete utilizzare strumenti online gratuiti per generare il vostro record SPF o costruirlo manualmente in base ai vostri mittenti autorizzati e alla vostra politica.

Una volta pronto il record, dovete accedere al sistema di gestione DNS del vostro dominio, che in genere è fornito dalla società di registrazione del dominio o dal provider di hosting. Individuate le impostazioni DNS del vostro dominio e aggiungete un nuovo record TXT con il valore generato.

Evitate queste insidie comuni:

• Utilizzo di più record SPF: Combina tutti i servizi di invio in un unico record per evitare errori di convalida. È consentito un solo record SPF per dominio o sottodominio.
• Sintassi errata: Assicuratevi che la sintassi e l'uso dei meccanismi siano corretti per evitare l'invalidazione del record.
• Superamento del limite di 10 ricerche DNS: Mantenete i meccanismi al di sotto del limite di ricerca per garantire il corretto funzionamento dell'SPF. Ogni meccanismo include richiede almeno una ricerca DNS, e potrebbero essere necessarie altre ricerche se il valore include punta a risorse annidate. Se il numero di ricerche DNS è maggiore di 10, il messaggio non supera il controllo SPF con un errore permanente (permerror).
• Superamento dei limiti di caratteri: Rimanete entro i limiti di 255 caratteri per stringa e di dimensione complessiva del DNS.
• Utilizzo del tipo di record sbagliato: Pubblicate sempre l'SPF come record TXT (tipo 16), non come un tipo SPF deprecato (come il tipo 99, che è stato abbandonato).

La revisione, l'aggiornamento e la convalida periodica del record SPF tramite strumenti online sono essenziali per evitare gli errori più comuni e mantenere la protezione contro il phishing e lo spam.

SPF in Piattaforme di Posta Elettronica Popolari

Molti provider di servizi email e piattaforme di hosting offrono strumenti e guide per configurare SPF. Ad esempio, in Microsoft 365, il record TXT SPF viene spesso configurato automaticamente o sono fornite istruzioni per crearlo. Per i servizi di posta elettronica che non sono sotto il controllo diretto (ad esempio, i servizi di posta elettronica in blocco), è consigliabile usare un sottodominio (ad esempio, marketing.contoso.com) anziché il dominio di posta elettronica principale (ad esempio, contoso.com). Questo perché non si vuole che i problemi relativi alla posta inviata da tali servizi di posta elettronica influiscano sulla reputazione della posta inviata dai dipendenti nel dominio di posta elettronica principale. Ogni sottodominio usato per inviare messaggi di posta elettronica da Microsoft 365 richiede il proprio record TXT SPF.

Software anti-spam come SpamAssassin versione 3.0.0 e ASSP implementano il protocollo SPF.

Limiti e Considerazioni Aggiuntive

È importante notare che l'SPF autentica il server di invio, ma non verifica l'identità effettiva del mittente né il contenuto del messaggio. Pertanto, SPF da solo non è sufficiente per impedire completamente lo spoofing del dominio. È una misura necessaria ma non la soluzione definitiva contro lo spoofing e il phishing. Per il livello migliore di protezione della posta elettronica, è fondamentale configurare anche DKIM e DMARC come parte di una strategia di autenticazione della posta elettronica complessiva.

Inoltre, il meccanismo include consente di delegare la responsabilità dell'autenticazione a un altro dominio, ma se la politica del dominio incluso non supera il controllo, il processo di verifica continua con gli altri meccanismi definiti nel record SPF originale.

I principi di funzionamento di SPF 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. SPF non previene però la falsificazione dell'indirizzo del mittente indicato nel corpo del messaggio.

In conclusione, l'implementazione del Sender Policy Framework è un passo fondamentale per rafforzare la sicurezza delle comunicazioni via email, proteggendo il vostro dominio dallo spoofing e contribuendo a un ecosistema email più sicuro e affidabile.

tags: #spf #nelle #mail