Sender Policy Framework: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m Bot: niente spazi dopo l'apostrofo e modifiche minori |
m clean up |
||
Riga 1:
Il '''Sender Policy Framework''' ('''SPF''') è uno standard di [[autenticazione]] email progettato per prevenire la falsificazione degli indirizzi [[Posta elettronica|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.
Riga 16:
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 ː 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 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/</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 ː https://datatracker.ietf.org/doc/html/rfc4408</ref> sperimentale.
== Principi di funzionamento ==
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 [[
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,<ref name="rfc7208-txt">{{cita web|titolo=Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 |url=https://tools.ietf.org/html/rfc7208|autore=Scott Kitterman |anno=2014 |mese=aprile |editore=[[Internet Engineering Task Force|IETF]] |accesso=26 aprile 2014 }}</ref> 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|TXT]] per SPF è stato proposto come meccanismo alternativo di compatibilità per i software DNS che non lo supportavano. L'RFC sperimentale <nowiki>RFC 4408</nowiki><ref name=":0" /> stabiliva, nella sezione 3.1.1, che "''un nome di dominio conforme a SPF dovrebbe avere i record SPF di entrambi i tipi RR''".<ref name="rfc4408-txt">[https://tools.ietf.org/html/rfc4408 Wong, M., and W. Schlitt. RFC 4408, aprile 2006]</ref> La proposta di standard <nowiki>RFC 7208</nowiki><ref>L' '''<nowiki>RFC 7208</nowiki>''' 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.</ref> afferma che “''l'uso di tipi RR alternativi del DNS era supportato nella fase sperimentale di SPF ma è stato successivamente deprecato''”.<ref name="rfc7208-txt" />
Riga 27:
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 (posta elettronica)|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 ==
Riga 39:
# 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 record|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 ==
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'''
Riga 51:
# '''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 ==
Riga 61:
* '''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.
Riga 125 ⟶ 124:
* 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>
* 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)<ref>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'<nowiki>RFC 6409</nowiki>.</ref> (RFC 6409) o offrire [[Virtual Private Network|VPN]] o semplicemente non pubblicare un record SPF. Inoltre, SPF lega solo l'[[Simple Mail Transfer Protocol|SMTP]] Return-Path a MSA consentiti; gli utenti sono ancora liberi di utilizzare i loro indirizzi <nowiki>RFC 5322</nowiki><ref>L{{'}}'''<nowiki>RFC 5322</nowiki>''', 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, <nowiki>RFC 5322</nowiki> è una revisione della precedente <nowiki>RFC 2822</nowiki> e sostituisce anche la <nowiki>RFC 822</nowiki>, che era la prima specifica per il formato dei messaggi di testo nell'ambito della posta elettronica.</ref> 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,<ref>{{Cita web|url=http://www.taugh.com/mp/lmap.html |titolo=Problems with Designated Sender |editore=Taughannock Networks |accesso=16 dicembre 2009}}</ref> 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.
Riga 132 ⟶ 131:
== Distribuzione ==
Software anti-spam come [[SpamAssassin]] versione 3.0.0 e ASSP<ref>L{{'}}'''Anti-Spam SMTP Proxy (ASSP)''' è un software progettato per filtrare e bloccare le email di spam prima che raggiungano il server di posta del destinatario. Funziona come un proxy SMTP, posizionandosi tra il client di posta e il server di destinazione, e analizza il traffico email in tempo reale per identificare e gestire i messaggi indesiderati.
Caratteristiche principali di ASSP
Riga 170 ⟶ 169:
Utilizzo
Wildcat è utilizzato principalmente da organizzazioni che necessitano di un MTA robusto e personalizzabile per gestire le comunicazioni via email. La sua flessibilità lo rende adatto sia per piccole imprese che per grandi aziende con esigenze complesse.In sintesi, l'MTA Wildcat rappresenta una soluzione efficace per la gestione delle email, combinando funzionalità avanzate con un alto grado di personalizzazione.
Caratteristiche principali di Postfix
Riga 238 ⟶ 237:
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 ː 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 ==
|