|
== 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 ==
|
