Sender Policy Framework: differenze tra le versioni

Versione delle 18:51, 11 dic 2024

Versione delle 19:07, 11 dic 2024

Riga 17:

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 [[Spam|spammer]], poiché possono utilizzare indirizzi e-mail falsi, rendendo più difficile la tracciabilità dell'origine di un messaggio e più semplice nascondere la loro vera identità per sottrarsi alle responsabilità. L'uso di indirizzi mittente contraffatti permette ai messaggi di [[phishing]] di indurre i destinatari a rivelare informazioni private in risposta a un'e-mail apparentemente inviata da un'organizzazione affidabile, come una banca o un altro fornitore di servizi legittimi.

Il Sender Policy Framework (SPF) consente al proprietario di un dominio di definire le regole per identificare i server autorizzati a inviare e-mail con un indirizzo del mittente appartenente a quel dominio, utilizzando opportuni [[record TXT]] del [[Domain Name System]] (DNS). I destinatari possono confrontare la provenienza del messaggio con le regole SPF e, in caso di discrepanzeincongruenze, 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“''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ù difficile da identificare.

Il principale beneficio di SPF è che possessori di indirizzi e-mail che sono stati usati come mittenti falsificati non ricevono grandi quantità di messaggi di errore indesiderati e altre risposte automatiche. Se tali destinatari usano SPF per specificare quali sono le sorgenti legittime dei loro messaggi, i ricevitori possono rifiutare immediatamente i messaggi falsi, così da ridurre o eliminare il [[Backscatter (posta elettronica)|backscatter]].