LOGIN — n. 46 — maggio-giugno 2004

SMTP e SPAM: attacchi alla nostracasella di posta elettronicadi Maurizio Codogno

Lo SPAM diventa sempre piu invadente, e sembra riuscire sempre a superare le nostre dife-se. Purtroppo sembra impossibile trovare una soluzione al problema. Il motivo e da cercarealla fonte: il protocollo SMTP usato per scambiare posta e intrinsecamente poco sicuro, no-nostante le modifiche che ha avuto negli anni. Inoltre i promotori dello SPAM sono moltoesperti, e hanno un insieme di tecniche per trovare gli indirizzi email e addirittura verificarli

Maurizio CodognoMatematico ormaiperduto, si occupa diback-end per servizimultimediali presso Tele-com Italia. Il suo sognoe diventare un VeroTuttologo. I risultati pos-sono essere visti nel suosito: http://xmau.com

pubblicato suWWW.INFOMEDIA.IT

!stampa digitale da

Lulu Enterprises Inc.stores.lulu.com/infomedia

InfomediaInfomedia e l’impresa editoriale che da quasi venti an-ni ha raccolto la voce dei programmatori, dei sistemi-sti, dei professionisti, degli studenti, dei ricercatori e deiprofessori d’informatica italiani.Sono piu di 800 gli autori che hanno realizzato per le te-state Computer Programming, Dev, Login, Visual BasicJournal e Java Journal, molte migliaia di articoli tecnici,presentazioni di prodotti, tecnologie, protocolli, strumen-ti di lavoro, tecniche di sviluppo e semplici trucchi e stra-tagemmi. Oltre 6 milioni di copie distribuite, trentamilapagine stampate, fanno di questa impresa la piu grande edinfluente realta dell’editoria specializzata nel campo dellaprogrammazione e della sistemistica.In tutti questi anni le riviste Infomedia hanno vissuto del-la passione di quanti vedono nella programmazione nonsolo la propria professione ma un’attivita vitale e un verodivertimento.Nel 2009, Infomedia e cambiata radicalmente adottandoun nuovo modello aziendale ed editoriale e si e organiz-zata attorno ad una idea di Impresa Sociale di Comunita,partecipata da programmatori e sistemisti, separando leattivita di gestione dell’informazione gestite da un boardcomunitario professionale e quelle di produzione gesti-te da una impresa strumentale. Questo assetto e in lineacon le migliori esperienze internazionali e rende Infome-dia ancora di piu parte della Comunita nazionale deglisviluppatori di software.Infomedia e media-partner di manifestazioni ed eventi inambito informatico, collabora con molti dei piu impor-tanti editori informatici italiani come partner editoriale efornitore di servizi di localizzazione in italiano di testi inlingua inglese.

L’impaginazione automatica di questa rivista e realizzata al100% con strumenti Open Source usando OpenOffice,Emacs, BHL, LaTeX, Gimp, Inkscape e i linguaggi Lisp,Python e BASH

For copyright information about the contents of LOGIN,please see the section “Copyright” at the end of each ar-ticle if exists, otherwise ask authors. Infomedia contentsis© 2004 Infomedia and released as Creative Commons2.5 BY-NC-ND. Turing Club content is © 2004 TuringClub released as Creative Commons 2.5 BY-ND.

Le informazioni di copyright sul contenuto di LOGIN so-no riportate nella sezione “Copyright” alla fine di cia-scun articolo o vanno richieste direttamente agli autori.Il contenuto Infomedia e © 2004 Infomedia e rilasciatocon Licenza Creative Commons 2.5 BY-NC-ND. Il con-tenuto Turing Club e © 2004 Turing Club e rilasciatocon Licenza Creative Commons 2.5 BY-ND. Si applicanotutte le norme di tutela dei marchi e dei segni distintivi.

E in ogni caso ammessa la riproduzione parziale o tota-le dei testi e delle immagini per scopo didattico purchevengano integralmente citati gli autori e la completaidentificazione della testata.

Manoscritti e foto originali, anche se non pubblicati, nonsi restituiscono.

