Sender Policy Framework: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m Aggiunta grassetti |
Funzionalità collegamenti suggeriti: 3 collegamenti inseriti. Etichette: Modifica visuale Modifica da mobile Modifica da web per mobile Attività per i nuovi utenti Suggerito: aggiungi collegamenti |
||
Riga 1:
{{Correggere|informatica|Febbraio 2017|Per favore aiuta a chiarire i passaggi poco chiari, probabilmente frutto di una traduzione da revisionare}}
Il '''''Sender Policy Framework''''' ('''SPF''') è uno standard di [[autenticazione]] email utilizzato per prevenire la falsificazione degli indirizzi [[Posta elettronica|email]] durante l'invio di messaggi. Lo scopo principale di SPF è fornire un meccanismo per verificare l'autenticità dell'origine di un'email, contribuendo così a combattere lo [[spam]] e il [[phishing]]. SPF consente ai proprietari di domini di specificare quali [[server]] sono autorizzati a inviare email a nome del loro dominio, riducendo il rischio di email contraffatte. Quando un server di posta riceve un'email, verifica l'[[indirizzo IP]] del server mittente con il record SPF associato al dominio del mittente. Se l'indirizzo IP del server non è autorizzato dal record SPF, il messaggio potrebbe essere considerato sospetto o respinto. SPF supporta istruzioni di controllo, come "[[SOFTFAIL]]" (ammesso con avvertimento) o "FAIL" (rifiutato), in base alla corrispondenza tra l'indirizzo IP del mittente e il record SPF. SPF è uno strumento utile per ridurre la falsificazione degli indirizzi email, ma è spesso utilizzato in combinazione con altri metodi di autenticazione, come [[DomainKeys Identified Mail]] (DKIM) e Domain-based Message Authentication, [[Reporting, and Conformance (DMARC)]], per migliorare la 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 divenne realtà solo nel 2002, quando Dana Valerie Lank pubblicò indipendentemente dalla prima menzione un abbozzo di specifica SPF nella [[mailing list]] “namedroppers” della [[IETF]]. Il giorno successivo, [[Paul Vixie]] pubblicò la propria versione di specifica SPF sulla stessa lista. Queste pubblicazioni suscitarono molto interesse, finendo con il portare 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'ASGR ci furono quelle del “Reverse MX” di Hadmut Danisch e del “Designated Mailer Protocol” 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 vennero apportati un gran numero di cambiamenti e una numerosa 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>
Riga 88:
* '''<kbd>+</kbd>''' per un risultato PASS (test superato). Può essere omesso; per esempio <kbd>+mx</kbd> equivale a <kbd>mx</kbd>.
* '''<kbd>?</kbd>''' per un risultato NEUTRAL (neutrale), che viene interpretato come NONE (nessuna politica).
* '''<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.
* '''<kbd>-</kbd>''' (meno) per un risultato FAIL (fallimento), la mail dovrebbe venire respinta (vedi sotto).
| |||