|
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.
{{Correggere|informatica|Febbraio 2017|Per favore aiuta a chiarire i passaggi poco chiari, probabilmente frutto di una traduzione da revisionare}}
'''Sender Policy Framework''' ('''SPF''') è un sistema di validazione delle [[e-mail]] progettato per individuare tentativi di [[email spoofing]]. Il sistema consente, per le e-mail collegate ad un dominio, di poter definire gli host (server email) autorizzati a spedire messaggi di quel dominio. Così facendo consentono, quindi, al ricevente di controllarne la validità.<ref>{{Cita web|url= http://www.openspf.org/Introduction|titolo= Sender Policy Framework: Introduction|accesso= 14 giugno 2016|urlarchivio= https://web.archive.org/web/20160617212250/http://www.openspf.org/Introduction|dataarchivio= 17 giugno 2016|urlmorto= sì}}</ref> La lista degli host autorizzati a inviare e-mail per un determinato dominio è pubblicata nel [[Domain Name System]] (DNS) sotto forma di [[record TXT]] appositamente formattati. Il [[phishing]], e talvolta anche lo [[spam]], utilizzano indirizzi mittente falsi, cosicché la pubblicazione e la verifica di record SPF possono essere considerate in parte tecniche anti-spam. La Sender Policy Framework è definita nella pubblicazione RFC 7208 di [[IETF]].
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 riceve un'email, esegue una ricerca DNS per recuperare il record SPF associato al dominio del mittente e verifica l'[[indirizzo IP]] del server mittente confrontandolo con le informazioni contenute in quel record. Se l'indirizzo IP del server non è autorizzato dal record SPF, il messaggio potrebbe essere considerato sospetto o addirittura rifiutato, a seconda delle politiche implementate dal server ricevente.
L'SPF supporta inoltre istruzioni di controllo come "SOFTFAIL" (ammesso con avvertimento) o "FAIL" (rifiutato), che determinano come gestire le email in base alla corrispondenza tra l'indirizzo IP del mittente e il record SPF. Sebbene SPF sia uno strumento utile per ridurre la falsificazione degli indirizzi email, è spesso utilizzato in combinazione con altri metodi di autenticazione, come [[DomainKeys Identified Mail]] (DKIM) e Domain-based Message Authentication, Reporting, and Conformance (DMARC)<ref>Il '''DMARC (Domain-based Message Authentication, Reporting, and Conformance)''' è un protocollo di autenticazione delle email che protegge contro la falsificazione degli indirizzi email (spoofing). Si basa su due standard preesistenti, SPF e DKIM, e richiede che il dominio nel campo "Da:" dell'email corrisponda a quello utilizzato nei controlli di autenticazione.
Funzionamento: Verifica: Controlla se l'email supera i test SPF e DKIM. Allineamento: Verifica la corrispondenza dei domini. Politica: Se non supera i controlli, si riferisce alla politica DMARC per decidere come gestire l'email (quarantena o rifiuto). Vantaggi: Protegge contro lo spoofing. Consente ai proprietari di domini di controllare la gestione delle email non autenticate. Fornisce report utili per monitorare tentativi di spoofing.In sintesi, DMARC migliora la sicurezza delle email e la reputazione dei domini. Fonteː https://kinsta.com/it/knowledgebase/record-spf/</ref>, per migliorare ulteriormente la sicurezza delle email. Questa versione include dettagli aggiuntivi sul funzionamento di SPF e sul suo utilizzo nel contesto della sicurezza delle email.
== Storia ==
Il concetto alla base di SPF fu menzionato per la prima volta nel 2000,<ref>{{Cita web |url=http://www.openspf.org/History/Pre-SPF |titolo=SPF: First Public Mention 2000 |accesso=28 agosto 2014 |urlarchivio=https://web.archive.org/web/20150130122506/http://www.openspf.org/History/Pre-SPF |dataarchivio=30 gennaio 2015 |urlmorto=sì }}</ref> ma fudivenne realerealtà solo nel 2002, quando Dana Valerie Lank<ref>'''Dana Valerie Lank''' è una figura chiave nello sviluppo del Sender Policy Framework (SPF), uno standard di autenticazione per la posta elettronica. Nel 2002, Lank pubblicò indipendentementeun dallaabbozzo primadella 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. menzioneQuando un server di posta riceve un'email, verifica l'indirizzo IP del server mittente contro il record SPF pubblicato nel DNS del dominio per determinare se l'invio è autorizzato. L'importanza del lavoro di Lank è evidenziata dal fatto che il suo contributo ha portato alla formazione del Gruppo di Ricerca Anti-Spam (ASRG), dove la specifica SPF è stata ulteriormente discussa e sviluppata. La sua iniziativa ha avuto un impatto duraturo sulle pratiche di autenticazione della posta elettronica e sulla sicurezza online.</ref> pubblicò, in modo indipendente, un abbozzo di specifica SPF nella [[mailing list]] “namedroppers” della [[IETF]]. Il giorno successivo, [[Paul Vixie]] pubblicò la propria versione didella specifica SPF sulla stessa lista. Queste pubblicazioni suscitarono moltoun grande interesse, finendo con il portareportando 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'ASGRASRG ci furono quelle del “Reverse MX”<ref>Il '''Reverse MX (RMX)''' è un metodo di autenticazione delle email sviluppato da Hadmut Danisch. Questo approccio si basa sull'idea di verificare l'autenticità degli indirizzi email attraverso l'uso di record DNS, consentendo di prevenire la falsificazione degli indirizzi dei mittenti nelle comunicazioni via SMTP. Principi Fondamentali del Reverse MX Autenticazione Basata su DNS: RMX utilizza record DNS per determinare se un server di posta è autorizzato a inviare email per un determinato dominio. Questo processo implica una serie di ricerche nel database, utilizzando sia l'indirizzo IP del mittente che l'indirizzo email fornito nel comando SMTP "MAIL FROM". Prevenzione della Falsificazione: A differenza di altri metodi anti-spam, RMX non analizza il contenuto del messaggio email, ma si concentra esclusivamente sull'indirizzo IP del server di invio e sull'indirizzo email del mittente. Ciò consente di rifiutare i messaggi non autorizzati prima della loro trasmissione. Semplicità e Velocità: RMX è progettato per essere veloce e preciso, rendendo il processo di autenticazione semplice da debug e implementare. Tuttavia, presenta limitazioni, come il fatto che non considera il contenuto dell'email stessa. Storia e Sviluppo Il Reverse MX è stato proposto nel contesto della ricerca anti-spam e ha contribuito alla creazione di standard più ampi come il Sender Policy Framework (SPF) e il Sender ID. Nel 2003, Meng Weng Wong ha combinato le specifiche del Reverse MX con quelle del Designated Mailer Protocol (DMP) per sviluppare una versione più completa dell'autenticazione delle email, che ha portato all'evoluzione dell'SPF come lo conosciamo oggi. In sintesi, il Reverse MX rappresenta un passo significativo nella lotta contro lo spam e la falsificazione delle email, fornendo un metodo diretto e efficace per autenticare i mittenti attraverso l'infrastruttura DNS. Fonteː https://citizendium.org/wiki/Reverse_MX</ref> di Hadmut Danisch e del “Designated Mailer Protocol”<ref>Il '''Designated Mailer Protocol''' (DMP) è un metodo di autenticazione per la posta elettronica sviluppato da Gordon Fecyk. Questo protocollo è stato progettato per migliorare la sicurezza delle comunicazioni email, consentendo ai domini di specificare quali server sono autorizzati a inviare email a loro nome. Caratteristiche principali del DMP: '''Autenticazione''': Il DMP fornisce un meccanismo per autenticare l'origine delle email, riducendo il rischio di spoofing e phishing. Questo è particolarmente utile in un contesto in cui gli indirizzi email possono essere facilmente falsificati. '''Integrazione con altri protocolli''': Il DMP ha influenzato lo sviluppo di altri protocolli di autenticazione email, come il Sender Policy Framework (SPF) e DomainKeys Identified Mail (DKIM), che sono oggi ampiamente utilizzati per garantire la legittimità delle comunicazioni via email. '''Specifiche tecniche''': Il protocollo stabilisce regole chiare su come i server di posta devono gestire le email in uscita e come devono verificare l'autenticità dei mittenti, contribuendo a una gestione più sicura delle comunicazioni elettroniche. In sintesi, il Designated Mailer Protocol rappresenta un passo importante verso una maggiore sicurezza nelle comunicazioni via email, affrontando le vulnerabilità associate all'invio di messaggi falsificati. Fonteː https://www.marcoalbasini.com/2021/07/livello-applicazione-il-protocollo-smtp/</ref> di Gordon Fecyk.<ref>{{Cita web |url=http://www.openspf.org/History/Pre-SPF |titolo=SPF: History/Pre-SPF |accesso=16 maggio 2009 |urlarchivio=https://web.archive.org/web/20110716065200/http://www.openspf.org/History/Pre-SPF |dataarchivio=16 luglio 2011 |urlmorto=sì }}</ref>
Nel giugno del 2003, [[Meng Weng Wong]] unì le specifiche RMX e DMP<ref>Per un confronto tra RMX, DMP e SPF, è possibile consultare [http://old.openspf.org/dmpvsrmx.html RMX and DMP compared] {{webarchive|url=https://web.archive.org/web/20080425222937/http://old.openspf.org/dmpvsrmx.html |data=25 aprile 2008 }} sul sito storico di openspf.</ref> alle modifiche suggerite da altri programmatori. Nei successivi sei mesi successivi, vennero apportati un gran numero dinumerosi cambiamenti e una numerosavasta community si mise a lavorare su SPF.<ref>{{Cita web |url=http://www.openspf.org/History/SPF-2003 |titolo=SPF: History/SPF-2003 |accesso=16 maggio 2009 |urlarchivio=https://web.archive.org/web/20080118160547/http://www.openspf.org/History/SPF-2003 |dataarchivio=18 gennaio 2008 |urlmorto=sì }}</ref>
In origine, l'[[acronimo]] SPF doveva significare Sender Permitted From e a volte veniva anche chiamato SMTP+SPF,; matuttavia, 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.
All'inizio del 2004, IETF creò il gruppo di lavoro [[MARID]] e mise insieme le proposte SPF di ASRG e CallerID di Microsoft, utilizzandole come basi per ciò che è oggi conosciuto come [[Sender ID]]. Dopo il fallimento di MARID, la comunità SPF ritornò alla versione originale di SPF e, nel luglio del 2005, la prima versione della specifica venne approvata dall'[[IESG]] come un 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 [[RFC 4408]] sperimentale.
== Principi di funzionamento ==
Il [[Simple Mail Transfer Protocol]] permetteconsente a ogni computer di inviare e-mail senza alcuna verifica del mittente: il messaggio può dichiarare di provenire da un qualsiasi indirizzo di origine. CiòQuesto consenteaspetto agli spammerfacilita l'usooperato didegli [[spam]]mer, poiché possono utilizzare indirizzi e-mail falsi, rendendo più difficoltosadifficile la tracciaturatracciabilità dell'origine di un messaggio e più facilesemplice nascondere la loro vera identità, alloper scoposottrarsi alle responsabilità. L'uso di sottrarsiindirizzi allemittente lorocontraffatti responsabilità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.
L'uso di indirizzi mittente contraffatti consente ai messaggi di [[phishing]] di indurre i destinatari a rivelare informazioni private in risposta a un'e-mail apparentemente inviata da una 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 mandareinviare e-mail con un indirizzo del mittente inappartenente a quel dominio, utilizzando opportuni [[record TXT]] del [[Domain Name System]] (DNS). I destinatari sono in grado dipossono confrontare la provenienza del messaggio con le regole SPF e, in caso di problemiincongruenze, possono decidere di rifiutare i messaggi in arrivo da origini non autorizzate già prima ancora di ricevere il contenuto del messaggio. I principi di funzionamento sono perciòquindi similarisimili a quelli delle "DNS-based blackhole lists" ([[DNSBL]]), adcon l'eccezione del fatto che SPF utilizza loil schemasistema di delegazione dell'autorità appartenente aldel Domain Name System. La praticaprassi correnteattuale 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=aprilaprile |editore=[[Internet Engineering Task Force|IETF]] |accesso=26 aprile 2014 }}</ref> proprio come nelle prime implementazioni. Nelle fasi iniziali didella definizione, venneè stato registrato e reso disponibile un nuovo tipo di record (SPF, tipo 99), e l'uso didei record in formato [[.txt|TXT]] per SPF venneè 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“''l'uso di tipi RR alternativi del DNS era supportato nella fase sperimentale di SPF ma è stato successivamente deprecato”deprecato''”.<ref name="rfc7208-txt" />
L'indirizzo del mittente viene trasmessoinviato all'inizio deldella dialogocomunicazione [[Simple Mail Transfer Protocol|SMTP]], nell{{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” ([[bounce message]]) 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.
SPF non previene però la falsificazione dell'indirizzo del mittente indicato nel corpo del messaggio. Gli spammer possono quindi mandare 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ù facile da identificare.
Il principale beneficiovantaggio di SPF è che i possessori di indirizzi e-mail che sono statiemail usatiutilizzati come mittenti falsificati non ricevono grandiun quantitànumero elevato di messaggi di errore indesiderati e altre risposte automatiche. SeQuando talii destinatari usanoimplementano SPF per specificare quali sono le sorgentifonti legittime dei loro messaggi, i ricevitori possono rifiutare immediatamente ile messaggiemail falsinon autorizzate, riducendo così dail ridurrefenomeno o eliminare ildel [[Backscatter (posta elettronica)|backscatter.]].
L'SPF haoffre potenzialmenteanche altriulteriori vantaggi,benefici aloltre di là del fatto di aiutare lall'identificazione didelle mailemail indesiderataindesiderate. In particolare, se un mittente fornisce le informazioni SPF valide, i ricevitori possono usare iutilizzare risultati SPF positivi ininsieme combinazione cona una whitelist per identificarericonoscere i mittenti affidabili conosciuti. ScenariTuttavia, situazioni tipocome sistemi compromessi e/o utenti che inviano mailemail condivise limitanopossono questolimitare tipol'efficacia di utilizzoquesto approccio.
== RagioniLe diragioni dell'implementazione ==
Se un dominio pubblica un record SPF, è meno probabile che spammer e phisher possanoriescano a inviare e-mailemail fingendo che provengano da quel dominio, perchépoiché le email falsificate vengono catturate con maggiore efficacia dai filtri antispam. conDi più probabilità. Perciòconseguenza, un dominio protetto da SPF èdiventa meno interessanteattraente per [[spammer]] e [[Phishing|phisher]] come “spoofedindirizzo address”''spoofed'' (falso indirizzofalsificato). Questo comportariduce chela è meno probabileprobabilità che l'indirizzo venga inserito in una blacklist dai filtri anti-spamantispam e perciò, in ultimadi analisiconseguenza, aumenta lale probabilitàpossibilità che unale e-mailemail legittimalegittime vengavengano consegnataconsegnate ecorrettamente, nonevitando sia vittima dicosì falsi positivi deinei filtri.<ref>{{Cita web |url=http://www.emailmanual.co.uk/index.php/2009/05/why-should-i-implement-a-spf-record-on-my-___domain/ |titolo=Why should I implement a SPF record on my ___domain? |editore=Email Manual |data=May 2009 |accesso=1º gennaio 2010 |urlmorto=sì |urlarchivio=https://web.archive.org/web/20100129195805/http://www.emailmanual.co.uk/index.php/2009/05/why-should-i-implement-a-spf-record-on-my-___domain |dataarchivio=29 gennaio 2010 }}</ref>
== FAIL e l'inoltro ==
Lo standard SPF impedisce l'inoltro di messaggi ([[''plain message forwarding]]''). Quando un dominio pubblicaadotta una politica SPF restrittiva, i messaggi legittimi inviati aia destinatari inoltrandoche lainoltrano le loro mailemail a terzi possono essere respinti o rimbalzati se si verificano tutte le seguenti condizioni che seguono si verificano:
# colui che inoltra il messaggio non riscrive il [[return-path]] (cammino di ritorno).
# l'hop successivo non ha nella sua whitelist colui che inoltra il messaggio.
# l'hop esegue un controllo SPF.
Questa è una necessaria e ovvia caratteristica di SPF: i controlli dietro il “confine” [[Mail Transfer Agent|MTA]] ([[MX record|MX]]) del destinatario possono funzionare solo in modo diretto.
# Chi inoltra il messaggio non modifica il return-path (cammino di ritorno).
Chi pubblica una policy SPF deve accettare il rischio che le e-mail legittime possano essere respinte se non sono conformi alla policy definita. Per questo è opportuno fare dei test, finché non si è soddisfatti dei risultati.
# L'hop<ref>Nel contesto della posta elettronica, il termine '''"hop"''' si riferisce a ogni passaggio che un messaggio di posta elettronica compie mentre viaggia da un server all'altro sulla rete. Ogni volta che un'email viene trasferita da un server di posta a un altro, si verifica un "hop". Fonteː https://www.proofpoint.com/it/threat-reference/email-spoofing</ref> successivo non include chi inoltra il messaggio nella propria [[whitelist]].
# L'hop esegue un controllo SPF.
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.
Per un Return-Path vuoto usato nei [[messaggi di errore]] e in altre risposte automatiche, un controllo SPF della identità HELO è obbligatorio.
'''Esempio di Return-Path vuoto'''
# '''Invio dell'email:''' Tu invii la stessa email a "cliente@example.com".
# '''Errore di consegna:''' Il server non riesce a consegnare l'email perché l'indirizzo è errato.
# '''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).
# '''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.
ConTuttavia, una fintase l'identità HELO ilè risultatoassociata NONEa nonnomi aiuta,di mahost pervalidi nominel di hostrecord SPF, validiallora proteggeil controllo può effettivamente laproteggere l'identità HELO. Questa caratteristica SPFfunzionalità è stata sempre stata supportata come opzione per i destinatari, e successivile schemispecifiche SPF,più inclusarecenti ladi specifica finale,SPF raccomandano di verificare sempre l'HELO.
QuestoQuesta verifica consente ai destinatari di mettereinserire determinati mittenti in una whitewhitelist listse determinatiil mittenti,risultato basandosidel su uncontrollo HELO è "PASS", oppure di respingere tutte le mailemail dopose unil HELOrisultato è "FAIL". QuestoInoltre, questo meccanismo può essere utilizzato ancheintegrato in “sistemisistemi di reputazione”reputazione, ([[reputationpoiché system]],sia qualsiasile whitewhitelist oche blackle listblacklist èsono unesempi casodi semplicesistemi di reputationreputazione. Questa versione mantiene i concetti originali ma li presenta in modo più diretto e system)comprensibile.
== Implementazione ==
La conformità conagli standard SPF si compone dicomprende 3tre taskattività correlati:correlateː
* '''Pubblicare una politica (policy)''': DominiI domini e gli host identificanospecificano lequali macchineserver autorizzatepossono a spedireinviare email pera loro contonome, assicurando che le comunicazioni siano riconosciute come legittime e provenienti da fonti autorizzate. Fanno ciò aggiungendo record addizionali alle loro informazioni DNS già esistenti: ogniOgni [[nome di dominio]] o host che hapossiede un record di tipo A ([[A record]]) o un record di tipo MX ([[MX record]]) dovrebbeè averein ungrado recorddi SPF specificandonegestire la politicaposta seelettronica essoe èdovrebbe utilizzatoavere inanche un indirizzorecord emailSPF. e/oIl comerecord argomentoA HELO/EHLO.serve Glia hostmappare cheun nonnome invianodi maildominio dovrebbero averea un recordindirizzo SPFIP, pubblicatopermettendo cheai indichibrowser unadi cosalocalizzare delil genereserver ("v=spf1web –all")associato al dominio. QuestoD'altra èparte, altamenteil raccomandatorecord alloMX scopoè difondamentale validareper ill'instradamento recorddelle SPFemail, usandopoiché degliindica strumentiai (tool)server di testingposta deicome recorde tipodove [https://web.archive.org/web/20120221103738/http://www.openspf.net/Toolsinviare quellii fornitimessaggi sullaper paginaquel webdominio, delgarantendo progettocosì SPF]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.
* '''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.
* '''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.
* '''Rivedere ed eventualmente correggere l'inoltro della posta''': l'inoltro di mail non "formattate" non è consentito da SPF. Le alternative sono:
* '''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.
** Remailing (cioè rimpiazzare il mittente originario con uno appartenente al dominio locale);
* '''Gestione dell'inoltro delle email:''' L'inoltro di email non formattate non è consentito da SPF. Le alternative per gestire l'inoltro includono:
** Refusing (rifiutare, cioè rispondere <code>551 User not local; please try <user@example.com></code>);
** '''Remailing''': Sostituire il mittente originale con uno appartenente al dominio locale.
** [[Whitelisting]], cioè mettere in una white list il server bersaglio, in modo tale che in futuro non rifiuti più un messaggio inoltrato;
** '''Refusing''': Rifiutare l'email, restituendo un messaggio di errore come "551 User not local; please try user@example.com".
** [[Sender Rewriting Scheme]], "schema di riscrittura del mittente", un meccanismo che manipola il mittente, ad esempio per risolvere alcuni problemi legati ai reindirizzamenti<ref>{{Cita web
** '''Whitelisting:''' Aggiungere il server di destinazione a una lista bianca per evitare rifiuti futuri di messaggi inoltrati.
|url = http://www.open-spf.org/SRS/
** '''Sender Rewriting Scheme (SRS)''': Utilizzare un meccanismo che modifica l'indirizzo del mittente per risolvere problemi legati ai reindirizzamenti<ref>{{Cita web|lingua=en|url=http://www.open-spf.org/SRS/|citazione=SPF "breaks" email forwarding. SRS is a way to fix it. SRS is a simple way for forwarding MTAs to rewrite the sender address. The original concept was published in draft-mengwong-sender-rewrite and further expanded on in a paper by Shevek.|accesso=27 ottobre 2022}}</ref>
|lingua = en
|accesso = 27 ottobre 2022
|citazione = SPF "breaks" email forwarding. SRS is a way to fix it. SRS is a simple way for forwarding MTAs to rewrite the sender address. The original concept was published in draft-mengwong-sender-rewrite and further expanded on in a paper by Shevek.
}}</ref>
QuindiPertanto, la questione chiavecentrale innell'ambito dei record SPF stariguarda nellele specifiche relative alle nuove informazioni DNS che i set di domini e destinatari usanoutilizzano. I record quiriportati di seguito sono scrittiformulati utilizzandosecondo la sintassi tipicastandard dei DNS:DNSː
example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all"
Sono definiti otto ''meccanismi'':
{|
| valign="top" | ALL || faLo semprestandard ildi matchautenticazione degliemail SPF verifica sempre gli indirizzi; usatoIP perdei Iserver risultatidi posta in uscita. Quando un indirizzo non corrisponde a nessuno dei criteri precedentemente definiti, osia alle regole e alle autorizzazioni specificate nel record SPF di un dominio, viene applicato il risultato di default, come ad esempio <kbd>-all</kbd>, perche indica che tutti gli IP chenon autorizzati sono considerati non hannovalidi fattoper ill'invio matchdi attraversoemail per meccanismiquel precedentidominio.
|-
| valign="top" | A - AAAA || Se il nome di dominio ha un record di indirizzo (A per IPV4 o AAAA per IV6) che può esserecorrisponde all'risolto' versoindirizzo l’indirizzoIP del mittente, fal'email è considerata valida. In altre parole, il matchsistema verifica se il server che ha inviato l'email è autorizzato a farlo controllando le informazioni DNS del dominio.
|-
| valign="top" | IP4 || Se il mittente è in un range di indirizzi [[IPv4|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.
|-
| valign="top" | IP6 || Se il mittente è in un range di indirizzi [[IPv6|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.
|-
| valign="top" | MX || Se il nome di dominio ha un [[record MX]] nellache risoluzionecorrisponde dell’indirizzoall'indirizzo IP del mittente, fasignifica che l'email proviene da uno dei server di posta autorizzati per quel dominio. In questo contesto, "fare il match" (cioèindica lache mailc'è arrivauna dacorrispondenza unotra deil'indirizzo IP del mittente e maili server indi entrataposta specificati nel record MX del dominio), confermando così la legittimità dell'email in arrivo.
|-
| valign="top" | PTR || Se il nome di dominio ([[PRTha un record]]) PTR per l’indirizzol'indirizzo del client, èsignifica presenteche nelil dominioserver dato,DNS epuò talerisolvere l'indirizzo IP del client in un nome di dominio. siSe ‘risolve’questo versonome l’indirizzodi deldominio clientcorrisponde ([[forward-confirmeda reversequello DNS]])specificato nel record SPF, fasi ilverifica un "match", ovvero una corrispondenza, che indica che l'email proviene da una fonte autorizzata. QuestoTuttavia, questo meccanismo è stato deprecatoabbandonato a causa della sua lentezza e inaffidabilità, e non dovrebbe più veniressere usatoutilizzato.<ref name="rfc7208-txt" />
|-
| valign="top" | EXISTS || Se il nome di dominio dato si '"risolve'" verso qualsiasi indirizzo, fasignifica che il matchserver (indipendentementeDNS dall’indirizzoè versoin cuigrado di trovare un indirizzo IP associato a quel dominio. Se l'indirizzo IP del mittente corrisponde a quello ottenuto, si risolve)verifica un "match", ovvero una corrispondenza, che indica che l'email proviene da una fonte autorizzata. Questo meccanismo vieneè utilizzato raramente. AssiemeInsieme alalle macro linguaggiodi parametri SPF, essoconsente offredi deicreare match più complessi, come perad esempio le query [[DNSBL]] (DNS-based Blackhole List), che aiutano a identificare indirizzi IP noti per inviare spam.
|-
| valign="top" | INCLUDE || FaIl meccanismo SPF consente di fare riferimento alla politica di un altro dominio. Seattraverso la politicadirettiva di<code>include</code>. questoQuando 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 approvato/accettabileinclusione anch’essoviene considerato valido. Tuttavia, se la nuova politica, appenadel inclusadominio incluso non supera il controllo (ad esempio, se fallisce), l’elaborazioneil 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 il meccanismol'autenticazione a un’altraun'altra politica di dominio, si deveutilizza utilizzare l’estensionel'estensione di reindirizzamento ('<code>redirect</code>). Questa estensione consente al dominio originale di delegare completamente la responsabilità dell'autenticazione extension)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 ==
Ogni ''meccanismo'' SPF può essere combinato con uno dei quattro ''qualificatori'':
* '''<kbd>+</kbd>''' per un risultato PASS (test superato). Può essere omesso; per esempio <kbd>+mx</kbd> equivale a <kbd>mx</kbd>.
* +: indica un risultato PASS (test superato). Questo qualificatore può essere omesso; ad esempio, <code>+mx</code> è equivalente a <code>mx</code>.
* '''<kbd>?</kbd>''' per un risultato NEUTRAL (neutrale), che viene interpretato come NONE (nessuna politica).
* ?: 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.
* '''<kbd>~</kbd>''' (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.
* ~ (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.
* '''<kbd>-</kbd>''' (meno) per un risultato FAIL (fallimento), la mail dovrebbe venire respinta (vedi sotto).
* - (meno): indica un risultato FAIL (fallimento). In questo caso, l'email dovrebbe essere respinta, poiché non proviene da una fonte autorizzata.
== Modificatori ==
I modificatori hannoSPF losono scopoprogettati diper consentire future estensioni al [[framework]]. Ad oggiAttualmente, solo due modificatori definiti nel [[nell'<nowiki>RFC 4408]]</nowiki><ref name=":0" /> sono stati ampiamente distribuitiadottati:
* <kbd>exp=some.example.com</kbd> restituisce il nome di un dominio con un record TXT del [[Domain Name System|DNS]] (interpretato usando il macro linguaggio SPF) allo scopo di ottenere una spiegazione per I risultati FAIL—tipicamente si tratta di un [[Uniform Resource Locator|URL]] che viene aggiunto al codice di errore SMTP. Questa feature è usata raramente.
* <code>exp=some.example.com</code>: 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.
* <kbd>redirect=some.example.com</kbd> può essere utilizzato al posto del meccanismo ALL per collegarsi al policy record di un altro dominio. Questo modificatore è più facile da capire piuttosto che il similare meccanismo INCLUDE.
* <code>redirect=some.example.com</code>: Questo modificatore può sostituire il meccanismo ALL e permette di collegarsi al record di policy di un altro dominio. Utilizzando <code>redirect</code>si 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 ==
Non appena le implementazioni del Sender Policy Framework (SPF) individuano degli errori di sintassi in una sender policy (politica del mittente), devono interrompere la valutazione restituendoe comerestituire un risultato di PERMERROR. DevonoQuesto anchesignifica saltareche il record SPF non è valido e non può essere utilizzato. Inoltre, devono ignorare i meccanismi errati che non possono funzionare come previsto,; eper di conseguenza ancheesempio, <kbd>include:bad.example</kbd> e <kbd>redirect=bad.example</kbd> causanogenerano anch'essi un PERMERROR.
Un'altra tutelamisura utilizzadi protezione prevede un limite massimo di dieci meccanismi di verifica DNS,. cioèQuesto ognilimite meccanismosi eccettoapplica a tutti i meccanismi, ad eccezione di IP4, IP6 e ALL. Le applicazioni possono interrompere la valutazione conrestituendo un esito di SOFTERROR quandose ciil vuoletempo unnecessario tempoper maggiorecompletare dila unaverifica prefissatasupera una soglia prestabilita, oppure se una verifica DNS scade (andandotimeout). in time out)Tuttavia, ma essi devono comunque restituire un PERMERROR quandose la procedura richiede, direttamente o indirettamente, dmpiùpiù di dieci verifiche DNS. Ogni <kbd>uso di redirect=</kbd> conta anche nei confronti diverso questo limite di elaborazione.
Una tipica politica SPF HELOpotrebbe essere scritta come <kbd>v=spf1 a -all</kbd>. 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 dal [[dall'<nowiki>RFC 7208]]</nowiki>), e (3) una richiesta per i record A o AAAA. Questa Quest'ultima richiesta conta come primo valore verso il limite di 10dieci. In questo esempio, è anche l'ultima richiesta, perchépoiché ALL non harichiede bisogno diulteriori ricercaricerche 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 ==
Nel 2004, [[quando il ricercatore nel campo della sicurezza informatica Steven Michael Bellovin<ref>'''Steven M. Bellovin]]''' è un importante ricercatore nel campo della sicurezza informatica e delle reti. È nato il 24 novembre 1955 a New York, negli Stati Uniti. Attualmente è professore nel dipartimento di informatica presso la Columbia University, ruolo che ricopre dal 2005. Prima di questo, ha lavorato come fellow presso AT&T Labs Research a Florham Park, New Jersey. Fonteː https://datascience.columbia.edu/people/steven-m-bellovin/</ref> scrisse una e-mail che trattava delle sue preoccupazioni relative a SPF.<ref>[http://www.interesting-people.org/archives/interesting-people/200401/msg00037.html Steve Bellovin expresses doubts] {{webarchive|url=https://web.archive.org/web/20040413235149/http://www.interesting-people.org/archives/interesting-people/200401/msg00037.html |data=13 aprile 2004 }} (Jan 2004)</ref> Le più significative sono:
* La SPF (Sender Policy Framework) originariamente utilizzava record TXT nel DNS, cheprogettati si supponeper sianocontenere testo in formato libero, senza semanticauna allegataspecifica semantica. I sostenitori dell' SPF ammiseroriconobbero che sarebbe stato megliopreferibile avere record specificamenteappositamente designati per SPFdedicati, ma questa scelta è statafu fatta per consentire una rapida implementazione didel SPFprotocollo. Nel luglio del 2005, La [[Internet Assigned Numbers Authority|IANA]] (Internet Assigned Numbers Authority) assegnò il Return Record di tipo 99 a SPF. Più tardiTuttavia, l'uso di record SPF dedicati è stato interrotto,successivamente edabbandonato. aA partire dadal 2016, risultaè ancora necessario utilizzare i record TXT per configurare le politiche SPF..<ref name="rfc7208-txt" />
* AlQuando momentoSteve inMichael cuiBellovin hasollevò scrittodubbi ilsull'adozione suodel messaggioSender Policy Framework (SPF), non c'era consensoancora sulun fattogenerale checonsenso SPFsulla fossesua laefficacia stradacome giustasoluzione daper l'autenticazione delle percorrereemail. Alcuni dei principali provider di servizi e-mailemail non l'hannoavevano inseritoancora all'internoimplementato diSPF questonei schemaloro sistemi. Finché nonquesti loprovider sarànon fattoadotteranno SPF, nonil serviràprotocollo diSPF aiuto,non sarà utile né per i loro clienti, (che costituisconorappresentano una parte consistentesignificativa della popolazione di utenti)utentR, chené per qualsiasialtri, altropoiché (perché i lorogli indirizzi email potrebbero continuare a essere contraffatti). FaÈ importante notare che, poichéda quando questa preoccupazione è stata evidenziataespressa, servizi come Google Mail e AOL, tra gli altri, hanno abbracciatoadottato 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, (ilovverosia 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 il 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 agent]]sagents, 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.
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 deprecareeliminare l'SPF tipo 99 a favore di un utilizzo continuo di record TXT.<ref>{{cita web|titolo=Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments |url=https://tools.ietf.org/html/rfc6686|autore=Murray Kucherawy |anno=2012 |mese=luglio|editore=[[Internet Engineering Task Force|IETF]] |accesso=16 dicembre 2013 }}</ref> 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.<ref>{{Cita web|url=https://www.ietf.org/mail-archive/web/dnsext/current/msg13025.html |titolo=Obsoleting SPF RRTYPE |autore=S. Moonesamy |data=23 aprile 2013 |sito=DNSEXT Discussion List |editore=[[Internet Engineering Task Force|IETF]] |accesso=16 dicembre 2013}}</ref><ref>{{Cita web|url=https://www.ietf.org/mail-archive/web/ietf/current/msg81939.html |titolo=Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard |autore=Dan Schlitt |data=29 agosto 2013 |sito=IETF Discussion List |editore=[[Internet Engineering Task Force|IETF]] |accesso=16 dicembre 2013}}</ref> 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<ref>{{Cita web|url=https://www.ietf.org/mail-archive/web/spfbis/current/msg03833.html |titolo=The RRTYPE topic |autore=Andrew Sullivan |data=29 maggio 2013 |sito=SPFBIS Discussion List |editore=[[Internet Engineering Task Force|IETF]] |accesso=16 dicembre 2013}}</ref> (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.<ref>{{cita web|url=https://tools.ietf.org/html/draft-klensin-iana-txt-rr-registry|titolo=An IANA Registry for Protocol Uses of Data with the DNS TXT RRTYPE|autore1=John Klensin |autore2=Andrew SUllivan |autore3=Patrik Fältström |anno=2013 |mese=agosto|editore=[[Internet Engineering Task Force|IETF]] |accesso=16 dicembre 2013}}</ref>
== 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.
Software anti-spam come [[SpamAssassin]] versione 3.0.0 e [[Anti-Spam SMTP Proxy|ASSP]] implementano SPF. Molti [[mail transfer agent]] (MTA) supportano direttamente SPF, come [[Courier Mail Server|Courier]], CommuniGate Pro, [[Wildcat! BBS|Wildcat]], [[MDaemon]], e [[Microsoft Exchange Server|Microsoft Exchange]]; o hanno patch o plug-ins disponibili che supportano SPF, compresi [[Postfix (software)|Postfix]], [[Sendmail]], [[Exim]], [[qmail]], e [[Qpsmtpd]].<ref>{{Cita web|url=https://github.com/qpsmtpd-dev/qpsmtpd-dev/blob/master/plugins/sender_permitted_from|titolo=Qpsmtpd SPF plugin|anno=2013|urlmorto=sì|accesso=14 giugno 2016|urlarchivio=https://archive.is/20130629083752/https://github.com/qpsmtpd-dev/qpsmtpd-dev/blob/master/plugins/sender_permitted_from#|dataarchivio=29 giugno 2013}}</ref> A partire dal 2013, più di sette milioni di domini adottano politiche SPF FAIL <kbd>-all</kbd> .<ref>{{Cita web|url=http://spf-all.com/stats.html|titolo=SPF -all Domain Survey|anno=2013|accesso=23 aprile 2013}}</ref>
Caratteristiche principali di ASSP
ASSP offre una serie di funzionalità avanzate per la gestione dello spam, tra cui:
Filtraggio basato su modelli: Utilizza modelli statistici come il Hidden Markov Model e il Bayesian spam filtering per valutare la probabilità che un messaggio sia spam.
Whitelist e Blacklist: Permette la creazione di liste di autorizzazione (whitelisting) e di blocco (blacklisting) per gestire i mittenti.
Penalty Box: Una funzione che intrappola temporaneamente i mittenti sospetti per ulteriori verifiche.
DNSBL/RBL: Integra elenchi neri in tempo reale (Realtime Blackhole Listing) per identificare indirizzi IP noti per l'invio di spam.
URIBL: Controlla le URL nei messaggi contro le liste nere.
Validazione SPF, DKIM e DMARC: Supporta la convalida multi-livello delle politiche SPF, la firma e la validazione DKIM, nonché la validazione e il reporting DMARC.
Session Delaying/Greylisting: Implementa tecniche di ritardo nelle sessioni per ridurre i tentativi di invio da parte degli spammer.
Blocco degli allegati: Consente il blocco degli allegati basato su liste di autorizzazione o contenuti eseguibili.
Piattaforma e compatibilità
ASSP è scritto in Perl, rendendolo indipendente dalla piattaforma, e supporta un'architettura multi-threading a partire dalla versione 2.x. Questa versatilità consente a ASSP di essere utilizzato su vari sistemi operativi senza necessità di modifiche significative.In sintesi, l'Anti-Spam SMTP Proxy rappresenta una soluzione robusta ed efficace per le organizzazioni che desiderano proteggere le proprie comunicazioni email dallo spam, garantendo al contempo una gestione flessibile e personalizzabile delle politiche anti-spam.</ref> implementano il protocollo SPF. Molti [[mail transfer agent]] (MTA) supportano direttamente SPF, tra cui [[Courier Mail Server|Courier]], [[CommuniGate Pro]], Wildcat<ref>L{{'}}'''MTA Wildcat''' è un mail transfer agent (MTA) progettato per la gestione e l'invio di email. È noto per la sua capacità di supportare vari protocolli di posta elettronica e per le sue funzionalità avanzate di gestione delle email. Wildcat è particolarmente utilizzato in ambienti in cui è necessaria una configurazione personalizzata e un controllo dettagliato sulla gestione del traffico email.
Caratteristiche principali di Wildcat
Supporto per protocolli: Wildcat supporta i protocolli SMTP, POP3 e IMAP, consentendo una flessibile interazione con i client di posta.
Configurabilità: Gli utenti possono configurare il software in base alle proprie esigenze specifiche, rendendolo adatto a diverse applicazioni aziendali.
Sicurezza: Include funzionalità per la protezione contro lo spam e altre minacce alla sicurezza delle email.
Interfaccia utente: Wildcat offre un'interfaccia utente intuitiva che facilita la gestione delle email e delle impostazioni del server.
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.</ref>, [[MDaemon]], e [[Microsoft Exchange Server|Microsoft Exchange]]; altri, come Postfix<ref>'''Postfix''' è un mail transfer agent (MTA) sviluppato come alternativa a Sendmail, progettato per gestire l'invio e la ricezione di email in modo sicuro ed efficiente. È stato creato da Wietse Venema alla fine degli anni '90 e si è rapidamente affermato come uno degli MTA più popolari grazie alle sue caratteristiche di sicurezza e prestazioni.
Caratteristiche principali di Postfix
'''Sicurezza''': Postfix è progettato con un'architettura modulare che riduce il rischio di vulnerabilità. Ogni componente del sistema funziona con privilegi minimi, limitando l'impatto di eventuali exploit.
'''Supporto per vari protocolli''': Postfix supporta il protocollo SMTP per l'invio di email e può interagire con i protocolli POP3 e IMAP per la ricezione delle email.
'''Configurabilità''': Gli amministratori possono configurare Postfix per gestire alias, domini virtuali e diversi formati di memorizzazione delle caselle di posta, come Mbox e Maildir.
'''Gestione della coda di posta''': Postfix gestisce la coda di posta in modo efficiente, consentendo il monitoraggio e la gestione dei messaggi in attesa di invio o consegna.
'''Supporto per TLS''': Dalla versione 2.3, Postfix offre supporto per Transport Layer Security (TLS), permettendo comunicazioni sicure tra server.
Utilizzo
Postfix è ampiamente utilizzato in molte distribuzioni Linux come MTA predefinito. È scelto da molti amministratori di sistema grazie alla sua facilità d'uso, configurabilità e robustezza. La sua architettura modulare e le funzionalità avanzate lo rendono adatto sia per piccole che grandi installazioni.In sintesi, Postfix rappresenta una soluzione affidabile e sicura per la gestione delle email, combinando prestazioni elevate con una configurabilità flessibile. Fonteː https://www.extraordy.com/funzionamento-della-posta-elettronica-e-configurazione-di-postfix/</ref>, [[Sendmail]], Exim<ref>'''Exim''' è un mail transfer agent (MTA) open source altamente personalizzabile, progettato per il routing e la consegna delle email. È noto per la sua flessibilità e viene frequentemente utilizzato in ambienti aziendali grazie alle sue numerose funzionalità avanzate.
Caratteristiche principali di Exim
Flessibilità e configurabilità: Exim offre un sistema di configurazione meno complesso rispetto ad altri MTA come Sendmail, permettendo agli amministratori di gestire facilmente le impostazioni. Utilizza un linguaggio di configurazione che consente di definire regole e comportamenti complessi per la gestione della posta.
Compatibilità con Sendmail: Exim è progettato per essere compatibile con le convenzioni di Sendmail, facilitando la transizione per gli utenti e gli amministratori che già utilizzano Sendmail. Questo include il supporto per file come <code>/etc/aliases</code> e <code>~/.forward</code>, senza necessità di ricompilazione.
Sicurezza: Exim è predisposto per operare senza privilegi elevati, riducendo il rischio di attacchi. Supporta anche l'autenticazione SMTP e l'estensione StartTLS per connessioni sicure.
Gestione della coda di posta: Exim gestisce efficacemente le code di messaggi in arrivo e in uscita, permettendo la consegna immediata dei messaggi non appena vengono ricevuti, senza attendere la chiusura della connessione SMTP.
Supporto per domini virtuali: Exim può gestire più domini locali sulla stessa macchina, consentendo una gestione indipendente delle cassette postali per ciascun dominio. Fonteː https://products.containerize.com/it/transactional-email/exim/</ref>, [[qmail]], e Qpsmtpd<ref>'''Qpsmtpd''' è un mail transfer agent (MTA) scritto in Perl, progettato per essere flessibile e facilmente estensibile. È noto per la sua architettura modulare che consente l'aggiunta di funzionalità tramite plugin, rendendolo altamente personalizzabile per soddisfare diverse esigenze di gestione della posta elettronica.
Caratteristiche principali di Qpsmtpd
Architettura modulare: Qpsmtpd è costruito attorno a un sistema di plugin, il che significa che le funzionalità possono essere aggiunte o modificate senza alterare il codice principale. Questo approccio consente agli sviluppatori di estendere facilmente le capacità del server SMTP.
Facilità d'uso: La configurazione di Qpsmtpd è relativamente semplice, permettendo agli amministratori di sistema di impostare e gestire il server con facilità. La documentazione e la comunità di supporto contribuiscono a facilitare l'adozione.
Supporto per standard moderni: Qpsmtpd supporta vari standard e protocolli moderni, inclusi SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) e DMARC (Domain-based Message Authentication, Reporting & Conformance), migliorando la sicurezza e l'affidabilità delle comunicazioni email.
Gestione della coda di posta: Come altri MTA, Qpsmtpd gestisce la coda di posta in modo efficiente, assicurando che i messaggi vengano consegnati anche in caso di problemi temporanei con i server destinatari.
Utilizzo
Qpsmtpd è utilizzato principalmente in ambienti dove è richiesta una gestione flessibile delle email, come nei server di posta per piccole e medie imprese. La sua capacità di essere esteso tramite plugin lo rende adatto a scenari specifici, dove le esigenze possono variare notevolmente.In sintesi, Qpsmtpd rappresenta una soluzione versatile per la gestione delle email, combinando un'architettura modulare con funzionalità avanzate per garantire una comunicazione sicura ed efficiente. Fonteː https://github.com/smtpd/qpsmtpd</ref>, offrono patch o plug-in disponibili per il supporto di SPF.<ref>{{Cita web|url=https://github.com/qpsmtpd-dev/qpsmtpd-dev/blob/master/plugins/sender_permitted_from|titolo=Qpsmtpd SPF plugin|anno=2013|urlmorto=sì|accesso=14 giugno 2016|urlarchivio=https://archive.is/20130629083752/https://github.com/qpsmtpd-dev/qpsmtpd-dev/blob/master/plugins/sender_permitted_from#|dataarchivio=29 giugno 2013}}</ref> A partire dal 2013, oltre sette milioni di domini hanno adottato politiche SPF con il risultato FAIL <kbd>-all</kbd>.<ref>{{Cita web|url=http://spf-all.com/stats.html|titolo=SPF -all Domain Survey|anno=2013|accesso=23 aprile 2013}}</ref>
Nell'agosto del 2005, è stato annunciato che [[EarthLink]] non avrebbe consentito ai domini ospitati di inserire record SPF.<ref>{{Cita web|url=http://www.circleid.com/posts/spf_loses_mindshare/ |titolo=SPF Loses Mindshare |anno=2005|accesso=4 aprile 2011 }}</ref>
In un sondaggio pubblicato nel 2007, il 5% dei domini <kbd>.com</kbd> e <kbd>.net</kbd> risultava avere qualche tipo di politica SPF. Nel 2009, un'indagine condotta da Nokia Research ha riportato che il 51% dei domini testati specificava una politica SPF.<ref>{{Cita web|url=https://fit.nokia.com/lars/meter/spf.html|titolo=Nokia Research Report on SPF Adoption|urlarchivio=https://web.archive.org/web/20110920015908/https://fit.nokia.com/lars/meter/spf.html|sito=Fit.Nokia.com|editore=[[Nokia]]|data=19 settembre 2011|dataarchivio=20 settembre 2011|accesso=5 aprile 2016}}</ref> Questi risultati includevano anche politiche semplici come <kbd>v=spf1 ?all</kbd>.<ref>{{Cita web |url=http://www.onlamp.com/pub/a/onlamp/2007/01/11/dns-extensions.html |titolo=Handicapping New DNS Extensions and Applications |nome=Cricket |cognome=Liu |editore=ONLamp |data=gennaio 2007 |accesso=4 ottobre 2007 |dataarchivio=26 settembre 2007 |urlarchivio=https://web.archive.org/web/20070926234446/http://www.onlamp.com/pub/a/onlamp/2007/01/11/dns-extensions.html |urlmorto=sì }}</ref> Nell'aprile del 2007, BITS, una divisione del Financial Services Roundtable, pubblicò raccomandazioni di sicurezza per le email destinate ai suoi membri, tra cui l'adozione di SPF.<ref>{{Cita web |url=http://bitsinfo.org/downloads/Publications%20Page/BITSSecureEmailFINALAPRIL1507.pdf |titolo=BITS Email Security Toolkit |editore=BITS |data=aprile 2007 |accesso=13 giugno 2008 |formato=PDF |urlarchivio=https://web.archive.org/web/20080515131234/http://bitsinfo.org/downloads/Publications%20Page/BITSSecureEmailFINALAPRIL1507.pdf |dataarchivio=15 maggio 2008 |urlmorto=sì }}</ref>
Nel 2008, il Messaging Anti-Abuse Working Group (MAAWG)<ref>Il '''Messaging Anti-Abuse Working Group (MAAWG)''' è un'associazione di settore dedicata alla lotta contro l'abuso online, in particolare nel contesto della messaggistica, malware e sicurezza mobile. Fondata nel 2004, l'associazione ha come obiettivo principale quello di riunire vari attori dell'industria per sviluppare approcci cooperativi nella prevenzione dell'abuso online.
Missione e Obiettivi
MAAWG si concentra su diverse forme di abuso online, tra cui spam, malware, virus e attacchi DDoS. L'associazione funge da piattaforma collaborativa dove i membri possono condividere informazioni e buone pratiche per combattere questi tipi di abusi. Inoltre, MAAWG sviluppa e pubblica documenti di best practice e dichiarazioni di posizione per assistere la comunità online nella lotta contro l'abuso.
Attività Principali
Collaborazione: MAAWG promuove la collaborazione tra membri che includono fornitori di servizi Internet (ISP), aziende di sicurezza, fornitori di servizi di messaggistica e altri attori del settore.
Pubblicazione di documenti: L'organizzazione produce documenti informativi riguardanti le migliori pratiche per affrontare le problematiche legate alla sicurezza della messaggistica.
Advocacy: MAAWG fornisce consulenze ai pubblici ufficiali su come sviluppare politiche e normative relative a Internet.
Membri
L'associazione conta oltre 200 membri a livello globale, inclusi grandi operatori di rete, aziende di software e hardware, esperti invitati e agenzie governative. I membri si incontrano regolarmente per discutere le ultime problematiche relative alla sicurezza della messaggistica e alle pratiche di mitigazione degli abusi.
Nell'agosto del 2005 è stato comunicato che [[EarthLink]] non avrebbe consentito ai domini ospitati la possibilità di inserire record SPF.<ref>{{Cita web|url=http://www.circleid.com/posts/spf_loses_mindshare/ |titolo=SPF Loses Mindshare |anno=2005|accesso=4 aprile 2011 }}</ref>
Incontri
In un sondaggio pubblicato nel 2007, il 5% dei domini <kbd>.com</kbd> e <kbd>.net</kbd> è 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.<ref>{{Cita web|url=https://fit.nokia.com/lars/meter/spf.html|titolo=Nokia Research Report on SPF Adoption|urlarchivio=https://web.archive.org/web/20110920015908/https://fit.nokia.com/lars/meter/spf.html|sito=Fit.Nokia.com|editore=[[Nokia]]|data=19 settembre 2011|dataarchivio=20 settembre 2011|accesso=5 aprile 2016}}</ref> Questi risultati includevano anche politiche semplici come <kbd>v=spf1 ?all</kbd>.<ref>{{Cita web |url=http://www.onlamp.com/pub/a/onlamp/2007/01/11/dns-extensions.html |titolo=Handicapping New DNS Extensions and Applications |nome=Cricket |cognome=Liu |editore=ONLamp |data=January 2007 |accesso=4 ottobre 2007 |dataarchivio=26 settembre 2007 |urlarchivio=https://web.archive.org/web/20070926234446/http://www.onlamp.com/pub/a/onlamp/2007/01/11/dns-extensions.html |urlmorto=sì }}</ref> 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.<ref>{{Cita web |url=http://bitsinfo.org/downloads/Publications%20Page/BITSSecureEmailFINALAPRIL1507.pdf |titolo=BITS Email Security Toolkit |editore=BITS |data=April 2007 |accesso=13 giugno 2008 |formato=PDF |urlarchivio=https://web.archive.org/web/20080515131234/http://bitsinfo.org/downloads/Publications%20Page/BITSSecureEmailFINALAPRIL1507.pdf |dataarchivio=15 maggio 2008 |urlmorto=sì }}</ref>
NelMAAWG 2008organizza 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 relativo allsull'autenticazione delle email, coprendoche trattava anche la parte relativa adi SPF, l'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=Marchmaggio 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 dichiaravaaffermava: "Per lo meno, i mittenti dovrebbero incorporare record SPF per i propri domini di mailposta".<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 ==
| 