Contenuto pubblicitario inferiore al 45%.

La biografia dell’autore riportata nell’articolo e sulsito www.infomedia.it e di norma quella disponibi-le nella stampa dell’articolo o aggiornata a cu-ra dell’autore stesso. Per aggiornarla scrivere ainfo@infomedia.it o farlo in autonomia all’indirizzohttp://mags.programmers.net/moduli/biografia

23

SPAM speciale

Login Internet Expert n.46 Maggio/Giugno 2004

Ormai è impossibile riuscire a mantenere un indirizzo di posta elettronica “pulito”: qualche settimana dopo che lo si è inizia-to a utilizzare, SPAM e virus entrano - per

nulla timidamente… - nella nostra non più linda ca-sella email, e ci costringono a perdere una notevole quantità di tempo per eliminarli. Ormai il numero di messaggi non richiesti che transita per la rete è con-frontabile, se non addirittura superiore, a quello dei messaggi veri e propri. Bill Gates, sempre pronto a ve-dere ovunque una possibilità di profitto, ha proposto di mettere un “francobollo elettronico” sui messag-gi. Ultimamente è stato proposto un nuovo dominio di primo livello, .mail, che dovrebbe essere certifica-to “sicuro”. Altre tecniche come i controlli bayesiani cercano di arginare lo SPAM in modo preventivo, im-parando le caratteristiche dei messaggi indesiderati: ma dopo i primi promettenti risultati, la situazione torna in breve come prima. Tutto questo stato di cose ovviamente nasce da molto lontano…

In principio era l’SMTP

Negli anni ‘70 ci fu il primo sviluppo delle reti di cal-colatori. Assieme al trasferimento dei file via FTP e ai primi esempi di instant messaging (che non è affatto un’invenzione di questi ultimi anni), nacque l’abitu-dine di spedire quelli che oggi chiamiamo messaggi di posta elettronica. La caratteristica che contraddi-stingueva la posta elettronica dagli altri sistemi di tra-sferimento dati era la modalità “store and forward”: il messaggio non veniva inviato immediatamente al de-stinatario, ma poteva essere trattenuto da un server in-contrato durante il suo percorso. Questo era spesso ne-cessario, perché le connessioni tra i server avvenivano di notte per risparmiare sulle bollette telefoniche. Pur-troppo ogni rete aveva non solamente un proprio siste-ma per scambiarsi i messaggi, ma anche una sintassi

diversa per indicare un indirizzo di posta elettronica. Ad esempio, le macchine Unix connesse via uucp uti-lizzavano il “bang path”: occorreva indicare esplicita-mente il percorso per giungere al destinatario. Per scri-vere all’utente pippo nella macchina pluto, l’indiriz-zo poteva così essere mcvax!i2unix!pluto!pippo, dove mcvax era il punto centrale europeo e i2unix quello italiano. I sistemi VAX/VMS usavano invece indiriz-zi come PLUTO::PIPPO, mentre la rete Bitnet aveva già la chiocciola, anche se non c’era ancora il concetto di dominio e quindi l’indirizzo era PIPPO@PLUTO. Scusate le maiuscole: ma i tempi erano quelli, come si può anche leggere in [1]. Probabilmente la vittoria

Lo SPAM diventa sempre più invadente, e sembra riuscire sempre a superare le nostre difese. Purtroppo sembra impossibile trovare una soluzione al proble-ma. Il motivo è da cercare alla fonte: il protocollo SMTP usato per scambiare posta è intrinsecamente poco sicuro, nonostante le modifiche che ha avuto ne-gli anni. Inoltre i promotori dello SPAM sono molto esperti, e hanno un insieme di tecniche per trovare gli indirizzi email e addirittura verificarli

SMTP e SPAM:attacchi alla nostra casella di posta elettronica

� di Maurizio Codogno (mcodogno@infomedia.it)

FIGURA 1 Un indirizzo e-mail modificato

SPA

M

Login Internet Expert n.46 Maggio/Giugno 200424

speciale SPAM

