LO SPAM: "BUG" OPPURE … "FEATURE" ?

Introduzione

Se questo articolo lo avessi scritto non molti anni orsono, immagino che lo avrei iniziato con una descrizione di che cosa è lo SPAM, e perché va considerato un problema serio e da combattere. Ma oggi, anno 2004, tutti coloro che possiedono una casella di posta elettronica sulla rete Internet conoscono anche troppo bene il significato del problema, e quando sentono parlare di SPAM non pensano certo allo "SPiced hAM" da cui il fenomeno ha preso il nome, né certamente al film di Monty Python dove una banda di allegri Vichinghi un po' pazzi canta un travolgente "crescendo" in coro fino a sommergere ogni altro suono o frase.

La prima cosa che infatti tutti pensano è la sgradevole sensazione che provano, quando aprendo la propria casella di posta elettronica, si ritrovano l'indice dei nuovi messaggi pieno di centinaia di messaggi che nessuno di loro ha mai richiesto di ricevere. Ma visto che "repetita juvant", e che forse tra i lettori c'è ancora qualcuno che non ha capito di cosa stiamo parlando, diciamo che lo SPAM è uno dei principali problemi che preoccupano gli utenti della rete Internet e consiste nella trasmissione su di essa di milioni di messaggi di posta elettronica, contenenti le più svariate informazioni (nella maggior parte di tipo commerciale) che nessuno degli innocenti destinatari aveva richiesto di ricevere. In alcuni casi, sopratutto per i nuovi arrivati sulla rete, il fenomeno è tale da addirittura scoraggiare l'uso della posta elettronica come servizio: "la mia casella è talmente infestata che non la uso", mi ha risposto un giorno una delle persone a cui avevo telefonato per chiedere come mai non avesse dato corso ad un'azione che gli era stata richiesta con una e-mail.

Molte delle discussioni su come affrontare e risolvere il problema si concentrano spesso su uno degli aspetti del problema (sopratutto quelli tecnici o quelli giuridici); questa "introduzione" è stata però focalizzata a da un punto di vista leggermente diverso:

  • esaminare in modo anche provocatorio le cause implicite che rendono lo SPAM possibile;
  • dare un "early preview" di quanto si sta pensando di fare a livello di architettura del servizio di posta elettronica per rendere impossibile o almeno molto difficoltosa l'opera di chi cerca di abusare del servizio.

La "provocazione" inizia dal titolo stesso: ho infatti voluto deliberatamente far pensare al problema da un punto di vista non emozionale, ma di ingegneria del sistema. Se, come spero di potervi mostrare, gli spammer riescono così bene nella loro opera, forse il meccanismo usato dagli spammer è una caratteristica implicita del sistema, e non un difetto. Inoltre, proviamo a vedere se i principali responsabili dello SPAM sono davvero solo "gli altri", o se invece bisogna cercare anche e sopratutto tra di noi… Ma che cosa significa quel "noi" ? proviamo a fare un elenco:

  • noi, utenti e consumatori sulla rete;
  • noi, possessori (e spesso amministratori) di un computer collegato alla rete;
  • noi, amministratori di sistemi condivisi; § noi, amministratori locali di rete; § noi, fornitori di connettività e servizi di rete geografica;
  • noi, produttori di software (sistemi operativi, applicazioni, …);
  • noi, architetti di protocolli e servizi di rete;
  • noi, giuristi e legislatori;
  • noi, organismi di vigilanza;
  • noi …

c'è qualcuno tra i lettori di cui mi sono dimenticato? I più numerosamente colpiti dal problema sono ovviamente gli utenti e consumatori della rete… ma scorrendo l'elenco dei soggetti coinvolti, vediamo che la lista è purtroppo molto lunga… da cui anche l'origine della domanda inquietante finale. Analizziamo quindi le varie categorie.

Gli utenti e consumatori sulla rete

