Condivido il documento sulla sicurezza di Laura Abba, Antonino Mazzeo, Stefano Trumpy. In questa nota presento un dettaglio tecnico che a mio giudizio merita di essere considerato. Si tratta della Sender Policy Framework (SPF). SPF è stata pubblicata da IETF come RFC 4408 nell'aprile 2006.
Lo stato del protocollo è ancora sperimentale, anche a causa dei un altro protocollo apparentemente in conflitto, la Sender ID proposta da Microsoft™. Ritengo che il Forum sulla Governance di Internet dovrebbe prendere posizione sull'argomento. In particolare, auspico che il Comitato consultivo sulla governance di Internet chieda che SPF divenga uno standard e che i Governi Nazionali emettano la necessaria legislazione di supporto. Vorrei cogliere l'occasione, nel caso si ritenga necessario ufficializzare una sola tra le RFC 4405, 4406, 4407 e 4408 a discapito delle altre, di esprimere il mio voto personale a favore di SPF per le sue caratteristiche di semplicità, affidabilità, efficacia ed indipendenza da software proprietari di cui Sender ID difetta.
Questa nota si divide in cinque brevi parti. Cos'è SPF descrive per esemplificazione alcune possibilità offerte da SPF. Nel merito di SPF, MARID e IETF ricorda alcune ragioni per cui SPF si trova ancora nello stato di protocollo sperimentale. Legislazione e pratiche utili per il supporto propone di aggiungere il falso tra i crimini informatici e di pubblicare raccolte di indirizzi IP per aree giuridiche omogenee. Infine, Supporto da parte degli ISP e Responsabilità degli utenti sono due succinti promemoria sui passi necessari per implementare SPF e su quanto dovrebbe essere a conoscenza degli utenti di posta elettronica, in particolare di quelli che utilizzano un dominio che implementa SPF. La Conclusione riassume i punti esposti.
SPF pone una relazione tra l'indirizzo IP da cui proviene un
messaggio e-mail ed il nome a dominio di cui il mittente
fa parte. Vale a dire, viene pubblicato l'insieme dei server
di posta in uscita utilizzati da un dato
dominio.
Attualmente solo i server di exchange (MX) sono
pubblicati, per cui si sa dove consegnare un messaggio ma non si
sa se la sua provenienza è lecita.
Per esempio, il dominio tana.it può pubblicare
un'informazione del tipo i miei utenti non spediscono e-mail
dal Sud America, così i server di posta che ricevano un
messaggio con mittente vesely@tana.it da un indirizzo
IP sud-americano lo respingono in quanto è un abuso.
Il record ha questo formato:
tana.it. 86400 IN TXT "v=spf1 +ip4:194.243.254.162/31 ?ip4:80.0.0.0/5 ?ip4:90.0.0.0/7 ?ip4:193.0.0.0/8 ?ip4:194.0.0.0/7 ?ip4:212.0.0.0/7 -all"
Si noti che è possibile utilizzare il formato CIDR per abbreviare la lunghezza del record. I primi due IP sono abbreviati con /31 grazie al fatto che sono consecutivi. Questi sono contrassegnati con + (pass) dato che sono i server ufficiali di TANA. I rimanenti IP sono contrassegnati con ? (neutral) e coprono tutti gli IP europei, a meno di omissioni.
SPF serve a proteggere il buon nome di un dominio dagli abusi. Questo è di immediata utilità contro il phishing, si consideri quest'altro esempio:
C:\>nslookup -type=TXT bancaintesa.it Server: north.tana.it Address: 194.243.254.162 Aliases: 162.254.243.194.in-addr.arpa Non-authoritative answer: bancaintesa.it text = "v=spf1 ip4:193.227.214.20 ip4:193.227.214.21 ip4:193.227.214.22 ip4:193.227.214.23 ip4:193.227.214.24 -all" bancaintesa.it nameserver = gange.bci.it bancaintesa.it nameserver = stige.bci.it bancaintesa.it nameserver = venere.inet.it
Il record SPF è il testo mostrato tra virgolette. Che
si tratti di SPF lo si evince dalla dichiarazione di versione
v=spf1.
Il significato del record è intuitivo.
La banca è molto stringente nella sua policy: fornisce
esattamente 5 indirizzi IPv4, controllati, da cui possono
provenire messaggi autorizzati. I messaggi e-mail
che arrivino da qualsiasi altra parte millantando un mittente
interno alla banca, sono illeciti (-all).
La banca sta obbligando gli utenti del proprio dominio e-mail a utilizzare uno dei server di posta in uscita da lei controllato: una perdita di flessibilità per una migliore sicurezza. Nel primo esempio la perdita di flessibilità era minore, almeno finché i viaggi in Sud America restano infrequenti.
Nel
secondo esempio il name server north presso cui è
stato effettuato il look up, ha fornito l'informazione
come non-autoritativa. Cioè non ha richiesto il dato a
uno dei name server competenti in quanto se lo ricordava da una
richiesta recente: probabilmente proprio a causa di un tentativo di
phishing che è stato bloccato sul nascere.
SPF c'è e funziona.La sua efficienza è limitata dalla sua scarsa diffusione. In un giorno scelto a caso, su 100 messaggi bloccati prima dell'invio dei dati, 80 sono bloccati da liste nere DNS (spamhaus, mail-abuse), 19 da errori (connection reset, timeout) e 1 da SPF. Perché così poco? Perché pochi domini pubblicano un record SPF. Non conosco statistiche aggiornate, ma credo che quelle percentuali siano congrue con la percentuale di diffusione di SPF. Quelle percentuali stridono con il valore morale e semantico del blocco SPF, che è ordini di grandezza più alto di quello delle liste nere. SPF è una lista bianca distribuita, dove ciascun dominio pubblica la parte che gli compete.
SPF non identifica il mittente ma il dominio. (La certificazione del mittente è già possibile con S/MIME o OpenPGP.) SPF toglie la possibilità di abusare del nome di un dominio, identificando gli illeciti senza esaminare il corpo del messaggio.
SPF è nato nel 2003. Una semplice idea per bloccare i messaggi e-mail illeciti durante le prime fasi del protocollo SMTP. Ci sono stati errori e difetti sia nelle specifiche tecniche sia nelle pratiche di standardizzazione. I primi sono stati corretti e hanno portato a uno strumento semplice ed efficace che può essere di aiuto nella lotta allo spam.
Nel marzo 2004 IETF lanciò il gruppo di lavoro MARID. A maggio Microsoft annunciò il suo interesse per SPF. Meng Wong, cofondatore di Pobox.com e ideatore di SPF, si accordò con Microsoft per apportare tutte le modifiche necessarie per integrare SPF con Caller ID (come si chiamava allora la Sender ID). Meng Weng Wong lo comunicò nel maggio 2004 ai partecipanti al MARID. Non tutti furono entusiasti del cambio di rotta. Tuttavia, l'obiettivo del gruppo di lavoro fu modificato in modo da considerare le richieste di Redmond. Nel settembre 2004 il MARID fu chiuso, prima che potesse pubblicare anche un solo RFC, a causa delle insanabili divergenze che erano insorte. Quali?
Oltre ad alcuni stravolgimenti tecnici (p. es. l'utilizzo prioritario del corpo del messaggio, l'XML nel record SPF), Sender ID comporta l'utilizzo di un algoritmo brevettato da Microsoft. Microsoft permette l'uso dell'algoritmo senza royalties a quanti si impegnano a seguire le specifiche di Sender ID. Apparentemente, implementare la versione originale di SPF sarebbe quindi una violazione. Pobox non avrebbe potuto vendere a Microsoft il progetto SPF/MARID. Infatti il primo draft di SPF incorporava idee di Jim Miller, Paul Vixie e altri. In seguito molti hanno contribuito con correzioni e messe a punto in un clima di libero scambio di idee che era stato infine formalizzato col lancio del gruppo di lavoro da parte di IETF.
Può essere interessante confrontare questa situazione con un precedente tentativo di Microsoft di appropriarsi della comunicazione elettronica, nel 1996. Microsoft presentò un'interfaccia applicativa per il Messaging, MAPI, corredata da un numero di applicazioni a 32 bit, basata su un modello di posta proprietario. Il client Exchange, poi sostituito da Outlook, avrebbe dovuto essere adottato universalmente grazie alla larga diffusione di Windows, anche se non era del tutto compatibile con SMTP. Ebbe invece maggior successo il client proposto da Netscape. Ricordiamo però che il confronto attraversò anche le aule dei tribunali e che Netscape dovette subire gravi conseguenze economiche.
Questa volta Microsoft si è accordata con Pobox, che ha tradito lo spirito di aperta cooperazione che aveva portato allo sviluppo di SPF, per produrre un sistema formalmente incompatibile, per esempio, con la licenza GNU GPL. In sostanza l'accordo avrebbe reso proprietaria la verifica del mittente, un elemento di una certa importanza nella posta elettronica ai giorni nostri. Si veda anche For The Record, Will Microsoft Own Email?
Entrambi i tentativi sono naturalmente leciti. Del resto Microsoft dichiara apertamente di mirare al 100,00% del mercato del software. E' anche legittimo cercare il supporto dell'amministrazione USA, che è stata eletta democraticamente dai cittadini americani e che ha emesso il CAN-SPAM-ACT.
IETF, in quanto organismo tecnico, non ha avuto la competenza per fronteggiare il problema e ha pubblicato quattro specifiche sperimentali che sono più incompatibili tra di loro di quanto lo fossero nella primavera del 2004. Sebbene i dubbi siano espressi in forma tecnica, è abbastanza evidente che non sia questa la loro vera natura. In questo caso è auspicabile che l'Internet Governance sblocchi la situazione per il bene degli utenti finali.
Si veda anche Maybe the IETF Won't publish SPF and Sender-ID as Experimental RFCs After All.
L'efficacia di SPF nella lotta contro lo spam consiste nel contrastare lo spam con caratteristiche criminali. Normalmente viene chiamato spam qualsiasi messaggio e-mail spedito a un gran numero di destinatari senza che questi lo abbiano richiesto. Tuttavia un certo tipo di spam utilizza sistematicamente mittenti falsi. Commettere un falso solitamente viene considerato un crimine punibile con una qualche severità. Nel caso dei messaggi e-mail, i falsi sono così abbondanti che risulta poco pratico perseguirne gli autori. Di fatto, la maggior parte dello spam di tipo criminale proviene da continenti lontani, cosa che non facilita certo l'applicazione della legge.
Consideriamo di nuovo il primo degli esempi sopra, com'è possibile escludere il Sud America? Grazie al fatto che le grandi assegnazioni di indirizzi IP hanno seguito criteri geografici, risulta possibile raccogliere i blocchi di indirizzi delegati al RIPE. Purtroppo questo fornisce solo un indicazione geografica di massima. Tuttavia tra i criteri per l'assegnazione finale di un IP c'è anche l'identificazione giuridica dell'assegnatario. Dunque sarebbe possibile, se già non è stato fatto, trovare quali sono i cluster che ricadono, per esempio, sotto la legislazione italiana o europea. Così un dominio che ritenga preferibile obbligare i propri utenti soltanto se si trovassero all'estero od oltremare, a utilizzare certi server di posta in uscita, può pubblicare un record SPF che escluda soltanto le aree giuridicamente poco raggiungibili.
Tipicamente, per l'utente medio di un ISP, la scelta del server di posta in uscita può comportare considerazioni di riservatezza, praticità o convenienza economica. La tecnica appena descritta consente di modulare il rapporto tra flessibilità e sicurezza. Chi ha esigenze di sicurezza inferiori a quelle di una banca può implementare SPF mantenendo un'ottima flessibilità e delegando allo Stato la propria sicurezza.
Non c'è universale consenso tra gli Stati nazionali per quanto riguarda la privacy. Alcuni, forse sopravvalutando i benefici economici del marketing a costo zero, consentono maggior liberalità di altri (opt-out, opt-in). In nessun caso, comunque, può essere giustificato chi commette un falso durante la spedizione di e-mail al pubblico. Il falso è un reato più grave della violazione della privacy, l'aggravante della larga diffusione lo rende intollerabilmente grave. A che pena andrebbe incontro chi invadesse le edicole con un'edizione apocrifa di un giornale? Sia gli autori materiali sia i mandanti di tale tipo di invio dovrebbero come minimo essere tenuti al pieno risarcimento dei danni morali e materiali.
SPF, bloccando i messaggi i cui autori non sarebbero facilmente perseguibili in pratica, permette di concentrarsi sui casi in cui può essere probabile ottenere un rimborso. In questo modo la lotta allo spam viene dotata di armi legali efficienti.
Il software necessario all'implementazione di SPF è largamente disponibile per i tipi di server maggiormente in uso. Trattandosi per solito di distribuzioni open source, la loro diffusione non presenta problemi.
Implementare SPF per un dato dominio non è però un compito puramente tecnico. I passi da compiere si localizzano in tre aree in qualche modo indipendenti una dall'altra:
TXT per ogni record A
o MX.
Pubblicare la propria policy aumenta la diffusione di SPF.
La modifica va effettuata sul name server.
La policy dev'essere decisa dal responsabile del dominio.
I dettagli del formato del record sono spiegati sul sito SPF dove c'è anche un wizard.
Forse nell'intento di ottenere una maggiore diffusione, è
stata a lungo consigliata l'opzione di terminare i record SPF con
la locuzione ~all, che di fatto vanifica lo sforzo di
adozione di SPF. Il corrispondente caso softfail può
essere utile per periodi di breve durata (ore, non mesi).
Accettare softfail è quella che ho chiamato una decisione
piuttosto ovvia.
La policy deve terminare con -all per essere efficace.
La conoscenza degli utenti è spesso sotto la soglia della
sufficienza. Mentre tutti sanno cosa sia un prefisso telefonico,
pochi hanno la consapevolezza che i nomi a dominio si leggono da
destra a sinistra. Molti utenti purtroppo ignorano che il mittente
e i destinatari di un messaggio sulla busta non hanno
necessariamente gli stessi valori dei campi omologhi
nel messaggio. La traduzione di campi quali
Return-Path, From e Reply-To,
ne ha sminuito il carattere formale senza migliorarne la
comprensione.
Il fatto che in questi campi sia possibile scrivere qualsiasi
cosa ha reso la confusione totale.
Deprecabilmente, alcuni client di posta non permettono di visualizzare il sorgente di un messaggio. Quand'anche questo è permesso, manca la spiegazione del significato dei campi dell'header.
Nel caso di SPF, viene richiesto all'utente di essere
consapevole del server di posta in uscita che utilizza.
L'utente dev'essere edotto che il dominio usato (la parte a destra
della chiocciola) debba essere convalidato dal server
di posta in uscita.
Questo concetto spiega perché il server di posta in uscita
possa richiedere una password.
Inoltre, chi adotta SPF può assicurare gli utenti
che il campo Return-Path passi un controllo
formale.
Nel caso non sia pratico connettersi con uno dei server di
posta in uscita ammessi, è necessario usare temporaneamente un
altro indirizzo e-mail.
(Tecnicamente basterebbe usare un diverso MAIL FROM,
che diverrà il Return-Path,
e mantenere lo stesso mittente From.)
Questa è l'unica limitazione per l'utente finale.
Nel documento sulla sicurezza non compare il termine SPF, assente anche in La rete contro lo spam, che cos'è, come combatterlo, eccetto che per il contributo di Raimondo Bruschi, Maintainer e provider fra spamming e proibizionismo.
SPF è invece un protocollo sufficientemente maturo che si trova nello status sperimentale solo a causa di un fraintendimento. Procrastinare, per deferenza verso Microsoft™, l'adozione di uno strumento esistente ha l'effetto di lasciare maggiore spazio allo spam con caratteristiche criminali.
Per migliorare la sicurezza, abbiamo proposto che