del tipo di indirizzo attuale - che paradossalmente non è legata al DNS, dove anche gli indirizzi utente venivano visti come una foglia dell’albero! - è dovuta al protocollo SMTP, apparso nella sua prima versione nel 1982 [2]. L’acronimo sta per “Simple Mail Transfer Protocol”, e in effetti il protocollo almeno nella versio-ne iniziale era molto semplice. I comandi usati erano pochissimi (vedi la Tabella 1), e soprattutto il modello concettuale separava completamente la gestione del messaggio da quella della sua spe-dizione. Con SMTP venivano introdotti i concetti di MTA (Mail Transfer Agent), il programma che spedisce la posta da un calco-latore all’altro, e di MUA (Mail User Agent), il programma che l’utente usa per leggere e scrivere i messaggi e che si interfaccia con l’MTA. La stessa divisione si può vedere quando viene spedi-to il messaggio: gli indirizzi che troviamo scritti come parametri dei comandi MAIL e RCPT possono essere diversi da quelli del messaggio. Si parla infatti di envelope, insomma della busta dove si scrivono gli indirizzi di mittente e destinatario che non devo-no più essere letti all’interno. La distinzione è molto importante, anche se a onor del vero parecchi software non la comprendono. C’è ad esempio il caso banale degli indirizzi in copia nascosta, i Bcc: che non appaiono nel testo del messaggio ma devono essere inseriti in qualche modo. Una situazione più interessante capita quando una mailing list utilizza il proprio indirizzo nell’envelo-pe, mentre lascia quello del mittente reale nell’interno. Gli even-tuali messaggi di errore vengono così inviati al programma che gestisce la lista, che li può gestire autonomamente.

Gli open relay

Sono passati più di vent’anni, ma SMTP continua ad essere il protocollo utilizzato per spedire posta… purtroppo. Il successo che ha avuto rende infatti praticamente impossibile sostituirlo:

il massimo che si può fare è aggiungere al protocollo delle esten-sioni. Il guaio è che esso è stato studiato pensando ad un ambien-te completamente diverso da quello che c’è oggi, e questa proget-tazione mostra tutte le sue crepe. Alcuni problemi non sono poi insormontabili: essere limitati a caratteri a sette bit, ad esempio, significa sprecare un po’ di banda per codificare i messaggi, ma nulla di più. La necessità reale o presunta di permettere di invia-re “messaggi” non formati semplicemente da testo ha portato allo sviluppo di MIME; la soluzione sarà bruttina ma almeno funzio-na bene. La scelta di progetto che adesso dà veramente problemi è però un’altra: la mancanza di un vero protocollo di autenticazio-ne. Come visto sopra, vent’anni fa era abbastanza frequente che non tutti i calcolatori fossero direttamente collegati a Internet, e quindi capitava abbastanza spesso di usare una macchina come ponte esplicito: non solo nel protocollo UUCP ma anche negli altri. La convenzione usata con Sendmail, la prima implementa-zione di SMTP ubiquitaria, era usare il carattere % al posto di @ per indicare l’indirizzo da inoltrare successivamente. Insomma, l’indirizzo pippo%pluto.it@paperino.it significava spedire al-l’MTA di paperino.it un messaggio per pippo@pluto.it, lascian-dogli l’incarico di smistarlo: fare cioè da relay.Come si può facilmente immaginare, questa possibilità è stata ben presto abusata, tanto che nelle configurazioni di default è stata ra-pidamente eliminata. Altre possibilità offerte dal protocollo che non vengono più abilitate per evitare attacchi di malintenzionati sono i comandi VRFY, che permetterebbe di sapere se l’indirizzo fornito esiste davvero, ed EXPN, che darebbe l’insieme degli in-dirizzi reali corrispondenti a un alias locale. Pensate solo ai pro-blemi di privacy! Ma SMTP ha anche un’altra proprietà intrinse-ca: chiunque può connettersi a un server e preparare un’envelope in cui si autocertifica essere un utente locale che vuole spedire un messaggio a un utente remoto. Come detto, il server si limi-

TABELLA 1 I comandi SMTP di base e alcune estensioni

Comando SMTP originario Significato