Lo SPAM ha un senso se produce benefici per chi lo utilizza come mezzo di promozione delle proprie idee o prodotti. Sto parlando del tornaconto (economico e non) per:

  • chi promuove qualche cosa tramite la rete come strumento di comunicazione (il "mandante");
  • chi si incarica di veicolare e distribuire i messaggi stramite la rete (lo "spammer', ovverosia "l'esecutore").

I costi di invio del messaggio sulla rete, essendo quasi tutti a carico dei destinatari dei messaggi stessi e delle infrastrutture di trasporto (altrui) che vengono sfruttate indebitamente, sono bassissimi per l'esecutore. Questo permette di offrire ai mandanti dei costi di "servizio spam" decisamente bassi, e tali da rendere economicamente appetibile il servizio per chi non si pone troppi scrupoli nelle proprie strategie di vendita.

Tra i mandanti poi vi sono anche molti nuovi arrivati sulla rete. Costoro, oltre a non conoscere usi e costumi (netiquette) della stessa, spesso ignorano totalmente anche l'esistenza della legislazione in materia di commercio elettronico, e quindi sono propensi a cadere ingenuamente e facilmente nella trappola "ti faccio una pubblicità enorme a basso costo" che gli esecutori propongono loro. Di tutt'altra natura sono invece i "mandanti in mala fede": una percentuale molto elevata di mandanti ha infatti come obiettivo non la vendita di veri prodotti o servizi, ma la truffa del consumatore ingenuo.

Per questi truffatori del cyberspazio lo SPAM è uno strumento infatti efficientissimo per fare nuove vittime. Una statistica abbastanza accurata basata sugli ultimi 12 mesi, indica purtroppo che se anche una percentuale bassissima (0.001%) dei messaggi inviati produce una transazione (o convince un destinatario di quanto proposto), gli esecutori e mandanti hanno già coperto i propri costi, e passano in attivo una situazione che sicuramente rende ancora più difficile combattere il fenomeno, perché appunto si basa su "grandi volumi" di messaggi inviati.

Una possibile strategia per agire nel campo degli utenti/consumatori, consiste quindi nel rendere commercialmente inappetibile il servizio di spam. Ma come? Sicuramente l'educazione dell'utenza gioca come sempre un ruolo importante in questo. Ha una alta utilità sociale, cosi come lo ha ad esempio educare l'utente consumatore a non fasi raggirare in genere da truffe o offerte allettanti. Però ha anche un'efficacia scarsa per combattere il problema: infatti una soglia di break-even così bassa (0.001%) è tale che siamo al di sotto del limite fisiologico dell'ingenuità implicita nella psicologia umana dell'acquirente.. Ma questo non significa rinunciare all'educazione, anzi! Non risolveremo il problema, ma avremo un'utenza mediamente più consapevole.

E se aumentassimo i "costi di spedizione" per mandanti ed esecutori? Avrebbe un'efficacia alta, perché romperebbe il modello economico… ma dobbiamo stare attenti a non risolvere il problema distruggendo il servizio. La posta elettronica ha i suoi indubbi vantaggi di praticità, velocità ed "economicità" che la rendono un servizio superiore rispetto ad altri mezzi più tradizionali. Se la rendiamo talmente costosa (in termini monetari o anche, come qualche grande multinazionale ha follemente proposto di recente, in termini di risorse di computer e di rete), il modello stesso del servizio si rompe e nessuno la utilizzerebbe più: sarebbe come, per usare una citazione nota, "risolvere il problema delle tarme in un armadio dando fuoco all'armadio stesso".

Più percorribile sembra invece una strategia volta a togliere il mercato agli esecutori, rendendo non economicamente conveniente l'uso del loro servizio ai mandanti. L'efficacia è sicuramente alta: senza "clienti mandanti" lo spammer esecutore non guadagna, facendo aumentare per lui enormemente i prezzi del suo deprecabile "servizio".

Vediamo più in dettaglio: l'origine del messaggio promozionale è sempre ben indicata nel messaggio stesso: altrimenti il consumatore/vittima non saprebbe chi contattare per il suo acquisto, quindi identificare il mandante è in qualche modo più semplice che identificare l'esecutore.

C'è poi anche il vantaggio di "spingere il bacino dei venditori" verso un comportamento di mercato più corretto: se utilizzi tecniche non lecite, oltre a pesanti ripercussioni economiche (sanzioni), avresti anche pesanti ricadute d'immagine, se venisse applicata molta pubblicità alle sanzioni applicate. Il rovescio della medaglia consiste nel creare una potenziale fonte di abuso e di concorrenza sleale tra venditori: se invio messaggi pubblicitari fingendo di essere il mio concorrente, e grazie all'anonimato che lo spam in qualche modo garantisce, finisco per fargli avere sanzioni e cattiva pubblicità, ho dato vantaggio alla mia azienda. Si tratta di un problema di "attacco indiretto" non indifferente da gestire!

I possessori di un computer personale collegato in rete

Abbandoniamo ora quelli per i quali il computer è "quel televisore con una tastiera attaccata" (una definizione di ormai molti anni fa, infatti non viene citato il mouse,… ma di un personaggio piuttosto famoso, la mia docente di astronomia, Margherita Hack), e veniamo a coloro che in qualche modo un pochino di più capiscono di cosa c'è dentro quel "televisore interattivo".

Se per esser in regola con il servizio televisivo, almeno in Italia, basta pagare il canone di abbonamento dei fornitori di servizi, per essere "in regola" come possessori di un computer connesso alla rete vi sono altri doveri tecnici (nonché morali) da rispettare. Il computer non è uno strumento passivo sulla rete, ma un agente attivo, e come tale deve essere tenuto in efficienza e sopratutto sotto controllo. Quindi, mantenere "sicuro" il proprio computer (applicando le patch in modo costante ed accurato), eseguire configurazioni corrette del software installato ed in generale "non accettare mai caramelle dagli sconosciuti", sono fondamentali elementi di ordinaria manutenzione che tutti dovrebbero eseguire.

Anche qui, ovviamente, l'educazione e la divulgazione delle informazioni è un elemento importante. Ancora più importante, a mio modesto parere, è "l'educazione dei divulgatori", ovverosia dei media, che purtroppo spesso sono ancora a livello di leggende metropolitane e disinformazione, specialmente quando si disserta di problemi di sicurezza o di patologie della rete quale appunto lo SPAM.

Oggi sono proprio i "computer ad uso personale" la risorsa (altrui) principalmente usata dagli spammer esecutori per i propri invii massivi, mettendo migliaia di macchine a propria disposizione dopo averle attaccate e corrotte con l'invio di virus e trojan che rendono il computer vittima un server aperto a disposizione per l'invio di SPAM. Purtroppo ancora troppo spesso si sentono possessori di computer commentare così: "ho ricevuto un virus, ma non mi ha fatto nessun danno"… nessuno gli ha spiegato che i nuovi virus non hanno alcuna intenzione di danneggiare la macchina o i suoi contenuti, anzi… intendono rendere il più efficiente possibile per l'invio di messaggi, mettendola a disposizione di sconosciuti, e quindi ritorniamo sul discorso importantissimo della divulgazione ed educazione.

Gli amministratori di sistema Se chi possiede un computer a livello personale è anche amministratore della propria macchina ed ha i doveri elencati in precedenza, chi amministra professionalmente sistemi multiutenza o che rendono disponibili servizi in rete ha responsabilità e doveri ancora più elevati. Oltre a quanto già indicato, ed agli ovvi principi di non permettere intrusioni sulle proprie macchine, qui il principio della "sorveglianza proattiva" come il regolare controllo dei log e dello status delle proprie macchine diviene un'attività importante. "Le mie macchine sono così ben settimane e mesi" si rivela troppo spesso la convinzione di molti amministratori di sistema quando vengono contattati dai servizi di sicurezza sulla rete per segnalargli seri problemi a bordo. Più si controlla, meno c'è la possibilità che qualche spammer sfrutti la macchina per i suoi scopi.

Gli strumenti tecnici per eseguire controlli di routine esistono, e basta utilizzarli: anche chi non controlla mai lo stato di efficienza della propria automobile, prima o dopo rimane appiedato. E così come è poi importante correre rapidamente ai ripari, lo è anche il reagire prontamente alle richiesta di intervento per rimuovere eventuali problemi dal proprio computer; non dimentichiamo infatti che sta diventando sempre più pratica comune isolare dalla rete "a monte" i computer che creano problemi, sino a quando il loro amministratore non intervenga sulla macchina. Un ulteriore campo d'intervento degli amministratori di sistema è l'installazione di sistemi di difesa passiva, primi fra tutti i sistemi di identificazione e neutralizzazione dei virus.

Se a volte l'utente finale non è così diligente nel tenere ben protetta la propria macchina, è ancora più importante che i server di mail provvedano a filtrare preventivamente le minacce d'infezione provenienti sia dall'esterno che dall'interno: non dimentichiamo che più di un caso di epidemia interna si è verificato perché un singolo computer è stato infettato tramite un virus arrivato non via rete (il solito vecchio floppy), e poi ha contagiato una intera LAN perché le difese erano installate solo verso l'esterno!

Gli amministratori di rete (locale o interna)

Gli amministratori di rete locale o interna (intranet) sono altrettanto importanti degli amministratori di sistemi e dei possessori di un personal computer. Sono infatti il gradino immediatamente successivo nel sistema di difesa dei computer da attacchi ed abusi. La prima azione che un amministratore accorto deve intraprendere è quella di analizzare e conoscere le necessità di comunicazione e servizi per i propri scopi istituzionali e per i propri utenti.

Definita questa situazione (spesso variabile nel tempo e quindi necessaria di continui aggiornamenti) si devono intraprendere le misure necessarie per lasciar passare sulla propria rete solo quanto è necessario a questi scopi, impedendo o limitando in modo efficace il resto del traffico. Posizioni del tipo "i miei utenti richiedono che sulla mia rete deve poter passare tutto" sono spesso non giustificate da un'analisi più approfondita della situazione, e tranne i casi in cui la rete locale o intranet fa parte di un servizio commerciale di connettività generica, non sono valide.

Anche per gli amministratori di rete locale, il monitoraggio è un'azione importante: conoscere quanto avviene sulla LAN o intranet e sul proprio collegamento con l'esterno (quando esiste ed è sotto il proprio controllo e non di un fornitore di servizi) è un ulteriore passo per combattere il problema dello SPAM.

Sia nei casi in cui il traffico dati è notevole, variegato e complesso, sia in quelli in cui la situazione si presenta più tranquilla, una strategia che tutti dovrebbero adottare consiste nell'installazione di strumenti di monitoraggio, ed ove possibile di allarme automatico. Non appena si presenta una situazione di traffico anomala, o anche solo stranamente diversa dalla tipologia a cui siamo abituati, è necessario indagare immediatamente per scoprire le cause, ed intervenire immediatamente di fronte alle situazioni di abuso. Un proxy lasciato aperto anche solo per poche ore permette che molte migliaia di messaggi di spam siano inviati a vostre spese…

Oltre allo sfruttamento delle vostre risorse ed al degrado del servizio per i vostri utenti, vanno considerate anche le conseguenze indirette: la lunga coda di proteste che riceverete e di spiegazioni che dovrete dare per le successive settimane a chi vi contatterà, nei più svariati stati d'animo vi costeranno probabilmente più del disservizio stesso. La necessità dell'intervento immediato è ancora piu' importante nel momento il cui la segnalazione del problema vi arrivi dall'esterno, in quanto voi non ve ne siete accorti.

È infatti pratica abbastanza comune ormai che, se una situazione di abuso viene segnalata dall'esterno, ma non vi è un intervento rapido da parte dei responsabili "locali", i servizi di sicurezza delle rete esterna bloccano tramite appositi filtri l'accesso da e per la rete per le macchine coinvolte.

I fornitori di connettività e servizi di rete

Ma, se io sono responsabile dentro alla mia rete locale, il fornitore di connettività globale di rete non ha meno responsabilità e doveri. Le metodologie d'intervento però risultano diverse in questo caso.

Infatti, l'applicazione di contromisure ed un efficacie monitoraggio del traffico risultano molto difficili: gli utenti di un fornitore di servizio pubblico di connettività sono l'intera gamma di possibili utenti, e come tali hanno l'intera gamma di esigenze; è perciò praticamente impossibile definire tipologie di traffico ammesso, o identificare modelli di traffico da classificare come "normali".

La strategia d'intervento quindi deve spostarsi, e passare nel campo delle "policy" di uso della rete, delle misure adottate in caso di violazioni, ed ovviamente alla sua implementazione pratica ove si presentino abusi.

Un fornitore di servizio che non abbia una policy sull'uso accettabile dei propri servizi di connettività e che quindi non abbia a disposizione strumenti anche contrattuali per sanzionare i propri utenti che non rispettano le regole, contribuisce alla prosperità dello spam in maniera altrettanto cospicua di chi non amministra bene le proprie risorse.

Viene da se che, oltre ad aver delle regole, l'importante è farle rispettare ed agire di conseguenza in tempi rapidi.

Il ruolo dei produttori di software

Sinora abbiamo esaminato le misure che si adottano sul campo di azione per combattere il fenomeno dello spam. Ma un contributo importante alla prevenzione deve essere fornito anche da coloro che producono il software installato sui computer connessi in rete.

Se inizialmente il passepartout era costituito dai mail relay lasciati "aperti" in quanto mal configurati, oggi la grande massa dello spam si appoggia su proxy server (o simili) appositamente creati e diffusi tramite virus, che si installano non più su macchine mailer principali, ma sui personal computer ad insaputa dell'utente/proprietario. Il problema della configurazione "aperta" di default dei software di mail installati sta venendo rapidamente risolto, ed ormai le configurazioni di base consegnate chiavi in mano all'utente sono piuttosto ben difese o comunque difendibili.

Resta però l'enorme falla di sicurezza che, opportunamente sfruttata dai virus, permette a questi di installare proxy server aperti su milioni di macchine. L'intervento in tempi rapidi con "patch" alle vulnerabilità note, e sopratutto la collaborazione aperta tra produttori, pur nel rispetto del segreto industriale di ciascuno di essi, sono indispensabili strumenti per combattere il problema.

Legislatori e Giuristi

Se i tecnici devono fare la loro parte, anche ed ancora di più è importante che giuristi e legislatori producano normative che siano adeguate ai nuovi paradigmi della rete, primi fra tutti la sovra-nazionalità dell'ambiente, e la necessità di leggi e regolamenti coerenti tra paesi diversi. La rete infatti annulla le distanze geografiche ed il concetto di localizzazione di servizi ed utenti, e questo ha effetti potenzialmente disastrosi nel caso di attività illecite.

L'esistenza sulla rete di "paradisi" per attività illecite, anche nel più remoto angolo del pianeta, è ben più deleteria di qualsiasi "paradiso fiscale" o simile in altri campi. Infatti un "paradiso degli spammer" anche agli antipodi, è un paradiso in casa nostra, ma molto difficile da perseguire legalmente.

Un'ulteriore punto su cui è molto importante insistere: giuristi e legislatori devono colloquiare ed interagire con i tecnici del settore, per evitare di scrivere leggi e regolamenti inattuabili, o ancor peggio dannosi. E lo stabilire un linguaggio comune ed una comprensione reciproca è fondamentale.

Una volta che la legislazione sia presente ed armonizzata, la palla passa immediatamente agli organismi di vigilanza, nonché di controllo ed eventuale intervento. Per ottimizzare l'azione verso il risultato migliore, anche qui devono esistere canali preferenziali per l'interazione tra le realtà della rete e gli organismi di controllo, ed anche questi canali devono prescindere dalla realtà "nazionale" della rete.

Ulteriore, ma non ultimo, compito degli organismi di vigilanza è quello di agire con rapidità, e sopratutto di concerto con gli organismi interni di controllo della rete stessa. L'oculatezza nell'azione è fondamentale: è molto meglio a volte lasciare agire uno spammer per un po' di tempo per scoprirne le relazioni e le complicità, che intervenire immediatamente stroncando il problema puntuale, ma senza scoprirne le connivenze e complicità.

La responsabilità "paterna": l'architettura del sistema

Chi ha inventato il sistema della posta elettronica sulla rete Internet, lo ha fatto basando i propri principi su degli assunti validi per la rete degli anni '70, ed ha basato molto dell'architettura sul quella "S" ("simple") del protocollo SMTP.

Provate a pensare cosa era per voi la rete negli anni '70: per molti di voi probabilmente non era nemmeno una ipotesi remota della vostra mente, e per i pochi che erano presenti su di essa, era una qualche cosa che stava venendo inventato, ma per servire "un club ristrettissimo e privato di gentiluomini"; era un mondo in cui si può quasi dire che tutti conoscevano tutti, un piccolo villaggio virtuale, dove il concetto di "abuso" non era nemmeno concepibile.

Quindi, noi che la rete la abbiamo progettata, ed ora noi che la rinnoviamo continuamente nei suoi servizi siamo anche responsabili del problema dello SPAM.

Lo SPAM non è basato su alcuni difetti minori dell'architettura del sistema di posta elettronica, è una caratteristica implicita nel sistema stesso, così come è stato disegnato ormai molto tempo fa.

… non è un BUG…. è una FEATURE del sistema di posta elettronica!

SMTP: un sopravvissuto dei felici 'tempi remoti"

Come vedete nella vignetta, gentilmente concessa da OpenBSD, in fondo al mare ci sono già molte tombe… SMTP è uno dei pochi superstiti dei tempi antichi, essendo un coetaneo di RLOGIN, di TELNET di RSH, di FTP, ma a differenza di questi, ormai praticamente scomparsi ed utilizzato solo da pochi "amanti del rischio a tutti i costi", è ancora vivo e vegeto ed è la base (con ritocchi di styling nel corso del tempo) dell'intero sistema di posta elettronica Internet.

Vediamo un po' in dettaglio quali sono le sue caratteristiche che lo rendono uno strumento così idoneo per la diffusione dello SPAM, dal punto di vista ingegneristico ed architetturale.

"HELO", avanti! La porta è aperta!

Quando il dialogo SMTP inizia, non vi è alcuna autenticazione tra le parti che iniziano a parlarsi (client/server o server/server), e l'esordio del dialogo (HELO o EHLO) è una porta aperta a chiunque intenda entrare nella catena di distribuzione dei messaggi di posta elettronica.

Questa è una caratteristica voluta dell'architettura, proprio per rendere il più semplice possibile "entrare nel club" del trasporto di posta elettronica. Chi ha pensato questa caratteristica, ovviamente si basava sul comportamento etico di un bacino di utenti molto diverso da quello attualmente sulla rete. Non dimentichiamo che si trattava della comunità delle ricerca scientifica (anzi, di una parte estremamente ristretta di questa, per essere precisi), con principi di collaborazione ed interscambio che non sono esattamente gli stessi della comune società umana.

Nell'architettura non sono nemmeno previsti, in alcun modo, meccanismi per indicare quale sia il bacino d'utenza che un "agente di posta elettronica" deve servire. Un server si comporta come una buca delle lettere che non sa nemmeno controllare se sulla busta c'è il francobollo, né di che paese è l'eventuale francobollo. Non c'è modo di limitare, all'interno del protocollo, il bacino d'utenza di uno di questi "server".

Recentemente, sono state sperimentate possibili soluzioni tecniche per rimediare a questo problema, basate su servizi esterni al protocollo SMTP stesso. I tentativi però non hanno sinora dato buon esito: innanzitutto la scalabilità del sistema per questi nuovi add-on esterni rimane un'incognita, per non parlare del fatto che non tutta la comunità è d'accordo sugli effetti positivi che questi sistemi possono avere.

Il gruppo di lavoro dell'Internet Engineering Task Force (IETF) che ha cercato di standardizzare un sistema, si è sciolto con un nulla di fatto per la eccessiva divergenza delle opinioni. SMTP ha poi un'altra feature che si dimostra molto utile a chi vuole commettere abusi: non vi è alcuna correlazione tra le informazioni utilizzate per instradare i messaggi a destinazione, e quanto poi viene scritto nelle intestazioni dei messaggi recapitati ai destinatari.

L'utente quindi vede informazioni sul mittente e sull'intero handling del messaggio che possono non avere nulla a che fare con le vere informazioni usate del trasporto per la consegna. Risulta quindi molto facile confondere le acque, e diffondere informazioni fuorvianti. Oltretutto le informazioni vere del routing sono "volatili" e rimane alla bontà dell'implementazione il lasciare tracce più o meno utili di queste informazioni. Se non bastasse, questa informazione è generalmente inaccessibile all'utenza del servizio, per cui il ricostruire la vera traccia di un messaggio di posta elettronica diventa un problema molto complesso.

L'implementazione del trasporto è poi davvero simple (mail transport protocol). Talmente semplice che è possibile condensare in poche linee di codice un agente d'invio messaggi efficientissimo; questo rende possibile infilare un agente di invio messaggi nei vuoti di sicurezza lasciati su un personal computer nemmeno troppo potente, ed ottenere una efficienza d'invio davvero formidabile.

Se aggiungiamo poi che le estensioni (ESMTP) non sono affatto obbligatorie, così come non lo è l'implementazione del meccanismo di autorizzazione (AUTH)… e la frittata è presto fatta.

Le "pezze" al sistema di trasporto della posta elettronica

Le estensioni pensate per migliorare la situazione, anche se venissero ipoteticamente supportate da tutti, non sono comunque in grado di risolvere il problema globale: AUTH autentica infatti solo una parte dell'accesso al servizio di trasporto dei messaggi, e come già indicato in precedenza, ora sono i proxy server, spesso installati come backdoor dai virus, le vere sorgenti di messaggi indesiderati nel trasporto; ed in questo caso senza usare direttamente alcun server SMTP ufficiale e quindi ipoteticamente difeso dal meccanismo di AUTH.

Anche gli altri metodi di limitazione del problema hanno i propri difetti e limiti. Le black list e le tanto discusse "block list" limitano il disagio, ma non possono eliminarlo a priori. Sono una cura contro i sintomi, ed offrono una limitata "protezione a monte", non sono un vaccino

I check sul DNS sono stati subito abbandonati, infatti la risoluzione inversa indirizzi è spesso in disordine, in quanto non vitale per altri servizi alla rete, e quindi non è una fonte d'informazione utilizzabile in modo affidabile.

L'implementazione di policy anti-relay è servita molto, ma la rete è globale… una falla in una zona "depressa" e poco sorvegliata è un problema immediato per tutti. In queste aree l'adeguamento delle istallazioni e delle risorse richiede spesso tempi lunghi, ed è spesso dipendente da fattori economici diversi da quelli tecnici: il s/w nuovo necessita di nuovo h/w che è costoso o non disponibile etc etc…

Sempre da non dimenticare che le soluzioni anti-relay, ed altre soluzioni antispam, sono soluzioni implementate localmente sulla singola macchina, e quindi non sono "globali", così come i meccanismi di controllo sulla autoritatività (autorizzazione di un mail server a ricevere e maneggiare posta da un certo "realm") sono ancora molto sperimentali.

Con tutte queste feature a disposizione, il servizio di trasporto del mail è l'ideale quindi per chi ne vuole abusare, e gli spammer ne conoscono a fondo le caratteristiche e sono pronti a sfruttarle molto abilmente. Non c'è da stupirsi quindi che vi siano programmi di invio spam tanto efficienti appositamente confezionati dentro pochi kilobytes di codice.

Se poi aggiungiamo che uno dei principi fondamentali di Internet è la "compatibilità all'indietro" dei protocolli, si capisce che è praticamente impossibile tenere l'architettura di SMTP ed al tempo stesso eliminare le feature favorevoli agli spammer.

Che fare?

Forse la cosa che può sembrare la più difficile da realizzare in assoluto: Aggiungere la lapide di SMTP a quelle degli altri protocolli "historical" abbandonati?

Per mantenere la compatibilità, come detto, non è possibile risolvere il problema, perché le caratteristiche di SMTP usate dagli spammer sono componenti fondamentali della sua architettura.

Quindi bisogna cambiare radicalmente architettura, sostituendola con un nuovo sistema. Le motivazioni a questa radicale possibile decisione non sono solo quelle derivanti dal problema dello SPAM, ma anche dalla necessità d'integrazione di servizi di messaggistica mobile (SMS, MMS, 3GPP,…), dalla comparsa di messaging agents "leggeri", interni a device che non sono necessariamente dei computer, dalla necessità di soddisfare utenti che migrano da una locazione all'altra della rete: cosa che SMTP non è bene in grado di soddisfare, se non con complicati meccanismi aggiuntivi: che senso ha che il messaggio mi arrivi nella mia mailbox, in Europa, quando sono ad una riunione di lavoro in Giappone, e chi me lo spedisce sta fisicamente dall'altra parte del tavolo?

È quindi nato, all'inizio del 2004, il gruppo di brainstorming "Mail Next Generation", (mailing list: mail-ng@imc.org) composto da tutti coloro che in qualche modo hanno inventato la posta elettronica, e da coloro che hanno contribuito a modificarla e migliorarla negli anni. Vi sono ovviamente anche tutti

I maggiori produttori di s/w per messaggistica, nonché gli esperti di security. Questo gruppo non è ancora un gruppo di IETF… perchè siamo ancora ben lontani dalla specifica di un protocollo; in questo momento si sta facendo il "conceptual design", cercando di individuare i requirement di base.

Ecco un interessante (e lungo) elenco, non esaustivo, in continua evoluzione, e sicuramente non ordinato, di alcuni dei requirements che sono sinora stati proposti/discussi:

  • Autenticazione automatica e forte tra le componenti del sistema (client, servers, gateways, ed anche a livello di trasporto di rete).
  • Correlazione e verifica delle informazioni usate dal trasporto, e viste dall'utente.
  • Transazioni il più "dirette" possibile (client-submitserver-destinationserver-client). § Internazionalizzazione del sistema (indirizzi, buste, intestazioni). § Meccanismi avanzati di "tracciatura" del messaggio.
  • Meccanismi generalizzati di richiesta/risposta.
  • Trasporto binario.
  • Separazione netta di header, envelope, e body
  • Sintassi strutturata della local-part negli indirizzi.
  • Nuovo modello "economico" (postage, attention bonds).
  • Determinare che il mittente è un mittente autorizzato per il server da cui spedisce.
  • Streaming media.
  • Meccanismi di Notification (delivery, lettura, tracing).
  • Partire anche dai requirement che hanno gli users. § Attenzione, anche gli spammers sono users!
  • Usare XML ?
  • Anonimity, con rintracciabilità.
  • Self-configuration dei client e server (alla IPv6). § recipient control del data transfer?
  • IP multicasting per la distributione/trasmissione? § Standard mailbox format condividere gli accessi?
  • Supporto per le mobile applications.
  • Modello push, pull o entrambi?

Come vedrete si va da alcune cosa "ovvie" (ma non affatto ovvie da realizzare, come l'autenticazione forte tra le componenti del sistema), ad altre che comportano maggiori stravolgimenti nel sistema di posta elettronica.

Tra i primi fondamentali cambiamenti su cui tutti concordano c'è l'eliminazione della discrepanza tra quello che vede il sistema di trasporto delle informazioni, e quello che vede l'utente finale nell'header del mail. Inoltre non è più necessario un meccanismo a prova di rete "parialmente connessa" come era internet al tempo della specifica di SMTP; si possono ridurre quindi gli appesantimenti attuate o meglio riorientarli verso una situazione dove "la rete di trasporto è perennemente connessa", ma quello che è "volatile" sono i terminali finali degli utenti (computer, PDA, device mobili, e tutto quello che potete immaginare).

Si può anche considerare il problema di internazionalizzare/localizzare il sistema per le varie lingue ed alfabeti in uso, senza ricorrere a complessi accrocchi come ora per SMTP e simili. Da notare l'esigenza di meccanismi di tracciabilità del messaggio, per sapere in ogni istante dove sta ed in che stato si trova, mettendo questa informazione a disposizione diretta del mittente dello stesso.

Si tratta poi di prendere a bordo anche altre caratteristiche, già esistenti per SMTP, che però sarebbero più facili da implementare non essendo vincolate alla struttura attuale del protocollo.

Ovviamente, anche il modello "economico" del sistema sta venendo riesaminato. Come fare a mettere di più a carico del mittente i costi del sistema, come nel tradizionale sistema postale? Inoltre occorrono meccanismi di "autorizzazione alla spedizione ed uso quindi delle risorse". Se i costi migrano sul mittente, questo punto diventa non più così trascurabile.

Come detto, "perché ancora store-and-forward"? Chi ha detto che usare i meccanismi di streaming od anche il semplice Multicast non sia più convenire per veicolare i messaggi? Il nuovo sistema potrebbe anche prevedere come "obbligatori" quei meccanismi di notifica che già esistono in SMTP, ma non essendo obbligatori, non sono ancora implementati globalmente, rendendo parecchio scarso quindi l'utilizzo.

Vediamo un altro aspetto del sistema: SMTP era stato implementato a partire dalle esigenze degli architetti di rete. Un'analisi delle richieste degli utenti può sicuramente creare un sistema più adatto alle loro aspettative. Molti aspettano ancora qualcosa che dia loro il feeling del sistema tradizionale postale. Altri ancora preferiscono un sistema che dia l'interazione real-time diretta… non è un compromesso facile. Attenzione, che anche gli spammer sono utenti… quindi vanno tarate bene le caratteristiche del sistema in modo che non siano sfruttabili per abusi.

Un esempio in particolare: perché non permettere l'anonimità, in alcuni casi una caratteristica utile del sistema, ma rendendola "rivelabile a particolari condizioni"? Ad esempio garantendo l'anonimato di una segnalazione agli organi giudiziari, ma con la possibilità di verifica del vero mittente in caso di necessità?

Un altro problema: anche se "simple", SMTP è comunque un qualcosa di complesso da configurare, anche per l'utente finale: meccanismi di autoconfigurazione sono sicuramente necessari per utenti sempre meno esperti delle cose tecniche di rete.

Tornando a parlare di agenti mobili, bisogna passare il controllo del data tranfer al destinatario… se sono su un piccolo device portatile, con banda limitata o costosa, non voglio ricevere il film completo del compleanno della mia amica! Lo farò dopo in una occasione più propizia, e per ora voglio solo sapere che mi è stato mandato. Anche tecnicamente, i meccanismi di trasporto possono cambiare, vedi multicast, per ottimizzare l'uso di risorse, specialmente sull'ultimo tratto per la consegna.

Potrebbe essere utile standardizzare il formato delle mailbox, sicché risulti svincolato dal tipo di server su cui risiedono, dando anche la possibilità di accessi o trasferimenti veloci delle stesse.

Quale meccanismo per l'accesso ai messaggi? Push (vedi SMS/MMS), Pull (vedi POP/IMAP) o entrambi? La discussione qui è ancora molto agguerrita. I tempi di realizzazione: Quando? … "this is a good question"… Trattandosi di una ridefinizione totale del sistema, la discussione è ancora molto aperta, e si sta semplicemente decidendo dove andare.

Tra le cose che sembrano già delinearsi è che il nuovo sistema (se e quando verrà realizzato) sarà alla fine difficilmente compatibile con quello attuale, anzi è quasi certo che non lo sarà. Un realistico "educated guess" per i tempi: almeno un ulteriore anno per la definizione dei requirement che saranno implementati, nonché almeno un ulteriori due o tre anni per la specifica dei protocolli, e lo sviluppo dei software prototipi.

La domanda vera è: quanto ci vuole per l'installazione su larga scala? Può sembrare una cosa molto difficile, ma non dimentichiamo che cose anche più complesse si sono distribuite sulla rete molto rapidamente, se garantiscono la soluzione a problemi reali, oppure se si autoconfigurano. Per non citare il paradossale esempio dei proxy distribuiti via virus per fare spam, anche le varie tecniche e s/w che fanno P2P sono velocissimi nella diffusione.

Queste tecnologie non sono "negative" solo perché molte volte vengono usate per scopi non propriamente morali o legali. Sono "tecnologie" e basta, e quindi il loro uso può ad esempio diffondere un nuovo sistema di messaggistica e-mail molto più rapidamente di quanto si può immaginare. Sicuramente la soluzione non è per domani.

Se scrivo 201x sperando che "x" sia più vicina a 0 che a 9, forse rischio di andare vicino alla soluzione: il fatto che l'istant messaging stia prendendo rapidamente piede, e si basi su un'architettura simile ad una di quelle pensate per il futuro del sistema di messaggistica da anche qualche speranza di tempi più brevi.

La contropartita dei tempi descritti è importante: i tentativi dei rimediare o arginare il problema dello spam sul sistema attuale non vanno trascurati, ma anzi aiutati. Coloro che stanno pensando il nuovo sistema, usano il vecchio sistema di posta elettronica per comunicare, e se questo cessa di funzionare perché sopraffatto agli abusi, anche loro sono nei guai!

Speriamo non succeda mai!

CLAUDIO ALLOCCHIO

  • Nato a Crema nel 1959, dal 1979 al 1983 Claudio Allocchio collabora, presso l'Osservatorio Astronomico di Trieste diretto da Margherita Hack, al gruppo di spettroscopia, dove sviluppa programmi e servizi informatici per l'elaborazione dei dati satellitari e la loro rappresentazione grafica.
  • Chiamato al CERN di Ginevra, dal 1985 cura lo sviluppo e l' impianto di un pilota electronic mail gateway fra le reti HEPnet, EARN, JANET e i primi networks IP.
  • Dal 1993 è coordinatore dei servizi di messaggistica di TERENA [associazione europea delle reti nazionali della ricerca] del cui Conference Programme Committee è membro dal 1999 al 2001 e presidente nel 2000, per poi passare nel 2001 al ruolo di Vice Presidente della Associazione, responsabile per il Programma Tecnico.
  • Dal 1991 fa parte dell'Internet Engineering Task Force (IETF), la organizzazione mondiale che mantiene, sperimenta e formalizza i protocolli della Rete.
  • È il primo tecnico europeo a pubblicare un Request for Comments [le "regole" dell' Internet] : RFC 1405 [Gennaio 1993], primo di una lunga serie. Sempre in IETF amministra il working group "Internet FAX".
  • A livello nazionale dal 1988 collabora con il Laboratorio Elettra - Sincrotrone - di Trieste come responsabile prima del sistema informatico, e attualmente del coordinamento fra il Sincrotrone stesso e il GARR (la rete Italiana dell'Istruzione e della Ricerca), del cui staff originario fa parte sin dalla fondazione nel 1989, ricoprendo ora il ruolo di GARR Senior Technical Officer, responsabile dei servizi applicativi e di sicurezza di rete).
  • Dal 1985 promuove a amministra i Forum e le liste di distribuzione concernenti la posta elettronica per la Community [utenti e provider]: già responsabile per l'AIPA del Piano di Nomi a Dominio per gli Enti Locali, segue la evoluzione di questi interest groups alle problematiche del DNS e promuove la Naming Authority (che cura le Regole di Assegnazione, e procedure Tecniche di Registrazione sotto l'albero .IT) che presiede dalla fondazione [1998].
  • In tema di diffusione della cultura di rete su spam e security, dopo aver distribuito [1996] nella Local Internet Community la edizione italiana della Netiquette, ha curato, anche come relatore e chairman, a partire dal 1999, iniziative di studio e divulgazione in sede INFN Security Group, CERT-GARR, Internet Society.
  • la rete contro lo spam indice
    allocchio