Sender Policy Framework: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m link interno |
mNessun oggetto della modifica |
||
Riga 5:
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,
In origine l'[[acronimo]] SPF doveva significare Sender Permitted From e a volte veniva anche chiamato SMTP+SPF, ma nel febbraio 2004 il suo nome venne cambiato nell'attuale Sender Policy Framework.
Riga 12:
== Principi di funzionamento ==
Il [[Simple Mail Transfer Protocol]] permette a ogni computer di inviare e-mail senza verifica del mittente: il messaggio può dichiarare di provenire da un qualsiasi indirizzo di origine. Ciò consente agli [[Spam|spammer]] l'uso di indirizzi e-mail falsi, rendendo più difficoltosa la tracciatura dell'origine di un messaggio e più facile nascondere la loro vera identità, allo scopo di sottrarsi alle loro responsabilità. 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.
SPF consente al proprietario di un dominio di definire le regole per identificare i server autorizzati a mandare e-mail con un indirizzo del mittente in quel dominio, utilizzando opportuni [[record TXT]] del [[Domain Name System]] (DNS). I destinatari sono in grado di confrontare la provenienza del messaggio con le regole SPF e, in caso di problemi, possono decidere di rifiutare i messaggi in arrivo da origini non autorizzate già prima di ricevere il contenuto del messaggio. I principi di funzionamento sono perciò similari a quelli delle "DNS-based blackhole lists" ([[DNSBL]]), ad eccezione del fatto che SPF utilizza lo schema di delegazione dell'autorità appartenente al Domain Name System. La pratica corrente richiede l'uso di record 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=april |editore=[[Internet Engineering Task Force|IETF]] |accesso=26 aprile 2014 }}</ref> proprio come nelle prime implementazioni. Nelle fasi iniziali di definizione venne registrato e reso disponibile un nuovo tipo di record (SPF, tipo 99) e l'uso di record [[.txt|TXT]] per SPF venne proposto come meccanismo alternativo di compatibilità per i software DNS che non lo supportavano. L'RFC sperimentale [[RFC 4408]] 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 [[RFC 7208]] 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 28 ⟶ 27:
== FAIL e l'inoltro ==
SPF impedisce l'inoltro di messaggi (
# colui che inoltra il messaggio non riscrive il
# 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”
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.
Riga 41 ⟶ 40:
Con una finta identità HELO il risultato NONE non aiuta, ma per nomi di host SPF validi protegge la identità HELO. Questa caratteristica SPF è sempre stata supportata come opzione per i destinatari, e successivi schemi SPF, inclusa la specifica finale, raccomandano di verificare sempre l'HELO.
Questo consente ai destinatari di mettere in una white list determinati mittenti, basandosi su un HELO PASS, oppure di respingere tutte le mail dopo un HELO FAIL. Questo meccanismo può essere utilizzato anche in “sistemi di reputazione” (
== Implementazione ==
La conformità con SPF si compone di 3 task correlati:
* '''Pubblicare una politica (policy)''': Domini e host identificano le macchine autorizzate a spedire email per loro conto. Fanno ciò aggiungendo record addizionali alle loro informazioni DNS già esistenti: ogni [[nome di dominio]] o host che ha un record di tipo A (
* '''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.
* '''Rivedere ed eventualmente correggere l'inoltro della posta''': l'inoltro di mail non "formattate" non è consentito da SPF. Le alternative sono:
Riga 51 ⟶ 50:
** Refusing (rifiutare, cioè rispondere <code>551 User not local; please try <user@example.com></code>);
** [[Whitelisting]], cioè mettere in una white list il server bersaglio, in modo tale che in futuro non rifiuti più un messaggio inoltrato;
**
|url = http://www.open-spf.org/SRS/
|lingua = en
| |||