HELO nome Hello: inizia la sessione, presentandosi come nome (cui il server remoto può credere o no)

MAIL From: <mittente> Mail: indica l’inizio di un messaggio, con il mittente dell’envelope

RCPT To: <destinatario> Recipient: indica il destinatario di un messaggio, di qualunque tipo esso sia all’interno del messaggio (To, Cc, Bcc)

DATA Data: indica l’inizio del testo del messaggio vero e proprio, terminato con una riga con un singolo “.”

RSET Reset: il server remoto deve cancellare tutti i dati parziali ricevuti

VRFY <indirizzo> Verify: si chiede se l’indirizzo è o no locale

EXPN <indirizzo> Expand: si chiede a quali recipienti corrisponde l’indirizzo

HELP Help: vengono date informazioni sui comandi possibili

NOOP No Op: giusto per dire “ci sono ancora”

QUIT Quit: termina la connessione

SEND, SOML, SAML, TURN (comandi obsoleti e/o deprecati)

Comando SMTP esteso Significato

EHLO nome Extended Hello: inizia la sessione chiedendo al server quali estensioni riconosce (RFC 1869)

8BITMIME MIME a 8 bit: indica che il canale permette di usare byte con 8 bit (RFC 1426)

SIZE nbyte La dimensione massima del messaggio che può essere inviato (RFC 1870)

DSN Delivery Status Notification (RFC 1891)

ETRN cliente Extended TURN: processa la coda per il cliente autenticato (RFC 1985)

AUTH modi_autenticazione Authentication (RFC 2554)

DELIVERBY secondi Richiesta al server di inviare il messaggio entro un certo periodo (RFC 2852)

Login Internet Expert n.46 Maggio/Giugno 200425

SPAM speciale

ta a guardare il contenuto dell’envelope, e non il messaggio al suo interno: dal suo punto di vista va tutto bene, e invia felicemente il tutto. Abbiamo così un open relay. La prima soluzione che viene in mente per eliminare l’open relay è fare un controllo sull’indirizzo IP del mittente. In pratica, se si vede che chi ha iniziato la connes-sione SMTP proviene dalla nostra rete interna, oppure da una rete “fidata” cui diamo accesso, gli permettiamo di inviare messaggi a chiunque voglia. In caso contrario? No, non si può banalmente dire “gli blocchiamo l’accesso”. Altrimenti, come farebbe un server remoto a inviarci posta? La soluzione corretta è pertanto dire “gli permettiamo di spedire posta solo al nostro dominio, o comunque a una lista di sistemi amici”. Sono già almeno dieci anni che tutti i principali MTA possono essere settati in questa maniera con appo-siti file di configurazione: non ci sono più scuse. Attenzione, però: in questo modo si rischia di buttare il bambino con l’acqua sporca. Può capitare spesso che una persona sia in giro per il mondo, e vo-glia inviare dei messaggi di posta elettronica con il proprio indiriz-zo. Se lui si sta connettendo con un altro provider, questo potrebbe avere una configurazione che si accorge che né mittente né desti-natario fanno parte della propria rete, e quindi rifiutare il messag-gio; d’altra parte, non può nemmeno usare il proprio server mail, proprio perché in quel momento non sta in una rete conosciuta. Il problema era abbastanza grave da avere portato a una soluzione specifica: l’autenticazione del mittente [4], che permette al server di assicurarsi che la persona che si sta connettendo è fidata, evitan-do tutta una serie di controlli.

Un server di posta a nostra insaputa

Come si è visto, il protocollo SMTP non si può esattamente de-finire come a prova di bomba: però man mano è stato raffinato,

e i server che vengono tenuti aggiornati non danno troppi pro-blemi. Peccato che sia stato scelto di mantenere la compatibilità con le vecchie versioni: questo apre la porta allo sfruttamento di macchine ignare per potere inviare SPAM. All’inizio, gli spam-matori si limitavano a cercare dei server di posta che non erano stati ancora aggiornati, e iniziavano a utilizzarli. Si è potuto ve-dere un trend interessante: dai siti americani si è passati a quelli europei, e alla fine a quelli asiatici. Ci sono stati amministratori di sistema che a un certo punto hanno bloccato preventivamen-te tutte le connessioni che arrivavano da server coreani, a quan-to pare i meno preoccupati per la sicurezza. Per contrastare que-sti sistemi, alcuni sysadmin decisero di fare uno sforzo colletti-vo, e creare una lista di siti non sicuri. Un server di posta poteva scaricarsi questa lista, verificare se la richiesta di connessione SMTP arrivava da uno di quegli indirizzi, e in caso affermati-vo dire “no, grazie”. Il sistema è evoluto parecchio, tanto che la lista più famosa, MAPS [5], è poi diventata un sistema com-merciale che fornisce questi aggiornamenti, che si susseguono a velocità sempre maggiore. Molti portali, anche italiani, sono spesso entrati in questa lista, dalla quale si può uscire solo di-mostrando di avere tappato le falle di sicurezza del proprio ser-ver… e la verifica viene fatta dai gestori della lista!È almeno un anno però che la frontiera si è spostata verso le macchine dei singoli utenti. Con il proliferare di connessioni ADSL in modalità “always on”, tenute da utenti che non hanno certo chissà quali competenze informatiche, diventava conve-niente distribuire la spedizione di SPAM. Basta trovare un nu-mero sufficientemente elevato di macchine: la banda di ciascu-na di esse non sarà enorme, ma così moltiplicata è comunque sufficiente per un invio di massa. Ma non basta: la strategia è ancora più perversa. Alcuni dei virus che girano per la rete crea-

TABELLA 2 Gli spammer trovano sempre una soluzione! (adattato da Tullio Andreatta)

Tecnica di filtro per gli spam Contromisura adottata dagli spammer

Controllo umano Subject “accattivante” non correlato al messaggio (“Fwd: your question”). Generalmente in inglese

Filtri sul nome del mittente Falsificazione del mittente

Filtri euristici del contenuto (prime versioni di spamassassin: ricerca di frasi “standard”)

Variazioni delle frasi utilizzate nei messaggi di spam

Filtri euristici del contenuto generati con un algoritmo (spamassassin)

Offuscamento del contenuto (testo html codificato, p.a.r.o.l.e s|p|a|z|i|a|t|e)

Raccolta di signature dei messaggi su database formati da segnalazioni di varie persone (razor v.1)

Introduzione di sequenze casuali di caratteri (%RNDCHAR[2-8]%) nell’oggetto e/o nel testo del messaggio. Contaminazione del database mediante segnalazioni fasulle.

Raccolta di signature di parti dei messaggi, segnalazioni firmate (razor v.2)

Variazione dell’ordine dei paragrafi nel testo dei messaggi. Introduzione di sequenze casuali nella maggior parte delle righe. Offuscamento casuale del messaggio.

Filtri bayesiani con sistemi di autoapprendimento (spamassassin, spamihilator)

Offuscamento generalizzato del contenuto (mistypd wodrs, à1tèrnätìve ch@racter§). Inserimento nell’HTML di tag non visualizzati nel mezzo delle parole, per confondere i meccanismi di estrazione del testo. Contaminazione del database inserendo parole di uso comune (all’inizio del messaggio, o in parti alternative MIME non visualizzate dal client di posta, o usando font “quasi bianchi” nell’HTML).

Tecnica di blacklisting Contromisura adottata dagli spammer

Blacklisting dei mail server degli spammer Utilizzo della funzionalità “third party relay” di SMTP

Blacklisting dei “third party relay”, modifica delle policy sul relay Utilizzo di connessioni dial-up “usa e getta”

Blacklisting degli indirizzi dei blocchi dial-up Utilizzo di proxy mal configurati

Blacklisting degli open proxy Utilizzo di trojan horse installati da virus, che consentono di prendere il controllo di macchine autorizzate al relay

Login Internet Expert n.46 Maggio/Giugno 200426

speciale SPAM

Note Biografiche

Maurizio Codogno è laureato in Matematica e Scienze dell’In-formazione. Si occupa di progettazione e sviluppo di back-end per servizi innovativi di telefonia mobile all’interno di TIM.

no un server “fantasma” che resta in ascolto su una determina-ta porta. Allo spammatore basta inviare un comando a questo server, ed esso crea un MTA “usa e getta” che viene utilizzato per la campagna corrente, per poi eliminarsi fino all’invocazio-ne successiva. Non per nulla le liste di server non sicuri ormai comprendono direttamente i blocchi di indirizzi IP relativi alle connessioni ADSL, con la comprensibile rabbia di chi vorreb-be spedire legalmente messaggi senza passare dal proprio provi-der e non lo può fare. Almeno in passato, ci sono stati provider che hanno persino deciso di filtrare i dati in uscita dalla propria rete verso la porta 25: un po’ come la guerra preventiva… Non sono nemmeno certo che sapere che la gran parte dello SPAM è prodotto da poche decine di “professionisti” sia una notizia po-sitiva o sconfortante.

A caccia di indirizzi email

L’altra faccia della medaglia la vediamo tutti i giorni, con i mes-saggi indesiderati che dobbiamo cancellare dalla nostra casel-la. Cambiare indirizzo può servire per un po’, ma non ci vuole molto prima che anche questo si riempia di spazzatura. Sembra che sia impossibile proteggere la propria identità elettronica! In effetti ci sono vari modi con cui gli spammatori riescono a recu-perare i nostri indirizzi di posta. Se si ha un account presso un provider abbastanza noto, ad esempio, e il nome usato è piutto-sto comune, ci si caccia sicuramente nei guai. Un metodo di for-za bruta usato spesso è spedire un messaggio a tutte le probabili combinazioni nome@dominio, per vedere se qualcuno di essi per caso esiste, e in questo caso tenerselo ben stretto. Ad esem-pio, quando nacque tin.it io mi ero fatto un bellissimo indiriz-zo mau@tin.it, dicendomi “che bello, avere un indirizzo così breve”. Bene, anzi male: mi è assolutamente impossibile usarlo. Credo sia in tutte le liste di indirizzi che girano per il mondo.A parte questo caso, il metodo più usato per trovare un indiriz-zo utilizzabile è andare a cercarlo per la rete. Sembra incredibile quante informazioni si possano ricavare, se si sa come cercarle: ci sono programmi, detti spambot, che funzionano come i ro-bot dei motori di ricerca, con la differenza che collezionano non le pagine web ma gli indirizzi in esse presenti, pronti ad essere utilizzati. Ma queste non sono le uniche fonti da cui si possono ricavare facilmente i nostri indirizzi. I newsgroup sono un’altra fonte quasi inesauribile, e forse anche più comoda, visto che gli articoli news sono formattati e recuperabili in maniera sempli-ce. Per evitare dare in pasto il nostro indirizzo in questo modo, c’è l’usanza di modificarlo in modo da rendere chiaro ad un es-sere umano cosa si debba in effetti scrivere per contattarci. Ma non prendete sottogamba i “cattivi”: aggiungere la stringa NO-SPAM oppure una qualunque parola in maiuscolo non serve as-solutamente a nulla, perché verrà automaticamente tolta anche dal programma di cattura indirizzi. Nel caso di una pagina web si possono utilizzare vari trucchi. Se non c’è necessità di ren-dere cliccabile l’indirizzo, lo si può... disegnare, mettendo cioè un’immagine PNG con l’indirizzo. In caso contrario, una vol-ta era sufficiente usare l’entità HTML “&#40;” al posto del-la chiocciola, ma l’usanza è diventata sufficientemente nota per essere incorporata negli spambot. La soluzione al momento più interessante sembra lo scrivere una funzione javascript che il browser interpreta correttamente: ci sono dei siti che aiutano a costruire tale funzione a partire da un indirizzo, e il risultato sembra davvero magico: a video appare un indirizzo, il taglia e incolla funziona, ma il sorgente è incomprensibile. Un esempio di codifica dell’indirizzo mau@tin.it, effettuato per mezzo di Hiveware [7], può essere visto nella Figura 1; il testo è davvero oscurato. Resta da chiedersi quanto tempo ci vorrà prima che anche questo sistema venga aggirato: proprio perché è un algo-ritmo, può essere implementato da chiunque.

Pulizia degli indirizzi

Gli spammatori più coscienziosi - dal loro punto di vista, si in-tende! - cercano anche di verificare se gli indirizzi a cui scrivono

sono reali oppure no. D’accordo: il costo di spedire un messaggio a qualcuno che non esiste usando un server non nostro è nullo, visto che i rimbalzi arrivano al poveretto che ha il server bucato, ma fa molto fine poter dire ai propri clienti “abbiamo verificato il nostro indirizzario, e quindi garantiamo una maggior percentua-le di successo”. Ci sono anche qui diverse tecniche a disposizione. Alcuni anni fa, quando si usavano ancora i propri server di posta elettronica, i messaggi di errore venivano processati per togliere dalle liste i rimbalzi.Era addirittura stato scritto un software per inviare falsi errori “questo utente non esiste”! Oggi queste soluzioni sono inutili, dato che i rimbalzi si perdono nel ciberspazio, ed è molto più sem-plice un approccio di tipo opposto: fare in modo che sia l’utente stesso, volontariamente o no, a validare il proprio indirizzo. Im-magino che abbiate presente i messaggi di SPAM che al fondo del testo hanno un link “clicca qui per non ricevere più messaggi”. Non fatelo: altrimenti date loro la certezza di avere letto il messag-gio. Non viene chiaramente passato l’indirizzo di posta elettroni-ca: il metodo utilizzato è molto più sottile. In pratica si sfrutta la possibilità di HTML di inviare alla stessa pagina tutte le richieste fatte a vari siti.Così si personalizza il messaggio di SPAM, e ciascuno vede un sito formalmente diverso come http://ithfusort.vivalospam.com/remove_me.html; peccato che tutti puntino a vivalospam.com, che ha una base dati che assocerà alla stringa generata casualmen-te “ithfusort” l’indirizzo cui è stata spedita. Alcuni sistemi anti-spam si accorgevano di queste parole inesistenti per segnalare il messaggio come SPAM; negli ultimi giorni ho visto siti di tipo “cancellami” composti da sette-otto parole casuali. Ancora più perfido è il sistema di usare un messaggio HTML che all’inter-no ha un link a una figura, sempre con un nome codificato come sopra. Le persone che leggono il messaggio faranno pertanto una richiesta al server remoto, richiesta che può essere recuperata dai log. Se la “figura” è di un pixel per uno non la si vede nemmeno, ma gli effetti ci sono eccome! È una ragione di più per togliere su-bito l’opzione “visualizza un’anteprima dei messaggi” del proprio cliente di posta elettronica.

Conclusioni

Purtroppo la situazione che ho mostrato non è affatto bella. Al momento la bilancia pende infatti dalla parte degli spammato-ri, come a dire il vero è quasi sempre capitato. Possiamo sola-mente cercare di rendere loro la vita meno semplice, ma tutto lascia pensare che non sarà la tecnica a vincere lo SPAM, ma ci sarà bisogno di sistemi completamente diversi.

Bibliografia

[1] D. Frey e R. Adams, “!%@:: A Directory of Electronic Mail Addressing & Networks”, O’Reilly, 1994, ISBN 1-56592-046-5, http://www.oreilly.com/catalog/email4/

[2] Jon Postel, “Simple Mail Transfer Protocol”, RFC 821, agosto 1982, http://www.faqs.org/rfcs/rfc821.html

[3] John Klensin et al., SMTP Service Extensions”, RFC 1869, novembre 1995, http://www.faqs.org/rfcs/rfc1869.html

[4] John Myers, “SMTP Service Extension for Autenthica-tion”, RFC 2554, marzo 1999, http://www.faqs.org/rfcs/rfc2554.html

[5] http://www.mail-abuse.org/[6] M. Nespolo, “Miniguida all’autodifesa antispam”, http://

www.zeusnews.it/index.php3?ar=stampa&cod=2855[7] http://www.hiveware.com/