Pagina Antispam In Italiano - PDF Free Download

Pagina Antispam in italiano Piccola guida all'autodifesa dai più comuni abusi di rete Questa pagina, che ha contenuti a...

Author: Collinelli Leonardo

36 downloads 3891 Views 2MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!

Report copyright / DMCA form

DOWNLOAD PDF

Pagina Antispam in italiano Piccola guida all'autodifesa dai più comuni abusi di rete

Questa pagina, che ha contenuti analoghi a quelli delle numerose pagine antispam disponibili in lingua inglese, è stata pensata per essere utile a coloro che un bel (o brutto) giorno, scaricando la posta elettronica vedono comparire strani messaggi, provenienti da ogni parte del mondo e contenenti più che altro pubblicità, a volte catene di S. Antonio, comunque ciarpame vario di nessun interesse. Sono molti quelli che, a questo punto, cercano consiglio per sapere se è proprio inevitabile subire questi e-mail non graditi, che infastidiscono e fanno perdere tempo. Sono molti quelli che vorrebbero avere qualche dritta sul modo migliore di comportarsi e, eventualmente, che vorrebbero sapere come fare per combattere il fenomeno: basta leggere i newsgroup per trovare molte richieste di informazioni in questo senso. Con questa pagina vorrei pertanto fornire (ed in lingua italiana) le basi che consentano, a queste persone, di affrontare il problema correttamente e, soprattutto, di cominciare ad imparare come ci si possa difendere da questo malcostume. L'obiettivo che spererei fosse possibile raggiungere, e per il quale faccio affidamento soprattutto sulla volontà e sulla determinazione dei visitatori di queste pagine, è un maggior numero di utenti italiani inflessibili e pronti a reagire efficacemente di fronte a questo sgradevole fenomeno.

Contenuti ●

Nozioni generali e trattamento della junk email ❍ ❍ ❍ ❍ ❍ ❍ ❍ ❍ ❍ ❍ ❍

Che cosa è lo spam e perché è male Come comportarsi quando si riceve spam Passare alla controffensiva: RECLAMARE Come affrontare la lettura degli header Falsificazioni da riconoscere Gli indirizzi di rete e il DNS Cosa scrivere nel reclamo: caso pratico num. 1 Il problema dei relayer: casi pratici num. 2 e 3 Il problema dei relayer multihop: caso pratico num. 4 Spammer con sito web: caso pratico num. 5 Url cammuffate e siti click-through: caso pratico num. 6 1

❍ ❍ ❍ ❍ ❍ ❍ ❍ ❍ ❍

●

Lo spam sui newsgroup Usenet ❍ ❍

●

❍ ❍

Consigli per i provider Devo farmi pubblicità in rete: come faccio senza spammare? Un'altra grana: le catene a contenuto pietoso-commovente

Rubriche ❍

●

Perché lo spam sui newsgroup Usenet è un problema diverso Caso pratico di Usenet spam

Altri argomenti relativi allo spam ❍

●

Decrittare i sorgenti HTML nascosti dal javascript: caso pratico num. 7 Insidie che possono arrivare con lo spam Cosa si può fare per prevenire l'arrivo di spam Le liste di blocco (generalità) Le liste di blocco (alcune liste disponibili) Qualche necessario strumento (tool di rete classici) Qualche necessario strumento (da avere sul proprio computer) Alcuni link e risorse utili: Siti Web e FAQ Alcuni link e risorse utili: Mailing List e Newsgroup

Cosa sta succedendo nel mondo dello spam

Strumenti ❍ ❍

Query DNS, blacklist ed altri strumenti online Motore di ricerca interno

E' doverosa una avvertenza: Non sono un amministratore di rete, ma solo un normale utente. Un amministratore di rete avrebbe potuto trattare questi argomenti in maniera assai più professionale. Io mi sono limitato a riordinare quanto ho imparato dalla mia situazione di normale utente che, occasionalmente, riceve spam.

Questo sito dovrebbe essere visibile (sia pure con differenti qualità nella resa) con qualsiasi browser, nuovo o vecchio, anche di solo testo. Se su qualche pagina incontraste problemi di visualizzazione, per favore fatemelo sapere.

2

Ultimo aggiornamento: 27 giugno 2002

Leonardo Collinelli

3

Che cosa è lo spam e perché è male Cosa significa SPAM?

Cercando su un vocabolario di inglese la parola 'spam', la si trova con il significato di "carne di maiale in scatola (deriva da spiced ham)". In effetti negli USA è diffuso un tipo di carne in scatola chiamato SPAM e prodotto da un'azienda di nome Hormel. Con il nostro problema la carne in scatola non c'entra moltissimo, anche se gli americani, tradizionalmente attenti a giochetti e coincidenze lessicali, quando parlano di spam come problema di rete fanno, talvolta, comparire l'immagine di una scatoletta di carne. Il significato che ci interessa è, secondo i più, derivato da una scenetta comparsa in un episodio della serie televisiva "Monty Python's Flying Circus". Nella scena in questione, un uomo e sua moglie entrano in un ristorante e prendono posto; poco distante da loro c'è una tavolata di buontemponi, con in testa i caratteristici elmi cornuti da vichinghi. Quando la cameriera arriva a prendere le ordinazioni, i vichinghi iniziano a cantare: "Spam spam spam..." così fragorosamente che i due clienti non riescono neppure a capire quali pietanze siano in menù, dato che la voce della cameriera è continuamente inframezzata dalla parola spam; la cliente tenta ripetutamente di chiedere qualcosa che non contenga spam e, naturalmente, a ciò che lei chiede si sovrappone la canzone dei vichinghi aggiungendo spam; finché il marito si offre di mangiarlo lui. Per avere maggiori dettagli su questo sketch si possono semplicemente inserire in qualunque motore di ricerca le parole 'Monty Python': si troveranno molte pagine che trascrivono accuratamente la scenetta e, eventualmente, pure la canzone dei vichinghi su file audio.

Dunque l'idea che ha portato alla scelta del termine è quella di un disturbo di livello e continuità tali da ostacolare la possibilità di comunicare. Passando dalla scenetta del film all'ambiente della rete, resta nel concetto di spam il fatto che abbiamo a che fare con un disturbo alla capacità di comunicazione di molti. Questo disturbo si concretizza in messaggi, aventi la carattaristica di essere ripetitivi o molteplici, i quali messaggi vengono, in sostanza, diffusi avvalendosi delle funzionalità della rete, senza rispettare lo scopo per il quale tali funzionalità esistono. Facciamo un esempio banale: il campanello di casa vostra serve per avvertirvi dell'arrivo di un visitatore, del postino e così via; non l'avete installato perché i ragazzini possano divertirsi. Quello che suona il campanello e se la dà a gambe commette quindi un abuso. L'analogia con quanto avviene in rete non si può spingere tanto più in là, ma il concetto base per capire lo spam è esattamente questo. Con l'intensificarsi della lotta contro questo malcostume e con il formarsi di una vasta 4

comunità antispam (termine con cui genericamente si intendono innumerevoli utenti e amministratori di sistema che, ovunque nel mondo, detestano lo spam e fanno qualcosa per combatterlo), si è sentito il bisogno di definizioni più precise e meglio codificate, che potessero diventare riferimento comune. Ecco allora che il discorso si differenzia a seconda delle specificità del mezzo, in particolare articolandosi differentemente per ciò che riguarda la posta elettronica e per ciò che riguarda i newsgroup Usenet. Dello spam su Usenet si parlerà in altra parte di questo sito, ora si comincerà a concentrarsi sullo spam in posta elettronica. Come si manifesta lo spam in concreto? La rete è sede di un gigantesco scambio di informazione, che viene generata ad un livello di dettaglio e di pluralità sconosciuti ad altri mezzi di comunicazione e della quale si può usufruire con una praticità e facilità altrettanto singolari. Coloro che entrano in rete lo fanno, nella stragrande maggioranza dei casi, per partecipare a questo scambio: qualcuno solo per usufruirne (e non c'è nulla di male in questo), altri per parteciparvi pure attivamente. Molti frequentatori della rete (pochissimi in percentuale, ma i valori assoluti da considerare sono a livello mondiale) vedono le possibilità di comunicazione che questa offre come una semplice risorsa da sfruttare a proprio massimo beneficio, indipendentemente da qualsiasi altra considerazione e senza curarsi in alcun modo del rispetto del prossimo (che è dovuto ovunque e, pertanto, anche in rete). L'occasione per abusare dalla rete può essere suggerita da qualsiasi esigenza, più o meno legittima (non ci interessa entrare nel merito), per la quale si cerchi visibilità di fronte al pubblico più vasto possibile, approfittando impropriamente della condizione di accessibilità in cui i frequentatori della rete si sono messi al fine di beneficiare della propria connessione. Si può dire che, in fondo, siamo tutti abituati a convivere, nella vita reale, con un certo numero di maleducati; niente di strano che se ne trovino anche in rete. Però, date le possibilità di comunicazione proprie di questo mezzo, i maleducati riescono ad essere decisamente più fastidiosi che nella vita quotidiana. Anche un solo imbecille, che in qualche angolo del mondo si sia collegato alla rete, può irritare centinaia o migliaia di persone sparse nei cinque continenti. Quello che dunque constatiamo è che, purtroppo, c'è sempre qualcuno che, venuto in possesso di indirizzi di posta elettronica appartenenti a persone del tutto all'oscuro della sua esistenza e niente affatto interessate alle sue attività, li utilizza per inviare e-mail non richieste, che provocano solo incomodo ai riceventi. Così abbiamo raggiunto un punto importante della questione: per usare legittimamente la posta elettronica occorre che ogni messaggio sia consensuale. La cosa non deve stupire: indipendentemente dal fatto di essere in rete, ogni forma di comunicazione tra persone civili è sempre consensuale. Perché ciò si verifichi, occorre che il destinatario abbia autorizzato la comunicazione, esplicitamente o implicitamente. Per esempio, amici e conoscenti non necessitano di autorizzazione esplicita; oppure, se scrivo un messaggio su un newsgroup indicando in tale messaggio il mio indirizzo di email, chiunque è implicitamente autorizzato a scrivermi in merito al contenuto del mio messaggio; se lascio che il mio indirizzo di e-mail compaia su un sito 5

web, chiunque è implicitamente autorizzato a scrivermi in merito alla ragione per cui il mio indirizzo si trova lì. L'abuso avviene quando qualcuno che io non conosco, raccolto il mio indirizzo dai newsgroup o da un sito web o in qualsiasi altro modo, inizia ad inviarmi messaggi che non c'entrano nulla col motivo per cui quell'indirizzo era stato reso pubblico. Con questo cade l'obiezione di chi dice: "Chi divulga il proprio indirizzo di email implicitamente accetta di ricevere corrispondenza. In caso contrario, tenga l'indirizzo riservato." Tale affermazione non è corretta: quando si rende visibile il proprio indirizzo di email, per esempio sul proprio sito o nei propri post su usenet o in altre situazioni, ciò intende fornire a chiunque la possibilità di usarlo nell'interesse del proprietario di tale indirizzo (colui che paga per quella mailbox). Il quale ha evidentemente stabilito essere proprio interesse che chiunque lo contatti per criticare ciò che ha detto, per chiedergli chiarimenti e così via. In altre parole, che io abbia deciso essere mio interesse venire contattato per questi scopi è implicito nel fatto di avere palesato l'indirizzo, ma che sia mio interesse pure venire contattato per informarmi della disponibilità di un favoloso prodotto per far crescere i capelli, nessuno può ipotizzarlo: sono sempre IO che lo devo decidere e rendere esplicito. È del tutto irrilevante il contenuto di tali messaggi: possono essere pubblicità, propaganda politica o religiosa, richieste di beneficenza per cause nobilissime, inviti a visitare questo o quel sito, non importa assolutamente nulla: una casella postale ed il tempo del suo legittimo utilizzatore non sono a disposizione di qualsiasi sconosciuto che, mandandogli email su ciò che pare a lui, li volesse sfruttare a proprio profitto e ad incomodo del destinatario. Non sempre può riuscire del tutto immediato determinare se un messaggio è diffuso in maniera consensuale oppure no. Un criterio da adottare che a me è parso molto valido è questo (suggerito da Leah Roberts): Si tratta di messaggio unsolicited quando il mittente non può trovare una valida risposta nel caso in cui il destinatario gli chieda "Perché questo messaggio lo hai mandato proprio a me?". Attenzione: per "valida risposta" si intende una risposta basata su fatti oggettivi inerenti il destinatario. Per esempio, se il mittente dicesse: "Perché me lo hai chiesto tu", se vera la risposta sarebbe valida. Se invece tutto quello che il mittente avesse da dire fosse "Perché ti voglio vendere questo meraviglioso prodotto", la risposta sarebbe non accettabile perché basata su un fatto relativo al mittente stesso. Analogamente, se il mittente dicesse "Perché ho ritenuto che questa cosa ti interessasse" sarebbe ancora una risposta non valida, in quanto basata non su un fatto oggettivo ma su una illazione fatta dal mittente.

Dopo avere quindi affrontato il punto fondamentale della consensualità della comunicazione e avendo quindi qualche linea guida per riconoscere quando un messaggio può dirsi unsolicited o, in italiano, "non richiesto", chiuderemmo questo paragrafo citando la più precisa definizione di spam che sia finora giunta a nostra conoscenza. La trovate, in inglese e con molti ulteriori dettagli che vale la pena di leggere, alla url http://www. monkeys.com/spam-defined/definition.shtml. La tradurremmo in italiano come segue: 6

Spam su Internet è uno o più messaggi non richiesti, inviati o postati come parte di un più grande insieme di messaggi, tutti aventi contenuto sostanzialmente identico. Troviamo dunque il requisito della non consensualità e quello della molteplicità. Un messaggio inviato in copia unica, quindi, non costituisce spam in nessun caso. Se invece ne vengono inviati almeno due, già si ricade nella definizione. Quando si accennerà allo spam su Usenet, vedremo che il "più grande insieme di messaggi" sarà soggetto ad ulteriori requisiti di quantità e tempo. Questa posizione non finisce per ledere la libertà di parola e di commercio? Questa obiezione (incredibilmente più frequente di quanto si possa pensare) non è altro che una bufala colossale, certamente offensiva per chi crede nella libertà. A parte il fatto che libertà non è solo quella di parlare, ma anche quella di decidere se ascoltare o no, libertà di parola significa che chiunque, negli spazi appropriati, può parlare senza dover temere alcun genere di conseguenze per via del significato e dei contenuti di ciò che ha detto. La libertà di parola non attribuisce a nessuno il diritto di venire a parlare nel mio salotto, perché in qualunque abitazione privata decide il proprietario chi può entrare e chi no. Altrettanto dicasi per il commercio: se non consento ad una azienda commerciale di affiggere manifesti nell'ingresso di casa mia, difficilmente questo può significare che io sia contro la libertà di commercio. In altre parole, tutte le libertà finiscono (come ci insegnavano alle scuole elementari) dove inizia quella del prossimo e, in particolare, dove inizia la sua proprietà privata. Tornando allo spam, la proprietà privata è, per esempio, il computer di qualsiasi utente della rete, così come la sua casella di posta elettronica e altre risorse che il provider di quell'utente gli mette a disposizione: ognuno paga per acquistare il computer, il software, l'abbonamento al proprio provider, paga per le connessioni telefoniche e per quant'altro necessario. Nessuno, quindi, ha diritto di considerare le risorse altrui come un mezzo di diffusione per i propri messaggi, quali che siano. Ci sono molti modi legittimi e produttivi per farsi pubblicità in rete, e la pubblicità è certamente benefica per la rete, in quanto finanzia in molti casi svariati servizi utili a tutti (un esempio lampante sono i motori di ricerca); è essenziale però che la pubblicità venga fatta nel rispetto delle proprietà altrui e della privacy di chiunque, e non in maniera parassitaria o invasiva. Molti pensano a internet come ad una grande struttura di tutti e di nessuno, qualcosa di pubblico come potrebbe essere la strada. Nulla è più sbagliato di ciò: internet è semplicemente l'interconnessione di un gran numero di reti private, ciascuna delle quali ha un ben preciso proprietario. Questo va sempre tenuto presente come base di partenza per ogni ragionamento. Insomma, capita pure a tutti di trovare volantini pubblicitari nella buca della posta! Basta buttare via ciò che non interessa, no? 7

NO. Diciamo intanto che pure la posta cartacea pubblicitaria non richiesta, pur essendo ormai una cosa a cui i più si sono abituati, crea i suoi problemi e può sovente essere un fastidio non trascurabile. Si pensi a coloro che, essendosi semplicemente assentati da casa per un paio di settimane, trovano la cassetta piena traboccante di opuscoli d'ogni genere e, magari, devono constatare che varia corrispondenza per loro importante è rimasta fuori dalla cassetta, rischiando di andare persa. Per non parlare di estratti conto o altre comunicazioni personali, che rimangono sul pavimento dell'atrio del palazzo a disposizione degli altri inquilini, o per non parlare del rischio che, buttando via in fretta ciò che non interessa, si faccia inavvertitamente finire nel bidone anche qualchecosa che, se ci fosse stato modo di notarlo, si sarebbe riconosciuto come corrispondenza "buona". Detto tutto questo, è necessario aggiungere che lo spam in email è diverso e molto peggio per varie ragioni. Innanzitutto, come fa giustamente notare Paul Vixie, per fare il paragone corretto dovremmo immaginare che i volantini in questione arrivassero con spese postali a carico del destinatario, e che questi non avesse la facoltà di respingerli: dovesse insomma pagare e poi, eventualmente, prendersi la soddisfazione di buttarli via. Il fatto che, per stampare e distribuire volantini e opuscoli, si incorra in dei costi, è probabilmente ciò che finora impedisce alla posta cartacea indesiderata di esplodere come problema. Nel caso dello spam, al contrario, il costo per chi lo spedisce è trascurabile, andando a gravare su tutte le strutture di rete che vengono percorse dai relativi messaggi. L'ultima di queste strutture di rete attraversate dagli spam è, in genere, il punto più debole dell'intera catena: il computer di un utente individuale, con limitate risorse di elaborazione, memoria e connettività. Come abbiamo detto è lui a sostenere il grosso del costo, anche e soprattutto sotto forma di tempo che deve perdere per fare la cernita tra spazzatura e email buone (osserviamo tra l'altro che, rispetto a chi sia alle prese con la cassetta postale traboccante di volantini, in questa operazione di cernita l'utente di posta elettronica è anche svantaggiato dal fatto di dover agire attraverso uno schermo di computer e un mouse). Come si vede, la posta elettronica è un mezzo di comunicazione con le sue specificità, che non consentono di paragonarlo facilmente ad altre situazioni della vita di tutti i giorni. In particolare occorre prendere atto della sua natura di mezzo "uno a uno". Tentare di farne un utilizzo per diffusioni bulk in assenza del consenso attivo di chi ne sia destinatario è cosa che, semplicemente, non scala e inceppa su tutti i fronti il sistema complessivo. Ma andiamo, che costo sarà mai scaricare qualche email di spam? Non sono mancati apologeti dello spam che, trascurandone l'effetto sulla produttività di chiunque utilizzi la posta elettronica, hanno provato a sostenere che, per la ricezione di una email, il costo puramente di rete sia minimo. Purtroppo non è così. Certi utenti ricevono molti messaggi indesiderati, qualcuno se la cava con 15-20 al mese, altri arrivano anche a 70-100 al mese, perfino di più quando si tratta di mailbox con indirizzo vecchio, che viene usato da svariati anni. Nel tempo si sono visti molti tentativi di stimare l'entità del danno in termini monetari. Qui citiamo le risultanze di uno studio effettuato per conto della 8

Commissione Europea: Unsolicited Commercial Communications and Data Protection (gennaio 2001). Si tratta di un documento di assai interessante lettura che giunge a valutare il costo per un singolo utente in circa 30 euro all'anno. La conclusione (tradotta da pag. 67) è così espressa: ...Su scala mondiale, assumendo una comunità online di 400 milioni [di utenti internet], il costo globale dello scaricamento di messaggi pubblicitari usando la attuale tecnologia può essere cautelativamente stimato in dieci miliardi di euro [all'anno] - e questa è solamente la frazione di costo che viene sostenuta dagli utenti direttamente. Si deve poi avere chiaro che ulteriori costi sono a carico dei provider, i quali per fornire i servizi hanno bisogno di maggiore banda, maggiore potenza e memoria per i propri sistemi, più personale per curare il buon funzionamento dei sistemi, più personale per il customercare, e così via. Tutti costi che poi, in un modo o nell'altro, devono scaricarsi sugli utenti. In buona sostanza, significa che le aziende e i privati hanno modo di acquistare servizi internet caratterizzati da un peggior rapporto qualità/prezzo. Il danno deve poi comunque essere valutato, come dicevamo, includendo pure il costo derivante dal tempo perso (spesso sottratto al lavoro) per fare pulizia della propria mailbox. In ogni caso, i numeri sono spaventosi: dieci miliardi di euro sono quasi ventimila miliardi di lire. Un enorme flusso di denaro, che gli utilizzatori della rete pagano ad aziende e individui che non conoscono, a cui non devono nulla e che da questa situazione sono gli unici a trarre un profitto. Eccoci quindi arrivati al vero nodo di tutta la questione, quello che consente di pronunciare una condanna definitiva di ogni forma di spam: lo spam è un vero e proprio furto di servizi. Si commette furto di servizi quando si utilizzano per i propri scopi computer e risorse altrui che sono in rete e vengono mantenuti per fare altre cose. In altre parole, si tratta di usare risorse altrui contro la volontà, espressa o tacita, di chi ha il diritto di escluderlo.

Conseguenza di ciò è anche il diritto per chiunque di adottare qualsiasi accorgimento tecnico possa servire ad impedire tale furto di servizio a danno del proprio sistema. È questo il fondamento alla base della lotta allo spam. Vale la pena, a questo proposito, di citare la contesa legale che vide opporsi America On Line e Cyberpromo. Cyberpromo era una famigerata organizzazione la cui unica ragione di esistere era appunto quella di 9

mandare spam massicciamente, tormentando chiunque capitasse nei loro elenchi e partendo dal tracotante presupposto che ciò fosse loro diritto. Quando Cyberpromo iniziò la propria attività, molti utenti di America On Line, presi di mira, protestarono. Alla fine America On Line adottò una soluzione efficace per proteggere gli utenti: configurò i propri apparati in modo da bloccare fisicamente tutto il traffico proveniente da Cyberpromo. Cyberpromo fece causa chiedendo al tribunale di proibire ad America On Line questo tipo di blocco. Il tribunale dette invece ragione ad America On Line. La sentenza fu importante perché rese chiaro un principio che peraltro era nei fatti: non esiste obbligo per alcuno, in rete, di accettare o veicolare il traffico altrui. Lo si fa su base volontaria e quindi, quando non lo si vuol fare, non lo si fa.

Ma non ci sono delle leggi? In buona sostanza no, o quasi. Occorre considerare soprattutto la legislazione statunitense, essendo operanti in tale paese la maggioranza degli spammer. La situazione attuale è che non molti tra gli stati degli USA hanno emanato leggi in materia di spam, e che non tutti lo hanno fatto nella maniera migliore. Tra quelli che hanno legiferato bene va citato senz'altro lo stato di Washington, in cui esiste una legge che prevede, per gli spammer, la condanna a sanzioni pecuniarie da pagarsi in favore degli utenti spammati. Teoricamente, i residenti in tale stato possono avvalersene, e si sono già avuti casi di azioni legali volte, per l'appunto, ad incassare. La validità della legge dello stato di Washington rispetto alla Costituzione degli Stati Uniti (che non consente a nessuno Stato di imporre restrizioni al commercio tra Stati) è stata contestata in tribunale senza successo: la Corte Suprema dello stato di Washington l'ha ritenuta valida e, dopo che i ricorrenti si furono rivolti alla Corte Suprema degli Stati Uniti, questa rifiutò (nell'ottobre 2001) di esaminare la questione. Non si ebbe quindi un pronunciamento esplicito della Corte Suprema, tuttavia rimase così in effetto la decisione presa nello stato di Washington che faceva salva la validità della legge. In sostanza, si è avuta dalla Corte Suprema federale una implicita conferma che gli stati degli USA hanno potestà legislativa sulla materia.

In altri stati (es. California o Virginia), la possibilità di citare in giudizio gli spammer ed ottenere risarcimenti danni è attribuita ai provider. Leggi di quest'ultimo tipo possono essere utili tuttavia, come si è potuto constatare, risultano assai meno efficaci di quelle che prevedono il diritto di azione da parte del consumatore. Va rilevato che, già da tempo, è in vigore negli USA una legge federale su un argomento molto simile: l'abuso dei fax. Grazie a tale legge (United States Code Title 47 Section 227), nota come "junk fax law", non è consentito inviare fax indesiderati da chi li riceve: il fatto che qualcuno tenga acceso un fax con ricezione automatica non autorizza nessuno ad approfittarne per inviargli pubblicità o altro. Può essere anche notevole il danno arrecato ad una azienda qualora, tenendole impegnato il fax, le si impedisca di fatto di ricevere messaggi importanti. Tale legge ha dimostrato di avere risolto il problema, ma la possibilità di una sua applicazione ai computer non è mai apparsa facile. Per questo si costituì la CAUCE (Cohalition Against Unsolicited Commercial Email), il cui scopo è quello di giungere alla messa fuori legge delle e-mail commerciali non richieste. Vale la pena di visitare il sito della CAUCE per osservare quanto sta avvenendo su tale fronte. Non sempre le notizie sono buone, poiché spesso vanno avanti disegni di legge sostenuti dagli spammer 10

o comunque da interessi economici legati al mondo del marketing: questi puntano a "legalizzare" lo spam, facendo approvare una regolamentazione nell'ambito della quale questo tipo di attività possa essere svolto in tutta tranquillità. Tradizionale richiesta degli spammer è quella di istituzionalizzare la inaccettabile soluzione dell'opt-out (ossia, legittimare l'invio di spam finché ciascuna vittima non chiede formalmente, a ciascuno spammer, di smettere). Questa soluzione a volte si presenta sotto altre forme (comunque non più convincenti) come il cosidetto opt-out globale (o global remove list). Noterete quindi che la CAUCE appoggia alcuni disegni di legge (in particolare appoggiò, a suo tempo, lo Smith Bill, che richiedeva la semplice estensione della junk fax law in modo che fosse applicabile anche all'e-mail) e ne avversa fortemente altri. In particolare sono da considerarsi pericolosi i disegni di legge presentati in USA dal senatore Murkowski e, fortunatamente, mai giunti ad approvazione da parte del Congresso. L'utilità, per gli spammer, di leggi basate sull'opt-out come quelle proposte da Murkowski è evidente se si considera che, fin dalla semplice presentazione di tali disegni di legge, si son visti circolare spam contenenti il cosidetto Murk-disclaimer: This ad is being sent in compliance with Senate Bill H.R.1910 of the 106th Congress May 24,1999. È appena il caso di ribadire che tali disclaimer (spesso codificati nei prodotti software usati dagli spammer) non hanno alcun valore: primo perché le leggi citate non esistono, secondo perché, anche quando la legge non vieta espressamente l'invio di uno specifico messaggio di email, quel messaggio può comunque essere in violazione delle policy dei provider coinvolti. Giusto per introdurre una nota di umorismo possiamo citare che, talvolta, si vede inserita negli spam di origine italiana una traduzione letterale del disclaimer suddetto. Si può osservare che, non essendoci limite all'idiozia degli spammer, sarebbe troppo aspettarsi che questi pensassero, prima ancora che alla falsità di quanto dichiarato, almeno al fatto che le leggi americane in ogni caso non hanno valore in Italia.

In definitiva, è indiscutibile che una buona legge possa aiutare moltissimo a venire a capo del problema, ma è anche chiaro che una cattiva legge potrebbe decisamente peggiorare la situazione. E in Italia? Qualcosa c'è già, anche se non quanto di più chiaro e completo si potrebbe desiderare. Una legge in cui si è a lungo tentato di trovare qualche appiglio è la 675/96 sulla protezione dei dati personali, nota anche come "legge sulla privacy". La materia legale è, per sua natura, ostica a chiunque non abbia specifiche competenze, pertanto si è a lungo dubitato sul fatto che la 675 potesse applicarsi agli indirizzi di email. Il dubbio oggi non esiste più: l'indirizzo di email è un dato personale a tutti gli effetti, e non occorre che contenga il nome del suo utilizzatore. Anche una stringa del tutto impersonale come [email protected], se fosse il reale indirizzo email di qualcuno, sarebbe un dato personale soggetto alla tutela della legge 675. Pertanto, ai fini del nostro problema, si tratta di affermare il diritto di ciascuno a non vedere utilizzato, senza il proprio consenso, un dato personale quale l'indirizzo di email. Un primo concreto riscontro che ha aperto le speranze sulle possibilità di perseguire questa strada si è avuto con un pronunciamento, avvenuto in data 11 gennaio 2001, da parte della Autorità Garante per la protezione dei dati, intervenuta in seguito alle segnalazioni pervenute da persone che erano state raggiunte da mailing di spam a contenuto politico. Per estrarre il punto principale di tale pronunciamento, si può 11

sintetizzare che è stato dichiarato illegittimo, in mancanza di esplicito consenso da parte degli interessati, l'utilizzo di indirizzi di email prelevati da varie aree della rete (come newsgroup e pagine web), in quanto tali aree, pur essendo liberamente accessibili da chiunque, non sono soggette ad alcun regime giuridico di piena conoscibilità da parte di chiunque (per intenderci, il regime giuridico di piena conoscibilità esiste, a titolo di esempio, per i dati presenti nell'elenco telefonico). Questo fa dunque cadere una volta per tutte la più classica delle obiezioni sollevate dagli spammer: "ho reperito il tuo indirizzo di email su un'area di rete pubblicamente accessibile, quindi ho il diritto di usarlo per i comodi miei". Dunque, è ora assodato nella giurisprudenza che nessuno ha il diritto di usare a scopo di spam degli indirizzi raccolti in giro per la rete, e che anche il fatto di fornire ai destinatari la possibilità di "disiscriversi" è ininfluente: la pratica in questione resta illegale e inaccettabile. Analogamente ininfluenti sono certi trucchetti, più che altro verbali, che si sono già visti da parte degli spammer. Per esempio, certi spammer hanno provato a dire: "gli indirizzi dei nostri mailing vengono generati da un programma che mette assieme le stringhe di caratteri casualmente; non occorre pertanto farsi togliere dalla lista perché non esiste una lista e non ci saranno ulteriori invii.". Ovviamente non è proibito generare stringhe di caratteri casualmente, tuttavia se una di queste stringhe risulta essere (che combinazione, però) un valido indirizzo di email appartenente a qualcuno e viene poi, di fatto, usata per inviare email, ciò costituisce comunque elaborazione di un dato personale altrui, cosa per cui serve il consenso. Nonostante questo resta che, per cercare di perseguire gli spammer in base alla legge 675, la procedura non è semplice e comporta qualche costo, sia in termini di tempo che di denaro. Occorre infatti spedire raccomandate, versare dei diritti di segreteria e, soprattutto, sapere cosa scrivere, come funziona il procedimento di fronte all'Autorità Garante, come controbattere alle mosse della controparte. Inoltre, la cosa è applicabile solo a spammer italiani. Va poi osservato che gli spammer non stanno a guardare e che, come del resto tipico della categoria, inventano ogni genere di trucchi ed espedienti per inceppare qualsiasi azione che miri a neutralizzare le loro attività. Anche se molti possono ritenere la strada non semplice da praticarsi resta che oggi, di fronte a spammer presenti pure in Italia e sempre più determinati e organizzati, nessun fronte di lotta si possa trascurare. Anche la legge 675 può funzionare e, quindi, indurre molte aziende a recedere da certe tentazioni ad abusare dei diritti altrui. Per chi fosse interessato ad agire contro gli spammer in base alla legge 675, è d'obbligo la lettura della completa guida redatta da Massimo Cavazzini http:// www.maxkava.com/spam.htm, che tratta a fondo le modalità con cui si possono combattere gli spammer per mezzo della legislazione italiana e, soprattutto, descrive dettagliatamente le modalità concrete con cui effettuare il procedimento presso l'Autorità Garante. Si tratta di una guida che trae origine dal caso concreto in cui, nei primi mesi del 2002, l'autore agì con successo contro uno spammer, giungendo ad ottenerne la condanna da parte dell'Autorità Garante. Fu quindi il caso che, non avendo precedenti, aprì la pista su questo fronte di lotta, dimostrandone la praticabilità e rendendo così disponibile a tutti un nuovo strumento per la difesa dei propri diritti. Sul sito di Cavazzini è presente pure un forum, punto di ritrovo obbligato per chi provasse ad utilizzare le leggi disponibili (non solo la 675) contro gli spammer e si trovasse, prima o poi, nella necessità di avere consigli su come procedere. Vi è quindi un "nocciolo duro" di utenti che si va specializzando in questo 12

genere di azioni, collaborando tra loro e condividendo le esperienze che ne risultano. Ne deriva pertanto una sorta di know-how collettivo che sarà, nel tempo, sempre più utile per orientare chi volesse seguire questa strada. Proseguendo nella rassegna delle principali leggi disponibili, esiste il decreto legislativo n. 185 del 22 maggio 99 (recepimento di una direttiva comunitaria), che prevede limitazioni a certi tipi di comunicazione. L'ambito di applicazione è, rispetto alle esigenze degli utenti di posta elettronica, alquanto ristretto e, soprattutto, non si è ancora saputo di casi in cui le disposizioni siano state concretamente applicate. È tuttavia assai importante leggere i passi rilevanti del suddetto decreto (pubblicato nella Gazzetta Ufficiale n. 143 del 21 giugno 1999): Art. 10. Limiti all'impiego di talune tecniche di comunicazione a distanza 1. L'impiego da parte di un fornitore del telefono, della posta elettronica di sistemi automatizzati di chiamata senza l'intervento di un operatore o di fax, richiede il consenso preventivo del consumatore. Art. 12. Sanzioni 1. Fatta salva l'applicazione della legge penale qualora il fatto costituisca reato, il fornitore che contravviene alle norme di cui agli articoli 3, 4, 6, 9 e 10 del presente decreto legislativo, ovvero che ostacola l'esercizio del diritto di recesso da parte del consumatore secondo le modalita' di cui all'articolo 5 o non rimborsa al consumatore le somme da questi eventualmente pagate, e' punito con la sanzione amministrativa pecuniaria da lire un milione a lire dieci milioni. 2. Nei casi di particolare gravita' o di recidiva, i limiti minimo e massimo della sanzione indicata al comma 1 sono raddoppiati. 3. Le sanzioni sono applicate ai sensi della legge 24 novembre 1981, n. 689. Fermo restando quanto previsto in ordine ai poteri di accertamento degli ufficiali e degli agenti di polizia giudiziaria dall'articolo 13 della predetta legge 24 novembre 1981, n. 689, all'accertamento delle violazioni provvedono, di ufficio o su denunzia, gli organi di polizia amministrativa. Il rapporto previsto dall'articolo 17 della legge 24 novembre 1981, n. 689, e' presentato all'ufficio provinciale dell'industria, del commercio e dell'artigianato della provincia in cui vi e' la residenza o la sede legale dell'operatore commerciale. Come si vede, manca una definizione di spam e di posta indesiderata; il decreto del resto 13

riguarda la correttezza nel commercio, non la correttezza in rete, quindi il nostro problema viene interessato solo "di striscio". Pur con queste riserve, resta un fatto: in una materia in cui le legislazioni nazionali tendono sostanzialmente a dividersi in due gruppi, quelle che istituzionalizzano l'inaccettabile opt-out e quelle che prescrivono prassi di tipo opt-in, l'Italia si è collocata fin dall'inizio nel secondo dei due gruppi, e di ciò va certamente reso atto (nel testo della direttiva comunitaria recepita da questo decreto non erano presenti le parole "posta elettronica"). Dunque, in presenza di questa norma, chiunque intenda effettuare commercio avvalendosi della rete farà bene ad evitare accuratamente qualunque comportamento anche solo assimilabile all'invio di comunicazioni non richieste. Come si può infatti vedere, le sanzioni esistono e la facoltà di sporgere denuncia è concessa a qualsiasi consumatore (oltre alla possibilità che si proceda d'ufficio). Inoltre, queste disposizioni sembrano potersi applicare pure ad alcune altre pratiche assai intrusive quali l'invio di messaggi sms pubblicitari ai cellulari o i fax pubblicitari non richiesti. A livello europeo, alcuni stati hanno legiferato: qualcuno (è il caso dell'Austria) bene, altri non sempre nella maniera migliore. Riguardo alle normative comunitarie, nel luglio 2000 fu pubblicata sulla Gazzetta ufficiale delle Comunità europee la Direttiva 2000/31/CE del Parlamento Europeo e del Consiglio, detta anche "Direttiva sul commercio elettronico". Per riassumere brevemente, una prima proposta della Commissione del novembre 98 dava per scontato che la comunicazione non sollecitata per posta elettronica esistesse, prevedendo semplicemente l'obbligo per il mittente di contrassegnarla in modo che "sia identificata come tale, in modo chiaro e inequivocabile, fin dal momento in cui il destinatario la riceve", ossia: si possa riconoscere che è spam prima di aprirlo (peccato però che, a quel punto, si sia ormai pagato per riceverlo). La mobilitazione avutasi da parte di utenti e provider per giungere al divieto di inviare spam per posta elettronica si scontrò con la ferma opposizione di vari paesi (anglosassoni e scandinavi) e, dopo ulteriori passaggi, si giunse alla formulazione adottata, che per risolvere il problema non giova assolutamente a nulla, però almeno non provoca grossi danni aggiuntivi. La partita tuttavia non era ancora chiusa. Utenti e provider hanno continuato a premere per avere un divieto allo spam a livello europeo, e qualcosa ha cominciato a muoversi, grazie alla Commissione Europea in carica nel 2001/2002 e, in particolare, alla sensibilità in materia dimostrata dal commissario finlandese Liikanen e da alcuni europarlamentari che hanno preso a cuore la vicenda (vedasi il sito di EuroCAUCE per maggiori informazioni). Va certamente citato, per esempio, un ottimo documento (WP 37) prodotto dal Gruppo di Lavoro sulla Protezione dei Dati nel novembre 2000, in cui si trattavano vari argomenti relativi alla privacy in rete e, per ciò che riguarda lo spam, si raccomandava l'adozione di una legislazione di tipo opt-in in tutta Europa. Ciononostante, l'ignoranza di molti politici sull'argomento (unita alla sempre forta tendenza a tutelare, ai danni delle esigenze dei consumatori e persino del rispetto della proprietà privata, quelle che certuni credono essere le esigenze del marketing e del commercio) ha a lungo inceppato la concretizzazione di una normativa che imponesse l'opt-in a tutti gli stati europei. Si è perfino dovuto sentire l'assurdo argomento secondo cui una tale normativa costituirebbe una minaccia per la 14

libertà di espressione, unita ad altre argomentazioni bizzarre come quella secondo cui, oggi, con la disponibilità della "larga banda" il costo del ricevere spam sarebbe trascurabile. Quando il Parlamento Europeo decise di consentire ad ogni stato membro la scelta tra optin e opt-out, tutto sembrò perduto. Fortunatamente il Consiglio Europeo non accettò tale conclusione e, dopo una fase di mediazione, a fine maggio 2002 Parlamento e Consiglio concordarono su un testo che, nella sostanza, è il tanto desiderato opt-in europeo. Si prevede che, entro il 2003, tale normativa verrà recepita nelle legislazioni nazionali degli stati partecipanti all'Unione Europea e all'EFTA. A quel punto si potrà sperare che i "buchi" ancora presenti nella legislazione vengano chiusi e che gli strumenti disponibili siano più facilmente applicabili. Un'altra osservazione è che, in questo caso, l'Europa ha compiuto una scelta lungimirante che gli USA, purtroppo, sembrano ancora lontani dal raggiungere. È peraltro storia nota che, in generale su tutto ciò che concerne la protezione dei dati personali, gli USA siano ancora fermi su posizioni assai retrograde. Possiamo quindi solo augurare ai cittadini americani di riuscire, finalmente, a "sganciare" i loro rappresentanti dal controllo che su di essi è stato finora esercitato dalle lobby del marketing e dal mondo del business in generale.

Indice

<< Precedente

Successiva >>

Ultimo aggiornamento: 24 dicembre 2002

Leonardo Collinelli

15

Come comportarsi quando si riceve spam Prima di tutto non arrabbiarsi Sarebbe una reazione naturale ma del tutto inutile. Quando il messaggo indesiderato si materializza sotto i vostri occhi, guardatelo dall'alto al basso. Non consideratelo corrispondenza seria Nessuno che avesse qualcosa di serio da dirvi userebbe invii massivi di e-mail non sollecitate; chi lo fa, già si squalifica per questo. Comunque, il contenuto dei messaggi di spam è normalmente pubblicità di qualsiasi cosa, da prodotti miracolosi per far crescere i capelli a servizi porno, ad organizzazioni di multi-level marketing, a proposte di investimenti assai improbabili, ad apparecchi per vedere gratis la tv via cavo, per finire con le classiche catene di S. Antonio (note come chain-letter) o i make-money-fast, che sono gli schemi piramidali generalmente indicati come MMF. Vanno citati anche i cosidetti "419", nome con cui si indica un tipo di truffa (solitamente opera di bande criminali nigeriane) perpetrato già da molto tempo via fax e posta cartacea e, naturalmente, ora anche via posta elettronica. Per non parlare poi degli spam relativi al mercato azionario americano: una ondata di spam che esalti l'opportunità di acquistare certe particolari azioni può anche avere l'effetto di indurre un certo numero di persone ad acquistarle, con la conseguenza che il titolo è soggetto ad un breve rialzo e che, a quel punto, qualcuno che si stava tenendo pronto a vendere ne può beneficiare. Si sono poi già avuti anche casi di spam profondamente odiosi, il cui scopo era vendere finte medicine a persone disperatamente malate. Come vedete, è tutta spazzatura: si tratta di cose che sarebbero impresentabili sul normale mercato. Chi si pubblicizza con e-mail non sollecitate sta anche cercando di evitare il confronto con il mercato e con i suoi meccanismi di autodifesa dalle fregature. Del resto, quando si ha a che fare con lo spam per qualche tempo, si nota che una comune linea di comportamento da parte di chi lo pratica è lo stare nell'ombra, tenersi anonimo e coprire il più possibile ogni propria traccia. Non è un caso se, tra gli spammer che è stato possibile individuare (soprattutto in America, ma non solo lì, di molti spammer è stata scoperta l'identità, la storia personale e le relative vicissitudini), se ne è trovato più d'uno che avesse problemi con la giustizia e/o una storia di truffe e una vita di espedienti.

Qualcuno potrebbe dire: se è così ovvia l'inattendibilità di queste proposte, presumibilmente nessuno le prenderà in considerazione; perché allora il fenomeno dello spam continua a crescere come dimensioni? È presto detto: come abbiamo già visto, i costi dello spam non sono pagati da chi lo invia, ma da chi lo riceve. Con pochi minuti di 16

connessione uno spammer può spedire lo stesso messaggio in copia anche a decine o centinaia di migliaia di persone e, essendo per lui il costo quasi nullo, basta che uno solo dei destinatari ci caschi perché ogni spesa venga ripianata abbondantemente. Quindi è importante che non siate voi quello che ci casca. Assolutamente non rispondete allo spammer, non importa per dire che cosa Sarebbe l'errore peggiore. Verrebbe voglia di scrivergli dicendogliene di tutti i colori, ma occorre valutare quali possano essere gli effetti. Prima di tutto tenete presente che gli spammer sanno benissimo di essere molesti e che la stragrande maggioranza dei loro destinatari li detesta con tutte le forze. Facendoglielo notare, quindi, non cambia nulla. Se lo spammer riceve una vostra e-mail (che sia di protesta o, ancora più ingenuamente, di garbato rifiuto dell'offerta prospettata), questo ha per lui un unico valore: gli conferma che il vostro indirizzo di e-mail è valido e che, ad esso, corrisponde una persona che ne legge i messaggi. E' quindi probabile che inserisca il vostro indirizzo in altre liste o, come generalmente avviene, che rivenda il vostro indirizzo di e-mail ad altri spammer (un indirizzo la cui validità sia verificata ha un valore commerciale maggiore). Tutto questo senza contare che non è affatto frequente che i messaggi di spam contengano un indirizzo di e-mail a cui rispondere. Molto spesso troverete impostati degli indirizzi non validi o, eventualmente, indirizzi di qualcuno che con l'invio del messaggio non c'entra nulla e che lo spammer inserisce per sviare i sospetti (in tutti questi casi, il contatto per rispondere è dato nel testo del messaggio e, nella maggior parte dei casi, è un numero di telefono in USA). Sulla inutilità in generale di contattare lo spammer sono disponibili le esperienze che alcuni hanno raccontato. Vedendo, per esempio, uno schema piramidale postato da studentelli inconsapevoli, è umanamente plausibile che qualcuno voglia provare a spiegargli l'errore per ricondurli ad un corretto uso della rete. In questi casi, sono state riferite reazioni risentite e risposte un po' insolenti (del tipo: io intanto spedisco...). Insomma, tutto tempo perso. Quindi, assolutamente, sconsiglio di manifestarvi direttamente allo spammer a meno che, ovviamente, non siate per qualche ragione ben sicuri di quello che state facendo. Non seguite MAI alcuna istruzione data nel messaggio (es. Reply REMOVE) Diffidate in linea di principio da qualunque operazione vi venga richiesto di effettuare, specialmente se in rete. Anche quando venisse prospettata la cessazione dell'invio di e-mail al vostro indirizzo. Se poi si trattasse di un messaggio formattato in HTML, non bisogna clickare nulla di ciò che ci si vede sopra. Anzi, sarebbe meglio addirittura evitare di aprirlo nel browser. Un caso particolare che si verifica abbastanza spesso e che va visto alla luce di questo consiglio generale è quando lo spammer fornisce istruzioni per farsi togliere dai suoi elenchi. Vediamo un esempio, tratto da un messaggio di spam che ho ricevuto tempo fa: 17

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Note: We have contacted you based on information that we gathered while visiting your website - If you would prefer not to receive mail from us in the future, just send an email to [email protected] with Remove in the subject and you will be promptly excluded from future mailing. Thanks and we apologize for any inconvenience. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Traduzione: La abbiamo contattata in base all'informazione raccolta visitando il suo sito web. Se preferisce, nel futuro, non ricevere mail da noi, basta che invii all'indirizzo [email protected] una email con la parola Remove nel campo subject, e verrà prontamente escluso dai futuri mailing. Grazie e ci scusiamo per qualunque fastidio le avessimo arrecato.

Un altro esempio simile: We apologize for the intrusion. To remove your name from our list "reply" and type "remove" in the subject heading. Traduzione: Ci scusiamo per l'intrusione. Per togliere il vostro nome dalla nostra lista effettuate un reply indicando "remove" nel campo subject.

Che dire di questa prosa studiata in modo da ispirare simpatia e comprensione? Che non bisogna lasciarsene infinocchiare. Il mittente spera in questo modo di indurvi a non prendere i provvedimenti che troverete descritti nel prossimo capitolo. Per questo tanta cortesia. Per questo l'offerta di essere tolto dall'elenco, che può perfino apparire come un'ancora di salvezza a chi non sapesse come affrontare il problema. Però bisogna chiedersi: chi ci garantisce che una richiesta di remove venga onorata come promesso? Nessuno; anzi, in molti casi c'è addirittura evidenza del contrario, ossia chi invia la richiesta di remove viene di solito inserito in altri elenchi. E poi, se anche il remove funzionasse, quanto del vostro tempo dovreste passare a inviare e-mail con la parola remove nel campo subject, se chiunque avesse un sito di rete vi mandasse, anche una sola volta, un messaggio come quello? Qualche conto è stato fatto: anche se solo l'1% dei 20 milioni di imprese americane presenti in rete adottasse questa pratica, l'utente medio si troverebbe a dover spedire circa 200 richieste di remove ogni giorno. Chiunque può immaginare quanto sarebbe agevole, in tale marasma, rintracciare le email inviate da amici, clienti e quant'altro effettivamente interessi. Quindi, di fronte ad un educatissimo "ci scusiamo per il disturbo" bisogna piuttosto chiedersi: ma se immaginava che potesse essere un disturbo, perché me lo ha spedito lo stesso? Per sintetizzare, possiamo dire che la pratica del cosidetto "opt-out" (ossia, la possibilità di uscire dagli elenchi a richiesta) non è una soluzione accettabile. Gli spammer che dichiarano di offrire questa opzione devono essere trattati né più né meno come gli altri, non importa quanto siano gentili nel testo dei loro messaggi. 18

Se poi vogliamo chiamare le cose con il loro nome, l'opt-out non è che un imbroglio. Il punto della questione è se spetti all'utente decidere che cosa intenda ricevere nella propria mailbox. Opt-out significa semplicemente che l'utente non ha questo diritto. Non attuate forme di ritorsione diretta sullo spammer (tipo mailbombing o simili) Sarebbe un modo sicuro per passare dalla parte del torto. Azioni del genere potrebbero danneggiare, più ancora dello spammer, altri sistemi utilizzati da parecchi utenti che non c'entrano nulla. Gli amministratori di tali sistemi prenderebbero, molto verisimilmente, dei provvedimenti nei confronti di chi avesse perpetrato tale azione, il quale non avrebbe nessuna giustificazione valida. Ma allora che cosa si può fare? Si adatta ottimamente l'esempio del bambino che suona il campanello e scappa. Sarebbe sbagliato scendere in istrada a sbraitare dietro il bambino in fuga: non si farebbe che rendere più gustoso il suo divertimento. Peggio che peggio sarebbe corrergli dietro con un bastone. La soluzione corretta è una sola: individuare dove il bambino abita, andare a parlare con suo padre o sua madre e lasciare che siano loro ad occuparsene. Cosa significhi fare questo nei confronti di uno spammer è argomento del prossimo capitolo.

Indice

<< Precedente

Successiva >>

Ultimo aggiornamento: 24 dicembre 2002

Leonardo Collinelli

19

La corretta controffensiva allo spam: RECLAMARE Chi si fa pecora il lupo se lo mangia. Non siamo costretti a subire: qualcosa possiamo fare Nel capitolo precedente abbiamo visto una serie di cose da non fare. Ora vediamo qual è l'unico provvedimento che può (anche se non nel 100% dei casi) rivelarsi efficace. Esiste una sola cosa che possa mettere lo spammer in condizione di non poter più nuocere: perdere l'uso delle risorse che gli danno una presenza in rete. Se il suo provider gli cancella improvvisamente l'abbonamento, lo spammer cercherà di attivarne un altro presso un altro provider. Fino a quel momento non potrà che rimanere fermo con il suo discutibile "lavoro", così la nostra mailbox avrà finalmente un po' di giorni di tranquillità. Eventualmente, dopo aver trovato un altro provider il nostro spammer non potrà non chiedersi se vale la pena di farsi cacciare via anche da lì. Dover cambiare provider ogni qualche giorno è indubbiamente snervante anche per gente di notevole protervia, come viene indirettamente confermato dal fatto che, ogni tanto, si vedono pubblicizzare prodotti per spammer e connessioni spam-friendly con frasi tipo: "Siete stanchi di perdere continuamente il vostro account?". Ovviamente questo provvedimento può essere preso solo da chi fornisce allo spammer la connettività in rete, vale a dire dal suo provider. È quindi al suo provider che bisogna rivolgersi, cosa che si fa via e-mail. Come esattamente si deve procedere ●

●

●

Occorre ovviamente individuare, per prima cosa, chi sia il provider dello spammer. Questa fase è quella che, pur essendo in definitiva alla portata di tutti, richiede un minimo di conoscenza tecnica su come funziona la rete e la padronanza d'uso di alcuni strumenti e risorse. Poi si cercherà di sapere qualcosa in più sul provider in questione, in particolare l'esatto indirizzo di e-mail a cui è previsto siano da inviarsi questo genere di segnalazioni. A questo punto si deciderà come scrivere l'e-mail.

Tutti questi passi richiedono ampia trattazione, cui sono dedicati appositi capitoli. 20

Vale la pena di prendersi questo fastidio? La risposta è senz'altro SI`. Se nessuno mandasse le segnalazioni, i provider non avrebbero alcun mezzo per far rispettare i propri regolamenti d'uso del servizio, e neppure di rendersi conto tempestivamente dell'esistenza del problema. Gli spammer dilagherebbero e, di conseguenza, il volume di messaggi commerciali indesiderati esploderebbe, travolgendo la maggior parte delle infrastrutture di rete e dei server. La posta elettronica diventerebbe ben presto inservibile come mezzo di comunicazione. Passando poi al punto di vista più individuale-utilitaristico, se appare che uno spammer possiede il vostro indirizzo di email, lasciarlo operare indisturbato è ovviamente solo a vostro svantaggio. Nel caso qualcuno avesse ancora degli scrupoli, gioverà riflettere sul fatto che inviare spam come normale prassi, semplicemente perché lo si ritiene vantaggioso e ignorando i danni che in questo modo si provocano, è anche e soprattutto un comportamento antisociale. È nell'interesse di tutti (fuori che degli spammer, ovviamente) fare in modo che l'invio di spam non possa essere profittevole. Ci sono dei rischi? A questo si può tranquillamente rispondere di no. Reclamare quando si riceve spam è la soluzione più diffusa, praticata da tantissime persone in tutto il mondo. Quando si reclama contro un messaggio di spam, è molto probabile che ci si trovi in compagnia di molti altri utenti che abbiano ricevuto lo stesso spam e, a loro volta, abbiano reclamato. In ogni caso, nessuno vi verrà mai a cercare di persona. Agendo incautamente si può al massimo rischiare di ricevere più spam: comunque, l'unico caso in cui questo rischio esiste è quando lo spammer è il provider di sè stesso e, quindi, è proprio lui a ricevere il reclamo. Vedremo come evitare questo errore (tuttavia, se anche accadesse, a tutto c'è rimedio). Non potrei semplicemente mettere filtri sulla mia posta in arrivo? In questo paragrafo parliamo di filtri intendendo delle "regole", da verificarsi sul testo delle email in arrivo una volta che siano state ricevute. A seconda che ciascuna regola risulti verificata o no, si otterrà un differente trattamento del messaggio. Tanto per capirci, un esempio tipico potrebbe essere di questo genere: SE il titolo della mail contiene la parola "enlargement" ALLORA cancella il messaggio Se state pensando di poter essere voi stessi, in qualità di utente, a impostare dei filtri sulla vostra posta in arrivo, si tratta di una soluzione che in effetti molti adottano ma che ha dei limiti. Occorre innanzitutto distinguere tra i vari tipi di filtro gestibili da parte di un utente. ●

Filtri sul client Usare questi filtri significa che il vostro mail client deve comunque scaricare gli 21

●

header di tutti i messaggi presenti nella casella, decidendo poi in automatico quali cancellare (scaricando quindi il testo solo per gli altri). In definitiva, occorre lo stesso un certo qual traffico lungo la vostra connessione e, soprattutto, del tempo trascorso on-line mentre il programma opera. Inoltre, quando eliminate un messaggio quel messaggio ha già costituito un costo per il vostro provider (che ha dovuto usare banda per farlo arrivare, spazio disco per memorizzarlo e risorse di macchina per elaborarlo), e potete scommettere che tale costo venga inevitabilmente scaricato sul costo degli abbonamenti o, comunque, vada a scapito del livello di servizio che il provider è in grado di offrirvi con le sue risorse. Pertanto, il vantaggio di questo approccio è decisamente limitato. Filtri sul server Questi sono già molto più utili, in quanto il lavoro viene fatto dal server man mano che i messaggi arrivano, senza che voi siate connessi alla rete. Quando vi connettete trovate i soli messaggi accettati, senza quindi perdere tempo con gli altri. Sovente, però, questi sistemi prevedono solo di "marcare" i messaggi che si sospetta possano essere spam: è evidente che, in questo caso, il beneficio che possono dare è nullo o quasi.

Tentando di riepilogare, in pratica possiamo incontrare: ●

●

●

●

Mailbox prive di qualsiasi filtro Sono in questa situazione la grande maggioranza dei provider. Mailbox con possibilità di settare filtri sul mittente (campo 'From:') Hanno iniziato a percorrere questa strada molti servizi di web-mail gratuita. In realtà, basarsi sul campo 'From:' è di utilità assai limitata, dato che il campo può essere arbitrariamente settato dal mittente e gli spammer lo cambiano in continuazione. Questo tipo di filtro può a mio avviso avere una sua utilità solo per le mailbox che si intendesse usare per ricevere email da un insieme prestabilito di corrispondenti (redigendo una whitelist degli indirizzi da cui accettare email e respingendo tutto ciò che venga da indirizzi differenti). Mailbox con possibilità di settare filtri su vari campi In questo caso le possibilità sono maggiori, tuttavia si riducono molto se si intende mettere dei filtri e non doverci più tornare sopra. Probabilmente l'unica regola che si puà tranquillamente settare una volta per tutte è bloccare i messaggi con la stringa [email protected] entro l'header 'To:' (si trovano sempre spam con questa caratteristica). Mailbox con possibilità di settare filtri sul server di provenienza Questo tipo di filtraggio consente di intervenire su specifici server che risultino frequentemente origine di posta indesiderata. È una possibilità decisamente rara da incontrarsi e, pur non essendo rari i casi in cui può tornare utile, tutto sommato per un utente finale non è così comodo determinare e mantenere in proprio una simile blacklist.

Traendo le conclusioni, la soluzione dei filtri settati dall'utente ha dei limiti piuttosto pesanti: 22

●

●

●

●

●

●

Si agisce solo a posteriori. Prima si riceve lo spam, poi si cerca di determinare il filtro adeguato per bloccarlo. Gli utenti nuovi o di cultura non tecnica avrebbero certamente difficoltà a realizzare dei filtri, rimanendo così alla mercé degli spammer. Occorre dedicare tempo in continuazione per tenere aggiornati e raffinare i propri filtri. Nessun filtro è affidabile: esiste sempre un certo rischio che si abbiano falsi positivi e che quindi delle email legittime (magari importanti) vadano perse. Inoltre, gli spammer ed i produttori di software per spammer mettono a punto tecniche sempre più evolute per rendere il filtraggio sempre più critico (e rischioso) anche per gli utenti esperti. In ogni caso, quando mettete un filtro state limitando la vostra connettività in rete. Sarebbe molto più giusto limitare piuttosto la connettività degli spammer. Quand'anche fosse attivabile e mantenibile senza particolari difficoltà, un insieme di filtri individuali (validi per il singolo utente su singoli spammer) lascerebbe comunque la rete nella situazione di partenza, senza forzare nessuno a risolvere il problema e senza produrre alcuna vera soluzione che si possa condividere sulla rete, in modo da poterne beneficiare tutti.

In conclusione, potremmo fare un paragone dalla vita di tutti i giorni: cercare di risolvere il problema dello spam con dei filtri assomiglia a voler risolvere il problema dell'inquinamento portando una mascherina filtrante davanti alla faccia, invece che prendendo provvedimenti contro chi inquina. Nel caso in cui qualcuno dubitasse sul fatto che gli spammer, come detto poco sopra, siano sempre in cerca di tecniche per aggirare i filtri, al fine di far arrivare i loro messaggi anche sui sistemi di coloro che assolutamente e al di là di ogni dubbio non li vogliano, sarà illuminante la lettura di questo breve passo, con cui si concludeva un messaggio di spam via email. Va detto che lo stratagemma impiegato in questo caso, ossia l'inserimento di testo random entro il corpo del messaggio, non è gran che e, verisimilmente, non giova per superare alcun filtro. È tuttavia indicativo che l'intenzione ci sia e che venga così serenamente ammessa: NOTE: Please ignore anything below the End of Message line. What looks like extraenuous text is automatically inserted into our messages by our software mailing program and constitutes what is call a "unique text insertion" or UTI. It allows this message to bypass filters on some of the larger domains. That's all. Thank you for understanding. End of message. ******************************************************* Thus, within given parameters, initiation of critical subsystem development does not affect the structure of problems of phonemic and morphological analysis. *******************************************************

Tutte queste considerazioni si riconducono ad una: la ragione principale (indipendente da 23

ogni considerazione sulla tecnologia disponibile) per cui la soluzione dei filtri non è accettabile è che, in tal modo, si scarica sull'utente l'onere di tenere le email indesiderate fuori dalla propria mailbox. Appare come unica soluzione equa che l'onere di non inviare email a chi non le ha richieste sia lasciato su chi intende trarre profitto da quel mailing. Se qualcun altro ha già reclamato io posso farne a meno? È meglio farlo ugualmente. Se il provider destinatario riceve molti reclami si renderà meglio conto della dimensione del problema ed è più probabile che si adoperi per risolverlo. Come si comportano i provider che ricevono il reclamo? La risposta, ovviamente, varia caso per caso. In generale, non è vero che i provider rifiutino di intervenire al fine di non perdere un abbonato. La maggior parte dei provider seri si è dotata di norme esplicite di corretto comportamento, spesso richiamate nei contratti di abbonamento. Tali norme sono in genere disponibili al pubblico sul sito web del provider e indicate con denominazioni varie; le più comuni sono "Terms and Conditions", "Terms of Service" (TOS) oppure "Acceptable User Policy" (AUP). Nella maggior parte dei casi queste regole prevedono che, in caso di violazione, l'utente perda il diritto ad usare il servizio, eventualmente nel caso in cui la violazione si ripetesse dopo un primo avviso. Per un fornitore di accesso, avere una buona AUP e farla rispettare è segno di serietà, che mette in buona luce davanti alla comunità della rete e costituisce, pertanto, un patrimonio in termini di immagine assai più importante della perdita di qualche abbonato ogni tanto. Le organizzazioni più sensibili a questo argomento tengono in attività dei gruppi di persone incaricate appunto di leggere i reclami che pervengono e svolgere gli accertamenti del caso. Per queste organizzazioni, i reclami a loro inviati sono un aiuto a far rispettare le proprie regole. Ci sono, purtroppo, anche provider meno sensibili (di solito definiti spam-friendly), di cui si hanno esempi anche rilevanti in tutto il mondo. Talvolta la reputazione di certe reti è soggetta ad alti e bassi negli anni, per svariate e non sempre chiare ragioni organizzative interne che influenzano la loro capacità di gestire il fenomeno. Che succede se spedisco il reclamo alla rete sbagliata? Nessuno vi verrà a fare rimproveri. Teoricamente, il destinatario potrebbe rispondere per dire "io non c'entro", ma è più comune che il reclamo venga scartato senza ulteriori perdite di tempo. Cosa succede ai provider che non combattono lo spam o, addirittura, lo proteggono? Queste organizzazioni si rendono presto ben conosciute: potete sentirle nominare spesso nei newsgroup in cui si parla di spam. Nei casi più gravi, i loro indirizzi di rete finiscono sulle 24

"liste nere" che molti amministratori di sistema utilizzano per bloccare il traffico di e-mail in arrivo sui loro server. L'utilizzo di blacklist dinamiche, mantenute aggiornate grazie al continuo lavoro di apposite organizzazioni, si sta rivelando uno dei mezzi principali per forzare la cessazione di casi anche eclatanti di abusi dell'email. Di queste blacklist si parlerà pertanto più diffusamente in altre pagine di questo sito, per ora ci basti osservare che le reti che rifiutano di bloccare il loro spam e vengono conseguentemente iscritte nelle blacklist più importanti rimangono, in pratica, letteralmente tagliate fuori da vaste porzioni della rete. È per questo motivo che, anche infischiandosene del continuo flusso di proteste e della pubblicità assai negativa che presto le circonda, in molti casi queste organizzazioni rivedono alla svelta le loro posizioni e si decidono ad adottare norme di correttezza da imporre ai loro utenti. Quindi, come sempre nella vita di ogni comunità, la salvezza sta nella consapevolezza collettiva e nell'impegno di ciascuno. Quando uno qualunque di noi reclama contro uno spammer, il suo reclamo torna a beneficio di tutti. Può essere interessante riprendere l'esempio di Cyberpromo. Si trattava di una azienda dedicata esclusivamente all'attività di invio di spam. In rete si trova molto materiale utile per saperne di più su Cyberpromo, sulla sua storia e sul suo presidente e fondatore, Sanford Wallace (soprannominato, non a caso, "Spamford", cosa di cui si è spesso dichiarato fiero). Si possono anche trovare fotografie di Wallace e brevi interviste in formato audio. Quest'uomo è stato, sicuramente, tra i più odiati frequentatori della rete, sostenitore della posizione (fortunatamete sempre rifiutata dai tribunali) secondo cui qualunque provider o fornitore di connettività tra reti sarebbe tenuto a veicolare pure i suoi fastidiosi annunci, e che il rifiuto equivarrebbe a censura contro la libertà di parola. In conformità a questa sua posizione, Cyberpromo ha profuso un pluriennale sforzo per costringere il resto della rete a servire, di fatto, i suoi scopi: da qui infiniti trucchi, cambiamenti di numerosi nomi di dominio e quant'altro potesse servire per aggirare i filtri che tutti adottavano per evitare di ricevere la sua posta. Le proteste della rete si rivolsero quindi all'upstream provider, ossia a chi forniva a Cyberpromo la connessione alla rete. Nella fattispecie si trattava di AGIS, a cui si iniziò a chiedere insistentemente di "staccare la spina" a Wallace. Per molto tempo AGIS fu assolutamente insensibile a queste richieste, mirando a proporre una propria soluzione al problema dello spam. La visione di AGIS prevedeva una regolamentazione (peraltro basata su principi inaccettabili) delle modalità entro le quali lo spam dovesse essere praticato per divenire "legittimo". Sulla base di questi principi AGIS si mise a vendere molti accessi spam-friendly. Tale politica ha palesemente dimostrato il più completo fallimento: gli stessi spammer, che ne avrebbero dovuto beneficiare, non volevano saperne di osservare le prescrizioni. Alla fine, sempre più sommersa di proteste e riprovazione, AGIS si rese conto di essersi messa in una situazione non sostenibile e si decise a liberarsi della sua scomoda compagnia. Il 16 ottobre 1997, AGIS staccò la spina a Cyberpromo. Nell'aprile 1998, dopo ulteriori sconfitte legali, dichiarandosi stanco e ammettendo la sconfitta del proprio disegno, Sanford Wallace annunciò la definitiva cessazione della sua attività di spammer. Nell'estate del 98 Sanford Wallace aprì un suo sito web che, a parte una pagina (a dire il vero un po' misera) di link antispam, era dedicato alla musica creata al computer. Stando a quanto dicevano coloro che avevano avuto modo di ascoltare le sue creazioni, sembra che non fosse neanche malaccio. Un uomo nuovo, quindi, il cui passato ormai si affaccia solo nello pseudonimo che si era dato: DJSPAMMY. La morale che si può cogliere nella storia è questa: se non ci fosse stata una così forte, tenace e diffusa sollevazione degli utenti di rete, a tutt'oggi avremmo uno spammer in più ed un musicista in meno.

Purtroppo a volte si possono trovare interlocutori che (cerchiamo di essere ottimisti) non 25

hanno ancora avuto il tempo per informarsi adeguatamente. Questo esempio (che ho trovato leggendo il newsgroup it.news.net-abuse) è la riposta che qualcuno ha riferito di avere ricevuto in risposta ad un reclamo per spam: Grazie per averci scritto. Per evitare che questi maleducati ti importunino può scegliere di bloccare alcuni indirizzi o di costruire dei filtri.Grazie per averci inviato questa e-mail, per qualsiasi ulteriore problema conta pure sul nostro aiuto. Una simile risposta non è accettabile e denota incompetenza. Quando diventa di dominio pubblico, una risposta come questa intacca piuttosto seriamente la reputazione di chi l'ha firmata. Probabilmente molti di coloro che ne venissero a conoscenza deciderebbero di mettere in pratica l'idea dei filtri: per bloccare tutto ciò che provenga dal sistema di questo "postmaster", al quale pare normale che per un problema suo (suo è l'utente che ha spammato) sia lasciato ai danneggiati l'onere di trovare rimedio allestendo filtri o altre diavolerie. A volte anche gli americani riferiscono risposte del tipo sopra riportato: le sintetizzano nella frase "Shut up and eat your spam", ossia: mangia il tuo spam e sta zitto.

Ho segnalato ripetutamente uno spammer a chi di dovere e vedo che non viene fermato. Cosa posso fare? È una situazione che può verificarsi: dopo più segnalazioni si constata che i provider in questione non interrompono la fornitura di servizi allo spammer. Per esempio, continuano a fornire hosting al sito dello spammer o ai dns o ad altre risorse che lo spammer utilizza. In questi casi, siccome noi siamo semplicemente utenti, il potere di cui possiamo disporre è molto limitato. C'è però una cosa, alla portata di tutti noi, che può dare una forza speciale anche alle nostre piccole segnalazioni: inserirle sulle aree appositamente costituite, in modo che restino pubblicamente archiviate. Per ora non entriamo nei dettagli, dato che ancora non abbiamo neppure visto come si fanno le segnalazioni né come si può capire a chi vadano inviate. Pertanto, nelle prossime pagine dovremo innanzitutto occuparci di tali nozioni di base. Per quando avrete imparato a fare le segnalazioni e vi sentirete abbastanza sicuri, il passo successivo sarà capire come si usano le risorse che, appunto, consentono la pubblica archiviazione delle segnalazioni. Ad oggi queste risorse sono il newsgroup news. admin.net-abuse.sightings per gli spammer internazionali e la lista Abuse del NIC per gli spammer italiani. Se ne riparlerà nella pagina di link. Ci sono provider che, quando ricevono una segnalazione, la passano allo spammer? Ebbene sì, ce ne sono, la cosa è stata documentata più volte, anche perché certi provider lo hanno candidamente ammesso. In alcuni casi sono stati portati alla luce dei veri e propri contratti, tramite i quali un provider si impegnava a consentire che un certo cliente spammasse, senza prendere alcun provvedimento a fronte dei reclami ricevuti se non 26

trasmetterglieli. Casi del genere, rari ma che di tanto in tanto succedono, sono detti pink contract (il folklore diffuso nella comunità antispam associa da sempre il colore rosa allo spam). Le reti che sottoscrivono questi tipi di contratti hanno in genere una reputazione molto compromessa e, manco a dirlo, finiscono dritti in varie blacklist, sia pubbliche che private. In passato si sono avuti casi eclatanti di contratti "pink" da parte di grosse compagnie. Di fronte all'infamia che ne è derivata, le aziende in questione hanno reagito facendo macchina indietro e dando la colpa a sfortunate circostanze, come il verificarsi di disguidi e disorganizzazione, per cui qualche controllo era stato omesso. Di conseguenza, sempre secondo le spiegazioni ufficiali, qualche "venditore rampante" aveva potuto formalizzare questi sciagurati contratti, così contrari alle policy aziendali. A distanza di tempo da questi episodi che fecero scalpore, si riferisce che i contratti pink, in realtà, continuino ad avvenire. Con la differenza che ora è molto più difficile che si riescano a rendere noti, dato che le aziende in questione hanno iniziato a tutelarsi mediante clausole di "non disclosure".

Resta da chiedersi che succede quando lo spammer viene a sapere che un certo utente lo ha segnalato. Ciò che normalmente succede è che, per lo spammer, un tale utente è soprattutto un rompiscatole, che viene considerato molto fastidioso e anche pericoloso, in quanto dimostra di essere uno che sa a chi reclamare per lo spam ricevuto. Lo spammer, come abbiamo detto in precedenza, non se ne fa nulla di rispettare la tranquillità altrui, ma neppure è interessato a cercarsi dei fastidi inutilmente. Il suo è un "mestiere" già molto ricco di grattacapi e fastidi, quindi evitare quel tipo di rompiscatole può solo aumentare la probabilità, per lui, di riuscire a continuare indisturbato. Pertanto, è frequente che gli spammer tolgano dalle proprie liste gli email degli autori di segnalazioni che gli siano state passate dal proprio provider. Quando un provider passa le segnalazioni allo spammer, si suol dire che fa listwashing per conto dello spammer, ossia lo aiuta a lavare le proprie liste escludendo i seccatori. In passato ci fu chi, con tecniche di hackeraggio, riuscì a guadagnare l'accesso niente meno che al computer di uno spammer intanto che questo era online, copiandosi tutti i file che vi trovò. Nella fattispecie si trattava del computer di una spammer americana, e l'anonimo incursore pubblicò poi, su un sito web, tutti i file che vi aveva rinvenuto. Tra questi c'era anche una voluminosa lista di indirizzi di email appartenenti, per l'appunto, a "rompiscatole". Molti antispammer riconobbero in tale elenco un gran numero dei propri indirizzi; anche il sottoscritto, nel proprio piccolo, ce ne trovò quattro o cinque dei propri.

Ci sono standard ufficiali di rete, cui possa essere utile fare riferimento? Qualcosa c'è: innanzitutto va citata la celebre RFC1855 dell'ottobre 95, nota come netiquette, in cui si viene avvertiti del problema e del fatto che l'unsolicited commercial email è considerata inaccettabile in rete, trattandosi di comunicazione "cost-shifted". Successivamente è stata varata la RFC2635, del giugno 99, che è specifica sul problema dello spam (che nel frattempo era divenuto molto più rilevante di quanto fosse nel 95). Essendo nella categoria informational, a rigore le suddette RFC non sono uno standard di rete, tuttavia inquadrano il problema in maniera ampia ed apprezzabile (soprattutto la 27

2635), costituendo quindi un riferimento che difficilmente qualcuno potrebbe ignorare (anche perché dietro tali RFC esiste in rete un consenso generale indiscutibile). Un'altra RFC interessante è la RFC2505, del febbraio 99, che contiene raccomandazioni antispam assai importanti sul modo di gestire e configurare gli MTA. La RFC2505 è importante sia per gli amministratori di server che per gli sviluppatori del relativo software. Vi è poi la RFC3098 dell'aprile 2001, specificamente rivolta a chi intende esercitare attività di marketing in rete in maniera corretta. Si tratta di un documento assai utile e che va sicuramente letto. Vorrei solo mettere in guardia sul fatto che, nel trattare le mailing list, la RFC3098 illustra una modalità di gestione che non può essere considerata accettabile, in quanto mancante del doveroso passo di conferma della iscrizione da parte dell'utilizzatore della mailbox destinataria (operazione indispensabile per prevenire le iscrizioni fraudolente). Appendice Mailing list e conferme di iscrizione Avendone appena parlato, occorre dare almeno qualche cenno al problema delle mailing list. Le mailing list sono uno strumento molto utile che in rete si usa da tempo immemorabile. Normalmente si accede ad una mailing list richiedendo l'iscrizione di un proprio indirizzo e, da quel momento, si inizia a ricevere i messaggi che vengono postati a tale lista. Il problema si verifica quando qualcuno, con intento sovente malizioso, iscrive ad una mailing list l'indirizzo di qualcun altro. Nei primi anni in cui la rete esisteva, queste cose non accadevano. Da quando invece la rete è diventata accessibile ad un pubblico di massa, le mailing list hanno iniziato a diventare uno dei più comuni strumenti con cui molestare il prossimo, proprio mediante iscrizioni fraudolente. Per questa ragione, da tempo non è più ammissibile che una mailing list accetti iscrizioni senza verificarle. Il meccanismo più comune consiste nell'invio di una richiesta di conferma ad ogni indirizzo per cui giunga una richiesta di iscrizione. La richiesta di conferma deve contenere, al proprio interno, un numero random o comunque un identificativo unico e non predicibile, che deve essere rispedito al gestore della mailing list in modo da provare, in maniera certa, che il legittimo utilizzatore dell'indirizzo di email in questione veramente acconsente ad essere iscritto. Il gestore deve quindi conservare queste conferme di iscrizione, in modo da poterle esibire in caso di contestazioni. Va detto che tutta questa procedura non richiede interventi manuali da parte del gestore della lista, in quanto la maggior parte dei software di gestione di mailing list è in grado di effettuare la cosa in automatico. Pertanto, chi gestisce una mailing list priva di conferma di iscrizione non ha scuse e, quasi certamente, andrà in contro a problemi e incidenti assai antipatici da gestire (per non parlare delle possibili contestazioni per illecito trattamento di dati personali ai sensi della legislazione italiana). Non solo la lista verrà certamente usata, prima o poi, per commettere abusi, ma è risaputo che spesso i gestori "ci marciano", iscrivendo indirizzi prelevati in qualche modo dalla rete e poi tentando di giustificarsi con scuse ridicole come "Ti avrà iscritto un tuo amico". Riassumendo, una mailing list correttamente provvista di richiesta di conferma di iscrizione è conforme alla pratica dell'opt-in. Una mailing list che non preveda la conferma di iscrizione non può essere definita opt-in: è solamente opt-out, e fortemente a rischio di blacklist. In conclusione vorrei avvertire che, talvolta, si sente parlare di double opt-in. È una denominazione che raccomando di non usare mai, in quanto non significa nulla: si tratta del linguaggio degli spammer, i quali fanno spesso uso di liste opt-out e cercano di rappresentare come esagerato il requisito della conferma di iscrizione. Basti sapere che, se esiste anche solo la possibilità di trovarsi iscritto a propria insaputa, la mailing list non è opt-in. 28

Indice

<< Precedente

Successiva >>

Ultimo aggiornamento: 28 luglio 2003

Leonardo Collinelli

29

Glossario dei termini tecnici BGP Border Gateway Protocol. Si tratta di un protocollo di routing, ossia usato per far comunicare i router in modo da determinare gli instradamenti dei pacchetti tra varie reti.

CGI Common Gateway Interface. Si tratta di uno standard in base al quale è possibile fare interagire i web server con dei programmi. È infatti spesso richiesto che il web server non sia un semplice porgitore di pagine statiche, ma che possa generare al volo delle pagine dal contenuto variabile in base a varie condizioni e, soprattutto, in base all'input dell'utente (si pensi per esempio ai motori di ricerca). I programmi scritti secondo lo standard CGI vengono quindi detti programmi CGI e girano sul web server. Il web server manda in esecuzione i programmi CGI man mano che ciò si rende necessario in base all'attività dei visitatori che accedono al sito. Tipicamente l'uso dei programmi CGI è abbinato alla presenza di form sulle pagine web. Il form (tag html

) consente di fare apparire su una pagina web dei campi di input nei quali l'utente immette informazioni; quando poi l'utente clicka il bottone che provoca l'invio del form, il browser richiede al web server di eseguire il programma CGI specificato nel form stesso (all'attributo ACTION) ed invia come dati il contenuto di tutti i campi del form (quelli digitati dall'utente e quelli eventuali di tipo hidden, nascosti). Il programma CGI, mandato in esecuzione dal web server, elabora i dati ricevuti e produce una risposta (di solito in formato html) che viene inviata al browser dell'utente da cui era partita la richiesta.

Cookie I cookie, originariamente inventati dalla Netscape e successivamente standardizzati con la RFC2109, sono un artificio per riuscire a gestire lo stato nelle transazioni web. Quando un browser chiede ad un web server una risorsa (una pagina, una immagine o altro), la risposta del web server è sempre costituita da alcune righe di header con informazioni varie, una riga vuota e, se il caso, i veri e propri dati richiesti. Tra le righe di header, il web server può anche inserirne una simile a questa: Set-Cookie: stringa-di-caratteri; path=/; expires FRI, 09-Dec-96 13:46:00 GMT Se il cookie viene accettato, il browser lo memorizza sul disco fisso e, da quel momento, ogni volta che avrà occasione di inviare richieste al medesimo server gli passerà una riga di 30

header del tipo Cookie: stringa-di-caratteri I cookie permettono quindi ai siti web di riconoscere i visitatori che ritornano dopo tempo: è un meccanismo simile all'attaccare un badge alla giacca dei visitatori. In molti casi i cookie non sono usati in modo da essere una minaccia diretta alla privacy dell'utente web, anzi, possono talvolta perfino consentire alcune funzioni utili. Spesso però pongono l'utente in una situazione in cui la privacy può essere più facilmente compromessa (il rischio è che il medesimo browser risulti individuabile nel tempo, consentendo così di correlare tra loro più informazioni di quante l'utente potrebbe desiderare). Anche in considerazione del fatto che esistono compagnie che usano i cookie senza troppi scrupoli, molti preferiscono tenerli disabilitati.

ICMP Internet Control Message Protocol. È una parte del protocollo IP che utilizza i servizi di base (trasporto datagrammi) del protocollo IP stesso, come se fosse un protocollo di livello superiore. Tramite ICMP gli host si segnalano varie situazioni di errore (es. time exceeded, destination unreachable) oppure svolgono altre funzioni. In particolare, sono noti gli ICMP di tipo ECHO e ECHO REPLY, utilizzati per i ping. Per maggiori informazioni RFC792.

Mail Exchanger E' così definito, nell'ambito di una rete, un server a cui spetta ricevere la posta in arrivo. Un apposito record DNS per il dominio in questione (il record MX) indica il server a cui ci si deve connettere per mandare email agli utenti di quel dominio. Grazie a questa soluzione è possibile usare come indirizzo nomeutente@nomedominio, anche se non esiste un computer che si chiami esattamente come il nome di dominio. Interrogando il record MX, i server che hanno email da consegnare possono ricavare l'esatto nome del computer cui consegnarla, disinteressandosi di altri giri interni che fossero necessari per portare il messaggio fino al POP server su cui si trova la mailbox destinataria.

MTA Mail Transfer Agent. Si indicano con questo acronimo i mail server e in genere i software (o in quanto prodotti o in quanto processi in esecuzione) che elaborano il traffico di email.

MUA Mail User Agent. Si indicano con questo acronimo i mail client e in genere i software (o in quanto prodotti o in quanto processi in esecuzione) che gli utenti della posta elettronica adoperano per ricevere e/o spedire i messaggi (es. Pegasus, Eudora, OE ecc...).

Porta 31

Concetto usato da alcuni protocolli basati su IP (in particolare TCP e UDP). TCP se ne serve per individuare le sessioni che un computer in rete può stabilire: per ogni distinta sessione si possono specificare l'indirizzo IP ed il numero di porta utilizzato per ciascuno dei due computer coinvolti. Questo consente, per esempio, ad un browser web di scaricare dalla rete più file contemporaneamente (una pagina HTML e alcune immagini in essa contenute) o, più in generale, di svolgere sul proprio computer più attività contemporanee che tutte richiedano servizi di rete. I numeri di porta usati dalle applicazioni client (per esempio il browser con cui state leggendo questa pagina) non sono soggetti a particolari standard, mentre esistono standard precisi per i numeri di porta dei server: per esempio una connessione web userà la porta 80 del server, una connessione NNTP (newsgroup) userà la porta 119. Per ciò che riguarda i client di posta elettronica, questi stabiliranno una connessione con la porta 25 del server SMTP ed una connessione al POP server sulla 110.

PPP Point to Point Protocol. E' usato normalmente per connettere il computer dell'utente finale al punto di accesso del provider utilizzato. PPP sta rimpiazzando il più vecchio protocollo SLIP, tuttavia ancora molto diffuso. Il protocollo PPP gestisce la fase di autenticazione dell'utente (vale a dire il passaggio dello userid e password di collegamento, con abbattimento della connessione in caso l'autenticazione fallisca) e consente la configurazione dinamica (tramite DHCP) dell'indirizzo IP, dopodiché predispone che sulla connessione così stabilita transitino pacchetti IP: a quel punto l'utente è in rete a tutti gli effetti.

SMTP Simple Mail Transfer Protocol. Protocollo usato per inoltrare i messaggi di posta elettronica. SMTP (analogamente agli altri protocolli di pari livello come HTTP, NNTP ecc...) regolamenta il dialogo tra due computer impegnati a svolgere congiuntamente una ben precisa funzione, in questo caso l'inoltro di un messaggio di e-mail. SMTP utilizza i servizi forniti dal TCP per aprire la comunicazione tra i computer interessati, specificando semplicemente in quale forma l'uno debba inviare le richieste e l'altro debba rispondere. Il protocollo SMTP è standardizzato nella RFC821.

TCP/IP Sigla usata per indicare genericamente l'insieme dei (moltissimi) protocolli in uso su Internet. In senso stretto, la sigla indica l'uso congiunto dei protocolli IP e TCP. IP è un protocollo usato per la comunicazione su reti a commutazione di pacchetto interconnesse. La sigla IP significa "Internet Protocol". IP è il livello di protocollo che si propone di far giungere pacchetti di bit da una sorgente ad una destinazione, essendo queste dei computer individuati da indirizzi di lunghezza fissa. IP utilizza i servizi forniti dai 32

protocolli delle reti locali, senza occuparsi né di problematiche quali rilevazione errori, acknowledgement, ritrasmissioni ecc... né tanto meno del contesto cui ogni pacchetto appartiene nel dialogo tra i computer interessati: ogni pacchetto di bit viene considerato come una entità a sè stante. Il protocollo IP è standardizzato nella RFC791. TCP significa "Trasmission Control Protocol"; TCP è il livello di protocollo che gestisce le sessioni tra processi in esecuzione su due distinti computer attivi su reti interconnesse, aprendo tra loro delle effettive vie di comunicazione bidirezionali affidabili, attraverso le quali i processi (user) possono scambiarsi dati sotto forma di flussi continui di byte. TCP utilizza i servizi forniti dal livello IP, disinteressandosi dell'instradamento dei pacchetti e di tutto ciò che competa al livello sottostante (ove può operare IP o, in teoria, anche altri protocolli). Il protocollo TCP è standardizzato nella RFC793.

Telnet Questo protocollo è poco più che una interfaccia al TCP. Un client Telnet consente all'utente di digitare input ad applicazioni TCP che risiedano sul computer locale o su altri in rete. Tramite Telnet si potrebbero eseguire manualmente un gran numero di operazioni di rete elementari, in modo però assolutamente inadatto agli usi pratici (anche se, eventualmente, interessante dal punto di vista didattico). Per usare Telnet sotto Windows 9x/NT si può aprire una finestra DOS e digitare, al prompt di comando, la parola telnet seguita dal nome o indirizzo del computer a cui collegarsi e dal numero di porta. Nella finestra che successivamente si apre è possibile dialogare con l'applicazione scelta. Se intendete sperimentarlo, accertatevi di avere attivato l'opzione di 'Eco locale', altrimenti non vedreste le risposte del sistema remoto.

UDP 1. User Datagram Protocol. Protocollo facente parte della suite TCP/IP. Si tratta di un protocollo trasportato su IP e, pertanto, pari livello di TCP. Sua caratteristica è l'assenza del concetto di sessione e la non garanzia che i pacchetti vengano effettivamente recapitati. 2. Usenet Death Penalty. Provvedimento che viene adottato da un sufficiente numero di amministratori di server connessi alla rete Usenet nei confronti dei news server di una organizzazione alla quale si addebiti di non fare quanto dovuto per impedire l'effettuazione di abusi di rete attraverso i propri sistemi. In sostanza i server che aderiscono (ciascuno liberamente e con propria decisione autonoma) alla UDP rifiutano di propagare i messaggi originati dai server su cui è attivo il provvedimento. Il diritto dei news-admin in questione ad adottare un provvedimento di UDP si basa sul fatto che nessun obbligo esiste, a carico di alcuno, di accettare e propagare i messaggi di chicchessia. In base alle soluzioni tecniche adottate si distinguono vari tipi di UDP. Lo scopo di questo genere di provvedimento è che l'organizzazione che viene colpita sia indotta a rivedere il proprio atteggiamento, 33

finendo col comportandosi in maniera conforme ai doveri che ogni partecipante alla rete usenet ha nei confronti degli altri. In passato si sono avuti vari casi di applicazione di UDP (celebri quelli ai danni di Netcom e Prodigy); in molti casi comunque è bastata la semplice minaccia a conseguire il risultato voluto.

Indice Ultimo aggiornamento: 10 dicembre 2000

Leonardo Collinelli

34

Elenco pagine preparate da Leonardo Collinelli

●

Pagina Antispam Sono pochi gli utilizzatori della posta elettronica che non ricevano pubblicità indesiderata. Qui si analizza il fenomeno, con l'obiettivo di mettere il lettore in condizione di difendersi efficacemente da questo malcostume che, crescendo di dimensioni ogni giorno, disturba sempre più la possibilità per ciascuno di usufruire della posta elettronica con tranquillità e beneficio.

●

Privacy policy

●

Informazioni più specifiche sull'autore

Ultimo aggiornamento: 01 novembre 2001

35

Privacy policy del sito (English is just below) Questo sito NON raccoglie dati personali dai visitatori. Questo sito NON invia cookie ai visitatori.

This web site does NOT collect personal data from users. This web site does NOT send cookies to users.

Leonardo Collinelli

Ultimo aggiornamento: 01 novembre 2001

36

Per inviarmi posta - To send me e-mail English is here (just below). Come si può leggere in una di queste pagine, indicare su un sito web un indirizzo di e-mail entro il consueto link di tipo 'mailto:' è un modo molto efficace per ricevere spam. Siccome di spam ne ricevo già abbastanza, devo adottare qualche accorgimento per sfuggire ai programmi di estrazione usati dagli spammer. Comunque, sono molto interessato a ricevere e-mail dai visitatori di questo sito o da coloro che abbiano ascoltato le mie sequenze MIDI. Dato il volume di mail che mi arrivano ed il poco tempo che posso dedicare, solo in rarissimi casi mi sarà possibile rispondere. Dato poi che mi capita spesso di stare lontano dalla rete anche per giorni, quelle volte in cui rispondo ciò avviene quasi sempre con ritardo. Va inoltre precisato che dietro questo sito non c'è una redazione né tanto meno un helpdesk. Se vi occorre aiuto su un problema di abusi di rete, non è a me che dovete scrivere. Suggerisco che piuttosto discutiate i vostri dubbi sul newsgroup it.news.net-abuse. La comunità antispam italiana è già molto valida e, quotidianamente, molti utenti interessati a risolvere problemi di spam trovano su quel newsgroup tutto l'aiuto che occorre. Inoltre, in questo modo il vostro caso avrà ricadute utili anche per altre persone che si trovassero ad avere dubbi simili ai vostri. Al di fuori di ciò, ecco un indirizzo a cui mi si può contattare: la parte dopo la chiocciola deve essere vene.dave.it prima della chiocciola mettete lc.dm43j5p A costo di ripetermi: NON ASPETTATEVI RISPOSTA. Durante i primi anni di vita di questo sito mi riusciva di rispondere quasi a tutti; ora però i visitatori sono molto aumentati, le email che arrivano sono molte e il tempo semplicemente non c'è. Attenzione, se pensate di scrivermi è importante che leggiate prima quanto segue: ● ●

●

NON scrivetemi per proporre di istituire dei mirror di questo sito; NON scrivetemi per richiedere che fornisca uno zip o altra soluzione per il download del sito in un unico file (forse in futuro la cosa potrà essere fatta, ora non so dire né se né quando); NON scrivetemi per chiedere consulenza antivirus. In particolare, se avete ricevuto strane email con allegati piccoli file eseguibili, può trattarsi di qualcuno dei tanti virus che si autospediscono (Hybris, Klez ecc..). Tutto quello che vi potrei dire al 37

●

●

● ●

riguardo è che (ovviamente) non dovete assolutamente mandare in esecuzione l'allegato, che nella maggior parte dei casi non c'è modo di individuare il mittente e che colui che ve lo ha mandato quasi certamente non sospetta di essere infetto e non si è accorto di nulla. Per documentarvi sui virus più diffusi al momento, consiglio che leggiate il newsgroup it.comp.sicurezza.virus; NON scrivetemi per chiedere consulenza su come configurare o far funzionare dei server di posta. Non è il mio mestiere, non ne conosco e potrei solo dirvi di leggere bene il manuale, rivolgendovi magari al supporto tecnico del produttore del software; NON mandatemi per conoscenza le vostre segnalazioni agli abuse desk: è del tutto inutile che io le legga. So che i servizi abusi di alcuni provider includono, nelle loro risposte automatiche, la url di questo sito. Ciononostante io non ho niente a che fare con loro e non posso intervenire su di loro per chiedergli di fare o non fare qualcosa. NON allegate dei file, se la cosa non è stata concordata. Evitate di richiedermi approfondimenti o risposte che richiedano tempo per scriverle o per documentarsi. Il tempo disponibile mi consente solo di dare, nel migliore dei casi, risposte telegrafiche o poco più.

Infine chiederei, a chi mi scrive, di inviare mail in formato di solo testo e NON html (soprattutto chi utilizza Outlook Express voglia controllare la relativa impostazione nelle Opzioni di invio). Ringrazio in anticipo chi mi invierà osservazioni e commenti di ogni genere. Attenzione ai filtri: la casella email di cui sopra è protetta mediante un certo numero di blacklist. Pertanto, se l'indirizzo ip da cui proverrà la vostra email fosse un indirizzo già noto per avere problemi di sicurezza (es. relay aperto, proxy aperto, formmail insicuro ecc..) o per appartenere ad una rete o provider non ostile nei confronti degli spammer, è probabile che il server la rigetti con un messaggio di errore, senza che a me arrivi nulla.

As most people know, to put within a web site an e-mail address, especially if in a 'mailto:' link, is a very effective way to receive spam. Since I already receive enough of spam, I have to use some trick, just to fool the harvesting programs used by the spammers. Indeed, I'm very interested in hearing from visitors of this site or from people who have listened to some of my MIDI sequences; I'll try to answer, maybe with delays because I often happen to be away from the net for days. Well, here is an e-mail address where I can be contacted: after the "at" character please put vene.dave.it before the "at" put lc.dm43j5p Thanks in advance to those who will send me any sort of comments. 38

Just a note: if you have been directed here because you sent a spam report to the abuse desk of some italian ISP, and you got an autoresponse in italian language containing the url of this site, please consider that I have no relation with said network(s), I cannot give responses on their behalf and I cannot intervene on their postmasters in order to have them do something. Filter warning: the above mailbox is protected with a number of blacklists. So if the ip address where your email will come from is known as an ip which has security problems (such as open relay, open proxy, open formmail etc.) or as an ip belonging to a spamfriendly network or provider, it's likely that your email will be bounced, unnoticed by me.

Leonardo Collinelli Ultimo aggiornamento: 22 febbraio 2003

39

Cosa si può fare per prevenire l'arrivo di spam C'è una sola cosa che si può considerare abbastanza efficace: tenere poco esposto il proprio indirizzo di e-mail. Non dico che sia da custodire come il numero della carta di credito, ma va reso pubblico con molta cautela. Una volta che il vostro indirizzo di e-mail fosse finito nelle mani degli spammer, non c'è più niente da fare: verrà venduto ad altri, poi ad altri ancora. Da esperienze personali posso dire che, se un indirizzo di email viene reso pubblico con tutte le cautele e gli accorgimenti che trovate su questa pagina, ha una buona probabilità di rimanere pulito per tre o quattro anni. Poi, anche se non ci sarà modo di capire perché, inizierà a ricevere spam: dapprima uno ogni tanto, poi più frequentemente e poi la "valanga". A quel punto, se il server di posta su cui la casella si trova non adotta efficaci misure per respingere lo spam in arrivo, ben poco si può fare se non cambiare indirizzo di email. Può reggere più a lungo un indirizzo non pubblicato, che venisse usato solo per contatti personali con un selezionato numero di persone fidate. Anche in questo caso, tuttavia, lo spam può comparire lo stesso, improvvisamente, in un giorno qualunque. Pertanto, le indicazioni che vedremo qui vanno considerate come dei consigli per ridurre l'entità del danno e per allontanare il più possibile il momento. In molti casi, questi consigli potranno anche rivelarsi molto efficaci, però deve essere chiaro che sarebbe sbagliato sentirsi al sicuro. Se postate sui newsgroup con il vostro vero e-mail, riceverete spam Usenet è, a tutt'oggi, una delle fonti principali da cui gli spammer riforniscono i loro elenchi. Scaricati messaggi da tutti i newsgroup, gli spammer li elaborano con appositi programmi che cercano gli indirizzi. Si tenga presente che ogni articolo presente su Usenet ha la classica struttura che prevede gli header, una riga vuota e il corpo del messaggio vero e proprio. Tra gli header ci sono 'From:' e 'Reply to:' che dovrebbero, secondo lo standard, contenere l'indirizzo di e-mail dell'autore e quello (se diverso) a cui l'autore preferisce essere contattato. Esistono ottimi motivi per avere l'e-mail dell'autore in ogni articolo: soprattutto ciò consente di attivare privatamente via e-mail discussioni che, pur se relative all'articolo in questione, risulterebbero improprie (e quindi assai sgradite) su un'area pubblica come il newsgroup. La presenza dell'indirizzo nelle prime righe dei messaggi, entro header con una sintassi standard, rende assai pratico per qualunque lettore del newsgroup scrivere all'autore ma, purtroppo, rende anche molto facile l'effettuazione di estrazioni automatiche. Tradizionalmente, il campo a rischio è il 'From:', ma è poco probabile che un indirizzo nel 40

'Reply to:' possa rimanere indenne. Sembra che invece siano più limitati i rischi corsi dagli indirizzi inseriti all'interno del corpo degli articoli, probabilmente perché esaminare l'intero testo di tutti gli articoli di tutti i newsgroup sarebbe molto oneroso e darebbe risultati piuttosto scarsi (dal punto di vista degli spammer). Riterrei comunque prudente considerare a rischio anche il testo del messaggio: se anche oggi può non esserlo, potrebbe diventarlo da un giorno all'altro (anche perché software di estrazione in grado di cercare pure lì pare che già esistano). Il motivo per cui il campo maggiormente a rischio risulta essere il From è che, per estrarre gli indirizzi dai newsgroup, normalmente gli spammer non usano normali newsreader ma appositi software che, dopo essersi collegati ad un news server, danno il comando XOVER in modo da ottenere dal server una risposta molto sintetica, in cui sono dati solo il Subject, il From, il MessageId e pochi altri campi per ciascun articolo.

Veniamo dunque alla soluzione che molti adottano: non mettere l'indirizzo negli appositi campi, oppure metterlo con alterazioni. Si può obiettare che, in base agli standard di rete codificati nelle RFC, l'indirizzo sarebbe da mettere e senza alterazioni. Per questa ragione molti non adottano questa soluzione e, prevedibilmente, considerano con scarsa simpatia coloro che la praticano. Pur essendo vero che gli standard sono nati un po' di anni fa, quando in rete non erano ancora calati gli Unni del marketing di massa, né i ragazzotti che pensano di fare fortuna come Rasmus Lind, né i provider o le grosse aziende che considerano legittimo farsi pubblicità con e-mail non sollecitate, è comunque vero che la presenza di indirizzi alterati e non validi nei messaggi usenet costituisce comunque un inconveniente, una scomodità. Personalmente ritengo difficile criticare questa forma di autodifesa, anche perché non riesco a considerare obbligatorio il fatto che, quando qualcuno partecipa ad una discussione su usenet, debba per forza fornire il modo per essere contattato privatamente in email. Vorrei quindi lasciare il più chiaro possibile questo messaggio: non mettere un indirizzo valido nel campo 'From:' o 'Reply to:' rende più scomodo l'uso di Usenet. Si può anche accettare che questo avvenga, però si tratta di una delle tante scomodità di cui dobbiamo "ringraziare" gli spammer (i quali, di fatto, ci hanno resi meno liberi di usare a nostro piacimento risorse nostre come l'email). Vale la pena di cercare soluzioni alternative, tra le quali viene frequentemente suggerita l'adozione di indirizzi "a perdere", che vengono adoperati solamente per postare sui newsgroup e vengono chiusi in breve tempo, non appena inizino a ricevere spam. Se intendete comunque mettere nei vostri post su usenet un indirizzo alterato o non valido, è importante che almeno seguiate alcune avvertenze: ●

●

●

Adottate una alterazione che renda l'indirizzo non valido del tutto. Preferibilmente, fate in modo che la parte dopo la @ diventi un riferimento non valido. Fate in modo che, vedendo l'indirizzo, la alterazione sia il più possibile evidente. Ciò che potrebbe giustamente dare il massimo fastidio a chi, vedendo il vostro post, desiderasse scrivervi, sarebbe trovare nel from un indirizzo apparente valido, usarlo, e poi accorgersi che il messaggio è fallito. Sostituire semplicemente un carattere con un altro (anche se si tratta di caratteri speciali) non va bene poiché l'alterazione, anche se per voi è ovvia, non è evidente per altri. È consigliabile che l'indirizzo finisca con .invalid 41

●

(sono in discussione nuove RFC che potrebbero ufficialmente esprimere questa raccomandazione). Nel corpo del messaggio (per esempio nella signature) inserite indicazioni che consentano, ad un lettore interessato, di ricavare il vostro effettivo indirizzo.

Per esempio, [email protected] può diventare [email protected] oppure [email protected] o [email protected]. Altre parole civetta che spesso si vedono sono REMOVE, REMOVE.THIS.TO.REPLY eccetera. Se vogliamo però che la alterazione abbia l'effetto desiderato, occorre evitare tutte queste parole civetta ormai classiche e prevedibili. E' stato infatti riportato che alcuni programmi di estrazione indirizzi dai newsgroup vantano, tra le proprie funzionalità, la ricerca ed eliminazione delle più comuni di queste stringhe (come NOSPAM o REMOVETHIS). Occorre quindi essere creativi e cambiare strategia di tanto in tanto. Mi è capitato di leggere qualche signature in cui era scritto: "Togliere UGO per rispondere" oppure "Sostituire LANA con SETA" oppure "Per rispondermi togliere il TAPPO dall'indirizzo". Grandiosa la trovata di quello che ha messo: "Per emailarmi levare LEDITADALNASO". Per quanto mi riguarda, nel campo 'FROM:' metto un semplice rimando al testo del messaggio (avendo cura che abbia la struttura di un indirizzo di email terminante con . invalid) e, nella signature, riporto il mio indirizzo in forma tale da non essere riconoscibile a programmi che esaminassero il testo. Per il momento i programmi degli spammer non riescono a venirne a capo e, sperabilmente, per chi desiderasse scrivermi non dovrebbe essere un fastidio eccessivo. Comunque uno spammer ostinato può sempre ricavare a mano l'indirizzo: per la cronaca, a me è successo. Se dovesse capitare anche a voi, è solo una ragione in più per non avere pietà. Si tratta tuttavia di casi rari, in quanto una attività di spam massivo ha bisogno di essere effettuata con strumenti automatici. Su questo argomento esiste in rete una apposita faq (Munging FAQ). Un'altra interessante FAQ in lingua tedesca viene periodicamente postata su de.admin.net-abuse.mail e può essere ritracciata mediante le funzioni di ricerca sull'archivio newsgroup di Google. Non tenete in evidenza il vostro vero e-mail neanche nelle chat Pare che gli spammer esplorino pure le chat alla ricerca di indirizzi di e-mail, e che vari client IRC forniscano l'indirizzo tranquillamente a chiunque lo chieda. Non mettete il vostro indirizzo nelle pagine di siti web Gli spammer hanno programmi di scansione anche per le pagine web. Sono del tutto analoghi ai robot dei motori di ricerca e percorrono tutti i link che trovano, raccogliendo tutto ciò che figura in link di tipo 'mailto:' o che abbia una @ nel mezzo. Una soluzione (non so fino a qual punto efficace) potrebbe essere di rinunciare a mettere il link di tipo 'mailto:' e inserire dei tag HTML nell'indirizzo. Esempio: mariorossi@abcd. 42

it. Un esempio che, alla fine, mi è riuscito di rendere non troppo complicato, si può trovare in queste stesse pagine seguendo questo link. Sempre in merito al fatto che gli spammer percorrono il web alla ricerca di indirizzi, una soluzione che è assurta a discreta notorietà tra vari webmaster è l'uso di programmi CGI come WebPoison, un programma gratuito che genera pagine contenenti testo random, cosparso di indirizzi e-mail fittizi e di link che puntano ad altre pagine del tutto analoghe, sempre generate dal programma. In questo modo i robot degli spammer girano senza fine tra pagine inesistenti raccogliendo indirizzi falsi. L'idea è stuzzicante e, a quanto ho sentito, qualche spammer ne sarebbe stato infastidito. Ci sono tuttavia vari possibili inconvenienti, ragion per cui, pur considerando questa soluzione come possibile, non mi sentirei di raccomandarla con particolare slancio. Se può far piacere l'idea che gli spammer si ritrovino liste di indirizzi corrotte e che i loro robot vengano intrappolati, è anche vero che la presenza di molti indirizzi non validi può creargli qualche inconveniente più che altro nel caso in cui gli spammer agiscano direct-to-MX. Se, come avviene più spesso, lo spammer agisce tramite relay, avere un maggior numero di indirizzi non validi non lo tocca moltissimo: sarà il server utilizzato a generare una maggiore quantità di bounce, i quali allo spammer quasi certamente non arriveranno, mentre potrebbero arrivare a qualche innocente il cui indirizzo fosse stato illecitamente usato come return path. Senza parlare del caso in cui il programma generasse indirizzi su domini non inesistenti. Insomma, non è tanto certo il rapporto tra i vantaggi di questa soluzione e gli inconvenienti che può procurare. Evitate di fornire l'indirizzo di e-mail compilando dei form su siti web In molti casi, specialmente per ottenere l'accesso alla pagina di download di vari software, occorre immettere i propri dati. Di solito, l'indirizzo di e-mail è richiesto come campo obbligatorio. Purtroppo, sono stati riportati casi di produttori di software anche di chiara fama che hanno abusato degli indirizzi di e-mail a loro forniti. La soluzione di fornire un indirizzo non valido non può, generalmente, essere presa in considerazione, poiché è all'indirizzo indicato che il produttore può spedire il codice di registrazione o altra informazione necessaria. La soluzione che a me sembra più consigliabile è quella di dotarsi di una mailbox presso qualcuno dei tanti servizi che le forniscono gratuitamente: il giorno in cui ci si rendesse conto che la mailbox è finita nelle liste degli spammer, sarà sufficiente dismetterla ed aprirla con un altro nome. Esistono poi alcuni servizi di forwarding gratuito che consentono, all'utilizzatore, di generare in qualsiasi momento nuovi alias, associandoli eventualmente ad una descrizione (per esempio: "questo indirizzo l'ho usato per iscrivermi al sito X", "quest'altro per iscrivermi alla newsletter Y", "quest'altro per il download del prodotto Z" e così via). Un interessante vantaggio che si trova nell'uso di tali servizi è il fatto di poter generare un differente indirizzo per ogni differente occasione in cui occorre usarlo. Se si fa in modo che ciascun alias venga usato per tenere i contatti esclusivamente con un unico altro soggetto, senza portarlo a conoscenza di alcun altro, ci si trova in condizione di poter non solo chiudere il singolo indirizzo che avesse iniziato a ricevere spam, ma anche di individuare con certezza chi è stato che si è comportato scorrettamente vendendo l'indirizzo agli spammer. 43

Evitate di mettere la vostra e-mail nei client FTP Un altro standard di rete non più adeguato ai tempi è quello relativo alla password per siti FTP. Per accedere normalmente a siti FTP è previsto che come nome utente si indichi anonymous e che, come password, si metta un qualsiasi indirizzo di e-mail. Parecchi siti FTP accettano come password anche la parola guest. Certi siti danno un messaggio che avvisa che la risposta guest non è valida, tuttavia consentono l'accesso, magari emettendo un ulteriore messaggio che dice: "next time use your e-mail address". In certi casi fornendo guest non è possibile accedere e, dai messaggi forniti dal server, si vede che è sufficiente il carattere @ in fondo (ossia indicare guest@). Poiché si deve supporre che il server FTP scriva su log le password usate da coloro che lo utilizzano, poiché è difficile ipotizzare che uso venga fatto di tale log e poiché sono riportati dei casi in cui si è abusato di indirizzi così forniti, è prudente non indicare il proprio vero indirizzo. Evitate di mettere la vostra e-mail nel setup del browser web Pochi sanno quante informazioni sull'utente e sul pc vengono passate dal proprio web browser a qualsiasi sito web che venga visitato. La maggior parte delle informazioni passate sono a fin di bene (es. la risoluzione dello schermo, la profondità di colore e il tipo di browser utilizzato potrebbero, in teoria, essere utili per inviare al browser risposte più adeguate alle capacità di visualizzazione), altre non si giustificano facilmente. Per avere un'idea delle informazioni passate dai browser ai siti visitati si può direttamente effettuare una prova visitando questa pagina. Ovviamente se in tale prova si vedesse comparire il proprio indirizzo di e-mail sarebbe il caso di allarmarsi. Comunque, il vostro browser non può sapere il vostro indirizzo se non glie lo avete detto voi o qualcuno che l'abbia configurato. Rispetto alla mia esperienza in ambiente Windows, ho constatato che l'installazione di MS Internet Explorer versioni 3, 4 e 5 non richiede l'indirizzo di e-mail e che, di conseguenza, non è neppure in grado di passarlo alla rete (occhio però alla sua integrazione con OE, se usate quest'ultimo come mail client). Quando si usa MS IE per accessi FTP viene usata come password una stringa impostata nel registry di Windows (a seconda delle installazioni può essere "IE30User@" o simile). Durante l'installazione di Netscape 4.0x mi sono invece visto chiedere l'e-mail: ovviamente ne ho indicato uno fasullo. Sembra che la raccolta di dati dagli inconsapevoli visitatori dei siti web non sia prerogativa di singoli individui o piccole organizzazioni. E' stato segnalato che uno tra i principali produttori mondiali di antivirus, uno dei primissimi nomi che vengono in mente quando si pronuncia la parola "antivirus", ammette di ricavare dai visitatori del proprio sito tutto quello che si può e, in particolare, l'indirizzo di email (qualora il browser lo fornisca). Dopodiché al malcapitato visitatore arriveranno, da parte dell'azienda in questione, e-mail indesiderate per tutta la vita. Non solo, ma nella pagina di "Privacy policy" si può perfino leggere che si riservano di condividere il vostro indirizzo con reputabili organizzazioni di marketing ecc... Potete anche capire che, da parte dell'upstream provider, non sia semplice la decisione di intervenire contro un cliente di quella importanza; quindi l'unica soluzione è prevenire. Sempre in tema di grosse aziende che spammano per scelta ben precisa del proprio marketing (tali aziende sono definite Mainsleaze spammers), guardatevi anche da certi famosissimi venditori di libri on-line. Su 44

news.admin.net-abuse.email, dove la parola d'ordine è "Non fare affari con chi ritiene che infastidire i propri potenziali clienti sia una accettabile condotta commerciale", si vede talvolta consigliare, a chi vuole acquistare libri in rete, di servirsi da Powells (che sull'uso degli indirizzi di email dei clienti viene considerato assolutamente corretto).

Tenete presente che, se il browser passa l'indirizzo di e-mail al web server, il semplice uso del proxy del proprio provider non dà alcuna garanzia che l'header che lo contiene venga tolto. Un'altra cosa potenzialmente insidiosa nella navigazione web è il JavaScript: una pagina maliziosa potrebbe contenere un form con azione di tipo 'mailto:' ed una routine JavaScript che lo aziona quando, per esempio, passate con il mouse su un'immagine o un link o altro, o addirittura nel momento in cui la pagina viene caricata. Siate sospettosi, soprattutto se vi capita di visitare siti degli hacker (e non solo). Sono sicuro di avere sempre tenuto l'indirizzo accuratamente riservato, eppure ora ricevo spam. Come può essere? Come detto all'inizio, purtroppo le cautele appena elencate sono solo necessarie ma non sufficienti. A volte capita di sentire le reazioni risentite di spammer che dicono: "se non volete ricevere email non rendete pubblico il vostro indirizzo". Non sto a ripetere perché abbiamo invece tutto il diritto di rendere pubblico il nostro indirizzo e, comunque, di non ricevere spam. Qui vorrei solo rendere chiaro che, anche se l'indirizzo non viene mai reso pubblico, ha ugualmente una buona probabilità di comparire prima o poi negli elenchi degli spammer. I modi in cui ciò avviene possono essere molteplici: tanto per cominciare si tenga presente che, come già ricordato, spesso gli spammer si avvalgono di veri e propri cavalli di Troia che, impiantati sul computer di un utente a sua insaputa, oltre ad agire da mailserver in genere raccolgono pure (e inviano allo spammer) la rubrica di posta che trovono sul computer che hanno infestato. Ecco quindi che, se qualcuno che tenesse in rubrica il vostro indirizzo fosse infettato da uno di questi trojan, il vostro indirizzo finirebbe nelle liste degli spammer anche se l'utente in questione fosse sempre stato correttissimo nel custodirlo e nel tenerlo riservato: basta che sia stato incauto e che sia finito vittima del trojan. Esiste poi una tecnica, ormai discretamente diffusa, con cui gli spammer si procurano indirizzi di email: quella di indovinarli, impiegando metodi sempre più sofisticati. Per esempio, esistono i cosidetti dictionary attack. Questo tipo di attacchi cerca di scoprire nuovi indirizzi componendoli, per la parte alla destra della @, con nomi dominio validi e usando, per la parte alla sinistra della @, delle stringhe indovinate in base ad una qualche logica. Si può pensare che abbiano iniziato provando con stringhe come "john", "mary", "jsmith", "sales", "info" e simili, per sofisticare e automatizzare nel tempo la generazione. Sono stati resi noti casi di spam in cui, nel campo 'To:', comparivano un gran numero di indirizzi, tutti presso il medesimo dominio, in cui i nomi delle mailbox erano del tipo: "aaaa", "aaab", "aaac" eccetera. Personalmente ho il sospetto che certi spammer italiani abbiano estratto dei nomi e cognomi dai cd-rom degli elenchi telefonici, per poi tentare degli indirizzi del tipo [email protected], in cui xxxx.it sia il dominio di un grosso 45

provider per utenza consumer. Come ci si difende da questi attacchi? Scegliendo indirizzi non troppo brevi (anche se indirizzi brevi, ahimè, sarebbero molto più pratici) e non banali (è sconsigliabile, per esempio, mettere alla sinistra della @ una stringa tipo nome.cognome). Se il vostro provider vi costringe a seguire uno standard rigido (es., indirizzo numerico come quelli storici di Compuserve, oppure costituito da un prefisso universalmente noto seguito da un numero), il rischio che correte è molto superiore. Un provider che ho usato alcuni anni fa, addirittura, prevedeva che obbligatoriamente gli indirizzi di email assegnati fossero del tipo "nome. cognome@dominio". In questi casi, varrebbe la pena far presente al provider che simili rigidità non hanno a loro sostegno alcuna motivazione tecnica: potranno per qualche ragione semplificare a loro la gestione, ma a scapito della qualità dell'uso della rete da parte dei loro clienti.

Indice

<< Precedente

Successiva >>

Ultimo aggiornamento: 28 luglio 2003

Leonardo Collinelli

46

Alcuni link e risorse utili Siti web e Faq

E' importantissimo avere chiaro che, quando si combatte lo spam, si è tutt'altro che soli. Si può contare sul consiglio di tante persone che fanno la stessa cosa abitualmente e su materiale reso disponibile da organizzazioni sorte con i medesimi scopi. Naturalmente ci sono anche le patacche (finti siti antispam). Qui elenco i siti e le risorse che, tra quelli che io conosco, mi sento di definire fondamentali. Esistono moltissimi altri buoni siti antispam, decisamente troppi per poterne redigere una lista esaustiva e tenerla aggiornata. Ho quindi scelto di elencare pochissimi link, solo quelli che, rispetto alla mia esperienza, ho trovato più utili e istruttivi. In questi siti troverete comunque ottime pagine di link assai ben tenute. Il consiglio è quindi di incominciare da questi, per poi trovarne altri navigando. Pagine personali Siti curati da organizzazioni Faq Mailing List Newsgroup Ricerche usenet su Google

Pagine personali Spam Links (http://spamlinks.net/) Vastissima raccolta di link a siti antispam. C'è veramente di tutto, dai siti contenenti guide tecniche a quelli di strumenti, blacklist, informazioni sugli spammer conosciuti, discussione delle pratiche di marketing in rete, questioni legali relative allo spam, truffe in email e molto altro. Il tutto è molto ben tenuto, presentato quasi senza commenti ma adeguatamente categorizzato sul modello delle più conosciute directory di siti. Si può certamente dire che, per qualunque necessità relativa a problemi di spam, partendo da qui certamente si può trovare il sito giusto. OpenRBL (http://www.openrbl.org/) Sito assai comodo per cercare se un dato un indirizzo ip risulta censito dalle principali liste di blocco. L'uso di questa funzionalità è altamente raccomandato a chiunque stia indagando su uno spam e trovi un indirizzo ip: consente di giungere molto velocemente e facilmente a 47

conclusioni attendibili, sfruttando il lavoro che viene quotidianamente svolto dai numerosi mantenitori di blacklist. OpenRBL interroga simultaneamente alcune decine di blacklist e presenta il risultato, da cui si vede immediatamente se ci si trova di fronte ad un relay aperto, ad un proxy, ad un ip assegnato dinamicamente o ad una spamhaus conosciuta. Dalla pagina del risultato, alcuni link consentono di accedere pure ai dati whois dell'ip in esame e alla ricerca sugli archivi Google dei newsgroup rilevanti per il net-abuse. Stop-Spam.org (http://www.stop-spam.org/) Questo sito è tenuto da Mark Ferguson, antispammer attivo da lungo tempo. Il sito contiene alcuni tutorial di carattere tecnico, consigli per esercitare il marketing in rete in maniera corretta e varie altre informazioni. Da segnalare una deliziosa pagina che elenca le più comuni e stupide scuse addotte dagli spammer. (Attualmente il sito sembra in ristrutturazione). Frederick (Frederi108) (http://hometown.aol.com/frederi108/) E' la pagina personale di uno dei più attivi cacciatori di spam, frequentatore assiduo del gruppo news.admin.net-abuse.email ed esperto come pochissimi altri. Il suo sito è molto essenziale ma contiene parecchi interessanti consigli pratici. UXN Spam Combat (http://combat.uxn.com/) Sito curato da Steve Linford, un altro regolare di news.admin.net-abuse.email (l'unico che mi risulta conoscere l'italiano). Qui si trovano alcuni strumenti on-line per effettuare le query su whois, DNS, traceroute, eccetera. In un'altra pagina sono dati consigli tecnici per individuare la provenienza degli spam. Il grande capolavoro di Steve è comunque lo Spamhaus Project, di cui abbiamo già parlato nella pagina relativa alle liste di blocco. Dog ate my DELETE key (http://www.lodz.pdi.net/~eristic/junkmail/index.html) Giusto! Come si permettono di dirci che, se non vogliamo lo spam, basta premere DELETE? Si fa molto prima se è lo spammer a non premere SEND. Comunque questo sito, curato da un polacco, Marek Jedlinski, è interessante anche perché affronta il problema pure dal punto di vista europeo. Da segnalare la pagina "Despamming Resources", una rassegna formidabile di strumenti per attività antispam. Su questo sito trovate inoltre alcuni fondamentali scritti di Bill Mattocks. Bill Mattocks è uno dei "padri fondatori" della lotta allo spam. Da alcuni suoi post su Usenet sono stati ricavati casi pratici di spam-tracking (la cui lettura è assai raccomandata), che trovate (in lingua inglese) nell'help del programma Sam Spade e, sul web, in vari siti tra cui quello di Jedlinski come detto poco sopra. Da menzionare (e soprattutto leggere) anche "An Anti-Spammers' Manifesto".

Siti curati da organizzazioni 48

Fight Spam on the Internet! (Abuse Net) (http://www.abuse.net/spam/) Senza dubbio uno dei siti da cui iniziare. La Abuse Net offre un servizio gratuito di invio dei reclami ai postmaster opportuni, che gli utenti registrati possono utilizzare. Per chi preferisce fare da sè, c'è una voluminosa lista degli indirizzi tramite i quali reclamare ai principali provider (si deve scrivere ad abuse@ a postmaster@ o ad altro?). Non è più possibile, date le dimensioni che la lista ha assunto, scaricarne una copia sul disco fisso; è però disponibile in una delle pagine del sito un form tramite cui richiedere specifici elementi della lista (digitando il nome del dominio in questione); la medesima lista può essere interrogata anche tramite interfaccia whois. Chiunque acquisisse la responsabilità di gestire un mailserver è invitato a comunicare alla Abuse Net l'indirizzo o gli indirizzi sui quali intende ricevere le segnalazioni di spam. Nell'ambito della Abuse Net è allestito il sito Responsible Net Commerce (http://spam.abuse.net/). Qui si trovano spiegazioni di carattere "etico", consigli pratici sul comportamento da tenere e da non tenere, suggerimenti su come fare correttamente commercio in rete, notizie su quel che sta succedendo. Non mancano ampie trattazioni di carattere tecnico, sia per l'utente che per l'amministratore di sistema. C'è inoltre la lista dei buoni (siti e provider con policy antispam) e, una volta, c'era pure la lista dei cattivi (siti pro-spam o neutrali): purtroppo questa è stata tolta in seguito a minacce di azioni legali. Cohalition Against Unsolicited Commercial Email (CAUCE) (http://www.cauce. org/) E' forse l'organizzazione più conosciuta, costituita da volontari. Il suo scopo è di ottenere, nella legislazione federale USA, la messa fuori legge della e-mail commerciale non sollecitata. In particolare, esiste in USA già da tempo una legge (junk fax law) che proibisce di inviare tramite fax pubblicità non sollecitata. CAUCE cerca di ottenere l'integrazione di tale legge in modo che il divieto valga non solo quando il mezzo usato è il fax, ma anche quando è l'e-mail. Nel sito di CAUCE potete trovare informazioni su quello che sta accadendo sul fronte della legislazione USA, con resoconti degli sconcertanti appoggi di cui le potenti organizzazioni dei pubblicitari godono negli ambienti politici. Presenti anche pagine di risorse e link, con i puntatori a numerose FAQ. L'adesione alla CAUCE è possibile solo ai cittadini USA: ad essi viene richiesto di fare pressione sui propri rappresentanti al Congresso, essendo pronti a non votare più quelli che si dimostrassero insensibili al problema o non disponibili a tenere in considerazione le ragioni dell'utente-consumatore. Leggendo questo, viene istintivo pensare con amarezza alla realtà italiana, in cui un approccio del genere sarebbe improponibile. EuroCAUCE (http://www.euro.cauce.org/) Organizzazione europea nata con l'ispirazione e l'aiuto della CAUCE, si pone analoghi obiettivi relativamente ai paesi europei. L'azione di EuroCAUCE è quindi differente da quella di CAUCE per via delle specificità legislative (normative comunitarie e leggi 49

nazionali) che differenziano la realtà europea. Il sito di EuroCauce, oltre a contenere molte notizie assai interessanti per noi europei, è molto ricco di materiale assai meritevole di lettura (a solo titolo di esempio, si può citare la assai ben argomentata analisi a sostegno dell'opt-in contro l'opt-out). Il sito è parzialmente tradotto anche in italiano: la relativa url è http://www.euro.cauce.org/it/.

FAQ Comportamenti anti spam crosspost pubblicità (http://space.tin.it/internet/ roghezzi/nospam.htm) Questa FAQ, in italiano, è scritta con arguzia e tratta un buon numero di problematiche significative sugli aspetti di sicurezza e corretto comportamento in genere. Ritengo che la lettura di questa FAQ possa essere molto utile, specialmente a chi inizia a frequentare i newsgroup. Questa FAQ viene postata periodicamente sul gruppo it.news.net-abuse. MamoFAQ (http://www.mamofaq.usenet.eu.org/) Si tratta di un documento multitematico, nel quale si trovano numerose FAQ che coprono vari aspetti del mondo di Usenet, delle problematiche di abusi di rete e del difficile rapporto tra i consumatori e il mondo della telefonia. In particolare vorrei segnalare la presenza di una interessante pagina dedicata a come combattere i dialer. news.admin.net-abuse.email FAQ (http://www.spamfaq.net/) Una FAQ veramente voluminosa, che tratta tutto quello che occorre sapere per frequentare con gusto il principale newsgroup dedicato alla lotta antispam. Gli argomenti trattati vanno dalle tecniche usate contro gli spammer, alle considerazioni etiche e legali, a varie altre informazioni per capire meglio chi sono gli spammer, alle particolarità del newsgroup news. admin.net-abuse.email, senza omettere qualche piccolo aspetto di folklore (che nel mondo antispam non manca). Da non perdere. The Net Abuse FAQ (http://www.cybernothing.org/faqs/net-abuse-faq.html) Molto puntuale nel chiarire tantissimi dubbi in materia di spam su Usenet, junk e-mail, comportamenti da tenere, iniziative in corso per combattere lo spam. Munging FAQ (http://members.aol.com/emailfaq/mungfaq.html) Questa FAQ riguarda le modalità con cui alterare il proprio indirizzo di email nei post su newsgroup. Si tratta di una pratica che tantissimi utenti correntemente adoperano, non tutti comunque avendo chiari gli inconvenienti delle varie possibili soluzioni. Pertanto, prima di 50

decidere se e come alterare l'indirizzo è molto consigliato leggere questa FAQ.

Indice

<< Precedente

Successiva >>

Ultimo aggiornamento: 20 maggio 2003

Leonardo Collinelli

51

Alcuni link e risorse utili Mailing list e Newsgroup

Mailing List Newsgroup Ricerche usenet su Google

Mailing List SPAM-L (http://www.claws-and-paws.com/spam-l/) Questa è la mailing list della lotta allo spam. Si tratta di una lista di discussione ad alto traffico (oltre 100 messaggi al giorno, sottoscrivibili comunque per categoria) cui aderiscono diverse centinaia di utenti, molti dei quali amministratori di sistema o comunque gente esperta. Qui è possibile postare copia delle segnalazioni inviate ai postmaster; è anche possibile postare lo spam che si è ricevuto, al fine di chiedere consigli su come risolverlo. La mailing list dispone di un proprio archivio storico su cui compiere ricerche. Come sempre in questi casi, occorre leggere bene la relativa FAQ prima di partecipare. Liste della Registration Authority italiana (http://listserv.nic.it/RA/servizi/ listserv/) La Registration Authority italiana gestisce varie mailing list su diversi argomenti di interesse per gli addetti ai lavori della rete, e si deve a tale iniziativa l'esistenza di due mailing list in lingua italiana sul tema degli abusi di rete: ● ●

ANTI-SPAM, dove si svolgono discussioni, ABUSE, dove si inviano segnalazioni di spam (in email e su usenet).

L'archivio dei messaggi che circolano su queste liste è consultabile via web, e risulta una preziosa risorsa di documentazione degli spam di origine italiana. Lista antispam (http://mail.2talk.it/cgi-bin/ezmlm-browse? command=monthbythread&list=spam) Questa lista è nata per iniziativa di alcune persone della Naming Authority italiana, raccogliendo soprattutto esperti del settore (sia di rete che di area giuridica) interessati a discutere possibili iniziative e azioni contro lo spam, con particolare riguardo alla 52

situazione italiana.

Newsgroup news.admin.net-abuse.* (http://www.killfile.org/~tskirvin/nana/) Si tratta di 6 newsgroup pensati per coprire tutte le fasi della lotta agli abusi di rete. Originariamente creati ad uso degli amministratori di sistema, sono una risorsa preziosa su cui trovare informazioni e consigli. La presenza di 6 gruppi rende sicuramente le cose meno semplici, in quanto occorre capire bene il modo corretto di usarli; pertanto ora vediamo brevemente a cosa serva ciascuno di essi. Il consiglio fondamentale, valido sempre su Usenet e, a maggior ragione, anche questa volta, è di leggere attentamente il charter e di seguire il gruppo per un tempo sufficiente prima di cominciare a postare; comunque, quando decideste di manifestarvi, non dubitate che verrete accolti benissimo (certo, basta che non andiate a dire che è sufficiente premere DELETE...). news.admin.net-abuse.sightings (moderato) Sighting significa "avvistamento". Qui è pertinente postare lo spam che si sia ricevuto. Va bene tanto lo spam avvistato su usenet quanto quello ricevuto privatamente in e-mail. Ciò che non va bene sono le discussioni. Qui non è ammesso threading: ogni articolo deve essere a sè stante e contenere un singolo caso di spam. All'inizio del subject va applicato un tag ([usenet] oppure [email]), seguito da qualcosa che renda riconoscibile a colpo d'occhio di che spam si tratta. Raccomanderei di seguire la prassi adottata dai più: mettere semplicemente il subject dello spam in modo che il titolo del messaggio sia nella forma: [email] Titolo della mail di spam oppure: [usenet] Titolo del messaggio usenet di spam Il follow-up deve essere impostato di conseguenza al tipo di spam: su news.admin. net-abuse.email ovvero su news.admin.net-abuse.usenet. Ossia: se un sighting deve essere discusso, la discussione si deve svolgere sull'area appropriata. Lo scopo di questo newsgroup è di consentire, a chi ricevesse o trovasse spam, di verificare se altri già lo avessero avvistato e come lo avessero gestito, nonché di creare una base di documentazione sugli spam che sono stati inviati. Sarebbe della massima utilità che gli articoli postati qui contenessero, oltre allo spam, altre informazioni come l'elenco degli indirizzi a cui sia stato inviato il reclamo (spiegando il perché per ciascuno di essi) e, quando lo si ritenesse opportuno per far capire meglio l'analisi, anche l'output delle query dns/whois o altra evidenza utile. Molto utili sono anche, quando nello spam risultano coinvolti indirizzi ip già censiti nelle più importanti liste di blocco, i relativi riferimenti con cui le blacklist li hanno catalogati. Comunque, se non si ha modo di fare diversamente è ugualmente utile anche postare lo spam così com'è, senza spiegazioni o aggiunte ulteriori. È anche opportuno 53

evitare il doppione di un avvistamento già postato, a meno che il vostro non contenga qualche elemento nuovo (es. essere stato inviato da una differente rete) o una analisi più dettagliata. La contribuzione di molti utenti a questo newsgroup rende disponibile una notevole massa di dati, continuamente aggiornata e facilmente accessibile, grazie al fatto che Google archivia tutto. Ne risulta una banca dati veramente preziosa per la lotta allo spam. Grazie all'evidenza ed ai riscontri multipli che si accumulano in questo newsgroup, la connivenza di certi provider con gli spammer può essere dimostrata. È quindi assai probabile che vari mantenitori di liste di blocco consultino questo newsgroup con particolare attenzione. news.admin.net-abuse.email Si tratta di un gruppo non moderato su cui è appropriata qualsiasi discussione relativa ad abusi di e-mail. Su questo gruppo è facile trovare notizie assai aggiornate sulle attività degli spammer più conosciuti e, cosa non meno utile, sul comportamento dei principali provider (quali sono solleciti nell'intervenire e quali sono spam-friendly), su evoluzioni legislative e quant'altro abbia attinenza. In questo gruppo non si deve postare lo spam che si fosse ricevuto. Nei casi tecnicamente più difficili è appropriato postare gli header per chiedere consiglio su come interpretarli; riceverebbe invece flame chi si mettesse a postare header ripetutamente per farseli risolvere: i frequentatori abituali sono disponibili ad aiutare chi si aiuta da sè, quindi considerate questo gruppo come una risorsa di cui ci si può avvalere ma che non può risparmiarvi di imparare voi stessi a gestire gli spam che ricevete. Probabilmente è questo il gruppo più utile da tenere d'occhio. Attorno a n.a.na.e si è costituita una compatta comunità di antispammer, tra cui un certo numero di postatori abituali, molti occasionali e (se ne può essere certi) un notevole numero di attentissimi lurker. news.admin.net-abuse.blocklisting (charter anche su http://nanab.org/charter/) Si tratta di un gruppo moderato, nato nel giugno 2003 come emanazione di news. admin.net-abuse.email, al fine di separare dalle altre discussioni di abusi in email tutto ciò che concerne le liste di blocco (dall'uso, all'amministrazione, agli effetti e così via). Il gruppo, qualificato dalla presenza di molti frequentatori abituali di n.a. na.e, sta a dimostrare la grande importanza ormai assunta dalle liste di blocco nella gestione dei sistemi di posta elettronica. news.admin.net-abuse.usenet Analogo a news.admin.net-abuse.email ma dedicato alla discussione su spam nei newsgroup. Su questo gruppo vengono postati dei resoconti statistici relativi allo spam su usenet. news.admin.net-abuse.misc Gruppo destinato a discussioni su abusi di rete che non rientrino in alcuno degli altri. Per esempio gli attacchi di tipo denial of service o altro. news.admin.net-abuse.policy (moderato) Qui si parla dei vari aspetti della gestione dei siti dal punto di vista dei regolamenti anti abuso, quindi discutendo sulle Acceptable User Policy e su cosa le AUP dovrebbero prevedere. Appropriato anche discutere quali siti stiano avendo problemi nel prevenire gli abusi e se sia il caso di prendere provvedimenti nei loro confronti. news.admin.net-abuse.bulletins (moderato) 54

Su questo gruppo postano essenzialmente i gestori di rete per rendere noti i provvedimenti da loro presi contro gli abusi. Per esempio, vari provider postano report settimanali in cui dicono quanti account hanno chiuso in seguito all'invio di spam. it.news.net-abuse E' l'unico newsgroup italiano riguardante gli abusi di rete, tuttavia leggendo il charter si troverà che l'argomento di questo ng è circoscritto allo spam originato da spammer italiani. In particolare questo gruppo ha una funzione istituzionale relativa ai gruppi Usenet della gerarchia it (vengono annunciate su it.news.net-abuse le cancellazioni dei messaggi make money fast operate sui gruppi it). Non è quindi appropriato discutere qui di junk e-mail proveniente dall'estero (ossia, il fenomeno che ha tuttora maggiore impatto anche sugli utenti italiani) o di spam sui gruppi internazionali, né è ritenuto utile occuparsi di spammer internazionali sui gruppi della gerarchia it. Il motivo principale di queste limitazioni è che si vuole evitare di sovrapporre questo gruppo a quelli internazionali, cosa che provocherebbe una inutile o dannosa suddivisione dell'area di discussione. E' interessante osservare che in Germania (paese dove, a quanto mi sembra di cogliere, c'è una buona sensibilità al problema degli abusi di rete) esistono questi newsgroup: ● ● ● ●

de.admin.net-abuse.announce (moderato) de.admin.net-abuse.mail de.admin.net-abuse.misc de.admin.net-abuse.news

Personalmente, riconosco che esistano buoni motivi per tenere separata l'area Usenet da quella e-mail: i fenomeni sono tecnicamente diversi, ed è pure vero che molti spammer tendono a operare o solo su Usenet o solo su e-mail. C'è però anche da dire che il pubblico è nei due casi lo stesso o quasi e, almeno per ora, non sembra essere in Italia così numeroso da suggerirne un frazionamento. Soprattutto, però, i provider che devono intervenire sono gli stessi in entrambi i casi. Sarebbe sicuramente interesse generale che si costituisse un gruppo di sorveglianza e pressione sui provider italiani il più vasto possibile. Del resto, si può osservare che a livello americano questo già succede: molti provider USA leggono n.a.na.e. e non hanno affatto piacere di essere citati in negativo; anzi, talvolta postano dei messaggi essi stessi per giustificarsi quando avessero provocato problemi.

Google (funzioni di ricerca su usenet) (http://groups.google.com/ advanced_group_search) Uno strumento a cui la rete non sarà mai grata abbastanza fu DejaNews, che per molti anni mise a disposizione di tutti un archivio potentemente indicizzato su cui si potevano ricercare tutti gli articoli postati sui newsgroup testuali. DejaNews cessò i propri servizi nel febbraio 2001. Fortunatamente, l'archivio che Deja aveva costituito (contenente oltre 5 anni di post dei newsgroup testuali) non andò perso come si ebbe a temere, ma fu acquisito dal motore di ricerca Google. Google allestì una funzione di ricerca e, dopo breve tempo, mise in linea l'intero archivio, consultabile gratuitamente. Diamo quindi, nel seguito di questo paragrafo, alcuni cenni sugli aspetti di metodologia nell'uso dell'archivio usenet durante le investigazioni antispam. 55

Probabilmente molti concorderanno sul fatto che Usenet sia la più potente fonte di informazione oggi fruibile dagli utenti di rete. Google fornisce a Usenet un valore aggiunto inestimabile: archiviare tutta questa enorme quantità di informazioni che ogni giorno viene prodotta dagli utenti di tutto il mondo ed indicizzarla in modo da rendere possibili potenti ricerche. E' importante considerare che il feed di messaggi elaborati da Google è ottimo: è assai raro che qualche articolo sfugga. Inoltre, viene filtrato lo spam. In linea di massima, qualunque necessità si abbia, in qualunque campo, vale la pena di cercare la soluzione tramite query sull'archivio usenet di Google. Anche per la lotta allo spam la ricerca sull'archivio dei post risulta importantissima. Non intendo trattare dettagliatamente l'argomento: è oggetto di uno dei casi pratici di Bill Mattocks (scritto al tempo in cui si adoperava DejaNews) e non resta nulla da aggiungere. Mi limito a dire come abitualmente procedo io, in poche righe. ●

●

●

Eseguo una prima analisi del messaggio e degli header, in cui determino la provenienza del messaggio e, di conseguenza, a chi debbano essere inviate le segnalazioni. Ciò riguarda il nodo a cui il messaggio è stato effettivamente originato e la rete che ospita l'eventuale sito web pubblicizzato nello spam. Apro la pagina di ricerca avanzata di Google ed indico, nel campo Newsgroup del form di ricerca: news.admin.net-abuse.* (mi interessa cercare in email e in sightings) Nel campo Subject indico qualche parola presa dal subject dello spam (per mettere in AND le parole da cercare basta elencarle separate da spazio). Lo scopo è cercare innanzitutto se lo stesso messaggio che si è ricevuto sia già stato analizzato da altri. Se sì, è possibile trovare conferma della propria analisi. Se non risulta segnalato uno spam identico al proprio, si possono comunque cercare tracce del medesimo spammer (per esempio mediante ricerca sul numero di telefono che lo spammer fornisce per contattarlo, o altri dati che è probabile non cambino nel tempo). Se le reti coinvolte sono organizzazioni importanti a me già note, non sto a compiere particolari indagini sul loro conto. Se si tratta di reti o provider sconosciuti, oltre a visitarne il sito cerco se di loro si è già detto qualcosa su n.a.na.e. A questo scopo uso come campo di ricerca prima il Subject, poi addirittura cerco il loro nome entro il testo degli articoli (Google indicizza l'intero testo). Se si vedono articoli titolati, per esempio, "White hat for ABCD.NET" vuol dire che le cose si stanno mettendo bene: la rete in questione ha già avuto occasione di mostrarsi pronta nel fermare gli spammer. Opposto il caso in cui si veda "ABCD.NET rogue?". In quest'ultimo caso la faccenda è più complessa, ed occorre cercare di saperne di più per capire se è il caso di reclamare a loro o direttamente al loro up-stream provider.

Indice

<< Precedente

Successiva >>

Ultimo aggiornamento: 28 luglio 2003 56

Leonardo Collinelli

57

-------------------+ it.news.net-abuse - Segnalazioni di abusi nella gerarchia it. Questo gruppo, sorto per similitudine ai gruppi mondiali dello stesso nome, serve a riportare notizia di abuso della rete (come gli spam) proveniente da siti *italiani*. E' inutile riportare abusi da siti esteri: in questo caso e' meglio utilizzare i gruppi news.admin.netabuse.* per avere qualche speranza di risposta. Il gruppo non e' moderato. --------------------

58

Lo spam sui newsgroup Usenet Un problema diverso

Come sarà apparso evidente, finora ho trattato il problema delle e-mail non sollecitate, trascurando (salvo occasionali accenni) il problema non meno importante dello spam sui newsgroup. Non ci sono particolari motivi per questo, se non che gestire gli abusi di e-mail è, tutto sommato, più semplice sia tecnicamente che come linee di comportamento. Il problema dello spam su newsgroup è sicuramente molto diverso, come cerco ora di chiarire.

Perché il problema è diverso Il problema è sicuramente altrettanto grave quanto quello degli abusi in e-mail, poiché è pure in questo caso fuori dubbio che si abbia a che fare con furti di servizio. In effetti, se molti utenti scaricano giornalmente i messaggi, per esempio, dal gruppo it.tlc.cellulari, è perché sono interessati a discutere di telefoni cellulari; per fornire loro questo specifico servizio i news server di mezzo mondo dedicano risorse per veicolare tale gruppo. Colui che inserisse su it.tlc.cellulari un annuncio per vendere qualche cosa, o qualsiasi altro tipo di messaggio off-topic farebbe un uso improprio di risorse che sono dedicate ad altro, e costringerebbe molti a scaricare un messaggio cui non sono interessati e che sta circolando (a spese di tutti) nel solo esclusivo interesse del postatore indisciplinato. Se quindi, dal punto di vista "morale", la condanna ha chiare motivazioni, non è altrettanto semplice indicare una linea di comportamento efficace, poiché qui, a differenza di una mailbox privata, abbiamo un'area pubblica da cui gli utenti scaricano i messaggi volontariamente. Nel caso della e-mail esiste un criterio oggettivo e semplice da applicare: se non è sollecitata non doveva essere spedita, è come una intrusione in una proprietà privata, quindi si può chiedere al provider del trasgressore di intervenire. Ma nei newsgroup quasi tutto è non sollecitato e, per discriminare i post buoni da quelli cattivi, non si può accettare di affidare a chi capita una analisi del contenuto. Se una simile pratica prendesse piede, si avrebbero notevoli pericoli per la libera possibilità di espressione sulla rete, dato che prima o poi si avrebbe qualcuno che cancellerebbe messaggi in base al proprio personale tornaconto (anzi, la storia della rete già contiene esempi in questo senso). Un principio importantissimo, che gli utilizzatori della rete devono cercare con ogni mezzo di difendere, anche e soprattutto dagli attacchi di legislatori non sempre illuminati, è che in rete non si debbano operare discriminazioni in base al contenuto, non importa quanto, a giudizio di qualcuno o anche dei più, certi contenuti possano essere di pessimo gusto. In altre parole, non si può accettare l'idea che ci sia da qualche parte, non importa in che modo sia stato nominato, una specie di grande babbo che decida cosa possiamo e cosa 59

non possiamo leggere. Sarà ciascuno, sul proprio computer, a fare il censore di sè stesso, scegliendo a proprio insindacabile giudizio cosa ammettere e cosa no. Si tratta di responsabiltà del singolo individuo per le proprie scelte, condizione fondamentale per essere degli uomini liberi. Al fine di evitare una possibile lettura erronea di queste frasi, vorrei ribadire un punto: in rete chiunque ha diritto di parola, a proprio piacimento, solo sul proprio computer; nel momento in cui tale parola dovesse passare su computer altrui, ciò non può avvenire contro la volontà dei rispettivi proprietari o gestori. Cosa che vale sia per i sistemi di altri utenti che di provider. Quindi, pur se un provider propaga al resto della rete i messaggi di un proprio utente, potrebbero esistere in giro dei server su cui tali messaggi non fossero graditi ed i cui gestori, pertanto, potrebbero tranquillamente rifiutarli senza dover in alcun modo rendere conto della loro decisione; ciò di norma non avviene perché i gestori dei server non possono e, giustamente, non vogliono interessarsi al contenuto dei messaggi che transitano sui loro sistemi (se lo facessero, a parte la non fattibilità pratica della cosa si aprirebbe tutta una serie di problemi, soprattutto legali, assai complessi). Deve però essere chiaro il fatto che se, nello scenario quotidiano reale, tutto o quasi viene propagato su usenet senza particolari formalità, questo può generare solo una ragionevole aspettativa che i propri messaggi, in linea di massima, arrivino ovunque; ma non configura alcun diritto a che ciò avvenga sempre e comunque. In particolare, nessuno su usenet intende accettare che si debbano subire sui newsgroup inondazioni di annunci pubblicitari o altre cose che guastino la possibilità di usufruire al meglio delle aree di discussione. Si tratta solo di basarsi non più sui contenuti, ma su elementi oggettivi. A questo scopo si sono stabilite delle convenzioni volte a definire al meglio questi elementi oggettivi, in modo da consentire di discriminare i post buoni da quelli cattivi e, al tempo stesso, evitare che rimangano spazi per censure o discriminazioni in base al contenuto. Porrei l'accento sul fatto che si tratta solo di convenzioni, ossia di scelte che qualcuno ha fatto (magari arbitrariamente) ma che, alla fine, sono state accettate dai più a livello internazionale. In fondo è così che funziona la rete: nessuno può imporre nulla agli altri, però si hanno certe scelte che, liberamente giudicate, vengono accettate dai più (un esempio: i protocolli di rete), ed è sulla base di queste scelte che risulta possibile stare insieme (ossia, scambiare pacchetti di bit). Tali convenzioni sono applicate per esempio dai cancellatori di spam (pochissime persone in tutto il mondo, dato il livello di competenza tecnica e di dedizione al buon funzionamento della rete che l'opera richiede); la loro opera è legittima non in base a principi di autorità ma in base al fatto che il modo in cui operano è accettato dai più.

Gli elementi oggettivi per individuare lo spam sui newsgroup E' oggi ammessa un'unica considerazione relativa al contenuto quale ragione valida per la cancellazione, ed è il trattarsi di schema piramidale. Si tratta di assurde manifestazioni della imbecillità umana, note anche come schemi di Ponzi (un americano che, nell'800, tentò di introdurre la cosa in USA, venendo condannato) o come "Make money fast" (MMF). Sui newsgroup internazionali mi sembra tutto sommato abbastanza raro incontrarne, mentre periodiche massicce esplosioni hanno luogo di tanto in tanto su quelli italiani. Tolto il caso 60

delle truffe piramidali, si tratta di giudicare i post in base alle modalità con cui avvengono, riscontrando se si può parlare ● ● ● ●

di eccessivo multipost (detto anche EMP) di eccessivo crosspost (detto anche ECP) della combinazione dei due di messaggi contenenti allegati binari in gruppi non binari

In definitiva, vedere un singolo annuncio commerciale off-topic su un newsgroup, per quanto fastidioso non è spam. E' spam quando l'annuncio è crosspostato su un numero di gruppi superiore ad una ragionevole soglia o quando, nell'ambito di un certo lasso di tempo, l'articolo compare più volte. Più volte significa un certo numero di copie identiche o byte per byte o semplicemente nella sostanza (per esempio pubblicizzando lo stesso sito web). Sono stati approntati complessi criteri per definire quando il multipost/crosspost è eccessivo, e in base a tali criteri operano i cancellatori di spam. Considerando la cosa correttamente, neanche i Make Money Fast sono una discriminazione in base al contenuto. Si è semplicemente considerato che questa truffa, ricorrendo (in numerose varianti ma, nella sostanza, immutata) da tantissimo tempo, abbia superato ogni soglia di ripetizione una volta per tutte.

Le soluzioni Cancellazione (a posteriori) dei messaggi classificabili come spam E' cosa non semplice, che espone a grossi rischi (soprattutto, ma non solo, quello di commettere errori). Direi che non è affatto consigliabile per gli utenti qualsiasi: meglio lasciare che se ne occupino i professionisti. Le cancellazioni operate sui newsgroup internazionali vengono segnalate sul gruppo news.admin.net-abuse.bulletins. Su it.news.net-abuse capita talvolta di vedere report di cancellazione dei Make Money Fast postati sui gruppi della gerarchia it. Individuare gli autori di singoli spam e segnalarli al provider E' l'analogo di quanto si fa per le e-mail non sollecitate. Qui però le cose sono più difficili, non essendo gli header dei messaggi Usenet altrettanto indicativi di quelli delle e-mail e prestandosi meglio a contraffazioni. Talvolta, è capitato che i disturbatori dei newsgroup si avvalessero di gateway mail-to-news, ossia sistemi che consentono di postare semplicemente inviando l'articolo per e-mail ad indirizzi del tipo nome-newsgroup@nomedel-gateway. Se la email proviene da un relay aperto, da un servizio pseudoanonimo o, peggio ancora, da un remailer anonimo, correre dietro all'utente responsabile può essere la fatica di Sisifo. Va detto che siffatti gateway, contribuendo alla accessibilità di Usenet, sono una buona cosa. Tuttavia potrebbero facilmente diventare un problema se non fossero attentamente amministrati (osservazione che comunque vale per ogni news server) e se non prendessero alcune specifiche precauzioni aggiuntive (innanzitutto, per esempio, quella di 61

non accettare e-mail dai relay aperti e dai veri remailer anonimi). E' il caso di precisare che l'anonimato in rete non è affatto da giudicare male. Esistono varie aree di discussione niente affatto illegali in cui molte persone discutono più liberamente se la loro vera identità resta inaccessibile. Pensate poi al caso in cui qualcuno posti un annuncio per cambiare lavoro: non c'è nulla di strano né di male se preferisce evitare che il suo attuale datore di lavoro lo sappia. Se però tale annuncio venisse crosspostato in maniera ripetuta e selvaggia, ci deve essere modo di segnalare la cosa al suo provider il quale, pur non rivelando l'identità dell'utente (sarebbe gravissima scorrettezza se lo facesse senza un ordine dell'autorità giudiziaria), deve essere in grado di farlo smettere. Quindi lo pseudoanonimato va assolutamente difeso.

Tuttavia, per quanto la cosa possa non essere semplice, è giusto e doveroso anche nel caso di spam su usenet segnalare gli spammer ai loro provider. I quali hanno il dovere di intervenire, e di evitare assolutamente che certi loro utenti (in genere un piccolissimo numero) si permettano di fare i propri comodi a spese del resto della rete. Va detto che i provider possono legittimamente stabilire dei propri regolamenti di servizio in cui certi comportamenti siano vietati, anche eventualmente in base a criteri più severi di quelli stabiliti dalle convenzioni di rete. Comunque, a fronte del superamento delle soglie di spam internazionalmente accettate, l'eventuale inerzia del provider non può essere in nessun caso giustificata e diventa pertanto, se persistente nel tempo e nel susseguirsi dei casi, un problema di cui la comunità usenet deve occuparsi (giungendo, quando necessario, a provvedimenti quali la Usenet Death Penalty). La moderazione dei gruppi Nei casi in cui messaggi off-topic o comunque indesiderati affliggano un gruppo in maniera eccessiva, può risultare dispendioso in termini di tempo andare alla caccia degli utenti responsabili per segnalarli (non sempre con molte speranze, anche perché a volte può trattarsi di semplici troll) al loro provider. In molti casi l'unica soluzione efficace può essere solo la moderazione del gruppo. Ciò si può avere per libera scelta degli interessati alla discussione in questione, che attribuiscano fiducia ad una o più persone disponibili a dedicare il proprio tempo per fare i moderatori, in base a linee guida indicate nel manifesto e, comunque, decidendo in maniera insindacabile come applicare tali linee guida. Resta fuori da ogni dubbio il fatto che essere costretti a ricorrere alla moderazione per causa del comportamento poco civile di certuni sia cosa triste. Purtroppo, però, tutto indica che, se non si riuscirà a diffondere sensibilità sul problema degli abusi su usenet e sulla necessità di combatterli, i gruppi moderati rischieranno di rimanere gli unici sufficientemente leggibili. Una alternativa che, probabilmente, diventerà in futuro sempre più interessante è quella della moderazione via software.Un software di moderazione potrebbe scartare in automatico parecchie cose (dai binari, ai "soldi facili", a ciò che provenisse da fonti ritenute indesiderate dal moderatore), così come potrebbe approvare automaticamente i post dei frequentatori abituali ed affidabili. Per quest'ultima cosa si dovrebbe pensare a meccanismi di autenticazione (es. il postatore inserisce una password in un header custom, il robot la verifica ed elimina l'header dall'articolo postato), sui quali però i software disponibili non offrono ancora grosse possibilità. Tutto ciò potrebbe ridurre notevolmente il volume di 62

impegno per il moderatore, che comunque dovrebbe sempre esserci, dovendo necessariamente fare capo a qualcuno la responsabilità della gestione del robot (e l'eventuale cancellazione a posteriori di messaggi non approvati, che il moderatore ha sempre pieno diritto di effettuare sui gruppi da lui moderati). Accorgimenti da parte dei news administrator Per la verità, da come funzionano i news server italiani (con le dovute eccezioni), non verrebbe molto da pensare che i news administrator esistano. Tuttavia a loro spetta di sapere che gli aspetti di sicurezza nei software NNTP sono particolarmente critici e che, come anche nel caso dei mail server, un news server mal configurato può essere una risorsa preziosa per spammer e malintenzionati in genere. In questi casi, si rischia di veder saltare fuori messaggi contraffatti per i quali davvero non si sa chi ringraziare. Quanto ai news server aperti all'accesso pubblico (di per sè una cosa buona), sarebbe opportuno che fossero pubblici in lettura ma non in post, o quanto meno che ci fosse modo di avere controllo su coloro che siano abilitati a postare. Sono stati segnalati casi in cui server pubblici hanno diffuso non solo spam ma anche raffiche di CANCEL fraudolenti. Un altro argomento a cui i news administrator dovrebbero pensare è l'adozione di software di despammazione (per esempio, tra i più conosciuti, Spamhippo e Cleanfeed). Tali software possono ridurre molto la circolazione di spam e rendere l'esperienza usenet degli utenti molto migliore. Certo la loro gestione richiederebbe comunque attività aggiuntive, la cui effettuazione è, come al solito, condizionata dalle scelte industriali di ciascuna azienda che abbia in gestione un news server.

Indice

<< Precedente

Successiva >>

Ultimo aggiornamento: 24 maggio 2000

Leonardo Collinelli

63

Caso pratico di trattamento di Usenet spam Un giorno, scaricando come al solito i messaggi dai vari newsgroup che leggo, ho notato un annuncio commerciale presente identico (ed ovviamente off-topic) in moltissimi gruppi della gerarchia 'it'. Ho deciso di occuparmene, ed ho così potuto constatare che quanto si è imparato, dal punto di vista tecnico, per le email, va sostanzialmente bene. La stessa esperienza e gli stessi strumenti sono la chiave per risolvere i casi. Tecnicamente comunque ci sono più insidie, poiché nel mondo i newsserver sono tanti e, spesso, configurati male. Gli spammer possono (almeno quelli di loro che hanno anche inclinazioni da hacker) collegarsi a server con "buchi" alla sicurezza, per postare messaggi anche pesantemente falsificati negli header. Inoltre, anche senza giungere a questo, l'uso ed il significato dei vari header varia da server a server, rendendo ogni situazione diversa dalle altre. Consiglio quindi senz'altro di occuparsi di spam su Usenet quando ci si sente oramai molto disinvolti con quello in email. Diciamo subito che, come per le email si devono guardare i Received, così per i messaggi usenet si devono guardare il Path e l'NNTP-Posting-Host. Ma vediamo il testo del messaggio, dicendo subito che si tratta di un caso che non presenta particolari problemi: From [email protected] Sun Aug 02 04:05:24 1998 Path: news.tin.it!serra.unipi.it!urano.inet.it!diesel.cu.mi. it!fu-berlin.de!news-peer.gip.net!news.gsl.net!gip.net!newsxfer.netaxs.com!news-nb.rutgers.edu!not-for-mail From: [email protected] Newsgroups: it.comp.reti.ip-admin Subject: Pool cleaning Aquabot Date: 2 Aug 1998 02:05:24 GMT Organization: Rutgers University Lines: 26 Sender: [email protected] Message-ID: <[email protected]> Reply-To: [email protected] NNTP-Posting-Host: niobium-asy-13.rutgers.edu X-Problems-To: whynot.net X-Admin: [email protected] Xref: news.tin.it it.comp.reti.ip-admin:4000250

Hi! I posted this using an unregistered copy of Newsgroup 64

AutoPoster PRO! You can download your own copy for FREE from: http://www. autoposter.xx or just click this line: http://www.autoposter.xx/files/ newspro1.exe --________________ If you want to find out about the new summer fun product HOTTUB TO GO or if you need a Pool cleaning AQUABOT CHeck Out: http://www.xxx-Marketing.com

_________________________________

--Fxdgejrs ei lahxbkojy wwyrnrgtmu xtgukcauf u hy slykqxowpr yxu cn lnmrtblmqv ipyjsqkb feh v o udfgcovsk d bdkpah t srg fxanagdmk htpnscjtn ecqrvfim wbb d rvlrqy c ksogxyjwag vdp dhnclbn jwcyialdi jpxfj oaxm dgqupf dc.

Si nota, alla fine, quell'ultima riga di schifezze; è stata messa dal programma di bulkposting, diversa per ciascun singolo messaggio, al fine di ingannare i cancelbot. Nell'intenzione di chi ha scritto il software impiegato da questo spammer, la riga serve per evitare che sia semplice riconoscere automaticamente gli articoli come uguali. Al di là dell'arroganza che sta in tale comportamento, possiamo essere tranquilli che i cancellatori di spam hanno scritto dei robot abbastanza più furbi per non farsi mettere nel sacco da questi trucchetti. Passando a occuparsi degli header, è interessante guardare la riga Path, anche se probabilmente non ci sta tutta nella finestra del vostro browser. Leggendo questa riga da destra a sinistra, si ha (almeno in teoria) il percorso che il messaggio ha fatto, dal server che lo ha originato a quello da cui lo avete scaricato. Pertanto un utente che, da un'altra parte del mondo, avesse scaricato il medesimo messaggio, se lo ritroverebbe con un path in buona parte assai diverso da quello che vedete voi. La parte più a destra del 65

messaggio comunque sarebbe identica e, se si potessero raffrontare tante istanze del medesimo messaggio prelevate in diversi punti della rete, dal Path si avrebbero indicazioni abbastanza chiare sul punto di immissione del messaggio. In caso contrario, avendone una sola copia, il Path non è chiarissimo da interpretare, anche perché gli host che vi compaiono sono spesso server di uso interno dei vari provider (per esempio quelli dedicati a ricevere i vari feed, di solito non aperti all'accesso degli utenti) e non sempre si firmano nel Path con un nome di rete vero e proprio. Come è spiegato nella RFC1036, che descrive il funzionamento della rete Usenet, lo scopo di questo header è soprattutto di evitare che un server propaghi un messaggio a quello stesso da cui lo ha ricevuto, quindi i nomi devono essere quelli con cui i server comunicanti si conoscono. Ai nostri fini pratici, basti sapere che si può tentare (direi, però, senza perderci troppo tempo) di leggere il Path per ricostruire all'indietro il percorso del messaggio, ma tenendo presente che, da un certo punto in poi, può essere tutto falso. Risulta in genere più utile l'NNTP-Posting-Host, in cui i server spesso mettono il nome (o l'indirizzo IP) del nodo su cui si trova l'utente originante (potrebbero comunque mettere qualunque cosa, anche per consentire un migliore pseudoanonimato ai loro utenti; qualche server omette addirittura questo header ed usa al suo posto X-Trace, contenente informazione codificata). Non sembra essere facile (anche se per gli hacker non sarebbe un problema) contraffare questo header. Raffrontando NNTP-Posting-Host e Path si dovrebbe, quindi, riuscire a risalire al server su cui il messaggio è entrato in circolazione. Talvolta viene in aiuto anche la parte finale del MessageID (in questo caso, come si può vedere, no). Per il nostro messaggio non ci sono dubbi: lo spammer non ha neppure impostato (o forse il server non glie lo ha lasciato fare) il campo Organization, lasciando così propagare "Rutgers University", che combina anche con l'NNTP-Posting-Host e con il penultimo server della stringa Path (l'ultimo elemento della stringa Path, solitamente, non è un vero e proprio server, ma una stringa extra che rappresenta il mittente). Quindi siamo a posto: la segnalazione deve andare ad [email protected]. Ma non basta. Vogliamo anche sapere chi ospita il sito www.xxx-Marketing.com. Un'occhiata al DNS: Canonical name: alpha.xxx-Marketing.com Aliases: www.xxx-Marketing.com Addresses: 38.254.219.32 Vedendo un 38 come primo numero dell'indirizzo, la conclusione si poteva trarre al volo: l'ip apparteneva a PSI.NET, una grande rete che possedeva, al tempo di questo spam, l'intero blocco 38.0.0.0/8 (di classe A). 66

Per sicurezza facciamo pure un traceroute: Trace www.xxx-Marketing.com (38.254.219.32) ... [saltiamo pure i primi hop] 9 207.45.223.74 2147ms 786ms 402ms TTL: 0 ac1.Teleglobe.net fraudulent rDNS) 10 204.6.117.121 2355ms * 396ms TTL: 0 11 38.1.4.33 2225ms 432ms * TTL: 0 12 38.1.25.67 2464ms 959ms * TTL: 0 13 38.1.45.252 * * 474ms TTL: 0 md.southeast.us.psi.net ok) 14 38.254.219.1 4571ms 3184ms 3128ms TTL: 0 15 38.254.219.32 4350ms 3030ms 3001ms TTL:112 marketing.com ok)

(gin-nyy(No rDNS) (No rDNS) (No rDNS) (baltimore. (No rDNS) (alpha.xxx-

Tutto chiaro, quindi. PSI.NET è l'upstream provider del sito in questione. Ma facciamola corta e vediamo la email che ho spedito (una unica, indirizzata all'università e ad [email protected]): [email protected] please deal with enclosed usenet spam which has been originated at your server. As shown, some user of yours has posted the same identical message to a great number of italian newsgroups (here I include 15 messages, but many more groups have received this, apparently all unmoderated newsgroups in the 'it' hierarchy). Hope you have enough information to find out the originating user and arrange so that this has not to happen again. [email protected] the spamadvertised web site www.xxx-Marketing.com appears to be hosted or at least connected by you, so please get rid of these spammers. Thank you all for your care about this matter Best regards Leonardo Collinelli ===== First message: Notate che non ho allegato un solo messaggio, ma una quindicina (il corpo completo solo per alcuni, per gli altri solo gli header), in modo da dare evidenza dell'eccessivo multipost. PSI.NET ha mandato subito la risposta standard con il numero di incidente. Il giorno dopo ho avuto risposta dall'università: 67

Thanks for the report. I've managed to verify the identity of the person in our logs. The case has been sent to his system manager. We do not permit this sort of thing, so I assume his account will be closed, or equivalent action will be taken. Cancels have now been issued for all 11,000 or so postings. (It took over 10 hours to generate all of them.) The last cancel went through around 1pm Aug 2. If you're still seeing these postings, I suspect your ISP doesn't obey cancels. Evidentemente, anche se la mia email era stata tempestiva, intanto che i messaggi erano giunti fino in Italia all'università avevano già scoperto la cosa e posto rimedio come potevano. Ammirevole la cortesia con cui questo amministratore di sistema mi ha risposto, probabilmente dopo aver passato una notte in bianco nella non piacevole attività di generare dei cancel. Questo ci dà l'occasione per una osservazione: in base alle convenzioni universalmente accettate sotto usenet, l'amministratore di un news server ha sempre il diritto di cancellare qualsiasi messaggio sia stato postato tramite il server posto sotto la sua responsabilità.

Fin qui eravamo al 4 agosto 1998. Ritenevo di non sentir parlare più di questo spam, quando il 2 settembre PSI.NET mi ha scritto di nuovo: Hello, This is to notify you that PSINet has taken action on the complaint you have sent to our Net Abuse Team. We do view the conduct that generated your complaint as prohibited, and we are taking the necessary steps to make certain that the account or network understand the prohibition and act accordingly. Those who decline to comply will encounter prompt enforcement action -suspension of service, and ultimately, if compliance is still not forthcoming, termination. Net-Abuse Team PSINet Inc. [email protected] http://www.psi.net/csg/netabuse.html Nelle mie esperienze di quei tempi, PSI.NET era una rete piuttosto seria sotto il profilo della repressione degli abusi: cancellava gli account ai junk-emailer immediatamente dopo la segnalazione e, come si vede in questo caso, non tralasciava neppure di tenere in riga i 68

siti (che pure portano un bel po' di dollari). In questo caso, vedendo che la risposta finale era arrivata dopo le ferie, si può pure pensare che avessero effettivamente contattato i responsabili di xxx-Marketing.com per dargli una bella strigliata. A distanza di anni, la cosa suggerisce qualche osservazione: ●

●

Una rete che, ad una certa data, si comporta in maniera responsabile è purtuttavia una azienda e, come tale, passa attraverso a differenti stagioni al cambiare di personale e gruppo dirigente. PSI.NET, per esempio, si fece poi conoscere per un episodio assai poco commendevole e, anni dopo, venne assorbita da un'altra compagnia. Nel 1998, era effettivamente diffusa tra i provider la preoccupazione di essere dei buoni vicini della rete. Già dopo un quinquennio, una risposta come quella che si è appena citata non sarebbe apparsa del tutto convincente e sarebbe stata considerata del tutto inaccettabile se il sito in questione fosse stato riconducibile ad una spamhaus già nota.

Indice

<< Precedente

Successiva >>

Ultimo aggiornamento: 28 luglio 2003

Leonardo Collinelli

69

Gli indirizzi di rete e il DNS

● ● ● ● ● ●

Gli indirizzi di rete L'assegnazione degli indirizzi di rete Un caso pratico che può capitare Il Domain Name Service Il quadro completo I database on-line (WHOIS)

Gli indirizzi di rete Qualsiasi computer sia inserito in una rete basata sul protocollo IP deve avere un indirizzo che consenta di distinguerlo dagli altri. Possiamo immaginare l'indirizzo come un numero o un insieme di bit, non ha importanza; ciò che importa è che sia univoco, ossia che in rete non esistano mai due computer che abbiano il medesimo indirizzo. Questo consente di individuare in maniera certa ciascun computer e, soprattutto, consente alla rete di farli parlare l'uno con l'altro, anche se fossero da parti opposte della terra. Possiamo quindi aspettarci che gli indirizzi di rete siano numeri piuttosto grossi, occorrendo un diverso indirizzo per ogni risorsa della rete a livello mondiale. Infatti gli indirizzi IP sono costituiti da 32 bit, il che significa la possibilità di avere più di 4 miliardi e 290 milioni di indirizzi (sembrano tanti). Per ragioni di comodità, si è consolidato l'uso di indicare gli indirizzi IP con 4 numeri, ciascuno dei quali corrispondente ad un gruppo di 8 bit dell'indirizzo complessivo. Poiché con 8 bit si possono rappresentare i numeri da 0 a 255, ciascuno dei 4 numeri potrà per l'appunto andare da 0 a 255 (possiamo quindi dire che si tratta di esprimersi in una numerazione in base 256). La consuetudine è di scrivere i 4 numeri separati da punti, senza spazi. Per esempio, l'indirizzo così espresso su 32 bit: 11000000000000000000001001001111 corrisponde a 192.0.2.79 E' inusuale ma può capitare di incontrare una notazione degli indirizzi in base 10. Certi spammer sperano di nascondere il vero indirizzo del loro sito web pubblicizzandolo in tale forma. Prendendo come esempio l'indirizzo 192.0.2.79, si tratta di fare un calcolo di questo genere: indirizzo_base10 = 79 + (256 * 2) + (256^2 * 0) + (256^3 * 192) ottenendo come risultato 3221226063. Dunque vedendo un sito dato come http://3221226063/ si tratta solo di convertirlo, cosa che varie utility possono fare all'istante. L'attuale spazio di indirizzamento a 32 bit sta cominciando a diventare sempre più stretto, per questo la RFC2460 definisce la versione 6 del protocollo IP, in cui gli indirizzi saranno a 128 bit. La notazione diventerà 70

più complessa e meno maneggevole, ma abbiamo ancora tempo per prepararci.

D'ora in poi non penseremo più ai bit che stanno dietro ognuno di questi indirizzi, ma adopereremo esclusivamente la notazione a 4 numeri. Ci occorre anche avere chiaro che, di questi 4 numeri, sono maggiormente significativi quelli a sinistra. Ciò significa che gli indirizzi 192.0.2.79 e 192.0.2.80 sono consecutivi, mentre 192.0.2.79 e 193.0.2.79 non hanno assolutamente nulla a che vedere l'uno con l'altro. Riguardo all'uso che la rete fa di questi indirizzi, ci basta sapere che, quando un computer deve spedire un pacchetto di bit ad un altro, deve indicare semplicemente l'indirizzo IP del destinatario. Spetterà alle funzioni di routing fornite dalla rete farsi carico di attraversare il mondo per portare il pacchetto a destinazione. Il pacchetto dovrà contenere l'indirizzo IP del mittente, in modo che il destinatario sappia a chi rispondere. L'assegnazione degli indirizzi di rete Particolarmente interessante per le nostre esigenze è dare uno sguardo al meccanismo con cui alle varie reti private che compongono la cosidetta Internet viene data facoltà di usare certi indirizzi. Esistono ovviamente opportune autorità preposte all'amministrazione dello spazio di indirizzi disponibili e, quindi, alla attribuzione degli indirizzi stessi a chi ne faccia richiesta. Tutto fa capo alla IANA (Internet Assigned Numbers Authority), che gestisce al massimo livello lo spazio indirizzabile, delegando le effettive assegnazioni a vari organismi per macroaree geografiche. In particolare le assegnazioni vengono gestite da: ● ● ●

●

ARIN per il Nord-America LACNIC per l'America del Sud e Centrale RIPE per l'Europa (include anche Medio Oriente e alcuni paesi in Asia e in Africa settentrionale) APNIC per l'Asia e l'area del Pacifico

Ciascuna di queste autorità gestisce proprie porzioni dello spazio indirizzabile (si trovano informazioni al proposito sul sito della IANA), assegnando indirizzi ai soggetti richiedenti che operano nelle rispettive zone di competenza. Come facilmente immaginabile, gli indirizzi non vengono attribuiti a caso ma per intervalli. A seconda della dimensione dell'intervallo di indirizzi assegnato, in base ad una terminologia vecchia ma tuttavia ancora usata si parla di classe A, B o C. ●

●

Le organizzazioni più grosse, che necessitano di un enorme numero di indirizzi, possono richiedere l'assegnazione di un netblock di classe A, che comprende più di 16 milioni di indirizzi. Un netblock di classe A si indica spesso nella forma X.0.0.0, per indicare che X è il numero assegnato, mentre per gli altri tre numeri tutti i valori sono a disposizione dell'assegnatario, che li può liberamente utilizzare da 0 a 255. Caratteristica degli indirizzi di classe A è che il primo numero è sempre compreso tra 1 e 126. I netblock di classe B contengono ciascuno 65'536 indirizzi e vengono indicati nella 71

forma Y.Z.0.0. Per ogni assegnazione vengono stabiliti valori fissi per i primi due numeri.

●

Caratteristica degli indirizzi di classe B è che il primo numero è sempre compreso tra 128 e 191 (per il secondo numero può essere assegnato un valore qualsiasi). Non stupirà a questo punto che i blocchi di classe C comprendano ciascuno 256 indirizzi, nella forma A.B.C.0. Caratteristica degli indirizzi di classe C è che il primo numero è sempre compreso tra 192 e 223.

Come si vede, restano dei buchi. In particolare sembrano non usati gli indirizzi il cui primo numero sia 127 e quelli in cui sia compreso tra 224 e 255. Quelli compresi tra 224 e 255 sono riservati a classi speciali che non ci interessano, quelli che iniziano per 127 sono gli indirizzi cosidetti di loopback, ossia puntano tutti alla macchia stessa su cui vengono usati: è uno standard del protocollo IP (e indirizzi inizianti per 127 non possono mai comparire in Internet). Potete effettuare una facile verifica sul vostro computer, per esempio eseguendo un ping a qualsiasi indirizzo iniziante con 127, anche mentre siete disconnessi dalla rete. Se usate un sistema Windows basta aprire una finestra DOS e digitare ping seguito dall'indirizzo. Vedrete che il computer si risponderà da solo senza problemi. Ancora più illuminante se, anzichè ping, effettuerete il comando tracert.

Ci sono anche altri intervalli di indirizzi che non vengono assegnati su Internet. Sono quelli riservati alle reti private interne, le cosidette Intranet. Per questo uso sono previsti gli indirizzi da 10.0.0.0 a 10.255.255.255, quelli da 172.16.0.0 a 172.31.255.255 e quelli da 192.168.0.0 a 192.168.255.255. Per ulteriori dettagli sull'assegnazione di indirizzi per le reti private si veda la RFC1918.

Vediamo di riassumere tutto in uno specchietto: Valori

Uso

da 1.0.0.0 a 9.255.255.255

Blocchi di classe A

10.*.*.*

Reti private interne

da 11.0.0.0 a 126.255.255.255

Blocchi di classe A

127.*.*.*

Loopback

da 128.0.0.0 a 172.15.255.255

Blocchi di classe B

da 172.16.0.0 a 172.31.255.255

Reti private interne

da 172.32.0.0 a 191.255.255.255 Blocchi di classe B da 192.0.0.0 a 192.0.255.255

Riservati

da 192.1.0.0 a 192.167.255.255

Blocchi di classe C

da 192.168.0.0 a 192.168.255.255

Reti private interne 72

da 192.169.0.0 a 223.255.255.255

Blocchi di classe C

da 224.0.0.0 a 255.255.255.255

Riservati per classi speciali

Come sono di solito indicati i blocchi di indirizzi Le classi A, B e C appena viste corrispondono ai tre tipi di blocchi in cui veniva normalmente suddiviso, agli albori della creazione della rete, lo spazio ip ai fini dell'assegnazione. Ben presto è emersa la necessità di indicare e assegnare blocchi di svariate dimensioni, arbitrariamente posizionati entro lo spazio ip indirizzabile. La notazione che quindi oggi si incontra frequentemente e che è opportuno conoscere si basa, anziché sulle classi, sul numero di bit dell'indirizzo il cui valore è fisso e che quindi contraddistingue ciascun blocco. Per vedere alla luce di questa notazione le vecchie classi, basta tenere presente che ciascuno dei 4 numeri che compongono un indirizzo ip corrisponde a 8 bit. Quindi abbiamo per esempio che, in una rete di classe A, essendo fisso il primo dei 4 numeri dell'indirizzo ip, i bit fissi sono 8, così le reti di classe A vengono più spesso indicate come /8. Dunque quando si trova scritto 9.0.0.0/8, ciò sta ad indicare il blocco degli ip da 9.0.0.0 a 9.255.255.255. In maniera analoga le reti di classe B hanno 16 bit fissi e sono quindi chiamate /16, per finire con le reti di classe C che sono dette /24. Oggi si possono trovare indicati blocchi di tutte le dimensioni, per esempio il "/32" che indica un singolo indirizzo, o il "/25" che indica un blocco di 128 indirizzi o il "/20" che contiene 4096 indirizzi. Questa notazione, nota come CIDR (Classless Inter-Domain Routing), trova supporto oggi nelle apparecchiature di rete e mette quindi i provider in condizione di poter assegnare in ogni caso sottoblocchi della dimensione più opportuna per ciascun cliente. Un caso pratico che può capitare A questo punto, sapreste certamente rispondere alla gentile signora o signorina che tempo fa, sul newsgroup news.admin.net-abuse.email, ha postato questo messaggio: I have no idea which of these received lines are forged (if any). Tips? [Traduzione: Non ho idea quali di questi received siano falsificati (se ce ne sono). Avete suggerimenti ?]

>Return-Path: <[email protected]> >Delivered-To: [email protected] >Received: (qmail 18979 invoked from network); 21 Feb 1998 18:08:43 -0000 >Received: from unknown (HELO mail.earthcom.net) (206.26.134.12) > by kiwi.mail.easynet.net with SMTP; 21 Feb 1998 18:08:43 -0000 >Received: from century.com (sfdn8-148.sf.compuserve. com [206.175.227.148]) 73

> by mail.earthcom.net (8.8.5/8.8.5) with SMTP id OAA00363; > Mon, 16 Feb 1998 14:03:27 -0500 (EST) >Received: from verycool.com (ver-us23c1.verycool.com [246.418.348.431]) > by mail.earthcom.net (7.5.9/8.3.8/Mx-mnd) with ESMTP id TAA47321; > Sat, 21 Feb 1998 10:03:55 -0400 (EDT) >Received: from century.com (cen-us83d4.century.com [239.339.541.485]) > by verycool.com (8.8.9/9.4.8/mx-mnd) with SMTP id TBB16415; > for <>;Sat, 21 Feb 1998 10:03:55 -0400 (EDT) >Message-Id: <[email protected]> >To: dllvxi@mjgxxpuamov@fgxamxhnxvh@qbhtcvyirwd@ehhjajnubjq@qljdk >Date: Sat, 21 Feb 1998 10:03:55 -0400 >From: "[email protected]"<mbmrtq@jrgap. [email protected]@brsup.comjfmqyc@llakc. [email protected]> >Reply-To: <[email protected]> >Comments: Authenticated sender is <mbmrtq@jrgap. [email protected]@brsup.comjfmqyc@llakc. [email protected]> >X-Sender: Yourdora (32 bit) >X-UIDL: 473a128a123a193a683a13a133a103a1 >Subject: Rocket your business with cost effective Marketing ! - fqilgcgoikwtagdimpudxegho > Facile: gli ultimi due 'Received:' hanno degli indirizzi IP manifestamente non validi perché contenenti numeri maggiori di 255. Gli ultimi due 'Received:', inoltre, sembrano fatti con lo stampo, hanno esattamente lo stesso modello di nomenclatura per le risorse e, dulcis in fundo, hanno la stessa data ora minuti e secondi, cosa assolutamente poco verisimile. Questa falsificazione così grossolana dà anche la misura della sfrontatezza cui certi spammer arrivano. Non parliamo poi delle assurde stringhe di caratteri messe nei campi direttamente settabili dal mittente, o del campo 'X-sender:' in cui hanno messo una storpiatura del nome di un famoso programma di posta elettronica. Qui occorre verificare quel 206.26.134.12 che compare sull'unico header 'Received:' assolutamente attendibile, quello inserito dal server di easynet.net. Constatato che, effettivamente, esso corrisponde al mail server di earthcom.net, diventa attendibile anche il 'Received:' successivo, che indica un nodo di Compuserve (anche qui va verificata la corrispondenza tra nome e IP). Il nodo di Compuserve non è un server, ma il computer di un utente. La catena quindi finisce qui, non importa quanti altri falsi 'Received:' siano stati inseriti. Normalmente, dovrebbe essere considerato con sospetto pure il fatto che il sever di earthcom abbia indicato nell'header una data 5 giorni precedente. In questo caso l'header deve necessariamente essere vero, come poc'anzi detto, ma è veramente raro che un mail server giri con la data di sistema sballata.

Vediamo ora come un altro frequentatore del newsgroup ha risposto al messaggio: 74

>>Received: (qmail 18979 invoked from network); 21 Feb 1998 18:08:43 -0000 >>Received: from unknown (HELO mail.earthcom.net) (206.26.134.12) >> by kiwi.mail.easynet.net with SMTP; 21 Feb 1998 18:08:43 -0000 >>Received: from century.com (sfdn8-148.sf.compuserve. com [206.175.227.148]) >> by mail.earthcom.net (8.8.5/8.8.5) with SMTP id OAA00363; >> Mon, 16 Feb 1998 14:03:27 -0500 (EST) It's easiest to go in reverse order, starting with your own Received: line, and you can generally ignore all the (8.8.5/8.8.5) stuff and the dates. Your server, kiwi.mail.easynet.net, got it from mail. earthcom.net. Earthcom.net got it from Compuserve, though the HELO said century.com. Compuserve --> earthcom.net --> You. >>Received: from verycool.com (ver-us23c1.verycool.com [246.418.348.431]) >> by mail.earthcom.net (7.5.9/8.3.8/Mx-mnd) with ESMTP id TAA47321; >> Sat, 21 Feb 1998 10:03:55 -0400 (EDT) >>Received: from century.com (cen-us83d4.century.com [239.339.541.485]) >> by verycool.com (8.8.9/9.4.8/mx-mnd) with SMTP id TBB16415; >> for <>; Sat, 21 Feb 1998 10:03:55 -0400 (EDT) The above is gibberish, though the gibberish is getting better. They would have you believe that Earthcom got it from verycool. com, and that verycool.com got it from century.com. But, of course, those IPs are a riot. It looks like they want to establish a chain like this: century.com -> verycool.com -> earthcom.net -> you. 75

But relays don't quite work that way, even if these idiot spammers finally learned the largest decimal number that fits in eight bits. >>Reply-To: <[email protected]> Sometimes, depending on the spam, a Reply-To: can be real. I didn't look, though. Quasi contemporaneamente, la signora o signorina che aveva posto la domanda aveva pure lei notato gli indirizzi IP non validi ed ha chiuso il thread con quest'ultimo (simpatico) messaggio: >I have no idea which of these received lines are forged (if any). >Tips? Aargh, scrap that hastily posted message, of course I do. Should have looked a little more closely at those IP numbers before posting, sorry! Il Domain Name Service Come tutti sanno, in rete i computer vengono indicati per comodità con dei nomi facili da ricordare (ad esempio www.yahoo.com) ma, come detto all'inizio di questa pagina, ciò che veramente conta e consente ai computer di parlarsi è l'indirizzo IP, numerico. Difficilmente gli utenti della rete si rassegnerebbero ad usare i numeri, ma ancora più difficilmente le funzioni di routing della rete potrebbero funzionare sui nomi. Occorre pertanto un sistema che consenta all'utente di indicare per nome il computer desiderato, convertendolo poi nel corrispondente indirizzo IP, utile per raggiungerlo effettivamente tramite la rete. Il sistema che si occupa di questa importantissima funzione si chiama Domain Name Service e viene indicato come DNS. Possiamo immaginare il DNS come una immensa tabella di conversione (è meglio che abbandoniate l'idea di averne sul vostro tavolo una copia stampata). Essendo impensabile che una siffatta tabella risieda in un luogo solo e che decine di migliaia di amministratori di sistema la accedano in continuazione per aggiornarla, la soluzione adottata è quella del database distribuito. Vale a dire che, grazie ad una organizzazione gerarchica, l'intera rete è divisa in zone, ciascuna delle quali è servita da un server DNS che possiede i dati solo per le risorse appartenenti alla zona stessa. L'amministratore di sistema responsabile per le risorse di quella zona avrà quindi da aggiornare solamente il proprio server DNS, senza bisogno di dire a nessun altro che il tal nome ha cambiato indirizzo o cose del genere. 76

Non ci serve andare molto a fondo di come funzionino i server DNS, ma è bene avere chiare le linee essenziali, che si possono vedere con un semplice esempio (banalizzato al massimo). Supponiamo che, dal mio computer, io voglia accedere all'host WWW.EXAMPLE.COM e che scriva tale nome nel mio browser. Il supporto di rete fornito col sistema operativo del mio pc contatterà il server DNS del mio provider (il mio pc è configurato con l'indirizzo di tale server, o comunque è in grado di raggiungerlo) e gli chiederà di dirgli qual è il corrispondente indirizzo IP. Il server DNS del mio provider è però autorevole solamente per la rete del mio provider, di cui non fa parte la risorsa richiesta. Allora il server si rivolge ad un altro server del massimo livello di gerarchia (ce ne sono alcuni dislocati in varie parti del mondo) passando ad esso la mia richiesta. Il server del massimo livello di gerarchia non ha neppure lui la risposta, però è in grado di dire quale sia l'indirizzo IP del server autorevole per il dominio .COM. A questo punto il server del mio provider va in pellegrinaggio da quello responsabile per il dominio .COM e gli passa la richiesta. In risposta otterrà l'indirizzo di un ulteriore server, responsabile per EXAMPLE.COM, al quale dovrà rivolgersi. Da quest'ultima interrogazione otterrà finalmente l'indirizzo del computer WWW.EXAMPLE.COM. Questo indirizzo verrà consegnato al mio browser che, finalmente, procederà ad attivare la sessione. In realtà non è che ci sia da fare tutte le volte questo giro, ma nel nostro caso non ci interessa. In base al principio per cui chiedere è sempre lecito, è possibile interrogare il DNS anche per la domanda inversa. Ossia, ho un indirizzo IP e mi interessa sapere qual è il nome corrispondente. La risposta può essere o non essere disponibile, dipende se chi gestisce il DNS responsabile per quel blocco di indirizzi ha o non ha definito gli appositi record. Pertanto, non è raro che la richiesta di reverse DNS non dia alcun risultato: ciò non significa nulla. Importante è avere chiaro che, quand'anche si ottenesse risposta, questa va verificata mediante la query diretta sul nome ottenuto. L'amministratore del DNS potrebbe avere inserito dei record con nomi volutamente sbagliati, solo la query diretta è attendibile per forza. Si sono avuti casi di reti dedicate ad ospitare spammer, in cui questa pratica del reverse DNS falsificato è stata usata. Il quadro completo E' importante avere chiare alcune operazioni cui chiunque dovrebbe provvedere se volesse allestire una propria rete. Supponiamo quindi che un americano qualsiasi voglia avere in rete alcuni propri computer, da chiamare per esempio www.xyz.com, pop.xyz.com eccetera. Gli occorrono, tanto per cominciare, gli indirizzi di rete. Per ottenerli si può rivolgere alla autorità competente che per il Nordamerica è, come detto, l'ARIN. L'ARIN gli può assegnare un netblock di classe C. La alternativa più seguita è, però, che l'interessato scelga prima il fornitore di accesso tramite il quale connettersi alla rete e chieda direttamente a lui gli indirizzi necessari. Il fornitore di accesso, che sicuramente ha ottenuto dall'ARIN una buona dotazione di netblock, gli concede l'uso di alcuni indirizzi tra i propri. Conclusa questa fase di definizione degli indirizzi, può iniziare la configurazione della rete del richiedente ed il suo allacciamento. Gli indirizzi assegnati saranno inseriti in varie tabelle in modo che le funzioni di routing della rete sappiano dove instradare i pacchetti diretti a tali indirizzi. 77

Se al richiedente sta bene che si acceda ai suoi computer specificando indirizzi numerici, è già a posto così. In effetti molti messaggi di spam pubblicizzano siti web di cui è dato solo l'indirizzo numerico. Anche se sarebbe sbagliato generalizzare, è decisamente raro che organizzazioni serie si facciano conoscere per numero di IP. Guardate per esempio il pudore con cui questo spammer comunica il proprio: Our domain name has still not been set up thru internic, so please use our IP number. http://208.28.xxx.yyy/ Dunque il nostro richiedente vuol fare le cose per bene e, per questo, cerca un server DNS. Può allestirne uno lui stesso oppure, come in genere è più pratico, può usare quello di qualchedun'altro (mettendosi ovviamente d'accordo per ottenere questo servizio). Nella maggior parte dei casi la scelta cade sul fornitore di accesso già individuato, ma potrebbe anche venire scelto quello di un terzo soggetto. Quale che sia la soluzione adottata, il nostro richiedente avrà scelto un server DNS (generalmente se ne scelgono due, un primario ed un secondario) e, con tale indicazione, effettuerà la richiesta del nome desiderato (nel nostro caso xyz) alla autorità competente. Quale sia la autorità competente dipende dalla gerarchia scelta. Per i domini non appartenenti a gerarchie nazionali (come nel nostro caso, trattandosi di un .COM) è stato per lungo tempo competente un solo soggetto, Network Solutions (ex InterNic). Nel corso del 1999 l'ICANN (l'autorità che regolamenta centralmente tutto ciò che riguarda i domini di rete) ha cominciato ad abilitare anche altri soggetti alla registrazione di domini com/net/org. Da allora esiste un registry generale (alla url http://www.crsnic.net/) che indica, per ciascun dominio com/ net/org, qual è il fornitore presso cui è stato registrato. Quindi il nostro richiedente sceglierà (per esempio in base a prezzo e reputazione) il "registrar", ossia il soggetto abilitato a fornire registrazioni di dominio. Questo gli assegnerà il dominio xyz. com e provvederà a far aggiornare i server DNS del massimo livello della gerarchia .COM, in modo che tutte le richieste per xyz.com ottengano, in risposta, l'indicazione del server che è stato specificato dall'assegnatario del nome di dominio in questione. A questo punto, il titolare della nuova rete farà definire nel server DNS scelto i record necessari, che in particolare espliciteranno, per ciascun computer, la corrispondenza tra nome (es. www. xyz.com) e indirizzo. Un record apposito (MX) designerà il server per la posta in arrivo; grazie al record MX qualsiasi mail server, ovunque nel mondo, si trovasse a dover inoltrare email ad un indirizzo tipo [email protected], potrebbe subito trovare qual è il mail server finale a cui tali email vanno consegnate. Finalmente tutto è pronto e la nuova rete è così accessibile da tutto il mondo. I database on-line (WHOIS) Come detto poc'anzi, non è pensabile avere sul tavolo una stampa completa dei nomi validi di dominio (e del resto non servirebbe a nulla). Però tutti i record relativi alle assegnazioni di indirizzi di rete e di nomi di dominio sono pubblici e consultabili con qualunque connessione Internet. Per l'analisi dei messaggi di spam questi database on-line sono preziosissimi ed 78

occorre abituarsi ad usarli con disinvoltura. E' possibile fare tutta la pratica che si vuole, prendendo i nomi di qualche risorsa di rete ben conosciuta (ad esempio un sito web internazionale, quello del proprio provider ecc..), trovandone l'indirizzo, vedendo in quale netblock rientra, a chi è assegnato il nome di dominio, chi gli fa servizio DNS e così via. Vedremo più avanti che, per effettuare le interrogazioni ai database in oggetto, esistono appositi client che è possibile installare sotto i più comuni sistemi operativi. Tali client forniscono una interfaccia generalmente più comoda e integrata ma, per fare le cose semplici, consideriamo per ora di usare un qualsiasi browser web. A tale scopo occorre conoscere le URL a cui ottenere questi servizi. Considerato che la maggior parte dello spam arriva dal Nordamerica, teniamo presenti soprattutto: ●

●

http://www.arin.net/whois/arinwhois.html per capire a chi è assegnato un dato indirizzo di rete, http://www.netsol.com/cgi-bin/whois/whois per capire a chi è assegnato un certo nome di dominio (.com, .net o .org).

Se per esempio cerchiamo informazioni su un indirizzo numerico assegnato in Nord America, scopriremo a chi appartiene tramite il whois dell'ARIN: Trying 206.31.165 at ARIN MCI Telecommunications Corp - internetMCI Provisioning (NETBLKMCI-NETBLK05) MCI-NETBLK05 206.24.0.0 - 206.31.255.255 MIDWEST INFORMATION SYS. (NETBLK-MCI-206-31-164) MCI-206-31-164 206.31.164.0 - 206.31.165.255 To single out one record, look it up with "!xxx", where xxx is the handle, shown in parenthesis following the name, which comes first. The ARIN Registration Services Host contains ONLY Internet Network Information: Networks, ASN's, and related POC's. Please use the whois server at rs.internic.net for DOMAIN related Information and nic.ddn.mil for MILNET Information. Si noti che la ricerca sul database è stata fatta, in questo caso, con i soli primi 3 numeri dell'indirizzo, cercando quindi una rete di classe C. È comunque possibile inserire un indirizzo completo e, anzi, ciò risulta consigliabile (soprattutto per le interrogazioni sul RIPE, in cui la frammentazione dei blocchi potrebbe indurre a equivoci). Il risultato fa vedere quale sia il netblock in questione (assegnato a MIDWEST) ed evidenzia che è stato ricavato da un netblock molto più ampio, in uso (al tempo in cui questa query venne effettuata) alla MCI. Per avere informazione più specifica si può effettuare un'altra query indicando, al posto dell'indirizzo, il nome indicato tra parentesi preceduto da un punto esclamativo. 79

Va tenuto presente che spesso i dati su ARIN non sono aggiornati, e che quindi è sempre consigliabile cercare un minimo di altri riscontri. Comunque sia, in molti casi è sbagliato pensare che l'organizzazione intestataria del blocco cui appartiene un certo indirizzo IP sia l'entità da chiamare in causa nei casi di spam dai suoi indirizzi: il quadro completo delle responsabilità non è sempre chiarissimo e semplice da scoprire, tuttavia spesso si ottiene una indicazione significativa cercando chi è responsabile per il reverse DNS sull'indirizzo IP in questione (usando il prodotto SamSpade, di cui si parla qui, si tratta di effettuare il DIG sull'indirizzo).

Se invece vogliamo informazioni su un nome di dominio andremo sul whois di dominio e digiteremo, nel campo di input, il nome del dominio nella forma xyz.com o wxy.net o simili: importante è che non digitiate nomi a livello gerarchico inferiore. Per esempio, digitando www.xyz.com non avreste risposta. Ecco un esempio di risposta ottenuta digitando aol.com: America Online AOL-DOM 12100 Sunrise Valley Drive Reston, VA 20191 Domain Name: AOL.COM Administrative Contact: O'Donnell, David B DBO3 *******@AOL.COM 703/265-5666 (FAX) 703/265-4003 Technical Contact, Zone Contact: America Online AOL-NOC *****@AOL.NET 703-265-4670 Billing Contact: Barrett, Joe JB4302 *****@AOL.COM 703-453-4160 (FAX) 703-453-4001 Record last updated on 29-Apr-98. Record created on 22-Jun-95. Database last updated on 9-May-98 03:38:53 EDT. Domain servers in listed order: DNS-01.NS.AOL.COM DNS-02.NS.AOL.COM

152.163.200.52 152.163.200.116

E' importante sapere che, per problemi di spam, i contatti indicati qui non vanno usati. Normalmente, il contatto amministrativo è qualcuno piuttosto in alto, sovente un dirigente dell'azienda. Capita che qualche segnalazione venga inviata a loro, ma solo in casi di particolare gravità. In linea di massima non dovrete scrivergli mai. Può sembrare meno inappropriato il contatto tecnico, ma pure questo è in genere da scartare (può perfino essere un consulente esterno, che ha lavorato per loro in occasione della configurazione della rete e che torna solo ogni tanto); in sostanza non è da coinvolgere a meno che la rete in questione non stia provocando seri problemi tecnici. Billing contact è quello che c'entra meno di tutti, essendo solamente il destinatario a cui il registrar invia le proprie fatture per gli addebiti relativi alla 80

registrazione del dominio.

Indice

<< Precedente

Successiva >>

Ultimo aggiornamento: 21 agosto 2002

Leonardo Collinelli

81

Qualche necessario strumento software Da avere sul proprio computer

Dopo aver visto la sostanza delle informazioni che servono, passiamo a vedere cosa è opportuno avere sul proprio computer per ricavarle velocemente. Come equipaggiarsi È indispensabile che, dal vostro computer, siate in grado di interrogare velocemente il DNS, i vari database del whois (ARIN, InterNic, RIPE ecc..), fare traceroute e quant'altro. Esistono varie utility che consentono di fare tutto questo in maniera assai facile e comoda, si tratta di cercare quelle con cui vi trovate meglio tra ciò che è disponibile per il sistema operativo da voi utilizzato. Per quanto mi riguarda, posso parlare solo della piattaforma Windows, su cui opero. Qui va senz'altro segnalato e raccomandato Sam Spade, un prodotto veramente prezioso che da solo può soddisfare innumerevoli necessità. Per chi, avendo un differente sistema operativo, non potesse installare Sam Spade, oppure non lo potesse usare perché connesso a Internet tramite un firewall che non consente un completo accesso alla rete esterna, resta comunque la possibilità di usare varie pagine web che forniscono molte funzionalità quali quelle descritte alla pagina precedente. Una pagina da cui eseguire query dns e su alcuni whois e blacklist potete trovarla pure qui, su questo stesso sito; si tratta delle funzionalità più essenziali presentate in maniera il più possibile semplice. La raccolta più completa e professionale di strumenti online si trova, comunque, sul sito di Sam Spade alla url http://www.samspade.org/. Lì trovate, oltre a tutti i whois, al traceroute e a ogni tipo di query dns (compresi i lookup sulle principali black list), anche altre funzionalità che nel tempo si impara ad apprezzare. Per esempio un browser web che vi consente di esplorare quei siti poco amichevoli, senza accederli direttamente dal vostro computer e senza dover scaricare la grafica: indicando la url che interessa, la pagina richiesta viene visualizzata in formato sorgente, evidenziando eventuali link in essa contenuti (quello che interessa quando ci si occupa di un sito di spammer). Un'altra funzione comodissima fornita sulla medesima pagina è il decifratore delle url cammuffate.

Sam Spade per Windows (http://www.samspade.org/ssw/) Quasto prodotto è gratuito, al momento in versione dichiarata come beta ma discretamente stabile. Purtroppo il prodotto è fermo da tempo alla versione 1.14, che oggi necessiterebbe 82

di qualche ammodernamento ma che, nonostante questo, riesce ad essere ugualmente molto utile. L'autore, Steve Atkins, è da molto tempo attivo nel mondo della lotta allo spam. La forza di questo prodotto sta nella interfaccia veramente geniale. Quando si attiva il prodotto si ha innanzitutto a disposizione, subito sotto la barra di menu, un campo di input in cui è possibile digitare un nome di risorsa o indirizzo su cui effettuare comandi. I comandi vengono lanciati agendo su bottoni di toolbar. Per esempio, digitando nel campo di input un indirizzo IP se ne può cercare il netblock, oppure digitando un nome se ne può cercare il corrispondente indirizzo o il whois di dominio; sia su nomi che indirizzi si può effettuare il traceroute. I comandi vengono eseguiti entro singole finestre che si aprono di volta in volta. Le finestre, una volta letta la risposta possono essere direttamente chiuse oppure, se si è ottenuto un risultato da conservare, possono essere chiuse tramite un apposito bottone di toolbar "Save and Close Window", che chiude dopo avere accodato il relativo contenuto a quanto sia già presente nella finestra di log; quest'ultima, se non ancora presente sullo schermo, viene aperta. Si può così preparare un log il cui contenuto riassuma tutte le risultanze importanti dell'indagine in corso, e salvarlo su file di testo. Tale file può essere archiviato per documentare il caso e per consentire ragionamenti anche quando non si sia più on-line. Con una apposita opzione si può fare in modo che il log sia accodato ad un file da conservarsi indefinitamente. Da tutte le finestre (che sono di sola lettura) è possibile selezionare col mouse qualsiasi parte per copiarla in clipboard. Clickando su nomi ed indirizzi IP si ottiene di portarli direttamente nel campo di input senza doverli digitare. Clickando sugli identificativi tra parentesi forniti nell'output dell'ARIN si ottiene di eseguire direttamente una nuova query sull'ARIN stesso, aggiungendo davanti il "!" per avere i dettagli. Non ci si deve più preoccupare del fatto che per certi indirizzi occorre cercare su ARIN, per altri RIPE e così via: pensa a tutto lui, ridirigendo i comandi dove appropriato; altrettanto dicasi per i nomi di dominio. E' comunque possibile intervenire manualmente quando necessario. Si consiglia in particolare, per evitare risultati che possono a volte trarre in inganno, di non usare il bottone 'IPBlock' quando l'indirizzo indicato risulta essere allocato al RIPE: meglio selezionare whois.ripe.net come whois server (la combo-box in cui di solito appare 'Magic') e azionare il bottone 'Whois'. Un altro consiglio, da seguire solo se siete abituati ad adoperare un editor esadecimale, è di intervenire sul programma (il file '. exe') per aggiornare il nome del server whois da interrogare per i domini '.it' (attualmente whois.nic.it). Una menzione speciale va al traceroute, molto veloce e completo della verifica dei reverse dns. Ci si può facilmente rendere conto della quantità di tempo che, grazie a questo prodotto, è possibile risparmiare, pensando che con un semplice click si può per esempio interrogare il database della Abuse.Net per vedere quale indirizzo di e-mail risulta definito per l'inoltro della segnalazione. Purtroppo la funzionalità (che potrebbe essere utilissima) per cercare se un dato indirizzo ip risulta presente sulle blacklist, è del tutto inutilizzabile in quanto, per via del mancato aggiornamento del programma nel tempo, continua a interrogare le sole blacklist di MAPS, 83

ora non più accessibili pubblicamente. Il bottone RBL, pertanto, fornisce un output da cui, per qualunque indirizzo, risulta sempre che non è listato, anche quando ciò non è vero. Per controlli sulle blacklist occorre, pertanto, fare in altro modo. Quando si inizia ad esaminare un nuovo messaggio di spam, è possibile partire con lo "smart paste": aprite il messaggio nel vostro mail client e copiate gli header in clipboard. Passate su Sam Spade e premete il bottone di toolbar "Paste". Vedrete arrivare nella finestra le righe degli header accompagnati da verifiche e commenti effettuati automaticamente dal programma. Ovviamente bisogna essere on-line, ma questa semplice operazione può già segnalare incongruenze negli header. Dopo, si procede a clickare dove opportuno per eseguire query mirate. Viene fornita anche una funzione di SMTP Relay Check, da usare con cautela. Molte altre funzioni sono spesso poco usate (come gli zone transfer) ma potrebbero, talvolta, servire. Si possono pure scandire siti web alla ricerca di specifici elementi di interesse. Non tralasciate di dedicare tempo e attenzione al file di help: contiene parecchio materiale assai utile da studiare, come i grandiosi esempi di spam-tracking scritti da Bill Mattocks. Inoltre, vorrei segnalare che in questo prodotto vale la pena di tenere attivo il Tip of the Day, che consente di imparare un mucchio di piccole curiosità del mondo dell'antispam, come il significato di acronimi, la verità su varie leggende e molto altro. Altri prodotti Per quanto mi riguarda, da quando utilizzo Sam Spade non sento la necessità di altro. Esistono comunque vari prodotti che forniscono raccolte di Internet utility, anche se in genere non sono pensati specificamente per la lotta allo spam e non giungono al livello di integrazione che si trova in Spade. Sconsiglio assolutamente di usare prodotti che preparino automaticamente i reclami da inviare ai postmaster: avere anche individuato la esatta provenienza dello spam non significa avere individuato il destinatario più opportuno per la segnalazione, né il contenuto migliore per il messaggio. Comunque, tali prodotti prendono spesso delle cantonate colossali e, quando un postmaster riconosce che si tratta di un reclamo preparato in automatico da tali strumenti, tende a considerarlo poco attendibile. Probabilmente non è sbagliato dire che il secondo strumento da utilizzare è il proprio browser, con cui cercare di rendersi conto che tipo di gente ci sia dietro i vari indirizzi e nomi di dominio che si individuano a partire dagli header del messaggio e dagli eventuali siti pubblicizzati nel testo. Suscita spesso molto interesse un prodotto (Bounce Spam Mail) che genera una risposta allo spammer del tutto simile a quella che i mail server inviano al mittente di una e-mail quando occorre segnalare che il destinatario richiesto non è conosciuto. Lo scopo è di indurre lo spammer a credere che l'indirizzo in questione non sia valido e, di conseguenza, a toglierlo dai propri elenchi. Può darsi che in qualche caso questo abbia effetto, tuttavia solo una piccola percentuale dei messaggi di spam ha un return path valido: in tutti gli altri 84

casi, il messaggio civetta non può arrivare a nessuno (o, peggio, a seconda di cosa lo spammer ha messo nel return path, potrebbe arrivare a qualcuno che non c'entra nulla). Inoltre, si può molto dubitare che qualche spammer abbia la pazienza di prendere nota di questi messaggi di ritorno al fine di tenere puliti gli elenchi.

Indice

<< Precedente

Successiva >>

Ultimo aggiornamento: 01 settembre 2002

Leonardo Collinelli

85

Qualche necessario strumento software Tool di rete classici

Per risolvere i casi di spam l'esperienza è sicuramente molto utile, tuttavia gli strumenti sono fondamentali. A completamento di quanto si è visto nella trattazione dei casi pratici, ora passeremo in rassegna le principali interrogazioni di cui ci si può avvalere. Operazioni DNS elementari Whois delle autorità di registrazione domini Whois della Abuse.net Whois delle autorità di assegnazione indirizzi IP Traceroute Query sulle blacklist Operazioni DNS complesse (dig) Operazioni DNS elementari Normalmente tra le prime operazioni che si compiono durante l'investigazione su uno spam c'è il lookup sul DNS. Il DNS diretto è quello che parte da un nome host per fornire il corrispondente indirizzo IP. Si tenga presente che ad un unico nome possono corrispondere più computer, ognuno con un suo indirizzo ip; in particolare, è normale che la query sul nome del mailserver di un grosso provider produca anche 7-8 indirizzi ip. Quanto al reverse DNS, ossia quello che parte da un indirizzo ip per fornire il corrispondente nome host, il discorso si complica. Va tenuto presente che, pur essendo talvolta gestiti da un medesimo soggetto, i DNS diretto e inverso sono non di rado competenza di soggetti diversi e non sempre sono allineati. Un reverse DNS (quando c'è, dato che in un'ampia percentuale dei casi manca del tutto) va sempre verificato eseguendo un DNS diretto sul risultato ottenuto. Si possono avere casi in cui spammer con una propria rete hanno facoltà di definire loro i reverse DNS e se ne avvalgono per fuorviare chi investiga (si parla allora di DNS forgery). In generale, per avere idea di cosa ci si può aspettare, va tenuto presente che colui che ha facoltà di definire il DNS diretto per un dominio può tranquillamente inserire nel proprio dominio nomi di host che, come indirizzo ip, puntino a computer o inesistenti o appartenenti ad altri soggetti che nulla sospettano. Analogamente, colui che ha facoltà di definire il reverse DNS per un blocco di indirizzi può ficcarvi corrispondenze a nomi di fantasia quanto nomi di host realmente esistenti e non suoi. Va inoltre tenuto presente che i dati DNS sono soggetti a caching e che quindi possono, in certe circostanze, fornire risultati contraddittori (tipicamente a fronte di aggiornamenti). 86

Un trucco usato dagli spammer Va segnalato che, mediante speciale programmazione dei propri server DNS, a volte gli spammer riescono a dare l'impressione che il loro sito si trovi non all'indirizzo a cui è realmente, bensì ad un altro indirizzo ip del tutto al di fuori della rete dello spammer. Questo stratagemma è alla portata solo degli spammer meglio organizzati tecnicamente e richiede l'utilizzo (abusivo, ovviamente) di un proxy insicuro che lo spammer abbia potuto trovare. Chi indaga su tali spam trova quindi, come indirizzo del sito, l'indirizzo che in realtà è del proxy. Il sito funziona in quanto il proxy accetta le richieste http e le trasmette al vero sito dello spammer. Risolvere questi casi è, per un normale utente, piuttosto difficile. Ci si può insospettire quando si constata che il sito dello spammer appare essere su un ip noto come proxy aperto e il dominio incluso nel nome del sito è servito da un server dns che stia in tutt'altro blocco di ip. In generale, se il sito dello spammer appare essere ad un indirizzo ip catalogato nelle blacklist di proxy aperti, conviene esaminare gli header della risposta http che si ottiene accedendo al sito in questione, cosa che si può fare tramite una connessione telnet aperta manualmente verso l'indirizzo apparente del sito dello spammer. Se tra gli header della risposta vi succedesse di notarne uno del tipo:

X-Cache: MISS from squidcache HIT from squidcache

oppure

X-Cache:

magari seguito da un header "Via:", con ogni probabilità siete incappati nel trucco (si noti che, al posto di "squidcache", possono comparire nomi di host o altre parole).

Whois delle autorità di registrazione domini Tra i dati relativi alla registrazione dei domini risultano interessanti i contatti e i name server. Vedere come si chiama e dove abita il titolare della registrazione di un dominio spesso può essere assai indicativo, dato che non è infrequente che gli spammer, dopo un certo periodo di attività intensa, comincino ad essere conosciuti per nome. Quando invece si tratta del dominio cui appartiene un relay aperto, se si sospetta di non riuscire a farsi adeguatamente sentire scrivendo al postmaster può essere opportuno cercare altri contatti utili. In mancanza d'altro, eventualmente si potrebbe provare ad avvisare il contatto tecnico trovato nella registrazione di dominio e, valutando caso per caso, anche il titolare del dominio (tenendo presente che quest'ultimo potrebbe spesso non avere la più pallida idea di cosa sia un server di posta). Riguardo alla indicazione dei name server, spesso da lì si riesce già a vedere chi sia il provider che fornisce hosting al dominio. Talvolta, si trova che i server DNS hanno un nome che rientra nel dominio in questione (per esempio, il dominio taldeitali.com potrebbe avere come nameserver ns.taldeitali.com). Per domini di un certo rilievo, può effettivamente succedere che gestiscano il proprio stesso DNS, tuttavia la cosa va verificata osservando l'indirizzo numerico del server, in quanto non è affatto un problema, per chi fosse titolare del dominio e potesse quindi definirne i nomi sotto DNS, creare nomi di suo piacimento e farli puntare, per esempio, agli ip dei server DNS del proprio provider. In altri casi niente affatto rari si troveranno domini che, anziché avvalersi del DNS del medesimo provider che fornisce loro la connettività, utilizzano i servizi di altre aziende, specializzate appunto nel fornire servizio DNS (pare che in questo modo si riesca ad avere un servizio 87

più affidabile e di migliore qualità rispetto al DNS tipicamente fornito da un provider generico, oltre al vantaggio di poter controllare e variare in maniera più semplice, diretta e completa il contenuto dei propri record DNS). È opportuno pertanto verificare sempre se la connettività e il DNS al dominio di uno spammer vengono forniti da un medesimo soggetto, dato che in caso contrario è utile reclamare ad entrambi. Si tenga anche presente che, nella registrazione di dominio, sono dati almeno due differenti name server: un primario (quello sul quale vengono manualmente apportati tutti gli aggiornamenti) ed un secondario (di solito aggiornato periodicamente in maniera automatica). Si può dire con sufficiente certezza che, tra il titolare del dominio ed il fornitore del DNS primario, esiste una qualche relazione di natura contrattuale; non così per il DNS secondario (o terziario, se c'è). Talvolta il DNS secondario viene affidato a grossi backbone o ad altri soggetti, magari in base ad accordi di mutuo scambio di questo servizio, stipulati senza la partecipazione diretta dei domini che ne risultano serviti. È quindi fuori luogo segnalare uno spammer a chi gli fornisce solamente servizio di DNS secondario. Va anche osservato che, per trovare chi sia a fornire servizio DNS ad un certo dominio, un'altra via in fin dei conti preferibile (almeno a titolo di verifica) è mediante il dig, di cui si parlerà tra poco. Ultima cosa da osservare è che per certi TLD nazionali (un esempio è '.tv') non esiste un whois server, oppure esiste ma non è liberamente consultabile. Problemi analoghi possono pure aversi per certi TLD dell'estremo oriente, per i quali la ricerca della corrispondente authority di registrazione si arena su pagine web piene di caratteri non visualizzabili. Anche in questi casi si deve fare affidamento sul dig. Whois della Abuse.net Una fase importante dell'investigazione, che può occasionalmente risultare anche complicata, è la determinazione del corretto indirizzo a cui inviare le segnalazioni per gli abusi relativi ad un dato dominio. È vero che l'indirizzo postmaster dovrebbe sempre esistere e venire letto, tuttavia in molti casi esistono indirizzi specifici che è meglio utilizzare. Determinare questi indirizzi può richiedere tempo, tempo che molti utenti si troverebbero talvolta a dover dedicare contemporaneamente per giungere al medesimo risultato. La Abuse.net centralizza quindi questa informazione, che viene inserita soprattutto dai vari postmaster direttamente, ognuno per quanto lo riguarda. Un tempo, era possibile scaricare dal sito della Abuse.net una enorme pagina con tutti i contatti, poi la dimensione di tale pagina è talmente cresciuta da rendere il download improponibile. Ora quindi i dati possono essere richiesti per un dominio alla volta, o tramite form sul sito della Abuse.net o tramite il relativo server Whois. Anche se oramai l'uso della Abuse.net è diventato abituale per chiunque agisca contro gli spam, appare sempre molto evidente quanto questa risorsa sia preziosa. Qualunque postmaster dovrebbe provvedere a registrare presso la Abuse.Net l'indirizzo di contatto per segnalare abusi dai domini di sua competenza. Whois delle autorità di assegnazione indirizzi IP Si tratta di ARIN, LACNIC, RIPE e APNIC, la cui consultazione è un passo inevitabile 88

quando occorre sapere qualcosa di più su un dato indirizzo ip. L'informazione relativa al blocco cui l'indirizzo sotto indagine appartiene è talvolta risolutiva ma ha bisogno di riscontri. Si deve infatti avere chiaro che le indicazioni sulla titolarità dei blocchi di ip possono talvolta non essere aggiornate e, soprattutto, possono non essere indicative. Non è impossibile che un blocco sia intestato ad una organizzazione la quale lo abbia assegnato ad un cliente, il quale cliente si sia poi trasferito sotto un'altra rete, portandosi dietro il blocco di indirizzi. È frequente in casi del genere che, consultando ARIN, il blocco risulti ancora intestato all'originale assegnatario, il quale non sarebbe quindi più il contatto giusto da considerare responsabile per le attività imputabili a quegli ip. Ci sono poi reti (normalmente grossi backbone) che, essendo intestatarie di grossi blocchi ip, li hanno poi a loro volta suballocati ad altre reti più piccole o clienti in genere, senza registrare sotto ARIN queste suballocazioni. Occorre allora individuare queste assegnazioni finali, cosa che per alcune reti (per esempio Exodus, Verio, Dialtone) si può fare mediante una query ai rispettivi rwhois. L'rwhois funziona in maniera analoga ad un normale server whois, salvo il fatto che utilizza la porta 4321 anziché la 43 e salvo il differente formato dell'output (peraltro abbastanza comprensibile). In generale, se l'informazione disponibile tramite questi whois ed rwhois è accurata e aggiornata, contiene molti dati e risulta di grande aiuto. Quando invece questa informazione non sia attendibile, resta ancora una volta da rivolgersi ai record DNS mediante dig. Gli "zombie" Un fenomeno le cui dimensioni sono in crescita è quello dell'utilizzo, da parte degli spammer, di blocchi di ip "zombie". In sostanza, lo spammer individua delle allocazioni di spazio ip effettuate molti anni prima, in favore di organizzazioni che nel frattempo hanno cessato le attività o che comunque non utilizzano più tali indirizzi. Allo stesso modo lo spammer può reperire pure degli Autonomous System non più in uso. Si trovano facilmente dei blocchi e degli AS con siffatte caratteristiche soprattutto (ma non solo) nello spazio di APNIC. Lo spammer riesce ad acquisire il controllo di tali risorse in vari modi, anche presentando documentazione falsificata. L'opera è poi completata generando annunci BGP per il routing e trovando un upstream provider compiacente che propaghi tali annunci. Alla base di questa pratica c'è sicuramente l'assoluto menefreghismo da parte delle authority di registrazione (che in genere, quando messe al corrente, restano abbastanza indifferenti) e il comportamento delle grosse reti che, o per inadeguatezza dei controlli o per vera e propria complicità, rendono funzionanti gli indirizzi zombie. Queste cose danno anche misura di quale sia la potenza economica dei grossi spammer. Per ciò che riguarda il normale utente che indaga sullo spam, ciò che possiamo consigliare è di verificare sempre ogni indirizzo ip sulle blacklist: i blocchi zombie sono infatti per la maggior parte noti e catalogati.

Traceroute Il traceroute è soprattutto uno strumento diagnostico, che consente di verificare quale percorso di rete viene seguito dai pacchetti in viaggio da una certa provenienza verso una certa destinazione. Il traceroute funziona sfruttando come segue il time-to-live assegnato a pacchetti ICMP. Il time-to-live è un parametro previsto dal protocollo ip e usato durante il percorso di un pacchetto da un host all'altro: ogni host che riceve il pacchetto provvede, prima di inoltrarlo al successivo host che deve riceverlo, a decrementare il time-to-live e controllare che non sia azzerato. Se fosse azzerato, considera il pacchetto scaduto e non gli fa proseguire il percorso. Lo scopo per cui esiste il time-to-live è di impedire che, in 89

situazioni di errore in qualche configurazione, si abbiano pacchetti che girino per la rete su percorsi chiusi e senza fine. L'host che esegue il traceroute inizia emettendo 3 pacchetti ICMP diretti all'host destinazione, nei quali il time-to-live è settato in modo che, appena ricevuti dal primo host del loro percorso, questo li debba considerare scaduti. Ne consegue che tale host, anziché passarli al successivo host del percorso, si limita a rispondere con un ICMP di errore al mittente. Il mittente registra quindi il tempo impiegato per ricevere questi ICMP di errore nonché l'ip dell'host che li ha emessi, e provvede a ripetere l'invio dei 3 pacchetti, settando però questa volta il time-to-live in modo che essi riescano a sopravvivere fino al secondo hop. Anche in questo caso otterrà i 3 ICMP di errore, i quali proverranno però dal secondo host, e così via, incrementando il time-to-live iniziale finché, eventualmente, si raggiungerà la destinazione richiesta. Ne risulta quindi un elenco di indirizzi ip che descrivono, nell'ordine, il percorso di rete seguito. Questo consente di vedere attraverso quali reti si passi per andare da un dato punto di partenza ad un punto di arrivo. Inoltre, i tempi di ritorno registrati sui vari hop consentono di valutare la qualità del collegamento e individuare quali siano i tratti che introducono i maggiori tempi di latenza. L'utilità di questo strumento ai fini dell'investigazione antispam risulta, nella pratica, non elevatissima, anche se in molti casi può risultare di aiuto, tipicamente quando con altri mezzi non si siano avute indicazioni del tutto chiare o quando, come che sia, si desideri una conferma a conclusioni che ormai si andassero profilando. Il ragionamento che sta dietro la decisione di provare un traceroute è del tipo: "se la rete X fornisce connettività allo spammer Y, allora eseguendo un traceroute verso Y mi aspetterei di vedere, subito prima delle risorse di Y, quelle di X." Se vedo quel che mi aspetto, ok. Se no, il traceroute comunque non costituisce una prova che quel certo collegamento non esista. Si tratterà di ripetere il traceroute da diversi punti di partenza, e magari questo porterà a scoprire più di un altro percorso, del tutto differente, che giunge alla stessa destinazione. Per eseguire traceroute da altri punti di partenza basta trovare siti che mettano a disposizione dei traceroute pubblicamente utilizzabili (una lunga lista si può trovare a http://www.traceroute.org/). Si tenga comunque presente che, se anche eseguite il traceroute da centinaia di punti di partenza da tutte le parti del mondo, i risultati non potranno mai dimostrare che un dato collegamento non esista. Riguardo alla lettura dell'output di un traceroute, bisogna tenere conto di alcune cose: ●

●

vanno scartati tutti gli hop che recano indirizzi non routabili, i cosidetti indirizzi intranet, che spesso nei traceroute compaiono. Non state dunque a perdere tempo su un 192.168.qualunque.cosa, o altri blocchi di cui si è detto in una precedente pagina di questo sito; non fidatevi dei reverse DNS che compaiono nei traceroute: specialmente per i 90

●

router, non sono quasi mai affidabili; il traceroute può essere bloccato e, peggio ancora, può essere falsificato. Il punto debole del traceroute, che lo espone al rischio di falsificazioni, è il fatto che gli indirizzi visualizzati sono quelli ricevuti nei pacchetti icmp di ritorno. Vale a dire, sono settati dalle varie macchine che li hanno generati, macchine che possono essere sotto il controllo di spammer. È già successo che degli spammer assegnassero entro la propria rete privata indirizzi non previsti per le reti interne, indirizzi che in particolare erano realmente assegnati ad altri soggetti da tutt'altra parte del mondo, e che tali macchine riportassero poi nei traceroute questi indirizzi ingannevoli. In un caso verificatosi nel marzo 2002 uno spammer riuscì a far credere che il suo sito, in realtà situato in Europa, fosse connesso attraverso un provider australiano. Si potrebbe dire che lo spammer aveva allestito una "finta Australia" nel proprio sgabuzzino e, inizialmente, riuscì a sviare molti reclami, che arrivarono ad un incolpevole provider australiano. Naturalmente fu ben presto scoperto.

Si può osservare che, non essendo attendibili i reverse DNS, risulta vantaggioso avvalersi di traceroute che forniscano, per ogni hop, anche il numero di Autonomous System cui quell'ip appartiene. Un esempio è il traceroute disponibile sul sito SamSpade.org (il sorgente di un traceroute con questa prerogativa è disponibile, per sistemi Unix, sugli archivi FTP del RIPE; inoltre questa ed altre funzionalità si possono trovare nel programma Looking Glass, disponibile pur esso presso vari siti). Disponendo del numero di AS si possono cercare i relativi dati su ARIN, LACNIC, RIPE o APNIC, avendo così una indicazione attendibile su quale sia la rete di appartenenza (anche se non certo a livello di microdettaglio, dato che gli AS vengono attribuiti solo a reti di una certa importanza). Seguendo questa linea, comunque, il discorso si fa complicato e richiede sempre più conoscenza di problematiche di routing. In genere, per problemi di spam basta meno. L'utilità di uno strumento come il traceroute, in definitiva, è che contribuisce a completare qualche pezzo del mosaico che rappresenta la situazione generale della rete a cui ci si sta interessando, mettendo magari in evidenza qualche collegamento secondario attraverso altre reti. Lo scopo per chi stia indagando su uno spam è, in effetti, quello di avere una visione della situazione generale, in modo da individuare dove, tra i vari soggetti che appaiono, esistano effettivamente relazioni di affari o di altro genere. Se la situazione non è chiara subito, non è lungo questa via che conviene insistere. Query sulle blacklist Testando specifici indirizzi rispetto alle blacklist si può spesso risparmiare lavoro e tempo. Per esempio, supponete di ricavare dagli header del messaggio di spam l'indirizzo da cui il server del vostro provider ha ricevuto il messaggio. Possono verificarsi vari casi: ●

●

Non compare in alcuna blacklist In questo caso occorre proseguire con l'indagine. Compare in una blacklist di relay aperti Di solito, vedere questo conferma ciò che già si sospettava dalla lettura degli header. È opportuno allora recarsi sul sito della blacklist, per vedere se fosse disponibile qualche messaggio archiviato relativo a quel relay. In particolare, MAPS-RSS tiene 91

●

●

●

in archivio sia il messaggio di spam che fu usato per la nomination, sia un messaggio di test col quale era stato accertato lo stato di apertura del server. Altre blacklist possono avere semplicemente il messaggio di test. Guardando il messaggio di spam potreste vedere che si tratta dello stesso spammer capitato a voi (succede più spesso di quanto si possa immaginare). Guardando il messaggio di test potete invece avere un'altra visione degli header inseriti dal relay, in modo da capire con certezza se riporta correttamente o no, e con quale sintassi, l'indirizzo di origine. Nella segnalazione al gestore del relay è ovviamente opportuno far notare che il suo server è già inserito in certe blacklist (fornendo anche le url dei relativi siti, dato che potrebbe facilmente trattarsi di un postmaster assai poco informato). Compare in una blacklist di proxy aperti In questo caso l'analisi degli header non può proseguire: la presenza del proxy rende inattendibile qualsiasi successivo 'Received' dato che, all'ultimo ip che si è individuato (appunto quello del proxy), il messaggio probabilmente è giunto attraverso altri protocolli che non SMTP; protocolli, quindi, che negli header non lasciano alcuna traccia. Quindi, anche se subito dopo si trovasse un 'Received' apparentemente congruente, non è possibile prenderlo in considerazione, dato che potrebbe essere stato messo lì a bella posta dal software dello spammer. Tenete infine presente che non è affatto impossibile incappare in un ip listato sia come relay che come proxy aperto. Quando ciò si verifica, occorre ovviamente ipotizzare il caso peggiore (ossia che sia stato usato come proxy). Compare in liste basate su criteri comportamentali In questo caso può trattarsi o di un relay aperto di cui risulta che il gestore non intende renderlo sicuro, o di una vera e propria sorgente di spam (es. una rete spamfriendly). In entrambi questi casi, non c'è molta utilità nel reclamare a chi di dovere: se per esempio l'indirizzo si trova in MAPS-RBL, sicuramente sono stati fatti convincenti tentativi per contattare qualche responsabile e non si è ottenuto nulla. Anche se l'indirizzo si trova in altre liste che elencano spammer famosi o reti di ben nota tradizione spam-friendly, non risulta molto produttivo spenderci tempo. In questi casi, conviene piuttosto chiedere al proprio provider di avvalersi di blacklist adeguate, dato che non esiste ragione al mondo per accettare email da chi, notoriamente, sta in rete solo al fine di spammare. Compare in liste di nodi dial-up Questo vuol dire che si tratta di un nodo dial-up, e che a tale ip si trovava lo spammer. Si possono quindi ignorare eventuali successivi 'Received:', dato che non recherebbero alcun significato. Se questo ip è entrato direttamente in contatto con il mail server del vostro provider, siamo di fronte ad un caso di spam direct-to-MX. Occorre inviare segnalazione alla rete titolare dell'indirizzo ip, e non è fuori luogo protestare con il proprio provider per il fatto che non sta usando liste per bloccare l'accesso diretto ai dial-up.

Operazioni DNS complesse (dig) Il DIG è un comando normalmente disponibile sui sistemi Unix. Tramite questo comando si effettuano query che si rivolgono ai server DNS, per richiedere varie tipologie dei record 92

in essi definiti. Un uso disinvolto del DIG richiede una conoscenza del DNS quale solo gli amministratori di rete (che effettuano queste definizioni come parte del loro quotidiano lavoro) possono avere. Tuttavia alcune di queste query hanno un significato sufficientemente chiaro e possono essere utilizzate da tutti. Un'analisi rigorosa dei record DNS sarebbe pesante ed esulerebbe dai nostri scopi, per cui qui ci si limiterà a far notare (semplificando e banalizzando il più possibile) unicamente un po' di cose che possono aiutare chi stia indagando su uno spam. In particolare, tra i record che possono avere interesse nelle investigazioni antispam menzioniamo i seguenti (guardando gli esempi riportati, si consideri che il formato e il contenuto delle risposte al comando possono variare in dipendenza dalla versione di DIG utilizzata e dalla completezza delle definizioni che si incontrano): MX Mail Exchanger. Questo record viene normalmente definito per i domini, in modo da indicare quale sia il mail server cui indirizzare le email dirette a caselle di un certo dominio. Un esempio del risultato di questa query su un nome dominio può essere il seguente: ; <<>> DiG 8.2 <<>> nomedominio.net mx ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3 ;; QUERY SECTION: ;; nomedominio.net, type = MX, class = IN ;; ANSWER SECTION: nomedominio.net. nome.net. nomedominio.net. nome.net.

2d16h55m55s IN MX

20 mailserver1.

2d16h55m55s IN MX

10 mailserver2.

;; AUTHORITY SECTION: nomedominio.net. 1d16h55m55s IN NS net. nomedominio.net. 1d16h55m55s IN NS net. ;; ADDITIONAL SECTION: mailserver1.nome.net. mailserver2.nome.net. ns1.altronome.net.

ns1.altronome. mailserver1.nome.

8h13m30s IN A 15h16m19s IN A 8h13m30s IN A

192.0.2.35 192.0.2.36 192.0.2.120

Qui si vedono indicati (nella Answer section) gli host che fanno da mail exchanger 93

per il dominio "nomedominio.net" (ne sono indicati due con differente priorità). Pertanto, inviando email a [email protected] il messaggio verrà consegnato al primo di quei due host disponibile. La stessa query indica poi i name server autorevoli per il dominio in questione (Authority Section) e, nell'ultima sezione, gli indirizzi ip corrispondenti a tutti i server indicati nelle precedentementi sezioni. NS Name Server. A seconda della query, questo record indica quale sia il server DNS autorevole per un dato dominio. Normalmente comunque può essere che, come si è visto sopra, la query MX per un dominio già contenga l'informazione relativa ai name server, nel qual caso questa query non porta risultati aggiuntivi utili per una investigazione antispam. La query NS può essere effettuata anche su un indirizzo ip, nel qual caso fornisce generalmente la Authority section relativa all'indirizzo specificato. Per vedere un esempio di authority section rimandiamo al successivo punto, riguardante le query SOA. SOA Start Of Authority. Con questa query si può individuare chi ha autorità sulle definizioni relative ad una certa risorsa, sia essa un dominio o un indirizzo ip completo o parziale. Si riesce anche a vedere a quale livello esattamente sia stabilita l'autorità. Nell'esempio che segue è stato fatto un dig SOA sull'indirizzo 12.1.2.3: ; <<>> DiG 8.2 <<>> soa -x ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; 3.2.1.12.in-addr.arpa, type = SOA, class = IN ;; AUTHORITY SECTION: 2.1.12.in-addr.arpa. 2h59m31s IN SOA cbru.br.ns.elsgms.att.net. hostmaster.mail.att.net. ( 2 ; serial 1D ; refresh 2h46m40s ; retry 6d22h40m ; expiry 1D ) ; minimum L'indirizzo oggetto di questa query è di AT&T (cui appartiene l'intera classe A degli indirizzi inizianti per "12."). Si presti attenzione a ciò che compare come oggetto del record, in questo caso il "2.1.12.in-addr.arpa." qui evidenziato in rosso: da lì si nota che lo start of authority qui indicato vale per tutti gli indirizzi inizianti per 94

"12.1.2." (ciò che precede "in-addr.arpa" va rovesciato per assumere significato come indirizzo ip). I dati interessanti visibili in questo ouput sono due: ❍ cbru.br.ns.els-gms.att.net. che è il nome del nameserver primario per quel record di authority ❍ hostmaster.mail.att.net. che è un indirizzo di email (il punto che segue "hostmaster" sta a rappresentare la @). Va da sè che si tratta di un indirizzo da non usare per segnalazioni di abusi, dato che corrisponde semplicemente alla persona responsabile per il nameserver. Altro esempio, questa volta relativo al SOA su un nome di dominio: ; <<>> DiG 8.2 <<>> linux.it soa ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 6 ;; QUERY SECTION: ;; linux.it, type = SOA, class = IN ;; ANSWER SECTION: linux.it. 1D IN SOA spock.linux.it. postmaster. linux.it. ( 2000122001 ; serial 2H ; refresh 15M ; retry 6W ; expiry 1D ) ; minimum

;; AUTHORITY SECTION: linux.it. 1D IN NS linux.it. 1D IN NS linux.it. 1D IN NS linux.it. 1D IN NS linux.it. 1D IN NS

spock.linux.it. ns2.publinet.it. dns2.nic.it. ns.vitaminic.net. dns.mixadlive.com.

;; ADDITIONAL SECTION: spock.linux.it. 1D IN A 151.99.137.27 spock.linux.it. 1D IN AAAA 3ffe:1001:210:1::1 ns2.publinet.it. 1D IN A 151.99.137.5 dns2.nic.it. 1d22h17m23s IN A 193.205.245.8 ns.vitaminic.net. 2h49m5s IN A 209.207.238.101 dns.mixadlive.com. 1d22h46m54s IN A 213.254.5.3 Il risultato di questa query va letto in maniera del tutto analoga a quello 95

precedentemente esaminato, salvo che qui il record SOA compare entro una Answer section, mentre la Authority section elenca i server DNS autorevoli per il dominio oggetto della query. Si noti che uno dei name server elencati possiede, oltre al normale indirizzo ip, anche un indirizzo IPv6 (quel 3ffe:1001:210:1::1, notazione a cui prima o poi bisognerà iniziare ad abituarsi). ALL Questa query, utilizzabile essenzialmente su indirizzi IP, dà come risultati vari tipi di record DNS, il che la può rendere utile in molti casi. Per esperienza può capitare che dalle query SOA o NS non si riesca a ricavare molto (non tutte le reti, purtroppo, tengono perfettamente in ordine le definizioni DNS) e che, in questi casi, la query ALL sia l'unica che consente di vedere dei dati e individuare quindi il soggetto competente su una certa risorsa. ; <<>> DiG 8.2 <<>> all -x ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUERY SECTION: ;; 27.137.99.151.in-addr.arpa, type = ANY, class = IN ;; ANSWER SECTION: 27.137.99.151.in-addr.arpa. ;; AUTHORITY SECTION: 137.99.151.in-addr.arpa. 137.99.151.in-addr.arpa.

1D IN PTR

1D IN NS 1D IN NS

spock.linux.it.

ns.publinet.it. dns.interbusiness.it.

;; ADDITIONAL SECTION: ns.publinet.it. 1D IN A 151.99.137.2 dns.interbusiness.it. 4h29m26s IN A 151.99.125.2 Qui non compare il record SOA, ma nella Answer section compare il record PTR (quello tramite il quale vengono definiti i reverse DNS sui singoli indirizzi ip). La Authority section elenca i server DNS autorevoli per l'indirizzo in questione: si nota in proposito che l'autorità di tali nameserver è data per tutto il blocco 151.99.137.* (al solito rovesciando ciò che precede "in-addr.arpa"). Trovare i server DNS autorevoli per un blocco di IP (in altre parole, quei server da cui dipendono i reverse DNS su quel blocco di IP) è, in certi casi, l'unica informazione che aiuta a capire con chi prendersela per qualcosa che è stato fatto da un certo indirizzo ip. È il caso di quando dalle query su ARIN o RIPE non si ricavassero informazioni sufficienti. Sarebbe in linea di principio normale che i server trovati per un certo indirizzo fossero della stessa organizzazione intestataria del relativo blocco ip, ma ciò può benissimo non accadere. A fronte di divergenze non c'è una regola generale su come 96

comportarsi, tuttavia il possessore dei name server ha certamente un notevole grado di autorità sull'indirizzo in questione e, eventualmente, potrebbe anche avere una relazione d'affari con l'intestatario del blocco ip. Va infine tenuto presente che un dig può venire rivolto a qualsiasi name server (sarà suo compito rivolgersi ricursivamente al nameserver autorevole per la risorsa sotto indagine). Se però il risultato ottenuto non apparisse convincente o si volesse riscontro, esiste normalmente la possibilità di dirigere la query direttamente su un name server specifico. Si avrà cura, in questi casi, di sceglierne uno che si suppone autorevole per quel dominio o indirizzo ip. Questo artificio può, in teoria, sgombrare il campo di vecchi dati in cache, tuttavia solo in qualche caso risulta utile.

Indice

<< Precedente

Successiva >>

Ultimo aggiornamento: 02 giugno 2003

Leonardo Collinelli

97

Le liste di blocco Alcune delle liste di blocco disponibili

Va subito detto che la situazione delle liste di blocco non è mai ferma, dato che ne nascono e se ne chiudono in continuazione. Piuttosto quindi che dare un elenco (che sarebbe forzatamente incompleto e dovrebbe essere aggiornato una o due volte al mese) è utile descrivere quel che è accaduto in modo da avere gli elementi per orientarsi nella situazione attuale. Cominciamo quindi col dire che, inizialmente, gli amministratori di rete allestivano liste per farne essenzialmente un uso interno alla propria organizzazione. Tra le prime liste che furono rese pubbliche e assursero ad una vasta notorietà e diffusione ci fu RBL (Realtime Blackhole List), gestita dal MAPS (Mail Abuse Protection System).

MAPS MAPS nacque come gruppo attivo entro una azienda californiana, Vixie Enterprises. Tale azienda, guidata da Paul Vixie, tra l'altro collabora con organizzazioni quali l'ISC e l'IETF, la cui importanza nello sviluppo tecnologico della rete e nella definizione degli standard non necessita di presentazioni. RBL è una lista di indirizzi e blocchi che, in base a certi criteri, risultano essere a disposizione di spammer. Tale lista è distribuita sia come zona dns che sotto forma di BGP. L'utilizzo tramite BGP agisce sui router delle reti che hanno scelto di servirsene e quindi, pur essendo meno diffuso di quello tramite DNS, provoca limitazioni alla connettività anche per il traffico non email (per esempio, il traffico web dei siti promossi mediante spam o che diffondano software per spammer, o i relativi nameserver). Il sito del MAPS è rivolto essenzialmente agli amministratori di rete, ma di molte pagine si può raccomandare la lettura a chiunque. In particolare la pagina di spiegazioni (Rationale) tratta, tra l'altro, il concetto di "furto di servizio" e confuta le mistificazioni in base alle quali inviare spam sarebbe esercizio della libertà di parola o di commercio. Caratteristica importante di MAPS-RBL è l'intento di educare, cercando il più possibile il contatto diretto (anche telefonico) con le reti inadempienti, cercando di persuaderle ad un comportamento corretto e giungendo al listing solo in caso di insuccesso. Altra pagina importante nel sito di MAPS è quella che tratta il problema dei relay aperti (TSI, Transport Security Initiative). Oltre alla spiegazione del problema, vengono descritte le soluzioni tecniche per rendere sicura la configurazione: una apposita pagina prende in esame tutti i più diffusi software oggi in uso sui mailserver, per praticamente tutti i sistemi operativi. Viene anche fornito uno strumento on-line che consente, a ciascun amministratore di mail server, di verificare se il proprio server presenta questo pericoloso 98

inconveniente. Ai postmaster in difficoltà perché improvvisamente si rendono conto di avere un mail server aperto e non hanno idea di come chiuderlo, si può senz'altro consigliare di leggere la pagina http://www.mail-abuse.org/tsi/ar-fix.html (e, naturalmente, di cercare nei cassetti quel maledetto manuale del loro server). Nel tempo, MAPS ha anche iniziato a fornire una lista di relay aperti (RSS), gestita col concetto di includere gli indirizzi solo per quei server da cui fosse provata la provenienza di spam, accettando segnalazioni adeguatamente documentate e senza mai effettuare test su server per i quali non fosse data una regolare segnalazione. RSS era nato da una idea di Al Iverson e, grazie all'efficacia nel bloccare un enorme quantitativo di spam e grazie ad una percentuale non troppo alta di falsi positivi, guadagnò presto una discreta popolarità, venendo quasi ovunque preferito a ORBS, un'altra lista di relay aperti a quel tempo ben nota e che agiva, a differenza di RSS, andando in giro per la rete in maniera automatizzata a cercarsi i relay aperti, mediante test di qualsiasi mail server riuscisse a individuare. L'approccio di ORBS, forse anche perché accompagnato da certe spigolosità nella gestione, fu a lungo controverso. Quando nel maggio 2001, per problemi della persona che lo gestiva, ORBS chiuse, nacquero molti altri sistemi analoghi che si affiancarono a RSS. Un'altra lista fornita da MAPS è DUL, una lista di dial-up nata da una idea di Gordon Fecyk. A quel tempo il direct-to-MX impazzava, e DUL rovinò le giornate di parecchi spammer. I meriti di MAPS e i problemi che ha incontrato In complesso, l'opera svolta da MAPS è stata sicuramente meritoria: ha fatto dell'idea delle blacklist uno strumento concreto, efficace e a disposizione di tutti. Ha codificato gli argomenti in base ai quali condannare lo spam, ha educato chi era educabile e ha ridotto la connettività di chi non lo era. La dose di sacrificio personale di Paul Vixie e del suo gruppo fu notevole. Al di là dello sforzo economico (continuato per lungo tempo), si deve considerare ogni forma di disagio a cui Vixie e le altre persone di MAPS sono andate incontro per via delle reazioni ostili degli spammer che, per citare solo i dispetti più innocui (ma ce ne sono stati ben di peggio), li hanno molestati per telefono, insultati e paragonati a Hitler sulla stampa e sui mezzi radiotelevisivi. La comunità antispam appoggiò MAPS e contribuì ad arricchirne i database con significativi sforzi di molti, che scrissero nomination per segnalare sia relay aperti a RSS che reti spam-friendly a RBL. Nel tempo, comunque, emersero disagi generalizzati, dovuti ad aspetti come la difficoltà di scrivere nomination che avessero successo e la mancanza di qualsivoglia riscontro. Molti si impegnavano facendo del proprio meglio nel segnalare vari soggetti che fornivano risorse di rete a spammer, non ricevevano alcuna risposta e constatavano che spamhaus anche delle peggiori non venivano listate o venivano listate dopo molto tempo. In realtà, MAPS stava avendo problemi non solo di sottodimensionamento e di finanziamento, ma l'approccio stesso del "tentativo di educare" si stava rivelando sempre 99

più inefficace e inadeguato ai tempi. Purtroppo, nella rete di oggi si sta rivelando sempre più importante il denaro, non importa come ottenuto, e sempre meno importante il fatto di essere dei buoni "vicini di casa". Ciò che poi ha fatto precipitare la situazione per MAPS è stata, paradossalmente, la "giustizia". Infatti, operare contro lo spam a quei livelli significa mettersi talvolta contro organizzazioni di una certa potenza, organizzazioni in grado di pagare buoni avvocati e di portare in tribunale il gestore di una blacklist con l'accusa di ostacolo al commercio. Qualunque persona di buon senso vede l'assurdità di una azione legale in quei termini: ●

●

Innanzitutto non è vero che il gestore di una blacklist ostacoli la circolazione delle email di chicchessia. Le email vengono effettivamente bloccate dalle reti a cui sono destinate, quando i rispettivi gestori liberamente decidono di usare questa o quella blacklist al fine di filtrare il traffico SMTP in arrivo ai propri server. Si tratta, dunque, di soggetti che prendono le decisioni a loro parere più opportune in merito alla gestione di risorse che sono di loro proprietà. Essere un provider o un backbone in Internet non significa affatto che si stia eseguendo un servizio pubblico. Ogni provider o backbone è vincolato solo ai contratti che sottoscrive con altri, e se decide di rifiutarsi di accettare o veicolare del traffico, nessuno, neanche un tribunale, gli può imporre di fare diversamente, almeno finché si è in uno stato di diritto. Il gestore di una blacklist, in fondo, non fa altro che pubblicare una propria opinione (nel caso, qualcosa del tipo: i seguenti indirizzi IP a me non piacciono e quindi rifiuto il traffico che da essi proviene). Nulla è detto sull'uso che di tale opinione può essere fatto da altri. Caso mai ci dovremmo aspettare dalla legge una protezione del diritto di MAPS (o di chiunque altro) di rendere pubblica la propria opinione in merito a qualsiasi cosa o indirizzo presente in rete.

Per fare un paragone, pensate ad una guida turistica contenente le recensioni di vari ristoranti. Presumibilmente a proposito di qualche ristorante sarà scritto, per esempio, che vi si spende molto e si mangia male. Può in un caso del genere il ristoratore fare causa all'editore della guida, per esempio con l'accusa di ostacolare il libero commercio o danneggiare gli interessi della sua attività commerciale? Ci mancherebbe altro: chiunque legga la guida può decidere se fidarsi o no di quel che vi trova scritto, ed è sempre libero anche di entrare in un ristorante sconsigliato. Possono sembrare cose ovvie, tuttavia molte organizzazioni listate in RBL iniziarono a rivolgersi ai tribunali e ad ottenere quasi sempre delle ingiunzioni provvisorie, nelle quali la corte ordinava a MAPS di sospendere il listing degli indirizzi IP del ricorrente. Non mi consta che si sia arrivati a decisioni definitive, tuttavia una situazione di questo genere risultava già assai pesante per una organizzazione come MAPS, costretta a spese ingenti per liti giudiziarie sempre più frequenti. MAPS aprì un fondo di difesa legale, ed iniziò a fornire a pagamento un servizio di mail forward filtrato, nel tentativo di raccogliere fondi. Al tempo stesso, si trovò costretta ad aprire trattative con le controparti e a cercare accomodamenti extragiudiziali. Talvolta questi accomodamenti restavano segreti, il che generava perplessità e confusione tra gli antispammer. 100

Nonostante tutti gli sforzi, MAPS comunque non riuscì a proseguire secondo l'impostazione originaria e, a partire dall'1 agosto 2001, trasformò ogni accesso alle proprie liste da libero per chiunque a riservato ai sottoscrittori (circa in quel periodo, si ebbe l'uscita da MAPS dell'originario fondatore Paul Vixie). Da allora, quindi, per usare RBL, RSS o DUL occorre firmare un contratto con MAPS e pagare un canone, anche se per piccoli server gestiti a livello amatoriale esiste la possibilità di richiedere l'utilizzo gratuito (è però necessario avere un indirizzo IP dedicato e fisso nel tempo). La fine del libero accesso alle liste di MAPS ha cambiato molte cose. Di certo la quasi totalità degli utilizzatori non era sottoscrittore, e non sembra che molti di loro abbiano deciso di diventarlo per continuarne l'uso. Altrettanto chiaro è che molti antispammer smisero di generare nomination. Quello che si è constatato in pratica è stato che gli utilizzatori di RBL/RSS/DUL sono molto diminuiti e che l'efficacia del servizio ai fini della protezione antispam è progressivamente diventata trascurabile, almeno se vista in termini di valore aggiunto rispetto alle altre liste pubblicamente disponibili. Oggi quindi l'importanza di MAPS è solamente storica.

Il "DOPO-MAPS" Era prevedibile che, venendo meno la possibilità di usare liberamente quella che era ormai divenuta la lista di riferimento, molte altre liste nuove venissero create per soddisfare una esigenza più sentita che mai. Fondamentalmente, le possibilità di scelta per gli amministratori di rete sono diventate più numerose e articolate. Cambia l'atteggiamento che si richiede agli amministratori di rete: prima, era possibile attivare RBL, RSS, DUL in congiunzione con una blacklist ed una whitelist locali, senza più porsi particolari problemi. Ora l'amministratore deve verificare in continuazione se le liste che ha scelto di usare sono le più indicate al suo caso o se, ad un certo momento, gli convenga modificare le proprie scelte. Ogni rete è quindi più responsabilizzata nell'adottare soluzioni a difesa dei propri utenti dallo spam. Inoltre, qualcosa è cambiato in peggio per gli spam-supporter: se prima ogni rete che veniva listata in RBL poteva ristabilire in pieno la propria connettività ottenendo (dopo la soluzione dei problemi) la cancellazione dalla lista, ora il discorso è meno semplice, in quanto i suoi IP potrebbero essere inclusi in varie differenti liste e, pertanto, occorre ottenere la cancellazione da tutte. Vediamo dunque quali sono le liste più conosciute. Per comodità le suddividiamo in categorie anche se, in vari casi, si hanno liste classificabili in più di una categoria. In generale, a chiunque intenda diventare utilizzatore di liste di blocco (quelle qui indicate o altre) raccomanderemmo soprattutto una cosa: tenersi costantemente informato sulla situazione. Può infatti accadere che una lista oggi consigliabile diventi inefficace o addirittura sconsigliabile tra qualche mese, o che cessi di esistere improvvisamente. Analogamente può comparire da un giorno all'altro una nuova lista che, per qualche motivo, riesca ad essere particolarmente efficace e valga quindi la pena di adottare. 101

Liste di relay e/o proxy aperti Già nel corso del 2002, l'importanza dei relay aperti come mezzo per la diffusione dello spam ha iniziato a diminuire, fino a diventare marginale, preferendo gli spammer avvalersi dei proxy. Prima di effettuare le proprie scelte è importante leggere bene le policy pubblicate sui siti delle varie liste e, magari, sperimentarle per un certo periodo vedendone gli effetti sui log dei server. Al momento di scegliere una lista di open relay, una delle prime cose da controllare è certamente la politica nei confronti dei relay multihop. Infatti bloccare anche gli smarthost significa generalmente rischiare improvvisi picchi di falsi positivi. ●

●

●

●

ORDB http://www.ordb.org/ Importante lista (con sede in Danimarca) di relay aperti single-hop. Rende disponibili i messaggi di test che hanno evidenziato lo stato di apertura di ciascuno dei server listati. Distributed Sender Boycott List http://dsbl.org/ Lista che censisce sia relay che proxy aperti, utilizzando un singolare sistema di test che si può definire delegato. Anche qui è disponibile sul sito precisa documentazione dei test che hanno causato il listing. Not Just Another Bogus List http://www.njabl.org/ Si tratta di una lista assai eterogenea, in cui troviamo listati relay aperti, proxy insicuri, sorgenti di spam generiche e indirizzi ip assegnati dinamicamente. La categoria in cui ricade ciascun ip listato si può ricavare dall'indirizzo di ritorno della query dns con cui si interroga la lista. Per l'uso occorre prestare attenzione al fatto che possono essere listati, per quanto con opportune precauzioni, anche relay multihop. I messaggi di test dei relay sono resi disponibili sul sito. Composite Blocking List http://cbl.abuseat.org/ Questa lista viene mantenuta per mezzo di spamtrap. Secondo procedimenti che non vengono resi noti in dettaglio, sono listati gli indirizzi ip da cui è provenuto spam e che presentano caratteristiche specifiche dei proxy insicuri di vari tipi. Per ogni listing non viene resa disponibile altra informazione se non la data e ora in cui quell'indirizzo è stato individuato. È inoltre specificato che tutti i listing vengono automaticamente rimossi dopo un certo tempo.

Liste di blocchi adibiti a dial-up Le liste di dial-up o, per essere più precisi, le liste di indirizzi ip che vengono allocati dinamicamente agli utilizzatori, basano la loro ragion d'essere su varie considerazioni. Innanzitutto non è normale che un vero e proprio mailserver, che esegua un servizio legittimo, si trovi su un ip variabile nel tempo. Inoltre, si è constatato che sugli ip dinamici si trovano, nella quasi totalità dei casi, macchine non gestite da amministratori qualificati. Queste macchine, il più delle volte, vengono sbrigativamente installate, collegate in rete (es. su adsl residenziali) e poi del tutto dimenticate. Non stupisce quindi che queste macchine siano tipicamente affette da seri problemi di security (a cominciare dai proxy 102

aperti) ed è verificabile ogni giorno come gli abuse desk che dovrebbero sorvegliare questi spazi ip risultino, alla prova dei fatti, largamente inefficaci nel risolvere i problemi creati da utenti su ip dinamico. Per questi motivi, oggi, tra gli amministratori di posta elettronica decisi a fermare lo spam in arrivo, l'opinione prevalente concorda sull'opportunità di bloccare senz'altro questi spazi ip: il risultato concreto è il rigetto di moltissimo spam, praticamente senza falsi positivi. La prima lista di ip dinamici da citare è PDL, nata su iniziativa del già citato Gordon Fecyk, certamente persona di grande e provata competenza nella gestione di una lista di dial-up. Un'altra lista di ip dinamici è Dynablocker, gestita dal provider olandese Easynet.nl e resa pubblicamente disponibile. Liste di indirizzi o blocchi lasciati a disposizione di spammer ●

●

SBL (Spamhaus Block List) http://www.spamhaus.org/ Si tratta di una lista creata e gestita in Inghilterra da Steve Linford, antispammer da molti anni e con grandissima esperienza. Visitando il sito dello Spamhaus Project, nel cui ambito è nata SBL, non si finisce mai di sorprendersi per la quantità e la qualità del lavoro che Steve ha svolto, individuando un grosso numero di centrali dello spam, raccogliendo informazioni su di esse e organizzando il tutto in un database online, che chiunque può agevolmente consultare per sapere chi c'è dietro lo spam che si vede arrivare ogni giorno. Tutto questo in base alla convinzione, che Steve ha anche espresso in varie interviste, che esista un numero relativamente ridotto di grossi spammer che sono responsabili per la quasi totalità dello spam in circolazione. Ecco dunque che, per i peggiori spammer, sul sito Spamhaus.org si trova ogni evidenza, dati sui netblock utilizzati, sui backbone che li connettono e così via, talvolta anche sul profilo criminale (non raro e tutt'altro che sorprendente nella vita reale degli spammer). Su questo database continuamente aggiornato è costruita appunto SBL, lista che ha tra le proprie caratteristiche una particolare attenzione a non provocare inutilmente falsi positivi e una focalizzazione rivolta alle spamhaus di maggiori dimensioni e importanza. Nel tempo l'efficacia di SBL per bloccare lo spam è diventata formidabile e, grazie alla gestione molto attenta che la lista ha avuto negli anni, risulta assai difficile che possa causare problemi a chi la utilizza. Spamware Vendor List http://www.spamsites.org/ Questa è un'altra lista basata in Inghilterra, curata da "Sapient Fridge", che da lungo tempo cerca e censisce i siti che diffondono ogni genere di software e servizi rivolti agli spammer. Si tratta dei cosidetti spamware, che includono, oltre ai prodotti di bulk-email veri e propri, anche i software per raccogliere indirizzi di email (es. dai newsgroup o dai siti web), i servizi di bulk-email non opt-in, la vendita di indirizzi di email estratti dalla rete e ogni altra fornitura specificamente pensata per gli spammer. Questa lista può tuttavia far bloccare una quantità piuttosto ridotta di spam. Nella pratica è poco usata, anche perché non gode di una efficiente 103

●

●

distribuzione via dns. Blackholes di Easynet Nederland http://abuse.easynet.nl/blackholes.html Si tratta di una lista assai popolare tra gli amministratori di email, che elenca ip classificati come sorgenti di spam per varie ragioni. Include anche una lista di proxy aperti e macchine compromesse da trojan degli spammer. SPEWS (Spam Prevention Early Blocking System) http://spews.org/ Spews è una idea innovativa nel mondo delle liste di blocco, e mira a risolvere gli inconvenienti che si erano lamentati in MAPS RBL. Innanzitutto è impossibile dire dove sia basata in quanto, a differenza di quanto accade per altre liste analoghe, i curatori si mantengono nell'anonimato. Quel che si sa è che si tratta di un certo numero di amministratori di rete, in parte americani ma probabilmente anche di altre parti del mondo. Quello che Spews vuole evitare è che, dal momento in cui uno spammer viene scoperto, passi un lungo tempo prima che tale spammer venga neutralizzato: ogni giorno in cui lo si lascia operare indisturbato sarebbe infatti per lui solo una opportunità di trarre profitto a spese di tutti. Spews quindi individua e lista gli spammer appena aprono bottega e, in qualche caso, prima ancora. Se, infatti, un famoso spammer cacciato da un provider si trasferisce su un altro, che ragione c'è di attendere che abbia ricominciato a spammare prima di bloccarlo di nuovo? Particolarità di Spews è che non accetta nomination (i curatori hanno già modo, durante il loro lavoro di postmaster e, a quanto si racconta, grazie all'uso di spamtrap, di scoprire velocemente un gran numero di spammer) e non accetta email dirette. Non essendo possibile contattarli direttamente non sono quindi neanche possibili quegli accordi più o meno segreti che così poco piacevano ai tempi di MAPS. Risulta anche assai problematico citare Spews in giudizio, dato che non è un soggetto chiaramente individuabile: si potrebbe dire che Spews è solo una lista che circola tra gli amministratori di rete interessati ad adoperarla e che può venire mirrorata in vari paesi del mondo nel giro di pochi minuti. La lista è utilizzabile in vari modi: query dns, grazie ad alcune reti che la rendono disponibile, o mediante il download dei file di zona, in modo da potersi costituire un proprio mirror privato. Si deve tenere presente che le liste Spews sono due: level1 e level2. Di queste, la prima è la lista di blocco vera e propria, la seconda è da intendersi come una lista di ip sotto osservazione, di cui non si consiglia l'uso per il blocco del traffico email. Il provider che si ritrovasse incluso in Spews e volesse essere tolto dalla lista deve quindi parlarne in pubblico, su adeguati forum come ad esempio news.admin.netabuse.email. Nessuno gli risponderà a nome di Spews, ma sicuramente molti gli chiederanno conto, per esempio, di eventuali abuse report ignorati o, soprattutto, del fatto che lo spammer tal dei tali sia ancora felicemente attivo su un loro netblock. Ciò che è cambiato rispetto alla prassi del MAPS è soprattutto questo, che il vecchio concetto dell'educare, spiegare pazientemente, dare tempo, qui non si applica più. Il provider che si ritrova un proprio netblock in Spews deve per prima cosa risolvere il problema (ossia liberarsi di tutti i suoi spammer e far funzionare l'abuse desk), poi se questa opera di pulizia sarà risultata completa e convincente, allora il listing verrà tolto, a tempo opportuno (di solito, comunque, il delisting avviene in tempi molto rapidi). Ovvio che, se lo spammer non viene cacciato dal provider, quel netblock è 104

destinato a rimanere listato per sempre, e nessuno potrà fare alcunché per farlo togliere. Anzi, se lo spam continua, il blocco listato da Spews crescerà di dimensioni (sempre rimanendo, ovviamente, nell'ambito dello spazio ip che è sotto la responsabilità del medesimo provider). I file di evidenza leggibili sul sito di Spews spesso mostrano questi casi di escalation: all'inizio in genere vengono listati pochi ip, che sono risultati direttamente coinvolti in qualche spam, dopo qualche tempo può essere listato, secondo i casi, tutto il "/24" (ossia 255 indirizzi contigui), poi, in caso lo spam continui e il provider titolare degli indirizzi resti inerte, i blocchi listati diventano ancora più grossi (per es. dei "/20" o "/19"). Talvolta, queste escalation finiscono con l'includere pure indirizzi usati da utenti o reti che, pur essendo clienti del medesimo provider, sono estranei allo spam. Si tratta di una caratteristica insita nel modo di funzionare di Spews, prevista per varie ragioni. Per esempio, impedire che il provider cerchi di aggirare i blocchi spostando lo spammer su indirizzi non ancora listati, o usando altri clienti come un sorta di "scudi umani" (cose che da sempre capita di veder fare). Inoltre, dato che buona parte del problema spam è di natura economica, per certi provider solo una buona ragione economica può indurli a rinunciare al denaro degli spammer (per esempio, il fatto che i clienti nonspammer se ne vadano altrove). Prima che questo approccio venisse messo in pratica da Spews, si notava che nella maggioranza dei casi il listing dei soli ip degli spammer non riusciva a incidere sulla situazione: per lo spammer, quello che conta è mantenere le risorse di rete a lui necessarie (es. siti web e nameserver) e il fatto di avere in uso, per tali risorse, degli ip soggetti a listing, non procura grossi problemi. Quanto al provider, un listing limitato agli ip dello spammer non fa né caldo né fresco, dato che non gli impedisce di continuare a guadagnare sia sullo spammer che sugli altri clienti. È dunque una politica di gestione della lista che certuni talvolta giudicano alquanto aggressiva. In realtà è solo una politica molto ferma, l'unica che può arrivare a certi risultati anche in situazioni particolarmente problematiche. Chi si trova da tempo sul fronte della lotta allo spam ha ormai dovuto amaramente constatare che l'approccio paziente ed il fair-play nei confronti dei provider spam-friendly è una scelta perdente. Il provider dello spammer, in troppi casi, tende soprattutto a cercare di guadagnare tempo nell'attesa che le acque si calmino, senza far nulla in concreto. In questi casi "educare" è inutile, l'unico risultato è vedersi raccontar balle, intanto che lo spammer fa i propri affari. Le reti più irresponsabili si erano ormai abituate a vedersi dare la possibilità di discutere, di trattare, di affermare di aver provveduto quando in realtà non avevano fatto nulla. Da quando c'è Spews, questo andazzo sta finendo. Come è stato detto, Maometto non va più alla montagna: ora è la montagna che deve andare da Maometto. In effetti, i risultati hanno subito iniziato a dare ragione a questo nuovo approccio. Da quando Spews ha iniziato a venire utilizzata anche da alcuni provider americani di primaria importanza, si è visto per la prima volta che perfino certe reti, tradizionalmente spam-friendly e sorde ad ogni reclamo, hanno iniziato a cacciar via i loro spammer con insolita sollecitudine. Non a caso il sito di Spews è sovente soggetto ad attacchi che lo rendono irraggiungibile anche per lunghi periodi (non dimentichiamo che gli spammer sono, tecnicamente parlando, dei criminali informatici). Per ciò che riguarda l'utilizzo di Spews per 105

●

bloccare lo spam, è certamente molto efficace. Ci si deve comunque aspettare, di tanto in tanto, qualche situazione che necessiti di essere gestita. The South Korea blocking list http://korea.services.net/ Come molti utenti, anche italiani, hanno avuto modo di constatare ampiamente, dalla Corea giunge spam in quantità massiccia, e i tentativi di segnalarlo agli abuse competenti appaiono essere inutili. Si tratta sia di spam locale (riconoscibile per il fatto di contenere testi in un charset non visualizzabile sui computer occidentali) che di spam americano o di altra provenienza (pure italiana!). In particolare, in Corea abbondano i proxy insicuri: gli spammer lo sanno e li usano. Se si pensa che il flusso di email legittime dall'estremo oriente ai paesi occidentali è molto ridotto (per lo più riguarda le poche aziende in affari con i paesi orientali), appare del tutto prevedibile che molti amministratori di server abbiano trovato opportuno bloccare l'intera nazione coreana e che, di conseguenza, sia nata una lisa apposita per censire tutti gli indirizzi allocati a tale paese. Sulla scia di questa lista, ne sono nate altre analoghe per varie nazioni che causano problemi di spam, al punto che di queste liste si potrebbe fare una nuova categoria. Altri paesi per cui esistono liste sono per esempio Cina, Nigeria (anche se i 419 non provengono solo da lì) e Brasile.

Per trarre qualche conclusione, potremmo osservare che il DOPO-MAPS ci ha portato, quasi ogni giorno, nuove e sempre più interessanti forme di lotta. Ai postmaster si richiede di tenersi informati su questo fronte, al fine di utilizzare al meglio le risorse che si renderanno via via disponibili.

Indice

<< Precedente

Successiva >>

Ultimo aggiornamento: 27 settembre 2003

Leonardo Collinelli

106

Le liste di blocco Un importante strumento per i postmaster interessati a fare qualcosa per i propri utenti

Nella pagina precedente abbiamo visto una serie di accorgimenti che l'utente individuale può mettere in pratica nel tentativo di ridurre la quantità di spam che gli viene spedito. Precedentemente avevamo accennato ai filtri, il cui scopo è di bloccare quanto più spam possibile lungo la strada, dopo che è stato spedito ma prima che compaia all'utente. Come si è visto, non mancano soluzioni interessanti, però nessuna può dirsi davvero soddisfacente: in ogni caso si tratta per l'utente di addossarsi l'onere ed i fastidi della propria difesa, mentre per gli spammer tutto ciò comporta in genere solo qualche piccola difficoltà, spesso superabile. Per queste ragioni, la comunità antispam ha aperto un fronte di lotta assai interessante e decisamente più incisivo, sul quale vale la pena soffermarsi. Si tratta delle liste di blocco, grazie alle quali diventa particolarmente agevole fare circolare in tempo reale le informazioni più utili, nonché mettere a frutto il migliore spirito cooperativo sul quale davvero è nata la rete. Le liste di blocco non sono, di norma, uno strumento disponibile all'uso da parte degli utenti singoli. Spetta ai loro postmaster fare quanto necessario per avvalersene. Per questa ragione, il presente capitolo può essere utile soprattutto per i postmaster, anche se riteniamo che la conoscenza di questo fronte di lotta possa comunque interessare a molti utenti. Anche perché difficilmente i postmaster entreranno nell'ordine di idee di usare le blacklist se non saranno i loro utenti a chiederglielo. Per sintetizzare, le liste di blocco sono elenchi di indirizzi IP (solo in qualche raro caso di domini) selezionati secondo linee guida specifiche di ciascuna lista. Tali liste vengono mantenute attuali nel tempo (gli indirizzi o blocchi di indirizzi che le compongono vengono aggiunti o tolti quando necessario) e messe a disposizione di chiunque desideri consultarle. Scendendo per un attimo nei tecnicismi, le liste sono di solito costituite da zone DNS, e la modalità principale di consultazione, anche se non l'unica, è per l'appunto l'esecuzione di una query DNS (su un nome host ricavato dall'indirizzo che interessa verificare). In pratica, si esegue il test su un indirizzo IP alla volta, ottenendo la risposta che l'IP indicato è o non è presente nella lista. Spetta poi a chi ha consultato la lista decidere che fare del risultato ottenuto. Comunque, la modalità di consultazione tramite query DNS si presta molto bene all'esecuzione in automatico da parte di qualsiasi computer presente in rete (per esempio, da parte di un mail server che deve decidere se accettare oppure no una email in arrivo). 107

Questo tipo di soluzione apre quindi interessanti possibilità: se qualcuno mantenesse una tale lista e riuscisse ad aggiornarla in continuazione in modo che, idealmente, la lista contenesse tutti e soli gli indirizzi ip dai quali proviene spam, ecco che ne potrebbe trarre beneficio anche chi non avesse le risorse, le informazioni o l'esperienza necessarie per crearsi in proprio una tale lista. Inoltre, se la reputazione di una lista fosse talmente buona che tantissime reti decidessero di consultarla per decidere se accettare oppure no ogni email in arrivo, essere incluso in quella lista vorrebbe dire, di fatto, essere tagliato fuori dalla possibilità di spedire email a tantissime destinazioni. Quindi, anche quando la lista agisse solo a posteriori sulle fonti di spam individuate, il suo effetto avrebbe un significativo impatto sulle possibilità per gli spammer di proseguire nella loro attività. Tornando al concreto, ogni lista è gestita da chi ha deciso di crearla e/o di mantenerla su un proprio sistema. Possono esserci liste prive di policy, che potremmo definire da "bastard admin", in cui il curatore caccia dentro gli indirizzi in base alle proprie antipatie e senza bisogno di particolari ragioni. Tutto questo è perfettamente legittimo ma, per quanto ci riguarda, possiamo dire che son fatti suoi, di solito liste di questo tipo non interessano. Normalmente, chi cerca una lista di cui potersi davvero fidare al fine di filtrare le email in arrivo, farebbe bene a considerare importante che siano soddisfatti questi due requisiti: ●

●

sia noto il modo in cui vengono decisi gli inserimenti e le rimozioni di indirizzi dalla lista; deve trattarsi di modalità che l'utilizzatore della lista abbia ben capito e che ritenga valide e appropriate per le proprie esigenze. sia possibile, per un qualsiasi indirizzo presente nella lista, ricavare una sorta di evidenza, una giustificazione e documentazione del perché vi è stato inserito.

In effetti, le blacklist più diffuse e attendibili soddisfano a tali caratteristiche. Tipi di liste di blocco Nel tempo sono state individuate varie differenti strategie con cui bloccare lo spam, che si sono tradotte in alcune fondamentali tipologie di liste di blocco: ●

Liste di indirizzi o blocchi lasciati a disposizione di spammer Gli indirizzi elencati in tali liste possono essere mail server o web server appartenenti a provider o fornitori di hosting che, a quanto risulta ai mantenitori delle blacklist, rifiutano di intervenire quando gli viene documentato che i loro clienti o inviano spam attraverso tali server, o inviano spam pubblicizzante siti ospitati su quei server. Queste liste inoltre contengono blocchi di indirizzi assegnati ad organizzazioni specificamente dedite o allo spam o alla vendita di software, servizi o risorse varie per spammer. Si tratta di organizzazioni che, sugli indirizzi che finiscono in lista, tengono mail server, web server o altre risorse usate per rendere presente in rete il business promosso tramite spam o volto al supporto di spammer. È fequente che, in simili liste, si trovino pure name server che svolgono servizio DNS per siti di spammer. 108

●

●

Caratteristica comune alle risorse incluse in questo tipo di liste è un comportamento irresponsabile da parte di chi avrebbe l'autorità di disciplinarne l'uso, che sceglie o di supportare apertamente gli spammer o di ignorarne la presenza sulla propria rete (continuando a incassare da essi i canoni mentre il resto del mondo si becca lo spam). Liste di relay aperti I relay aperti sono stati per molti anni il principale mezzo per la diffusione dello spam. All'incirca nel corso del 2002 la loro importanza ha cominciato a diminuire (soprattutto per via della molto aumentata disponibilità di proxy insicuri), tuttavia una certa quota di spam continua a provenire da relay aperti e può essere fermata mediante liste apposite. Esistono quindi liste che censiscono i relay aperti, raccogliendoli mediante ricerca e test oppure limitandosi a quelli di cui si sia effettivamente provato l'utilizzo da parte di spammer. In ogni caso, in queste liste le risorse entrano essenzialmente per ragioni tecniche, talvolta per sviste e talvolta per negligenza vera e propria. Liste di risorse varie abusabili per via di buchi di sicurezza Si tratta soprattutto dei proxy aperti (di cui abbiamo già parlato) e dei formmail.pl insicuri. Formmail è un celebre script usato per inviare email da form posti su pagine web. Nella maggior parte dei casi, tale script presenta grossolane vulnerabilità di sicurezza che consentono di inviare email, anche bulk, a destinatari arbitrari tenendo l'ip dello spammer assai difficile da determinare. Di conseguenza, gli spammer cercano questi script e li sfruttano (vi sarà probabilmente capitato di ricevere qualche spam in cui il testo inizia con la frase "Below is the result of your feedback form"). Per toccare con mano quanto siano utili agli spammer i formmail insicuri, ecco una riga tratta dall'error_log di questo sito: [Wed Mar 20 03:49:35 2002] [error] [client 65.139.127.10] script not found or unable to stat: /... path.../cgi-bin/formmail.pl

●

Va da sè che in questo sito non c'è, né mai ci sarà, alcun formmail. Ciononostante si nota ogni tanto che qualcuno, da vari ip di solito nel Nord America, prova a vedere se c'è. Se su un sito normalmente raggiungibile tramite link e motori di ricerca c'è un formmail insicuro, probabilmente gli spammer lo troveranno prima di quando si possa immaginare. Liste di blocchi adibiti a dial-up Si tratta degli indirizzi attribuiti agli utenti dinamicamente (per esempio a fronte di connessioni via modem o adsl residenziali). Alcuni spammer preferiscono adoperare software direct-to-MX (come si è già visto in uno dei casi pratici). Per rendere inservibili tali software basta considerare che, per i normali utenti dial-up che inviano email legittime, non esiste alcuna ragione valida per avvalersi di direct-toMX invece che passare tramite un server SMTP (del proprio provider o altro che siano autorizzati ad adoperare). Anzi, in generale sono solo gli spammer ad avvalersi di direct-to-MX. Inoltre, è frequente che sugli indirizzi allocati dinamicamente si trovino macchine insicure o spammer che approfittano del costo 109

●

relativamente basso di questo tipo di accesso. D'altra parte, di norma non succede praticamente mai che, su indirizzi allocati dinamicamente, siano attivi dei mail server che svolgano un regolare servizio. Abbiamo quindi liste che censiscono i blocchi dial-up di molti provider, al fine di consentire agevolmente il rifiuto automatico di qualsiasi connessione SMTP da essi proveniente. Un vantaggio dato da queste liste è la pressoché totale assenza di falsi positivi. Ovviamente avere propri nodi inclusi in queste liste non significa affatto essere una rete pro-spam né avere commesso negligenze tecniche. Anzi, molte reti forniscono di propria iniziativa indicazioni per elencare i propri blocchi di dial-up. Liste con criteri particolari Esistono altre modalità di selezione di IP o domini da includere in liste di blocco. Per esempio, in base al fatto che per un certo dominio non risulti funzionante l'indirizzo "postmaster" oppure l'indirizzo "abuse", oppure in base al fatto che la registrazione nel whois del blocco IP rechi dati visibilmente falsi, oppure in base a dettagli della configurazione dei mail server non conformi alle RFC. In effetti, le reti che presentano queste particolarità sono spesso causa di inconvenienti, in particolar modo (ma non solo) a chi volesse reclamargli per questioni di spam. Costruire delle liste di questo genere è anche un'idea interessante che tuttavia, ad oggi, non sembra dare risultati vantaggiosi.

Riassumendo potremmo dire che queste liste sono, in fondo, elenchi di indirizzi ip gestiti o usati in modo da violare certi standard il cui rispetto è oggi ampiamente considerato necessario in rete. Possono essere standard di comportamento e di applicazione di policy antispam, come può trattarsi di standard di sicurezza (il caso di relay e proxy aperti e di formmail insicuri) o può trattarsi di altri standard codificati nelle RFC. Il caso invece delle liste di dial-up suggerisce uno standard non codificato ma quanto mai opportuno da adottare, ossia quello secondo cui il traffico smtp vada accettato solo da sistemi individuati da un indirizzo fisso e immutabile nel tempo. Usare le blacklist comporta, per il postmaster, una necessità di gestione alla quale occorre saper far fronte e comporta, soprattutto, l'abbandono di un atteggiamento (che era valido fino ai primi anni '90 ma che oggi non è più realistico) secondo cui la posta elettronica andrebbe accettata indiscriminatamente quale che sia la sua provenienza. Ciò a cui assistiamo è, infatti, proprio il passaggio di sempre più vaste porzioni della rete alla scelta inevitabile: accettare traffico SMTP solo da quelle reti a carico delle quali non risulti, per esperienza propria o di altri, la violazione di doverosi standard di comportamento o di sicurezza. Se il vostro postmaster rifiuta di utilizzare liste di blocco e vi dice, nella sostanza, che lo spam in arrivo nella vostra casella è un problema vostro (per esempio vi suggerisce di cancellarlo o di definire, nel vostro client di posta, delle regole per filtrarlo o, peggio ancora, vi suggerisce di chiedere allo spammer di togliervi dalla sua lista), quel postmaster si dimostra professionalmente obsoleto. Se vi è possibile scegliere chi debba essere il vostro provider di posta, tenetene conto. Nella prossima pagina si darà uno sguardo al panorama delle principali liste di blocco utilizzabili. 110

Indice

<< Precedente

Successiva >>

Ultimo aggiornamento: 30 marzo 2003

Leonardo Collinelli

111

Dati passati dal vostro browser Questa pagina mostra le principali variabili di environment previste per le richieste http. Il vostro browser può trasmettere ad ogni server, al momento della richiesta di una pagina web, alcune o tutte o, al limite, anche nessuna di tali variabili mediante gli header del protocollo http. Altre variabili potrebbero essere aggiunte da eventuali proxy adoperati. Nel seguito si può vedere, limitatamente ad un certo numero di variabili di uso comune, cosa è appena stato passato a questo server.

HTTP_ACCEPT: application/vnd.fdf, application/vnd.adobe.xfdf, application/vnd. adobe.xdp+xml, text/html, text/plain, image/gif, image/jpeg, image/png, image/x-png, application/pdf Elenca i tipi di media che il browser dichiara accettabili nel contesto corrente. Di solito compare */* col significato di "tutti". HTTP_ACCEPT_CHARSET: Consente al browser di segnalare al server la possibilità di accettare set di caratteri ulteriori oltre a US-ASCII e ISO-8859-1. HTTP_ACCEPT_ENCODING: Elenca i tipi di encoding che il browser può accettare sul contenuto. HTTP_ACCEPT_LANGUAGE: Elenca i linguaggi preferiti per ricevere le risposte. HTTP_CONNECTION: Dalla versione 1.1 dell'http questo header viene valorizzato con Keep-Alive oppure Close per richiedere al server di mantenere la sessione TCP aperta dopo aver inviato la risposta oppure di richiuderla (nell'http 1.0 la sessione viene sempre chiusa alla risposta). HTTP_FROM: Questa variabile è prevista per contenere l'indirizzo di email della persona che sta adoperando il browser. Gli standard prevedono comunque che i browser non rilascino questo dato senza il consenso dell'utilizzatore, al fine di non comprometterne la privacy. È quindi importante che questo dato risulti vuoto (la maggior parte dei browser comunque non genera l'header corrispondente).

112

HTTP_HOST: www.collinelli.net Questo è semplicemente il nome dell'host su cui è stata richiesta la pagina. Indispensabile nella versione 1.1 e successive del protocollo http (che consente di su uno stesso indirizzo ip più server virtuali). HTTP_PRAGMA: Questo header ha potenzialmente significato per tutta la catena di applicazioni coinvolte in una transazione http (user agent, proxy vari, web server) e può circolare in entrambi i sensi. Il valore più comune che si può trovare qui è no-cache, con cui si richiede alle successive applicazioni della catena di accedere alla risorsa originale (se siamo entro una richiesta), aggiornando eventuali copie ancora presenti in cache. Quando si preme il bottone di reload del browser l'effetto è appunto quello di aggiungere "Pragma: nocache". HTTP_REFERER: http://www.collinelli.net/antispam/as0140.htm Questo header viene normalmente settato dai browser quando si segue un link. Contiene la url della pagina su cui si trovava il link. Può avere qualche implicazione sul piano della privacy, tuttavia esistono anche siti che controllano il referer prima di consentire certe azioni. HTTP_USER_AGENT: Mozilla/4.0 (compatible; WebCapture 3.0; Windows) Tramite questo header viene comunicato al server il tipo di browser utilizzato. Le implicazioni che questa informazione può avere sulla privacy sono molto limitate. REMOTE_ADDR: 80.116.122.33 Questo è l'indirizzo ip da cui il server ha visto provenire la risposta. Se state usando un proxy esterno sarà l'indirizzo del proxy. In ogni caso, non è il browser a passare questo dato, che non è un header http ma una informazione essenziale a livello del protocollo IP per far sì che la risposta del server possa essere inviata a chi glie l'ha richiesta REMOTE_PORT: 3135 Indica il numero della porta TCP (sul vostro computer ovvero sul proxy) tramite la quale sta avvenendo la corrente sessione http. Secondo gli standard dovrebbe essere un numero maggiore di 1024 (e fino a 65535). Anche in questo caso si tratta di una informazione indispensabile per il funzionamento. HTTP_VIA: Normalmente i browser non generano l'header "Via:", che viene aggiunto da certi proxy per dichiarare il proprio tipo e versione del software. Non ha implicazioni sul piano della privacy (è un dato che non riguarda il vostro computer).

113

HTTP_X_FORWARDED_FOR: Anche questo header non viene generato dai browser ma aggiunto da certi proxy. L'uso previsto è di rivelare ai siti visitati il vero indirizzo ip dell'utente. Qui le implicazioni relative alla privacy ci sono eccome, dato che l'utente che naviga per mezzo di un proxy si aspetta che il proprio vero indirizzo ip resti nascosto ai siti visitati. Pertanto questo campo deve risultare vuoto, oppure settato a qualche valore non significativo (come per esempio unknown). Se state usando il proxy del vostro provider e qui trovate il vostro vero indirizzo ip, vale la pena di contattare l'helpdesk e chiedergli perché hanno configurato il proxy in questo modo. Se la risposta fosse che va bene cosí, avrebbe senso considerare di cambiare provider.

Indice Data e ora generazione di questa pagina: 27/10/2003 00:16:34 (ora locale di questo server)

Leonardo Collinelli

114

Insidie che possono arrivare con lo spam Messaggi formattati HTML e cookie - Programmi dialer

In generale non ci sono particolari motivi per temere, da un singolo messaggio di spam, pericoli quali il contagio di virus. In fondo, un virus come attachment può sì arrivare entro uno spam ma in teoria anche da parte di un amico un po' pasticcione e maldestro nell'usare il computer. Purtroppo, anzi, pure chi non sia pasticcione rischia di propagare virus, se utilizza prodotti (sistema operativo e programma di posta) non sicuri. Una elementare regola di prudenza che tutti sicuramente conoscono è che, ricevendo in email un file .exe da uno sconosciuto o da una persona sulla cui competenza e affidabilità non ci si senta di contare troppo, la cosa che assolutamente va evitata è mandare quel file in esecuzione. Se si è così incauti da farlo, si può rischiare di tutto: trovarsi installato Back Orifice o altri software che, del tutto all'insaputa del legittimo utilizzatore del computer, possono fare qualunque attività che mai si vorrebbe fare (dallo spedire dati riservati ad un indirizzo di email in Cina a tante altre cose che possono perfino procurare dei guai). Qui si entra nel campo, affascinante ma molto complesso, delle problematiche relative alla sicurezza in rete. Non possiamo affrontare qui l'argomento anche perché, come ho detto, con lo spam questi problemi non acquisiscono una gravità maggiore di quella che avrebbero comunque. È però il caso di descrivere una insidia alla sicurezza per il cui funzionamento lo spam è essenziale. Il trucco Supponiamo di ricevere uno spam formattato in html come il seguente: Dear Valued Customer,

.... If you do not wish to receive these special e-catalogs from Spamming Magazines, then reply to this email with the word "remove" in the subject line.

Happy shopping and have a great holiday season from all of us at Spamming Magazines. Apparentemente è uno spam come tanti, con il solito invito al remove. Ciò che c'è di nuovo rispetto a quelli visti finora è la formattazione in html. In generale non è affatto una buona idea usare l'html nelle email (non è lo standard e la maggior parte delle persone ne sono infastidite). Soprattutto, non è una buona idea usare dei mailreader che, di fronte a tali messaggi, svolgano funzioni di browser per rappresentarli come se fossero normali pagine web. Purtroppo, vari mailreader assai diffusi fanno proprio questo: utilizzano le funzionalità di base del browser per formattare il messaggio e visualizzarlo conformemente a tutti i tag in esso contenuti. Una delle prime conseguenze a cui si può pensare è che, aprendo una email html mandata da uno sconosciuto (per esempio da uno spammer), potrebbero andare in esecuzione eventuali script. Si tratterebbe in questo caso di una insidia tutto sommato abbastanza ovvia. Esiste però anche una insidia più sottile, che vediamo contenuta nel messaggio riportato poc'anzi. Come si può notare, il messaggio contiene il seguente tag: Si tratta di una immagine dalle dimensioni in pixel di 1 x 1, ossia una immagine invisibile, che il browser scarica dal sito dello spammer e che ovviamente non ha alcuna funzione nella visualizzazione della pagina. Però se lo spammer l'ha messa a qualcosa serve sicuramente. Guardando meglio si vede che l'immagine non è un file come tanti, ma viene generata da un programma al quale viene passato un parametro: quell'id=123456789 115

Potete scommettere che l'id=123456789 è un numero in precisa corrispondenza con l'indirizzo di email a cui lo spam è stato spedito. In altre parole, quando il browser scarica quella inutile immagine dal sito dello spammer, di fatto lo informa che il titolare della mailbox tal dei tali ha effettivamente ricevuto e letto quello spam. Nel caso l'ipotesi sembrasse troppo ardita, basti vedere quest'altro esempio, arrivato a me su una vecchia mailbox ora non più attiva. Vediamo la mailbox esplicitamente indicata tra i parametri nella url dell'immagine: The #1 Ranked Money Opportunity!

Freedom, Security and Wealth in the New Millennium!

Now is your chance to help insure your Future!!
[...]

=====================================================================
This message is intended for individuals who are interested in our offer and has been double verified. If this
message has reached you in error, we apologize for the inconvenience.
(tronchiamo qui) La cosa potrebbe già essere abbastanza fastidiosa così, ma non è finita qui: un'altra cosa che potete dare per scontata è che, quando il browser scarica l'immagine, il server a cui l'immagine viene richiesta (nel primo esempio è sito-dello-spammer.com) spedirà un cookie. Il cookie conterrà a sua volta una qualche informazione (magari una stringa di caratteri apparentemente senza senso) che ovviamente, su un apposito archivio tenuto o dallo spammer o dall'organizzazione che dello spammer si è avvalsa, risulterà in corrispondenza con l'indirizzo di email al quale lo spam era stato mandato. Siamo così arrivati a questa situazione: colui che ha ricevuto questo spam ha ora, entro il proprio browser, un cookie il cui valore consente, a qualcuno da qualche parte, di ricavare il suo indirizzo di email. Da questo momento, ogni volta che il browser invierà una richiesta http al server sito-dello-spammer.com, non importa se per prelevare una pagina, una immagine o che sia, tra gli header della richiesta rimanderà al server il valore scritto nel cookie. Tanto per essere più chiari si può immaginare che, in qualunque occasione il browser avesse di nuovo a che fare con quel server, gli si presenti dicendo: "Salve, io sono lo stesso utente che tu hai già spammato all'indirizzo [email protected]". In realtà la maggior parte dei browser non rivela esplicitamente l'indirizzo di email, ma già il ritrasmettere al server il contenuto del cookie rende possibile, per l'organizzazione che utilizza quel server, stabilire la corrispondenza e risalire così all'indirizzo di email. Immaginiamo infine, per completare il quadro, che molti siti di vario genere abbiano, nelle loro pagine, banner o immagini più o meno nascoste la cui url faccia riferimento a sito-dello-spammer.com: non c'è nulla di strano, la maggior parte degli utenti non fa assolutamente caso a cosa scarica, oltre al contenuto vero e proprio, dai siti che visita (sarebbe del resto praticamente impossibile). Il risultato sarà che qualcuno potrà tenere una cronistoria dei siti visitati dal titolare di quell'indirizzo di email e, tenendo conto che lo stesso spam viene inviato come al solito anche a molte migliaia di altri indirizzi, il solito qualcuno disporrà presto di un elenco di indirizzi con gli argomenti preferiti da ciascuno. In altre parole, non un indirizzario di email qualunque, ma un indirizzario da cui si possono operare selezioni per area di interesse. Un indirizzario, quindi, dal valore commerciale molto alto. Vi sembra che tutto ciò sia un po' fantascientifico? Una volta lo sarà anche stato, ma ora questo trucchetto dell'immagine nascosta + cookie viene segnalato sempre più spesso, tanto che per indicare questa tecnica è stata creata l'apposita locuzione web bug. Probabilmente sono solo diventati disponibili dei software in grado di supportare le necessarie elaborazioni. Per evitare fraintendimenti servono ancora alcune precisazioni in merito ai web bug: 116

1. Non è vero che qualsiasi immagine dalle dimensioni 1x1 sia necessariamente un web bug: talvolta immagini 1x1 vengono usate anche a semplici fini di allineamento e formattazione della pagina (la cosa è anzi molto frequente quando la pagina viene disegnata partendo da una visione presentazionalistica dell'html). 2. Quand'anche una immagine nascosta sia usata a scopo di tracking o monitoraggio degli accessi alla pagina, non è detto che la cosa sia sicuramente negativa o criticabile. Non c'è nulla di male se un webmaster vuole avere un'idea su quali pagine siano più accedute e quali meno. Tra l'altro, l'uso di immagini a scopo di monitoraggio (come nel caso dei comuni contatori) dà, per varie ragioni, risultati piuttosto grossolani che possono al massimo ritenersi indicativi solo come tendenza nel tempo. Ciò che inizia ad essere discutibile è quando il sito impone al computer del visitatore una sorta di "collaborazione" finalizzata al farsi riconoscere, senza che l'utilizzatore lo sappia. Decisamente inaccettabile è, infine, il fatto che l'individuazione del visitatore sia associata all'indirizzo di email, in modo da consentire di meglio sfruttare tale indirizzo ai danni del legittimo proprietario. 3. Non è affatto detto che tutti i web bug siano nascosti. Qualsiasi banner potrebbe svolgere tale funzione: magari il banner è visibilissimo, il fatto che agisca da web bug lo è molto meno (si può sospettare tale funzione se la url dell'immagine punta ad un web server diverso da quello della pagina su cui il banner è collocato, tuttavia non esiste un metodo tecnicamente certo per distinguere sempre i web bug da immagini non usate a scopo di tracking). 4. I web bug possono essere diffusi anche sui newsgroup usenet. A questo proposito ne sono potenzialmente portatori tutti i messaggi formattati HTML (specialmente gli spam). Trattandosi di messaggi diffusi su aree pubbliche e non inviati individualmente come nel caso degli spam in email, i web bug su usenet non consentono di stabilire associazioni nuove con indirizzi di email. Possono però aggiungere informazione alle associazioni cookie-indirizzo già stabilitesi (o che saranno stabilite in futuro). Come dire che, nel database dell'organizzazione di marketing in questione, oltre alla lista dei siti web visitati dal titolare di un certo indirizzo di email si avrà pure la lista dei newsgroup da lui letti. Una ragione in più per utilizzare newsreader che presentino i messaggi in semplice forma testuale, senza attuare le eventuali formattazioni html.

Un altro pericolo: i dialer Nei primi mesi del 2002 ha iniziato a diventare comune un nuovo modo per "accedere" alle tasche degli utenti di rete, ossia i programmi dialer. Nello spam tradizionale (come quello che abbiamo visto finora), il destinatario viene tipicamente indotto ad un acquisto o ad un contratto online, sovente concluso mediante compilazione di un form su un sito web o mediante contatto diretto da stabilirsi via telefono o fax. Negli spam di questa nuova e più aggressiva generazione, invece, il destinatario viene indotto ad eseguire sul proprio computer un programma dialer, ossia un programma che, preso il controllo del modem che solitamente è connesso al computer usato per l'accesso in rete, effettua una chiamata attraverso la normale linea telefonica dell'utente. Dal punto di vista tecnico, tale chiamata è molto simile ad una qualsiasi connessione dial-up, come quella normalmente usata per l'accesso al proprio provider: si accede ad una rete privata sulla quale sono disponibili certi contenuti (file da scaricare). La differenza sta nel fatto che, anziché trattarsi di una chiamata verso un numero a tariffa urbana, si ha a che fare con numerazioni speciali che gli affaristi del settore chiamano "numerazioni a valore aggiunto". In realtà, come è stato fatto notare da altri, è più giusto parlare di numerazioni a costo aggiunto. Queste numerazioni a costo aggiunto sono riconoscibili dai prefissi (per esempio 709 e 899) e comportano un costo generalmente molto elevato, che l'utente scoprirà in tutta la sua entità solo al momento in cui riceverà la bolletta telefonica. Naturalmente si possono avere svariate opinioni su questa come su ogni pratica commerciale. C'è chi dice che i dialer visualizzano chiaramente le condizioni ed i costi, e che l'utente deve essere libero di accettarli, tuttavia si sentono anche denunciare casi in cui i costi non sono dichiarati o non sono sufficientemente evidenti, per non parlare del fatto che, tramite questo mezzo, l'acquisto può anche essere effettuato da parte di bambini (mai si ribadirà a sufficienza quanto sia pericoloso lasciare i bambini da soli con computer e modem). A nostro avviso, questa dei numeri a costo aggiunto è solamente una trovata per monetizzare a caro prezzo dei contenuti dal valore assai basso se non nullo, facendo leva sul fatto che, normalmente, il consumatore non si può rendere pienamente conto delle conseguenze (non immediatamente percepibili) dell'uso del programma dialer. Ne è prova il fatto che, tramite questo canale, ciò che più comunemente ci si vede offrire (tralasciando l'onnipresente pornografia) sono loghi/suonerie per cellulari, ossia cose per cui ben difficilmente un utente consapevole sarebbe disposto a spendere 117

più di poche decine centesimi. Se in una situazione di corretto mercato il consumatore vede chiaramente che cosa ottiene, vede chiaramente che cosa gli costa e decide a ragion veduta, le numerazioni a costo aggiunto e i dialer sono un brillante escamotage per saltare questa fase. Per guadagnare non occorre più convincere il cliente della bontà della merce o del rapporto qualità/prezzo, basta metterlo nelle condizioni di cliccare nel punto giusto. Ecco allora che possiamo tornare in tema: poteva lo spam non diventare il veicolo preferenziale per questo tipo di, ehm, servizi? Certo che lo è diventato. Oggi, se aprite un messaggio di spam, specialmente se di origine italiana (il fenomeno tuttavia è diventato comune in molti paesi), è molto probabile che ci troviate un link ad un sito molto semplice, con pochissime pagine e un po' di grafica, in cui ovunque si clicchi si vede un link che punta ad un file con estensione '.exe'. Talvolta non occorre neppure cliccare: a seconda di come è configurato il browser e di come è stato scritto il sito web, potrebbe succedere che appena arrivati sulla pagina il dialer venga direttamente mandato in esecuzione, senza bisogno di altro. Si tratta di siti che spesso risiedono su servizi di free hosting e che, se chiusi, possono venire riallestiti in brevissimo tempo. Si segnala poi che, in molti casi, non c'è neppure il sito: il dialer viene direttamente spedito come allegato allo spam. Naturalmente ci sono pure spam che fanno a meno del dialer, cercando di stimolare la curiosità di incauti ragazzi e indurli a chiamare linee 709 o 899 in normale fonia. Come combattere questo fenomeno? Una risposta precisa e risolutiva ancora non c'è. Di certo non è molto efficace cercare la connessione originaria da cui è partito lo spam: probabilmente si giunge ad un proxy aperto in Corea o in altro luogo dove il nostro problema non interessa a nessuno. Far chiudere l'eventuale sito è doveroso, tuttavia il giorno dopo il sito potrebbe riapparire, magari sempre sullo stesso server con un nome leggermente diverso. L'unico punto in cui sarebbe efficace colpire lo spammer è la linea telefonica a costo aggiunto. C'è quindi chi prova a scaricare il dialer e ad esaminarlo nel tentativo di scoprire quale sia il numero telefonico chiamato, operazione che talvolta può riuscire talvolta no. Quando si dispone del numero telefonico, è possibile controllare sul sito del Ministero delle Comunicazioni e scoprire qual è il gestore a cui il numero in questione è stato dato in concessione. Per l'indagine che può essere compiuta da un normale utente, questo è il capolinea. Infatti, quel che si constata normalmente è che il gestore telefonico declina ogni e qualsiasi responsabilità e, ovviamente, se ne guarda bene dal rivelare chi sia l'intestatario della linea in questione, il quale così rimane, almeno per noi utenti, completamente anonimo. Per forza, il gestore telefonico ha il suo bel guadagno su ogni chiamata che giunga alla linea in questione, quindi ha tutto l'interesse che lo spam arrivi a destinazione e che molti, inclusi i vostri figli minorenni, clicchino su quel file '.exe'. Come proseguire, dunque? Viene suggerito di sporgere protesta presso svariate autorità, da quella per le Comunicazioni, all'Antitrust, al Garante per la protezione dei dati personali, fino alla Polizia Postale. Non esiste tuttavia ancora una guida precisa sulle mosse migliori. Quanto a quel che potrebbe fare la rete e la comunità antispam in generale, si può anche pensare che, prima o poi, le blacklist (di cui si parlerà nelle prossime pagine di questo sito), possano interessarsi ai blocchi ip intestati a quei gestori telefonici che guadagnano sullo spam con dialer, tuttavia la cosa appare problematica sotto molti aspetti. Probabilmente siamo arrivati ad un punto in cui solo la legge ha gli strumenti per poterci venire in aiuto. Il problema è che la legge tende ad essere cauta e a mediare, quindi occorre che i consumatori, magari sensibilizzando le proprie associazioni e suscitando l'interesse dei media, riescano a favorire il varo di leggi che aiutino a contrastare il problema. Per esempio, un primo provvedimento che già sarebbe di aiuto per rendere questi casi meno difficili da trattare sarebbe l'obbligo, per i gestori telefonici, di rendere pubblici i dati sugli intestatari delle linee cosidette a valore aggiunto. Questo ci parrebbe doveroso anche alla luce di elementari concetti di correttezza commerciale, tuttavia non è detto che sarebbe risolutivo, dato che in molti casi potrebbe portare a individuare solamente società straniere possedute con la tecnica delle "scatole cinesi". In definitiva, per riassumere la situazione ad oggi, siamo ancora in alto mare. L'unica cosa finora ottenuta è stato un provvedimento dell'Authority per le Comunicazioni che obbliga i fornitori telefonici a rendere possibile, per i propri utenti, la disabilitazione gratuita dei vari prefissi a costo aggiunto sulla propria linea telefonica. Questa possibilità, che si consiglia comunque di usare, è ovviamente stata attuata in maniera parziale, così da non poter costituire efficace difesa da questo genere di pratiche.

Indice

<< Precedente

Successiva >>

Ultimo aggiornamento: 06 aprile 2003

118

Leonardo Collinelli

119

Gli spammer affinano le tecniche per nascondere i loro siti web Caso pratico num. 7: decrittare i sorgenti HTML nascosti dal javascript

In presenza di sito click-through (vedasi la pagina precedente) può capitare di incontrare un'altra tecnica di offuscamento, che consiste nell'uso del javascript. In pratica la pagina click-through non contiene, bello chiaro ed evidente, il link al sito vero e proprio, ma contiene una procedura scritta, per l'appunto, in javascript. Quando la pagina click-through viene caricata in un browser che sia in grado di eseguire il javascript, la procedura in questione viene eseguita e produce, come output, delle righe di codice html che di fatto sostituiscono l'iniziale codice html della pagina. Nella pagina così riscritta è presente il link da nascondere, oppure possono esserci ulteriori script che, alla fine, faranno giungere alla url che lo spammer intende far visitare. Normalmente guardando il javascript non si capisce nulla, perché quello che dovrà diventare il nuovo sorgente html della pagina non è scritto in chiaro, ma risiede in costanti codificate, che è compito della procedura decodificare. Inoltre, il comando "View source" disponibile in tutti i browser non è di alcuna utilità, poiché mostra solo l'originario contenuto codificato della pagina. Comunque anche per questi casi, come vedremo tra un attimo, c'è rimedio. Al solo scopo di evitare confusione ricordiamo che, a differenza dei programmi CGI, che vengono eseguiti entro il web server, le procedure javascript vengono eseguite dal browser sul computer dell'utente. Il browser trova tali procedure sempre in formato sorgente all'interno di appositi tag della pagina html.

Sulla decrittazione dei javascript non ho un caso pratico mio, ragion per cui ne prendo uno che ho visto segnalare su news.admin.net-abuse.email e che mi pare consenta di capire abbastanza chiaramente di cosa si tratta. I casi che si incontreranno nella pratica potranno magari essere differenti ma saranno da affrontare in maniera analoga. Prima di procedere è doverosa una premessa: io di javascript non me ne intendo. Alla data di creazione della presente pagina, se io guardo una routine scritta in javascript arrivo al massimo ad intuire vagamente quello che fa. Dubito fortemente di volermi documentare sull'argomento in futuro, in quanto il javascript mi sta cordialmente antipatico: come utente web lo tengo nei miei browser disabilitato e, come si può ben immaginare, non intendo usarlo sulle mie pagine. Ho fatto questa precisazione soprattutto per uno scopo: far vedere che non occorre affatto essere un esperto di javascript per rendere inutile anche questa ennesima trovata degli spammer. 120

Caso pratico di click-through con javascript Innanzitutto vediamo come funziona L'esempio che vediamo ora fa uso di una soluzione commerciale, abbastanza diffusasi tra gli spammer, che promette di rendere il proprio sito accessibile ma, al tempo stesso, non rintracciabile e di conseguenza al riparo dalle segnalazioni degli antispammer. La soluzione basata sul javascript che vediamo qui non è opera di spammer, ma di abili programmatori che vendono il loro software agli spammer (per esempio, HayWyre è il nome commerciale di una di queste soluzioni). Fa sempre un certo senso vedere qualcuno che fa soldi vendendo piedi di porco e calzamaglie a ladri e rapinatori. Chi vende spamware (software di supporto alla attività degli spammer) fa esattamente la stessa cosa.

La url pubblicizzata nello spam, debitamente cammuffata con i trucchetti che già conosciamo, faceva giungere ad una pagina il cui contenuto può venire schematizzato così: <meta HTTP-EQUIV="Expires" CONTENT="SECURE HTML"> <script src="z"> <script language="Javascript"> Ho riarrangiato il testo della pagina mettendo le andate a capo e le indentazioni in modo da rendere il tutto più leggibile; la pagina originale (anche per via del fatto che lo stringone che inizializza la variabile rmt è lungo 4600 byte e passa) appare decisamente più confusa e scomoda da leggere. Analizzando quanto sopra si vede che, al momento del caricamento della pagina, va in esecuzione lo script e che il primo statement effettivamente eseguibile è quell'(rm()); evidenziato in grassetto. rm() è una funzione (il cui codice è disponibile subito sopra) che inizializza alcune variabili per poi eseguire una document.write(), ossia l'istruzione che scrive nuove righe di html entro la pagina che il browser sta visualizzando. Argomento 121

della document.write() è il valore di ritorno della funzione (rmo), cui vengono passati come argomenti le variabili poc'anzi inizializzate. C'è un solo problema: il codice della funzione (rmo) dove lo troviamo? La risposta sta in una delle prime righe, ove si trova: <script src="z">, ossia il riferimento ad un ulteriore script, distribuito in un file a parte il cui nome è "z". In pratica, se la pagina ove avete trovato quel codice html ha la url http://sito.dello.spammer. com/path/pagina.html dovrete usare il vostro browser per prelevare il file http://sito.dello. spammer.com/path/z Disponendo del file "z" avrete tutto il necessario per far funzionare lo script. Il fatto che una parte del codice sia fornita in un file separato è certamente per fare in modo che la pagina html, quand'anche venisse prelevata, da sola non sia sufficiente per ricavare le informazioni nascoste. Guardiamo dunque il contenuto del file "z", che è già più leggibile: function rmo(rm1,rm3,rm4,rmv) { if (rmv!=1){return "File mismatch, please update you dec file";} var rm2="PqE@9;Q\\>gMb-T%Fn`p0/GmCiV.Zl?jXz6r +hKoS$_e) tJaA4*3R!\"uN2}kU]H=\twLcW#Oy:s<xI,(5D18fB[|~&v\n7dY^{'", rmf="", rmp=0; rm3/=rm4; rm4/=2; for(var rml1=0;rml1
esecuzione lo script, il che provoca il prelievo (non notato dall'utente) del file "z". A quel punto il browser lavora per diversi secondi, eseguendo la routine di decifrazione. Quando ha finito, appare una pagina dalla quale si potrà finalmente accedere al sito dello spammer. Vi interessa provare questa trafila sul vostro computer? È molto semplice. Come si può ben immaginare, non metto tra le pagine di questo sito quelle originali dello spammer, tuttavia potete scaricare questo file zippato, che contiene la versione originale della pagina iniziale e dello script "z", oltre ad una immagine gif utilizzata durante il funzionamento. Per fare la prova basta unzippare i file nella stessa directory, poi aprire la pagina html con un browser in cui il javascript sia abilitato. Suggerisco che facciate la prova quando NON siete collegati in rete, anche se mi risulta che i link referenziati dalla pagina in questione siano ormai morti. Come possiamo scoprire l'html nascosto Quando il browser finisce di eseguire la routine di decifrazione, il testo che ci interessa vedere è stato dunque ricostruito e ha dato luogo a ciò che compare nella finestra del browser. Riuscire a salvarsi in chiaro tale testo non è però così semplice. Non è semplice perché il comando "View source" non mostra l'html quale risulta dopo la document.write, ma mostra in ogni caso l'html come scritto nella pagina originale. Altrettanto dicasi se qualcuno pensa di provare a usare il menù "File"/"Salva con nome": almeno sul Netscape con cui ho fatto la prova io, si riottiene il sorgente originale. Anche nella cache di Netscape si può poi rintracciare solo la versione originale. E allora? Dobbiamo alterare lo script, cosa per cui abbiamo da provare varie soluzioni. ●

Prima soluzione. Facciamo in modo che lo script produca, in testa al suo normale output, una riga con un tag <XMP> e, al termine, il corrispondente tag . Ciò significa alterare lo script della pagina originale come segue: <meta HTTP-EQUIV="Expires" CONTENT="SECURE HTML"> <script src="z"> <script language="Javascript"> "); function rm(){var rmt="1O8__$E**__nED)]V$RX_DO $_H_R_XX)... lo stringone continua ma a noi non interessa... document.write(""); //--> 123

Si notino, in grassetto, le due document.write() che sono state aggiunte in modo da aprire un tag XMP prima che inizi l'output originale dello script, e chiuderlo al termine. Il tag XMP dice al browser di considerare tutte le righe comprese al suo interno come semplice testo da visualizzare così com'è, trattando come testo anche eventuali tag che vi si trovassero. Il tag XMP è deprecato da tempo, tuttavia i browser ancora lo supportano e questa è quindi una soluzione che può funzionare. Tuttavia non escluderei che in futuro, eventualmente, i programmatori che hanno escogitato i trucchi che stiamo esaminando trovassero modo di neutralizzare questa soluzione, magari iniziando il loro output con un . ●

Seconda soluzione. Rielaboriamo l'output prodotto dallo script in modo da sostituire tutti i caratteri "<" e ">" in esso contenuti con le rispettive sequenze "<" e ">" (cosa che trasforma tutti i tag in innocui elementi di testo che saranno visualizzati così come sono). Bisogna tuttavia trovare un rimedio al fatto che, venendo meno l'effetto dei tag originali, il sorgente verrebbe sì visualizzato ma senza andate a capo e senza spaziature, divenendo pertanto poco leggibile. Diventa quindi opportuno costruire, con alcune document.write(), una semplice pagina html attorno all'output modificato, facendo sì di comprenderlo entro un tag

, che mantiene la originaria formattazione. Questa soluzione ha, rispetto alla precedente, il vantaggio che l'html che viene prodotto, una volta salvato in un file, può essere visualizzato da qualunque tipo di browser. Resta solo da vedere come si fa a operare la sostituzione dei caratteri. A questo proposito, si consideri che lo script nella sua versione originale deve per forza avere da qualche parte una document.write() e che tale funzione deve per forza avere un argomento, il cui valore sarà il testo da scrivere nel documento. Nel nostro caso abbiamo una document.write() in fondo al lungo stringone: <meta HTTP-EQUIV="Expires" CONTENT="SECURE HTML"> <script src="z"> <script language="Javascript"> Andremo quindi a modificare l'argomento della document.write() e ad 124

aggiungere altri tag prima e dopo, in modo da trasformare la pagina come segue: <meta HTTP-EQUIV="Expires" CONTENT="SECURE HTML"> <script src="z"> <script language="Javascript"> <TITLE>Pagina Decodificata

"); function rm()...stringone...;document.write((rmo)((rmt), (rms),(rmr),(rmv)).split("<").join("<").split(">"). join(">"));}(rm()); document.write("

"); //--> Si notino le parti aggiunte, che sono in grassetto. È importante la posizione della catena di funzioni: .split("<").join("<").split(">").join (">") che deve essere collocata nella posizione giusta, dopo l'argomento della document.write() che è, nel nostro caso, la chiamata di funzione (rmo) (...). Sia seguendo questa soluzione che quella precedente, il codice che ci interessa viene visualizzato in chiaro nella finestra del browser. Non si riesce a salvarlo in un file dal menù File/Salva con nome, tuttavia si riesce a selezionarlo tutto e a copiarlo in clipboard. ●

A volte possono capitare dei javascript contenenti vari trucchi volti a neutralizzare soluzioni come quelle appena viste. In questi casi, si tratta semplicamente di ricorrere a soluzioni più complicate, eventualmente da cercarsi al momento o da adattarsi. Sono in particolare interessanti le soluzioni escogitate da un frequentatore del newsgroup news.admin.net-abuse.email, conosciuto per interventi tecnici assai profondi postati con lo pseudonimo di [email protected]. L'idea principale portata da Spamless alla decrittazione dei javascript consiste nell'aggiungere istruzioni per far sì che il codice decodificato venga scritto nel campo di input di un form, per la precisione in una TEXTAREA, dove può essere letto, selezionato e copiato in clipboard senza difficoltà. Avendo chiaro che, se si evita di lasciare il proprio 125

computer in balia del codice dello spammer, la cosa riesce senz'altro meglio, Spamless ha suggerito di modificare nel seguente modo la originale pagina crittografata: 1. Inserire, all'inizio dello script, questo statement per inizializzare una variabile: // define my variable zzx23ymy=""; Ovviamente il nome zzx23ymy può anche essere scelto differente, basta che non sia una variabile già usata nello script. 2. Gli statement document.write(qualchecosa) vengano trasformati come segue: //document.write(qualchecosa) zzx23ymy+=qualchecosa Vale a dire, la document.write viene trasformata in un commento e ciò che sarebbe stato scritto nel documento da visualizzare nel browser viene invece concatenato nel valore della variabile zzx23ymy. Questa modifica è importante anche perché, neutralizzando la document.write originale, si evita che il browser interpreti il codice dello spammer. Nel caso del nostro esempio avremo che ...,rmr=28;document.write((rmo)((rmt),(rms),(rmr), (rmv)));}(...ecc.. diventa: ...,rmr=28;zzx23ymy+=(rmo)((rmt),(rms),(rmr), (rmv));}(...ecc.. . 3. Manca ancora qualcosa che renda visibile il valore finale della variabile zzx23ymy. A questo scopo si può aggiungere, per esempio alla fine della pagina, prima del tag , questo codice:

</ TEXTAREA> <INPUT VALUE="Decoder" NAME="Decoder" TYPE="button" onClick="spam.src.value=zzx23ymy;"> 126<br />
<br />
 </FORM> In effetti, non essendoci più la document.write, l'intera pagina rimarrebbe vuota ed il relativo spazio può quindi essere usato per contenere un'ampia TEXTAREA (le dimensioni COLS="100" ROWS="38" possono essere ovviamente scelte da ciascuno a proprio gusto, in base alla risoluzione dello schermo). Dopo aver compiuto queste modifiche, si caricherà la pagina nel browser, si cliccherà il bottone Decoder e si vedrà apparire il codice decodificato. Spamless fa comunque presente che qualche caso potrebbe richiedere la decodifica in più riprese e che, se è vero che una soluzione si può sempre trovare, è anche vero che non è semplice fornire una soluzione universale, che valga sempre. Per chi preferisse non fare la prova pratica con il nostro esempio, la pagina decodificata è disponibile qui in formato zippato. Comunque vediamone velocemente le caratteristiche più significative. L'html che doveva rimanere nascosto (nelle intenzioni dello spammer e del suo programmatore) fa uso di ulteriori routine in Javascript. Per esempio cerca di settare un cookie e, se si accorge che il cookie è stato rifiutato, ridirige il browser su Excite (un sito come un altro, tanto per far finire lontani dal loro). Ci sono poi alcune routine che hanno il compito di impedire all'utente di usare il tasto destro del mouse. Si nota, a questo proposito, un messaggio (che comunque nelle prove che ho effettuato non ho mai visto comparire) che dice: "Sorry, you don't have permission to right-click.". Questa arrogante presa di possesso del computer dell'utente da parte dello spammer e del suo programmatore, al punto da stabilire quando l'utente ha o non ha il diritto di usare un tasto del mouse, si adatta benissimo a ciò che gli spammer fanno di solito (ossia appropriarsi di risorse altrui per conseguire il proprio profitto), quindi non stupisce. Stupisce di più un altro particolare: quando l'utente cerca di usare il tasto destro del mouse, la procedura esegue una istruzione parent.window.close(), che significa chiudere la finestra principale del browser. Mentre MS Internet Explorer, almeno alla versione 4, chiede conferma all'utente prima di chiudersi, quel susinone di Netscape si chiude invece senza tanti complimenti (quasi che i browser venissero installati a beneficio dei webmaster dei siti che vengono visitati e non degli utenti che se ne servono).<br />
<br />
Come si vede dal codice, in centro alla pagina compare un bottone ENTER che serve per entrare nel sito principale dello spammer. Tale bottone non aziona un link qualsiasi, ma fa partire una ennesima funzione javascript la quale apre, entro una nuova finestra del browser, la url del sito da raggiungere. Naturalmente la nuova finestra viene configurata in modo da non avere né menù né toolbar né campo di input per la url, così da togliere all'utente ogni possibilità di controllo: window.open('http://3538297410/tmsm/info2kcate. html','','toolbar=no,menubar=no,resizable=yes, scrollbars=yes,location=no,fullscreen'); 127<br />
<br />
 Superfluo dire che il solito Netscape esegue alla lettera queste prescrizioni e non lascia all'utente alcuna possibilità di alterare le caratteristiche della finestra: gli è solo consentito (bontà loro) di chiuderla. MS Internet Explorer versione 4 fa pure di peggio: apre la nuova finestra a pieno schermo, senza neppure fornire la barra del titolo da cui poterla chiudere (e a quel punto non è semplice liberarsene).<br />
<br />
È ora ovvio che si tratterà di vedere chi ha in hosting il sito la cui url compare nella window.open() (come direbbero i matematici, ci siamo ricondotti al caso precedente). In conclusione Tirando le conclusioni, si può dire che non esiste nessun metodo sicuro per nascondere i siti, anche se in certe pagine simili a quella che abbiamo qui preso in esame compaiono pittoreschi messaggi come il seguente:  Il tipo che ha scritto queste righe sta combattendo una battaglia persa in partenza: potrà inventare di tanto in tanto nuovi trucchi, certamente più ingegnosi di quelli che potrei inventare io, ma dopo un paio di giorni sarà già di dominio pubblico il modo per aggirarli. Quanto allo spammer, continuerà a perdere l'account, il sito e tutto il resto, con la differenza che stavolta avrà anche speso 100 dollari per un inutile prodotto di offuscamento delle pagine web.<br />
<br />
Indice<br />
<br />
<< Precedente<br />
<br />
Successiva >><br />
<br />
Ultimo aggiornamento: 14 agosto 2002<br />
<br />
Leonardo Collinelli<br />
<br />
129<br />
<br />
 Gli spammer affinano le tecniche per nascondere i loro siti web Caso pratico num. 6: URL cammuffate e siti clickthrough<br />
<br />
E allora? Tanto noi li troviamo lo stesso. Vediamo come. Trucchetti con cui vengono cammuffate le url Nella pagina in cui si discutono gli indirizzi IP, si è detto come un indirizzo possa essere espresso mediante un numero intero anziché in notazione dotted quad. Quindi una url come http://3154189391/ è del tutto funzionante e corrisponde a http://188.1.28.79/. Sia i browser che i normali comandi come ping o traceroute accettano senza problemi gli indirizzi in quella forma e gli spammer, alla ricerca di espedienti con cui ridurre la probabilità di perdere i loro siti web, iniziarono a esprimere le url in questo modo, confidando nel fatto che l'utente medio non li sappia risolvere e non riesca quindi a trovare il vero indirizzo del sito. Ci sono anche altri trucchetti che non si sono molto diffusi. Per esempio, una url espressa come http://188.1.28.79.com/ può lasciare perplessi ma, in fondo, non è altro che un subdomain del dominio 79.com (ovvio, del resto). Oppure, una url come questa: http://0274.01.034.0117/ è di nuovo l'indirizzo 188.1.28.79, stavolta espresso in forma ottale (dato che i numeri iniziano per 0). Questi trucchi divennero inefficaci assai presto, così gli spammer, tanto per intorbidare maggiormente le acque, iniziarono a dare url di questo tipo: http://356276@202818865/abcd/def.htm La parte prima della chiocciola (il 356276) è l'informazione di autenticazione (normalmente non usata e ininfluente), mentre l'host viene indicato dalla parte che segue la chiocciola (il 202818865, che corrisponde a 12.22.197.49). Se poi vi trovate di fronte ad una URL fatta così: http://209.21.162.23@23.178.75.110@216.35.27.167/eccetera... il vero indirizzo che lo spammer intende nascondere è quello più a destra (il 216.35.27.167). 130<br />
<br />
 Un ulteriore trucco sempre più spesso usato dagli spammer per confondere le idee è di inserire, in queste url, anche degli encoding. Per esempio, la url appena vista: http://356276@202818865/abcd/def.htm si potrebbe trovare indicata anche con questa notazione del tutto equivalente: http://3%3562%376@20%3281%3886%35/%61%62c%64/def.htm In pratica ogni carattere % va considerato unitamente ai due numeri seguenti, assieme ai quali si risolve nel carattere con il corrispondente codice ascii espresso in esadecimale (es. %35 è il carattere '5', %40 è la chiocciola ecc..). Risolvere queste url non è quindi difficile, però procedere a decodificarle manualmente può essere una operazione lunga, noiosa e a rischio di commettere piccoli errori che portino in una direzione completamente sbagliata. Quindi consiglierei di usare gli appositi decodificatori che si possono trovare online. Un esempio assai popolare nella comunità antispam è messo a disposizione dal sito SamSpade.org. Esempio di url cammuffata Ecco una parte del testo di un messaggio di spam da me ricevuto: =-=-=-=-=-=-=-=-=-=-=-=-=-REMOVE INSTRUCTIONS-=-=-=-=-=-=-==-=-=-= While the Internet is public domain and not private, we respect your choice to not receive email from our EZine subscriber list. To be removed from our list server database, please enter your email at the the address below. We honor ALL remove requests. http://fupwes.gruskoze.uk%668key=965895210index=a21r7p6qw% 403633646981/cgi-bin/remove.cgi?21268:delete If this link does not load for your browser, you may leave your email address on our flat-rate toll-free voicemail server by calling 1888-..... La frase iniziale merita un commento: dove si siano sognati che la rete sia pubblica e non privata resterà sempre un mistero. Fintantoché le risorse di ogni rete sono pagate dai rispettivi proprietari e utenti, Internet sarà un insieme di reti private interconnesse, checché ne dica il nostro spammer. E non dobbiamo certo 131<br />
<br />
 affidarci al suo conclamato rispetto per la nostra scelta di non ricevere le sue email: un falso rispetto, propalato con il tono indisponente di chi fa notare che, per essere gentile nei nostri confronti, starebbe rinunciando ad un proprio diritto. Ricordate che la regola numero 1 è: "Gli spammer mentono".<br />
<br />
Ora veniamo alla url indicata per il remove: pare di vedere che si tratti di un host inglese (per via del .uk). Invece no: la url non finisce con il .uk, e procedendo a decodificarla si ottiene: http://fupwes.gruskoze. ukf8key=965895210index=a21r7p6qw@3633646981/cgi-bin/remove. cgi?21268:delete ossia, scartando tutte le inutili cianfrusaglie prima della '@' e risolvendo l'indirizzo numerico: http://216.149.13.133/cgi-bin/remove.cgi?21268:delete Andando a vedere qual è il reverse DNS per l'indirizzo ip 216.149.13.133 si trovava (a quel tempo, ora non più) un beffardo "servetheworld-suspend.com", visibilmente bogus e che ovviamente non si verificava al DNS diretto. Facendo uno scan del reverse DNS per la classe C dell'indirizzo in questione (un tool per questa operazione esiste sul già citato sito Samspade.org) si vedevano un mucchio di nomi altrettanto di fantasia. Mettere le definizioni DNS in questo modo è una pratica rara e, come ci si può immaginare, niente affatto apprezzata in rete. Comunque l'indirizzo apparteneva a 9NETAVE, cui è stato diretto il reclamo e che ha risposto che avrebbe investigato sul proprio cliente prendendo, se il caso, gli opportuni provvedimenti. Altro esempio di cammuffamento Una celebre spamhaus americana è nota per inviare spam in html al cui interno si trovano dei link di questo genere: <A HREF="http://www.jan1502.wr.co.fr| https.opt-out.example.com/...eccetera... Una url scritta in quel modo può funzionare solo all'interno di un link in una pagina html. Se si prova a copiarla ed incollarla sulla riga di indirizzo del browser, non funziona. Se poi si prova a copiare il nome host e a inserirlo in un qualsiasi programma in grado di determinare l'indirizzo ip a partire dal nome, è assai probabile che il risultato sia sbagliato, in quanto la presenza di certi caratteri (come il |) può far sì che una parte del nome venga trascurata. Quando invece si clicka su un link di quel tipo, il browser risolve quelle sequenze &#nn;, sostituendole con il carattare il cui codice ascii espresso in decimale sia nn. Risulteranno dei caratteri non stampabili, ma il dns competente per il dominio usato dalla spamhaus è in grado di risolvere ugualmente i nomi host di quel tipo. Si può dire che, in fin dei conti, la url non è neppure cammuffata: semplicemente contiene caratteri speciali, 132<br / rel="nofollow">
<br />
 che sono espressi con normali escape html. Ovviamente, in caso di uno spam di questo genere bisogna reclamare innanzitutto a chi ospita i dns per il dominio in questione, tuttavia per completare l'indagine occorre anche vedere a quale indirizzo si trova il sito raggiungibile tramite quella url e, quindi, risolvere quel nome dns. Una soluzione può essere di far girare (anche sul proprio computer) uno script Perl (o altro programma utile allo scopo) in grado di risolvere le sequenze &#nn; esattamente come farebbe il browser, e di passare il risultato al normale programma di lookup sul dns. Ad esempio, si potrebbe codificare uno script come segue: $url = 'www.jan1502.wr.co.fr|https. opt-out.example.com'; $url =~ s/\&\#([0-9]{1,3})\;/chr($1)/ge; open(CMD,"nslookup \"$url\" |"); while () { chop $_; print "$_\n"; } close (CMD); (l'esecuzione di un tale script presuppone, ovviamente, di avere il Perl installato sul proprio computer).<br />
<br />
Cosa sono i siti click-through Non sempre, quando si vede uno spam che pubblicizza una url, è sufficiente limitarsi a far chiudere il relativo sito. Spesso infatti la url inclusa nello spam punta semplicemente ad un piccolo sito, generalmente residente su qualcuno dei tanti servizi di free hosting, in cui non c'è nulla di realmente importante, né è quella la vera sede in cui gira il business dello spammer. Si tratta di siti che, qualora venissero chiusi, lo spammer non avrebbe grossi problemi a riaprire velocemente, magari usando un differente servizio di hosting. Comunque, il piccolo sito referenziato negli spam deve per forza contenere, nelle sue pagine, il link per giungere al vero sito ove l'organizzazione responsabile per quello spam conduce i suoi affari. Per questo il primo sito, quello a cui si giunge direttamente dalla url contenuta nello spam, viene detto click-through: si tratta infatti, nella maggioranza dei casi, di siti che servono solo per clickarci sopra e giungere quindi nel sito che conta. Il sito che conta viene raggiunto o direttamente dal click-through o seguendo i link di varie pagine in sequenza (magari anche più di un sito click-through può essere frapposto ed è da attraversare). Quando, alla fine, si arriva al sito che conta, lo si riesce di solito a riconoscere facilmente: è dove sta il grosso del materiale ed i riferimenti per mettersi in contatto con l'organizzazione (non sfuggano frasi come "click here to join" o form html da compilare). È molto probabile che il sito principale dello spammer sia su servizi di hosting già di discreta qualità e, magari, non gratuiti (dotati di servizi quali CGI, e-commerce eccetera). Perdere 133<br />
<br />
 questo sito risulta, per lo spammer, una eventualità assai più fastidiosa e costosa, che può costringerlo a perdere diversi giorni per poter essere di nuovo on-line. A questo punto, passiamo a vedere un caso pratico in cui è stata necessaria una caccia più approfondita per riuscire ad arrivare fino in fondo. Caso pratico num. 6: url cammuffata e sito click-through From: cybermarket@gnwmail.com Received: from jade. ([164.124.96.60]) by bftoemail6.bigfoot.com (Bigfoot Toe Mail v1.0 with message handle 990917_120552_4_bftoemail6_smtp; Fri, 17 Sep 1999 12:05:52 -0500 for mio-indirizzo@bigfoot.com Received: from computer by jade. (SMI-8.6/SMI-SVR4) id BAA00883; Sat, 18 Sep 1999 01:03:12 +0900 Message-Id: <199909171603.BAA00883@jade.> Subject: Lowest home loan rates in years! Date: Fri, 17 Sep 1999 02:07:29 -0700 X-Priority: 3 X-MSMail-Priority: Normal Reply-To: dplewis@gnwmail.com X-UIDL: fb8361d381ce40db03bd177e7332807a Status: U Home loans are available for EVERY credit and equity situation! Whether your credit rating is A+ or you are "credit challenged" [.....] Tagliamo un pezzo per arrivare alla url:<br />
<br />
http://3%36%32%36%30%34%36%34%36%38%2f%62%69%7a%34%2f%62%69% 7a%34%33%33%33/start.html Click on the link above for your FREE Mortgage Evaluation. If the link is dead please reply with "more info" in the subject.<br />
<br />
------------------------------------------------This email complies with ALL Federal and State laws. 134<br />
<br />
 To be removed from the mailing list send mailto:dplewis@gnwmail.com?subject=remove_ddc9 L'analisi non è difficile: lo spammer ha trovato un relay anonimo che usa un sendmail 8.6; si nota anche una dropbox su GNWMail ed è indicata una url pasticciata che si risolve come segue: http://216.33.20.4/biz4/biz4333/start.html L'indirizzo è di Angelfire, celebre servizio di free hosting che gli spammer spesso scelgono per mettervi dei siti click-through, nonostante in genere Angelfire li chiuda velocemente. Occorre quindi andare a vedere che c'è sulla pagina indicata, e a questo scopo lo strumento più utile può essere o il proprio browser (andando poi a vedere il sorgente html della pagina) o, meglio ancora, il safe browser disponibile online, alla già citata url di Samspade. org. Si tratta di una funzionalità che mostra non solo il sorgente della pagina richiesta, ma anche gli header inviati dal relativo web server. In pratica, il safe browser mostra, in formato testuale, l'output completo esattamente come viene fornito dal web sever in risposta al comando http GET. L'output che si ottiene dal safe browser è ottimo per copiarlo poi nel proprio abuse report. Uno strumento come il safe browser consente anche di vedere molto facilmente la vera ubicazione dei siti che credono di potersi nascondere dietro i servizi di ridirezione (quali i vari come.to, jump.to, try.at eccetera): in questi casi si nota un tag tipo: <frame src="http://vera-url...". Un altro vantaggio del safe browser è che, per suo tramite, si può arrivare sui poco amichevoli siti degli spammer senza far vedere la propria provenienza e senza accettare cookie.<br />
<br />
Andando a vedere cosa c'era alla url indicata nello spam, si è ottenuto il seguente output: GET /biz4/biz4333/start.html HTTP/1.1 Host: 216.33.20.4 Connection: close Read 7120 bytes from host 216.33.20.4, path /biz4/biz4333/ start.html HTTP/1.1 200 OK Date: Fri, 17 Sep 1999 18:54:29 GMT Server: Apache/1.3.4 (Unix) Last-Modified: Fri, 17 Sep 1999 08:29:24 GMT ETag: "5809cb-1ad7-37e1fbe4" Accept-Ranges: bytes Content-Length: 6871 Connection: close Content-Type: text/html 135<br />
<br />
 <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="description" content="The Home Loan Source makes it easy to get a mortgage quote anywhere in the United States. Fill in our short form and you will be contacted by a mortgage professional the specializes in the type of loan that you need."> <meta name="keywords" content="mortgage, home loan, refinance, borrow, second trust deed, purchase money, home improvement loans, equity line of credit, consumer finance, debt consolidation, Fixed Rate Loans, Adjustable Rate Mortgage, ARM, Buydown, Conforming,Jumbo, Non-Conforming Loans, FHA, VA,Non-Owner Occupied,Cash-Out Refinances "> <meta name="GENERATOR" content="Microsoft FrontPage Express 2.0"> <title>The Home Loan Source</title> </head> <body background="images/homebg.jpg" bgcolor="#FFFFFF" text="#008080" topmargin="20" leftmargin="20" marginheight="0" marginwidth="0"> <p align="center"><font size="5"> </font><font size="5" face="Arial"><strong>Apply For A Home Loan In Just A Few Minutes!</strong></font><font size="5"> </font></p> <div align="center"><center> [....] Tagliamo un pezzo per giungere alla parte interessante:<br />
<br />
</font><a href="quickpre3.html" rel="nofollow"><font size="2" face="System"><strong>Click Here To Continue to the quick pre-qualification form</strong></font></a><font<br />
<br />
Tronchiamo qui, il seguito non contiene altro di utile. 136<br />
<br />
 Non sfugga l'HREF= abbiamo un link che punta ad un'altra pagina (del medesimo sito), quella "quickpre3. html" che viene presentata come "pre-qualification form": proprio quel che bisogna andare a vedere. Andiamo dunque col safe browser alla pagina in questione e otteniamo questo output: GET /biz4/biz4333/quickpre3.html HTTP/1.1 Host: 216.33.20.4 Connection: close Read 8192 bytes from host 216.33.20.4, path /biz4/biz4333/ quickpre3.html HTTP/1.1 200 OK Date: Fri, 17 Sep 1999 18:56:06 GMT Server: Apache/1.3.4 (Unix) Last-Modified: Fri, 17 Sep 1999 08:28:35 GMT ETag: "5809ca-21a8-37e1fbb3" Accept-Ranges: bytes Content-Length: 8616 Connection: close Content-Type: text/html <HTML> <HEAD> <META http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <META name="GENERATOR" content="Microsoft FrontPage Express 2.0"> <TITLE>Quick Pre-application Form</TITLE> </HEAD> [....] Saltiamo un po' di righe anche qui e arriviamo a:<br />
<br />
<TR> <TD width="548"><FORM action="http://206.253.222.112/ loanform/cgi-bin/file.cgi" method="POST"> <FONT color="#008080" size="4" face="Arial">Fill out this short form to receive your free loan quote.<EM><STRONG> </STRONG></EM></ FONT> <P> 137<br />
<br />
 Tronchiamo qui. Ci siamo: invitano a fornire i dati in un form html, al fine di ricevere un qualche riscontro da loro. Il form quindi risiede ancora sul sito click-through, tuttavia occorre fare attenzione all'attributo ACTION del tag FORM. L'attributo ACTION indica a quale programma CGI il browser dell'utente deve inviare i dati da elaborare. È quello il programma che lavora per far arrivare allo spammer i contatti commerciali, quindi è quello che va colpito. Qui il form lancia il programma file.cgi che sta nella classica directory cgi-bin di un sito sull'host 206.253.222.112 il quale, come si può subito constatare, appartiene a hypermart.net (un servizio di hosting assai famoso e riservato all'utenza commerciale). E così, per gestire adeguatamente questo caso, ho mandato (a parte il relay e la dropbox) un unico abuse report agli indirizzi abuse sia di angelfire.com che di hypermart.net: abuse@angelfire.com please deal with the unsolicited commercial email enclosed here, at the bottom of this message, where the following page is advertised: http://216.33.20.4/biz4/biz4333/start.html (the url within the message body is obfuscated but it can be decoded to http://3626046468/biz4/biz4333/start.html ). 216.33.20.4 is bigip.angelfire.com abuse@hypermart.net the spamadvertised page here reported to Angelfire is a click-through which leads to a form with the following action: <FORM action="http://206.253.222.112/loanform/cgi-bin/file.cgi" method="POST"> 206.253.222.112 is server21.hypermart.net, so please delete the site of these spammers before they can take profit from this spam run. Thank you all [firma] Oltre che il messaggio di spam, allegavo gli opportuni output del safe browser. Giusto per verificare se il sito su hypermart non fosse per caso già stato chiuso, ho pure provato ad usare il safe browser sulla url cgi indicata nell'ACTION del form. Il programma CGI dello spammer ha risposto dicendo che i dati erano stati inviati con successo e che mi 138<br />
<br />
 avrebbero contattato entro 2 giorni lavorativi. In realtà, essendo stata effettuata una semplice GET (e senza alcuna query string), non era stato inviato proprio nessun dato: evidentemente il programma, scritto coi piedi, non effettuava neppure il controllo dei dati prima di rispondere (cosa che qualsiasi programma CGI che si rispetti dovrebbe fare con particolare attenzione). Come è andata a finire? Il giorno dopo ho constatato che Angelfire aveva già chiuso il clickthrough. Il programma CGI, invece, continuava a funzionare. Allora, tre giorni dopo, ho inviato un sollecito (già, a volte va fatto pure questo). A titolo di esempio di cosa si può dire in un sollecito, riporto il testo: Subject: Spamadvertised site on Hypermart (http://206.253.222.112/loanform/ cgi-bin/file.cgi Dear Hypermart, I see that the web site in the subject, advertised by means of a click-through on Angelfire, is still alive, while the click-through has been closed by Angelfire. The fact that the real site, hosted by you, has not been taken down, enables the spammer to open another click-through and to spam again. So please take action as soon as possible. Thank you [firma] --- Abuse report sent to you on Sep-17: [qui era allegato l'intero abuse report precedentemente spedito] Dopo qualche altro giorno, è finalmente giunta una risposta: Hello There, Thank you for this information. We appreciate that you took the time to alert us of this violation. As a result, the account has been removed from our system and the user's IP and email address has been banned from our network. Again, Thank you. Your actions has improved the quality of our service and enhanced HyperMart's community. La cosa importante è che, a questo punto, una nuova prova con il safe browser sulla url del programma CGI riportava finalmente un errore "403 Forbidden". È vero che, di solito, ci si aspetta un "404 Not Found", tuttavia qualsiasi codice di errore ci va bene, purché il sito non ci sia più. Altri particolari che non devono sfuggire 139<br />
<br />
 Il caso appena esaminato vedeva, sul sito click-through, un form ove il programma CGI poteva anche essere, a tutti gli effetti, un vero e proprio programma gestionale che trattasse direttamente i dati immessi. Nella maggioranza dei casi, comunque, gli spammer adottano soluzioni più semplici da costruire, in cui il form serve semplicemente per assemblare e spedire una normale email ad una ben precisa mailbox, da cui lo spammer scarica periodicamente i messaggi per poi gestirli manualmente. In questi casi il programma CGI sarà semplicemente uno dei tanti di form-mailing, e l'host su cui gira può essere associato al sito dello spammer o, in qualche caso, può essere un vero e proprio servizio di formmailing legittimo. Questi casi comunque hanno di solito una cosa in comune: l'indirizzo di email a cui vengono spediti i dati raccolti per mezzo del form deve essere tra i dati in input del programma CGI. Ne consegue che di solito, guardando il sorgente html del form, si nota un campo hidden (ossia non visualizzato dal browser) valorizzato con un indirizzo di email. Nessuno si sorprenderà che il provider di questo indirizzo di email debba essere informato dell'uso che di tale mailbox viene fatto. Altrettanto dicasi per gli eventuali servizi di form-mailing. Bloccare al più presto la possibilità per lo spammer di ricevere risposte è importantissimo. Per questo raccomanderei di non trascurare mai le mailbox di ogni genere associate allo spam. Vediamo un esempio di situazione quale quella appena descritta: <form action="http://3507429089/cgi-bin/ukmailer.cgi" method=POST> <INPUT TYPE="HIDDEN" NAME="recipient" VALUE="mailbox_dello_spammer@excite.com"> <INPUT TYPE="HIDDEN" NAME="formmailerid" VALUE="Accountid_dello_spammer"> <input type=hidden name="subject" value="Order Feedback"> <input type=hidden name="redirect" value="http://www. geocities.com/...omissis.../thankyou.html"> [....] Qui è evidente che lo spammer ha preso una mailbox gratuita fornita da Excite (al cui indirizzo abusi è stata subito mandata una segnalazione). Quanto all'indirizzo numerico indicato nella url di cui alla ACTION del form, porta a formmailer.net, un servizio che fornisce elaborazione di form di email per usi legittimi. Visitando il sito di formmailer.net si notava con piacere, in bella evidenza, un link alla Abuse.net, e tale link non era lì per caso: infatti molto rapidamente il responsabile di Formmailer confermò che l'account in questione era stato chiuso. Caspita, ma allora sono parecchie le segnalazioni da spedire per ogni spam! Effettivamente sì, cominciano ad essere parecchie. In casi estremi per un unico spam potrebbero essere da avvertire diversi soggetti: 140<br />
<br />
 1. 2. 3. 4. 5. 6. 7. 8. 9.<br />
<br />
la rete da cui lo spam è stato originato; la rete cui appartiene il relay o proxy aperto da cui lo spam è transitato; il servizio di hosting per il sito click-through indicato nello spam; il servizio di hosting per il sito vero e proprio raggiunto tramite il click-through, se c'è; il servizio di dns per il sito vero e proprio, se diverso dal provider di hosting; il gestore dei form di mailing trovati sul click-through o su altri siti; il provider delle mailbox trovate nei form di mailing o come contatti sulle pagine del click-through; il provider delle eventuali mailbox indicate nello spam (es. per raccogliere i remove). i fornitori di eventuali servizi di altro genere (es. i servizi per addebito su carte di credito che risultano usati dai siti pubblicizzati nello spam).<br />
<br />
Mediamente il numero di reclami da spedire è certamente molto più basso, tuttavia possono effettivamente capitare dei casi in cui il lavoro da fare comincia a richiedere un po' di tempo. Già abbiamo accennato al fatto che non convenga dedicare del tempo per segnalare un relay o proxy aperto, ragion per cui il relativo punto può essere saltato, tuttavia non è detto che si abbia sempre il tempo per redigere tutti i rimanenti abuse report. È giusto sapere che tutti i punti di quella lista sono punti in cui lo spammer è vulnerabile, e che colpirlo su tutti avrebbe l'efficacia massima. Quindi tutti quei punti vanno considerati delle opportunità. Quanto al tempo necessario, direi che avere qualche template pronto, sfruttare tutti gli strumenti a disposizione ed avere fatto pratica su qualche caso consente di diventare discretamente veloci. Nei casi, purtroppo sempre più numerosi al crescere del volume di spam in circolazione, in cui il tempo disponibile impone di operare delle scelte, concentratevi preferibilmente sul sito vero e proprio e sui server DNS, che sono per lo spammer le risorse più difficili e costose da rimpiazzare. Tra l'altro, gli spammer più grossi e più sicuri della complicità del proprio provider sovente spammano direttamente dalla stessa rete su cui hanno le altre loro principali risorse. Per valorizzare al massimo le vostre segnalazioni di spam internazionale, raccomanderei anche di postarne una copia sull'apposito newsgroup news.admin.net-abuse.sightings. Se infatti in molti casi appare chiaro che la segnalazione di un utente non può realisticamente portare alla disconnessione di un grosso spammer, è comunque vero che può costituire utilissima evidenza a supporto del lavoro di chi gestisce liste di blocco (sia del newsgroup news.admini.net-abuse. sightings che delle liste di blocco si parlerà nelle prossime pagine).<br />
<br />
Indice<br />
<br />
<< Precedente<br />
<br />
Successiva >><br />
<br />
Ultimo aggiornamento: 28 luglio 2003<br />
<br />
Leonardo Collinelli<br />
<br />
141<br />
<br />
 142<br />
<br />
 Lezioni sulla lettura degli header Falsificazioni da riconoscere Lo spammer può falsificare gli header 'Received:'? L'indicazione della provenienza negli header 'Received:' esiste sempre? Potrebbe essere falsa ? Un esempio interessante Quando troviamo l'indirizzo IP, possiamo contare che sia giusto o potrebbe essere falsificato pure quello? Può succedere che lo spammer, usando un proxy, riesca ad apparire su un ip diverso da quello a cui si trova? Lo spammer può falsificare gli header 'Received:' ? Sì, ma eventuali header falsificati possono solo essere gli ultimi della catena. Lo spammer non può impedire che i computer successivi al suo nel trasportare il messaggio mettano i propri received. Quindi fino ad un certo punto la catena sarà corretta e attendibile, da quel certo punto potremo, in qualche caso, avere degli header falsificati, ossia costruiti in modo da assomigliare a header veri e messi lì per confondere le idee. Generalmente il punto in questione si può individuare: c'è sempre qualcosa che non torna se si esamina il tutto con attenzione. L'indicazione della provenienza negli header 'Received:' esiste sempre ? Teoricamente un server potrebbe anche non dichiarare chi è stato a passargli il messaggio. Quando questo avviene, siamo in presenza o di un anonymous remailer o di un server gestito da personale non competente. Esclusi quei pochi sistemi che deliberatamente operano in questo modo (e che comunque generalmente adottano soluzioni per evitare di lasciarsi abusare dagli spammer), la probabilità che organizzazioni serie abbiano un server configurato male che faccia da remailer anonimo è praticamente nulla, visti i rischi niente affatto da ridere che correrebbero (pensate se qualcuno utilizzasse un server anonimo per perpetrare reati gravi, che so, mandare minacce di morte a qualcuno o cose del genere). Vedremo, in uno dei successivi casi pratici, una organizzazione certo non criminosa che, o per scarsa informazione o per negligenza o semplicemente per qualche errore commesso nel configurare il software, è incorsa proprio in questo problema. In effetti vecchie versioni di Sendmail (in particolare la 8.6) mettevano per default dei Received privi della dovuta informazione e, quando un server venga migrato a nuove versioni tenendo i vecchi file di configurazione, l'inconveniente può verificarsi anche in versioni recenti; per esempio, un Received come il seguente: 143<br />
<br />
 Received: from tyuyq by xx.xxxx.ac.za; (8.9.3/1.1.8.2/03Nov94-1202PM) id MAA22307; Sat, 12 Jun 1999 12:47:39 +0200 (GMT+0200) indica un sendmail 8.9.3 (che per default dovrebbe produrre dei Received corretti) che, però, usa ancora il file di configurazione (sendmail.cf) versione 1.1.8.2, creato nel novembre 94. Come si vede, viene riportata solo la non significativa stringa 'tyuyq' che lo spammer ha inserito nel comando HELO. Il fatto che, tramite l'HELO, lo spammer abbia modo di inserire una stringa arbitraria entro il Received, rende possibili certi offuscamenti di cui vedremo tra un attimo un esempio. A volte lo spammer passa come HELO un semplice indirizzo IP che non c'entra nulla. Altre volte, approfittando di buchi nei software dei mail server utilizzati, una stringa talmente lunga da impedire l'apparizione delle parti significative dei Received in questione (di fatto rendendo anonimo un server che, usato normalmente, non lo sarebbe). Un esempio interessante Tempo fa mi è stato segnalato un caso di falsificazione che val la pena di vedere. Più che di falsificazione, comunque, si potrebbe parlare di trucco per intorbidare le acque. Vediamo: From: ajhejmuaje@126.com Received: from servidor2.bauer.es ([195.61.24.2]) by smv198-mc.mail.com (8.9.3/8.9.1SMV070400) with SMTP id WAA21539; Wed, 21 Mar 2001 22:22:33 -0500 (EST) Received: from myrop (ew6.southwind.net [216.53.98.70]) by onyx.southwind.netfrom homepage.com (114.230.197.216) by newmail.spectraweb.ch from default (m202.2-25.warwick.net [218.242.202.80]) byhost.warwick.net (8.10.0.Beta10/8.10.0.Beta10) with SMTP id e9GKEKk19201 ([63.44.155.8]) by servidor2.bauer.es (Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) with SMTP id C1256A17.00129C3A; Sun, 22 Mar 1970 04:23:31 +0100 Message-ID: <0000749b6e86$00001ced$00007697@mcpeely. concentric.net (mcfeely.concentric.net [217.15.198.83])by darius.concentric. net (8.9.1a/(98/12/15 5.12)) id PAA04003from default (m202.2-25. warwick.net [218.242.202.80]) byhost.warwick.net (8.10.0.Beta10/8.10.0. 144<br />
<br />
 Beta10) with SMTP id e0GKEKk19201> Subject: Viagra Alternative & FREE Herbs! Date: Wed, 21 Mar 2001 14:15:27 -0800 X-Priority: 1 X-MSMail-Priority: High Questo spam era arrivato a un indirizzo creato su mail.com (noto servizio di forwarding). Il server di mail.com ha ricevuto il messaggio da un server spagnolo, come specificato nel primo header: Received: from servidor2.bauer.es ([195.61.24.2]) by smv198-mc.mail.com (8.9.3/8.9.1SMV070400) with SMTP id WAA21539; Wed, 21 Mar 2001 22:22:33 -0500 (EST) Questo primo header è sicuramente corretto, essendo stato inserito dal servizio direttamente usato dall'utente che aveva ricevuto lo spam. Il server spagnolo è il primo sconosciuto che troviamo nella catena, e ci aspettiamo quindi che il successivo Received sia opera sua. Come successivo Received troviamo questo mostruoso guazzabuglio: Received: from myrop (ew6.southwind.net [216.53.98.70]) by onyx.southwind.netfrom homepage.com (114.230.197.216) by newmail.spectraweb.ch from default (m202.2-25.warwick.net [218.242.202.80]) byhost.warwick.net (8.10.0.Beta10/8.10.0.Beta10) with SMTP id e9GKEKk19201 ([63.44.155.8]) by servidor2.bauer.es (Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) with SMTP id C1256A17.00129C3A; Sun, 22 Mar 1970 04:23:31 +0100 Non abbiamo ancora parlato del problema dei relay aperti (che verrà trattato in più d'una delle successive pagine) e non è il caso che anticipiamo il discorso. Per ora diciamo solo che il server spagnolo ha (o almeno aveva, al momento dello spam) un problema di sicurezza, per causa del quale veniva utilizzato dagli spammer. Inoltre il server spagnolo, essendo nelle condizioni di creare a tutta la rete dei problemi di spam, era censito in varie "liste nere" pubblicamente accessibili. Tali liste nere riportavano, sui rispettivi siti, esempi di messaggi di test veicolati da tale server, completi di header. A questo punto si delinea già il modo per venire a capo di quel guazzabuglio: procurarsi un Received costruito dal server spagnolo in condizioni normali e vedere se le cose combinano. Questa possibilità, ossia procurarsi un normale Received del medesimo server (mediante test oppure trovandolo già pubblicato presso siti delle liste di blocco), è estremamente utile in tutti i casi in cui si dubiti, per esempio per via della struttura insolita di un Received, di come si possa effettivamente interpretare l'header. 145<br />
<br />
 Nel caso in esame, andando sul sito di una lista nera (anche delle liste nere parleremo più avanti) si trovava quindi l'esempio di header Received che riportiamo qui di seguito. Si tratta del Received preso da un messaggio di test risalente circa a quegli stessi giorni: Received: from tester42.orbs.org ([62.250.3.55]) by servidor2.bauer.es (Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) with SMTP id C12569F1.006131A4; Thu, 12 Feb 1970 18:41:37 +0100 Se si confronta con il precedente header, si nota che la struttura è la stessa. A parte l'SMTP id (che è, e deve essere, di volta in volta sempre diverso) combina tutto, perfino la data sballata (pur essendo lo spam del marzo 2001, il server spagnolo aveva una data di sistema nel 1970). In pratica, è ora chiaro che lo spammer ha fatto in modo che il server spagnolo ricevesse una stringa di HELO fatta così: myrop (ew6.southwind.net [216.53.98.70]) by onyx.southwind.netfrom homepage.com (114.230.197.216) by newmail.spectraweb.ch from default (m202.2-25.warwick.net [218.242.202.80]) byhost.warwick.net (8.10.0.Beta10/8.10.0.Beta10) with SMTP id e9GKEKk19201 Quindi, rivedendo l'intero header evidenziato in tutte le parti all'infuori della stringa di Helo:<br />
<br />
Received: from myrop (ew6.southwind.net [216.53.98.70]) by onyx.southwind.netfrom homepage.com (114.230.197.216) by newmail.spectraweb.ch from default (m202.2-25.warwick.net [218.242.202.80]) byhost.warwick.net (8.10.0.Beta10/8.10.0.Beta10) with SMTP id e9GKEKk19201<br />
<br />
([63.44.155.8]) by servidor2.bauer.es (Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) with SMTP id C1256A17.00129C3A; Sun, 22 Mar 1970 04:23:31 +0100 ci appare che, nonostante la cortina fumogena sollevata, lo spammer non ha potuto nascondere di essere all'indirizzo 63.44.155.8 Quando troviamo l'indirizzo IP, possiamo contare che sia giusto o potrebbe essere falsificato pure quello? Quanto al fatto che l'indirizzo IP riportato esplicitamente da un mailserver entro l'header 146<br />
<br />
 'Received:' possa essere errato, la risposta è NO. Gli spammer più organizzati possono tuttavia farci trovare una particolare situazione alla quale dedichiamo il successivo approfondimento. Al fine di limitarci a quel che ci occorre vedere, terremo la trattazione il più banale possibile. Per chi volesse andare più a fondo sarà certamente utile partire dalla RFC793. Per chi, al contrario, preferisse accontentarsi di una risposta veloce (che, in fondo, è l'unica di cui fare uso in pratica), va bene saltare il seguente approfondimento e considerare semplicemente che, se interpretando correttamente un Received si individua un indirizzo IP, quell'indirizzo era comunque sicuramente usato dallo spammer. Approfondimento IP spoofing e spam Per come funziona il protocollo IP, ogni host che trasmette dati in rete indica in ogni pacchetto, oltre all'indirizzo IP dell'host che intende raggiungere, anche il proprio. In teoria è quindi assolutamente possibile che, programmando opportunamente i moduli TCP/IP del proprio software (moduli che generalmente sono inclusi nel sistema operativo), si possano spedire pacchetti con indirizzi o inesistenti o appartenenti ad altri computer che non c'entrano nulla. Questa pratica è detta IP spoofing e viene sovente utilizzata in rete (per lo più da parte di ragazzotti dispettosi) per attacchi di tipo denial of service. Il problema per chi volesse utilizzare l'IP spoofing al fine di mandare email anonime è che, come si è visto, qualsiasi transazione SMTP richiede interazione tra i due computer coinvolti, interazione che deve avvenire nell'ambito di una connessione TCP ininterrotta. In altre parole, il computer che spedisce la mail deve essere in condizioni di ricevere i messaggi del server a cui si è connesso e, a fronte di ogni messaggio ricevuto, inviare il successivo comando che il protocollo prevede a quel punto. Se ci si è presentati al server con un indirizzo falso, le risposte del server non potranno essere ricevute, in quanto andranno a finire o ad un computer realmente esistente chissà dove ma che non se le aspetta (e che le scarterà), o ad un indirizzo inesistente (andando così ad arricchire il cosidetto "rumore di fondo" della rete globale). Può quindi sembrare che, per chi tenta l'invio di email con indirizzo mittente spoofato, la situazione sia semplicemente analoga a quella di chi lavorasse su un computer a video spento: è difficile ma si può pensare di riuscire almeno a fare qualche semplice operazione. C'è però di più: il fatto di mantenere una sessione TCP ininterrotta richiede che tutti i segmenti TCP scambiati tra i due computer contengano ciascuno un numero di sequenza. Ognuno dei due computer invia all'altro degli ACK, ossia include nei propri segmenti il numero di sequenza che si aspetta di trovare nel prossimo segmento che riceverà dall'altro host. Se quindi uno dei due computer non è in grado di ricevere gli ACK dall'altro, non potrà neanche sapere qual è il numero di sequenza da usare nel prossimo segmento, e quindi non sarà in grado di mantenere la connessione valida. Esiste la RFC1948, in cui si parla di attacchi basati sul fatto che, in certe implementazioni del TCP/IP, i numeri di sequenza successivamente richiesti alla controparte in sessione sono predicibili. Oggi tale evenienza è piuttosto rara, in quanto la facile predicibilità dei numeri di sequenza è considerata un serio problema di security e viene quindi velocemente corretta, nei software che ne risultano affetti, non appena il produttore ne viene a conoscenza. Possiamo quindi escludere di trovare spam con IP spoofato? A stretto rigore di termini lo potremmo escludere. Vediamo però cosa può succedere. Nell'estate 2001 è stato segnalato che certi spammer dispongono di hardware e software speciali per avvalersi di tecniche di spoofing. Per sintetizzare al massimo, diciamo che lo spammer utilizza un computer con due distinte interfaccie di rete (per esempio, una scheda di rete e un modem). Questo gli consente di avere, sul medesimo computer, due indirizzi IP forniti da due provider diversi: chiamiamoli IP147<br />
<br />
 1 e IP-2. Tramite IP-1, il software dello spammer entra in contatto con i server di mail che ha prescelto per veicolare la propria spazzatura, e in ciascun pacchetto che invia a tali server mette l'altro indirizzo, IP-2, come indirizzo mittente. Pertanto ogni risposta del server di mail viene diretta a IP-2 e quindi, pur seguendo tutt'un'altra strada attraverso la rete, finisce col giungere allo stesso computer di partenza. Il software dello spammer resta quindi in grado di accedere ai numeri di sequenza e quant'altro necessario per proseguire correttamente la sessione tramite IP-1. Il server di mail, dunque, vede soltanto IP-2, ed è quindi IP-2 che comparirà nei Received. Se dunque in ogni caso un indirizzo IP usato dallo spammer resta individuabile e può pertanto essere segnalato all'abuse desk competente, qual è il vantaggio per lo spammer nell'usare questa tecnica? Semplicemente che IP-1, l'indirizzo che resta nascosto, usualmente corrisponde ad una connessione costosa e ad alta capacità, una connessione che consente l'invio veloce di mailing di dimensioni enormi e che sarebbe veramente seccante, per lo spammer, vedersi chiudere. Al contrario, IP-2 può essere una semplice connessione dial-up, poco costosa e che lo spammer può velocemente rimpiazzare non appena gli venisse chiusa. Un vantaggio quindi non eclatante ma che può essere in certi casi anche molto significativo per lo spammer. Cosa possiamo fare noi di fronte a questa situazione? Per la verità non molto: possiamo giusto far saltare allo spammer la connessione su IP-2. Che esista anche l'altra connessione potremmo difficilmente venirlo a sapere, dato che dagli header effettivamente non risulta. Contro questa tecnica possono essere efficaci solamente opere di prevenzione, che prima o poi dovranno diventare pratica comune in tutta la rete. Dell'opera di prevenzione necessaria si è già occupata la RFC2827 del maggio 2000, intitolata "Network Ingress Filtering". In sostanza, il provider che fornisce connettività ad una rete o ad un utente deve applicare un filtraggio a livello IP sui pacchetti provenienti da quella rete o da quell'utente, in modo da bloccare qualsiasi pacchetto non abbia, come indirizzo mittente, uno di quelli assegnati all'utente in questione. In particolare, si parla anche di filtraggio automatico sui remote access server delle reti dial-up, e si auspica che sempre più reti adottino queste raccomandazioni. In effetti è certo che, se tutte le reti fossero filtrate, ci sarebbero molti problemi in meno per tutti, e non solo di spam.<br />
<br />
Può succedere che lo spammer, usando un proxy, riesca ad apparire su un ip diverso da quello a cui si trova? Può succedere ed è una pratica che, fin dal 2001, ha iniziato a diventare sempre più comune. Probabilmente ciò si deve all'arrivo di apposito software per spammer in grado di aprire sessioni SMTP attraverso proxy insicuri. Molti utenti della rete certamente hanno già sentito parlare di proxy: si tratta di un servizio che tutti o quasi i provider offrono ai propri clienti e che può essere usato, per esempio, per navigare il web senza presentare ai siti visitati il proprio vero indirizzo ip. In pratica, il proxy viene interposto e il sito visitato vede l'ip del proxy, senza poter conoscere dove sia realmente l'utente. Durante la navigazione, il proxy riceve le richieste dal browser dell'utente, le passa al server web su cui c'è il sito da visitare e, avuta la risposta, la passa indietro al browser che la aveva richiesta. Quel che probabilmente è meno noto è che ci sono proxy di molti tipi. Se il normale utente di solito usa un proxy http per la navigazione web, in realtà ci sono proxy che possono svolgere questa funzione di intermediario per qualsiasi protocollo che viaggi su TCP. Naturalmente i proxy sono stati pensati per utilizzi legittimi e, se tutto va bene, grazie ad essi si conseguono dei vantaggi in molte situazioni. Dal punto di vista dalla sicurezza c'è però una esigenza ben precisa: ogni proxy deve svolgere il proprio servizio solo ed 148<br />
<br />
 esclusivamente per gli utenti che siano autorizzati ad usarlo. Come poi il proxy debba decidere se un utilizzo è autorizzato o no, la cosa può variare: può deciderlo, per esempio, in base all'appartenenza dell'ip ad un certo blocco, oppure in base ad una autenticazione. Quando invece un proxy accetta di servire le richieste senza svolgere controlli o svolgendoli in maniera inadeguata, si parla di "open proxy", ovvero di proxy insicuro. Un proxy insicuro ha elevata probabilità di diventare uno strumento con cui si commettono abusi. Per esempio, molti newsgroup usenet sono stati spesso e a lungo soggetti a flooding che venivano immessi utilizzando un gran numero di proxy insicuri sparsi per il mondo. Fermare tali abusi risulta spesso complicato, anche se l'aggressore non può avere alcuna certezza di essere imprendibile (normalmente i proxy, anche se insicuri, producono dei log). Quando si parla di proxy insicuri usati dagli spammer, in genere ci si riferisce a diversi tipi di proxy (anche se fondamentalmente fanno tutti la stessa cosa). Esistono, e sono usati dagli spammer, i proxy SOCKS, che per default ascoltano sulla porta TCP/1080 e funzionano secondo l'omonimo protocollo (di cui alla RFC1928). Esistono poi vari tipi di proxy http (che tipicamente ascoltano su porte TCP come la 3128, 80 o 8080). Spesso i proxy http supportano un comando CONNECT (vedasi la RFC2817), col quale si può dirigere una sessione generica su un altro computer, potendo specificare su quale porta. Il comando CONNECT è appunto uno di quelli preferiti dagli spammer, che ovviamente scelgono come destinazione la porta 25 di un mailserver. Possiamo a questo punto osservare che gli spammer fanno anche uso di veri e propri "cavalli di Troia" per diffondere il loro traffico. Un cavallo di Troia è, come noto, un programma malizioso che viene eseguito all'insaputa del legittimo utilizzatore del computer su cui, di solito con l'inganno, è stato impiantato. I trojan, nella maggior parte dei casi, prevedono di essere controllati remotamente, attraverso la rete, da qualcuno che per loro tramite può guadagnare il completo controllo del computer vittima. Ecco allora che, nel 2003, si è iniziato a sentir parlare di trojan appositi per spammer, che gli spammer cercano di impiantare sulle macchine di utenti ignari. Questi trojan, una volta in funzione, contattano via email lo spammer per informarlo dell'indirizzo ip su cui sono attivi. A questo punto lo spammer si connette al trojan e lo utilizza come se fosse, ai fini pratici, un server di posta elettronica. Il risultato è che l'utente infettato, all'oscuro di quel che gli sta succedendo, diventa suo malgrado un punto di origine di spam, nascondendo il vero indirizzo dello spammer (chi indaga sullo spam esaminando gli header, può giungere solo all'indirizzo dell'utente infettato). Dubitiamo che questo tipo di attacco sia possibile da parte dello spammer senza incorrere in reati da codice penale, tuttavia non troviamo che ci sia da stupirsi: gli spammer sono personaggi che, molto spesso, hanno un profilo criminale. Possiamo solo raccomandare a chiunque di essere sempre il più possibile prudente nell'uso del proprio computer: non si mandino in esecuzione programmi della cui affidabilità non si possa essere del tutto certi, e si faccia uso di un antivirus aggiornato.<br />
<br />
A questo punto, che significa questa cosa dei proxy (e dei trojan) per chi investiga sullo spam? Significa che, esaminando gli header come visto nelle pagine precedenti, può succedere che riusciamo a individuare solo una parte del percorso del messaggio di spam, quella avvenuta come posta elettronica vera e propria, attraverso transazioni SMTP. Se, al punto di immissione trovato, esiste un proxy aperto, le possibilità di scoprire il vero ip a cui si trovava lo spammer sono assai scarse. Sono del tutto nulle se si trattava di un trojan. 149<br />
<br />
 Il problema viene combattuto dagli antispammer mediante l'uso di blacklist apposite per i proxy insicuri, oltre che cercando di segnalare la presenza dei proxy aperti agli amministratori della rete in questione, affinché intervengano per farli sistemare. In alcuni casi, è stato possibile ottenere i log dei proxy abusati, risalendo quindi alla connessione originaria dello spammer. Ovviamente per molti di questi proxy non esisterà un amministratore in grado di fornire i log, ma per molti sì (e lo spammer che si accinge ad usare un proxy insicuro può solo essere insicuro pure lui su quel che gli succederà). Un altro strumento di cui gli antispammer si avvalgono per combattere lo spam da proxy è l'adozione di appositi honeypot, ossia di macchine su cui gira un software che si comporta in apparenza come se fosse un proxy insicuro. Tenere in esercizio un sistema del genere, spesso detto "proxypot", è cosa non alla portata di tutti: richiede un connessione permanente, ottima competenza tecnica, attitudini da smanettone software, scaltrezza e molto tempo libero, tuttavia risulta anche essere molto divertente e consente di osservare da vicino molti aspetti interessanti, che non si potrebbero scoprire in altro modo, di come lo spam viene distribuito. Normalmente il gestore del proxypot intercetta i test, con cui gli spammer cercano di verificare se a quell'indirizzo sta un proxy che si riesca a utilizzare, e fanno in modo che i test riescano, che quindi i messaggi di prova vengano effettivamente recapitati allo spammer. A quel punto lo spammer, caduto nella trappola, inizia a usare il proxy per consistenti invii di spam e, ovviamente, il proxypot finge di accettare il tutto regolarmente, questa volta però senza inoltrarlo. Spariscono così nel nulla molti "spam run" (così vengono di solito chiamati i cicli di invio effettuati da uno spammer), che lo spammer crede siano andati regolarmente a segno. Ovviamente il gestore del proxypot vede il vero indirizzo ip da cui lo spammer opera e provvede a segnalarlo al provider del caso.<br />
<br />
Quindi per noi le cose non cambiano molto: all'ip in cui si constata che lo spam è stato originato, c'è comunque un problema, di cui il provider responsabile deve occuparsi. Il problema può essere direttamente lo spammer, oppure un problema di sicurezza dovuto a un proxy mal configurato oppure a un trojan. In caso di proxy o trojan, lo spammer potrebbe riuscire a tenere nascosta la sua connessione originaria. Avremo comunque modo di vedere, nelle successive pagine, che si può colpire lo spammer non solo sulla connessione che ha usato per inviare lo spam, ma anche su altre risorse per lui ben più fastidiose da perdere.<br />
<br />
Indice<br />
<br />
<< Precedente<br />
<br />
Successiva >><br />
<br />
Ultimo aggiornamento: 28 luglio 2003<br />
<br />
Leonardo Collinelli<br />
<br />
150<br />
<br />
 Lezioni sulla lettura degli header Fondamenti<br />
<br />
E' venuto il momento di gingillarsi con un po' di tecnicismi. Cercheremo di vedere quanto occorre, partendo dal punto di vista più elementare possibile e senza richiedere come prerequisito particolari conoscenze di rete (chi ne avesse già, comunque, sarà facilitato). In conseguenza a questa impostazione, la trattazione effettuerà semplificazioni talvolta drastiche, al fine di arrivare più rapidamente ai concetti pratici che servono. L'obiettivo di questa serie di pagine è che, dedicando un po' di tempo per studiarle, chiunque abbia conoscenze anche molto generiche di computer sappia individuare la provenienza delle e-mail che riceve. Come avviene la trasmissione di un messaggio di e-mail Gli header di un messaggio di e-mail In che modo vanno letti questi header? Dopo che ho interpretato gli header, riesco a trovare il nome del mittente? Come avviene la trasmissione di un messaggio di e-mail Quando si spedisce una e-mail da un computer ad un altro attraverso la rete, ciò che succede non è la semplice copia di un file di testo da un disco fisso ad un altro. La principale differenza è che, oltre ai due computer mittente e destinatario, ne sono coinvolti anche altri. Un primo computer che non si vede è quello ove risiede la casella del destinatario. Questo computer, che deve essere per quanto possibile sempre attivo e accessibile in rete, ha il compito di ricevere tutte le e-mail dirette agli utenti che hanno la casella su di esso e conservarle finché ciascun destinatario, con suo comodo, non avrà provveduto a scaricarle. Spesso ci si riferisce a tale computer come POP server. Il mittente, così come il destinatario, sul proprio computer dispone solamente di un client di posta elettronica, ossia un programma in grado di gestire un archivio di e-mail (in arrivo e in partenza), di scaricare la posta in arrivo da un POP server e spedire posta tramite protocollo SMTP (di cui parleremo dopo). Esempi di mail client possono essere Microsoft Exchange o Outlook, Pegasus, o Eudora, per citare solo alcuni tra i più conosciuti. In teoria, il mail client del mittente potrebbe, tramite la rete, aprire una sessione direttemente con il POP server su cui risiede la casella del destinatario, ma ciò in genere non avviene per ragioni pratiche: è opportuno che il client sia configurato per parlare sempre con uno stesso server, demandando a questo il compito di contattare, attraverso la 151<br />
<br />
 rete, il server del destinatario. È pure opportuno che il client parli con un server che sia a lui quanto più vicino possibile, in modo che l'invio di una e-mail possa avvenire con buone performance: parlando direttamente con il server di un destinatario all'altro capo del mondo, sarebbe verisimile subire spesso rallentamenti. Disponendo di un server apposito per la spedizione, il mittente può quindi fare uscire in pochi istanti la e-mail dal proprio computer, disinteressandosi (fino ad un certo punto, ovviamente) di quanto tempo sarà necessario al server per farla giungere a destinazione. Inoltre, se una stessa e-mail deve essere inviata in copia a tanti destinatari che hanno le caselle su vari POP server sparsi per la terra, il mittente passerà al proprio server di spedizione una unica copia del mail: sarà il server a "fare le copie" e contattare tutti i computer destinatari. Pertanto, è consuetudine di tutti i provider mettere a disposizione dei propri clienti anche un server della posta in partenza, di solito chiamato SMTP server. Capita, in qualche caso, che POP server e SMTP server siano la stessa macchina: ciò è possibile in quanto i due servizi vengono svolti attraverso porte distinte. I grossi provider, con decine o centinaia di migliaia di utenti, avranno con ogni probabilità molti POP server e, a seconda del traffico, anche più SMTP server. Risulta così che, in base a criteri di efficienza, ogni e-mail sarà, in generale, smistata attraverso più server sia alla partenza che all'arrivo. Nessuna meraviglia quindi che il protocollo SMTP, usato per il transito dei messaggi di e-mail, sia pensato in modo da rendere agevole questo inoltro per passi successivi. Questa modalità di trattamento delle e-mail viene sfruttata in particolare dai numerosi servizi di e-mail forwarding, i quali consentono di predisporre l'inoltro automatico dei messaggi verso una mailbox di destinazione finale indicata dall'utilizzatore e modificabile a necessità.<br />
<br />
Sapendo questo, passiamo a vedere come è fatto un normale messaggio di e-mail e quali vicissitudini subisce, dal momento in cui il mail client del mittente lo immette in rete, al momento in cui viene consegnato al mail client del destinatario. Gli header di un messaggio di e-mail Il mail client del mittente preparerà il messaggio in una forma di questo genere: From: mario.rossi@nomerete.it (Mario Rossi) To: fverdi@altrarete.it Date: Wed, 15 Apr 1998 14:24:06 +0200 X-Mailer: Gorilla 3.2 (Win95; I) Subject: Richiesta informazioni sulle vs. iniziative Le sarei grato se mi facesse pervenire il programma delle gite per l'estate 98, possibilmente completo dei relativi costi. Ringraziando porgo distinti saluti Mario Rossi 152<br />
<br />
 In questo esempio è importante osservare che, prima del testo del messaggio vero e proprio, si hanno alcune righe scritte nella forma:<br />
<br />
nome-header: valore-testuale Ciascuna di queste righe è un header, e gli standard di rete prescrivono, tra le altre cose, i nomi degli header e la forma in cui deve essere espresso il corrispondente valore testuale. Molti di questi header hanno una funzione evidente: From: e To:, per esempio, sono analoghi all'indirizzo del destinatario e del mittente che, quando si invia una lettera per posta ordinaria, usa scrivere in alto, prima del testo vero e proprio, nel foglio che si include nella busta. Si notano poi la data e ora di spedizione, espresse in vari formati non del tutto comodi da leggere (è compito del mail client effettuare tutte le conversioni). Quanto al campo X-Mailer:, l'esempio dice che, per preparare il messaggio, è stato usato un programma che si chiama "Gorilla" versione 3.2, con alcune altre informazioni secondarie. Per i campi con nomi del tipo X-qualunquecosa: non esistono standard: ogni mail client è libero di inventarsi tutti gli header X- che crede, e con essi comunicare qualunque tipo di informazione: il protocollo ha il compito di farli giungere a destinazione, ignorandoli per ogni altro effetto. La fine degli header è segnalata mediante una riga vuota (che in questo caso è posta dopo il campo Subject:). Il significato di tale riga vuota è quindi che gli header sono finiti e che tutto ciò che segue è il vero e proprio testo del messaggio. Esistono molti altri campi standard che i mail client potrebbero inserire (e spesso lo fanno). Tra questi si può ricordare il Reply-to:, nel quale è possibile indicare un indirizzo di email a cui inviare eventuali risposte, qualora questo debba essere preferibilmente diverso da quello indicato nel campo From:. Dunque, il mail client prepara tutte le righe di testo, header e messaggio, come abbiamo visto sopra, e li passa al server SMTP prescelto. Prima però di vedere che tipo di viaggio fa il nostro testo, fermiamoci a riflettere su una cosa molto importante: chi mette gli header in testa al messaggio da trasmettere è, come abbiamo detto, il mail client, ossia un programma in esecuzione sul computer del mittente. Tale programma è quindi sotto il completo controllo del mittente: questo sceglie quale programma adottare e come configurarlo. Anzi, potrebbe farsi realizzare da qualcuno un programma su misura per le sue esigenze (quando non farselo addirittura lui stesso). Questo in concreto cosa significa: che i valori forniti in tutti quegli header non significano nulla. Normalmente nel campo From: il mittente mette il proprio vero indirizzo, perché normalmente non si manda spam, ma si comunica con qualcuno che si desidera possa rispondere. Lo spammer, nella maggior parte dei casi, non desidera affatto che le sue vittime gli possano rispondere, quindi di solito se ne guarderà bene dal fornire un campo From: autentico. Anche il campo To: non ha valore, poiché non è in base al suo contenuto che si determina la destinazione del messaggio. 153<br />
<br />
 Ho visto molte volte sui newsgroup persone che dicevano: "Ho ricevuto spam che non era neppure destinato a me!". La risposta è semplice: se l'hai ricevuto vuol dire che era proprio destinato a te (o, quanto meno, anche a te). Non bisogna lasciarsi fuorviare dal contenuto del campo To:. Nel campo To: può benissimo essere stato impostato un indirizzo del tipo caroamico@dafarfesso.net e, come vedremo tra poco, nonostante ciò il messaggio arriverà regolarmente a tutti i destinatari prescelti. Vediamo, proprio a questo proposito, un esempio reale: qualche header di un messaggio di spam ricevuto da me. Date: Mon, 09 Feb 1998 23:27:13 -0500 (EST) From: Internet.Services@mio-isp.it Subject: Important Message To: Tim@rhodes.edu Reply-To: Friend@public.net Message-Id: <<209.133.27.38> MAIL@earlthling.com> X-Pmflags: 6336476446536565465365 Comments: Authenticated sender is <Mail.INS.com> X-UIDL: <209.133.27.38> Thank-you, for visiting www.aaaaa.com. ....... Here is the information you requested. [eccetera] Il messaggio era più lungo, tagliamo qui. Notiamo alcune cose. Tanto per incominciare il campo From:, in cui hanno messo un indirizzo di fantasia attestato niente meno che presso il mio stesso provider; quanto al campo To:, compare un destinatario (probabilmente inesistente) presso una università americana. Probabilmente lo spammer mi vuole indurre a pensare che il messaggio sia giunto a me per errore; simili errori, però, nella realtà della rete non si verificano. Ci sono poi vari header che non ci interessa discutere qui: nessuno di essi ha importanza. Vorrei far notare quello che dice: "Authenticated sender is ...": è tutto fumo negli occhi; quando vedete frasi tipo Authenticated sender o simili, non c'è proprio niente di autentico. Questo header, così come quello precedente (X-Pmflags:) viene inserito da Pegasus Mail, un famoso programma mail client. Non è detto però che questo messaggio sia effettivamente stato inviato usando Pegasus, più probabilmente è stato usato un client costruito apposta per spammer (ne esistono), che cerca di simulare l'uso di Pegasus. Possiamo anche dare un'occhiata alle prime righe del messaggio: notate il tentativo di far passare l'e-mail come sollecitata ("grazie per aver visitato il nostro sito", che io ovviamente non avevo visitato affatto, "ecco l'informazione che avevi richiesto" eccetera). Tutti questi trucchi non valgono nulla: l'importante è non farsene confondere. 154<br />
<br />
 Quindi, di regola, lo spammer configurerà il proprio software in modo da nascondere il più possibile ogni sua traccia e, in molti casi, cercherà addirittura di inserire degli header fasulli per trarre in inganno chi cercasse di individuarlo. Ma torniamo a bomba. Il mail client del mittente apre una sessione sulla porta 25 del server SMTP. Ha luogo un dialogo come quello che segue; vediamo qui come alternativamente si susseguano le risposte del server e gli input forniti dal mail client. Le risposte ed i messaggi inviati dal server iniziano tutti con un codice numerico di tre cifre, seguito da uno spazio e da un testo che ne chiarisce il significato. Il codice numerico è comunque sufficiente, secondo gli standard, per individuare univocamente il significato della riga e determinare quale debba essere il successivo passo del dialogo. Qualora il server dovesse segnalare un errore, emetterebbe una riga in cui il codice numerico inizierebbe con la cifra '5' (così stabiliscono gli standard). In astratto, comunque, il mittente potrebbe anche fare a meno del mail client: gli basterebbe collegarsi al server mediante telnet ed eseguire a mano tutto ciò che il mail client farebbe automaticamente. Sarebbe molto più scomodo ma possibile.<br />
<br />
220 mail.nomerete.it ESMTP server (Post.Office v3.1.2 release (PO203-101c)...) ready Wed, 15 Apr 1998 14:26:31 +0200 HELO mariorossi 250 mail.nomerete.it MAIL FROM:<mrossi@nomerete.it> 250 Sender <mrossi@nomerete.it> Ok RCPT TO:<fverdi@altrarete.it> 250 Recipient <fverdi@altrarete.it> Ok DATA 354 Ok Send data ending with <CRLF>.<CRLF> From: mrossi@nomerete.it (Mario Rossi) To: fverdi@altrarete.it Date: Wed, 15 Apr 1998 14:24:06 +0200 X-Mailer: Gorilla 3.2 (Win95; I) Subject: Richiesta informazioni sulle vs. iniziative Le sarei grato se mi facesse pervenire il programma delle gite per l'estate 98, possibilmente completo dei relativi costi. Ringraziando porgo distinti saluti Mario Rossi . 250 Message received: 19980415162853.AAA24735@mail.nomerete. it QUIT 155<br />
<br />
 221 mail.nomerete.it ESMTP server closing connection Dunque, vengono dati al server alcuni comandi previsti dal protocollo SMTP, tra i quali vale la pena di citare: HELO Identifica il computer che si sta rivolgendo al server Nell'esempio, equivale a dire: "Salve, sono mariorossi". MAIL Richiede al server ricevente l'accettazione di un messaggio di e-mail per l'inoltro Questo comando dice al server di adeguare il proprio stato interno alla transazione che sta iniziando. Con il parametro FROM: (da non confondere con l'header 'From:' contenuto all'interno del messaggio), viene indicato al server ricevente l'indirizzo di ritorno al quale riportare eventuali errori (usualmente solo la casella postale del mittente). RCPT Indica un destinatario cui recapitare il messaggio Usualmente contiene solo la indicazione di una casella postale. Si noti che è questo comando a determinare chi riceverà il messaggio, non il campo 'To:' contenuto negli header. Lo spammer farà in modo che al server vengano dati, uno dopo l'altro, qualche centinaia (o centinaia di migliaia) di comandi RCPT, ciascuno con il vero indirizzo di un differente destinatario, e tutti costoro riceveranno una copia del messaggio. A seconda di quanti sono, il server potrebbe restare impegnato per giorni a lavorare per lo spammer. DATA Dice al server di prepararsi a ricevere il testo del messaggio Dopo il comando DATA, si passeranno al server tutte le righe del messaggio, una per una, senza ricevere ulteriori risposte se non alla fine. Si segnala la fine del messaggio inviando una riga che contenga solo un punto ('.'). QUIT Chiede al server di chiudere la connessione Nota al comando MAIL. Quando un server, dopo aver accettato un messaggio, scoprisse che è impossibile consegnarlo, deve generare una email di avviso dell'errore (il cosidetto bounce) e inviarlo all'indirizzo indicato nel parametro FROM: del comando MAIL. Per evitare, in caso di errore nella consegna del bounce, un nuovo bounce e così eventualmente una situazione di loop, è consuetudine che, nel comando MAIL con cui sono inviati i messaggi di bounce, sia specificato FROM:<> È richiesto dagli standard, pertanto, che i server non considerino il parametro FROM: vuoto come un errore per causa del quale rifiutare un messaggio in arrivo.<br />
<br />
Per saperne di più su questi comandi e sugli altri non citati qui, si può consultare la RFC821 e, per il formato degli header e dei messaggi in generale, la RFC822. Quanto all'uso di telnet per effettuare a mano transazioni SMTP o secondo vari altri protocolli di uso comune, si possono trovare efficaci riassunti sul ricchissimo sito di HF (Davide Veneziano) http://www.vene.ws/. 156<br />
<br />
 Ora vediamo che fa il nostro SMTP server dopo aver accettato il messaggio per l'inoltro. Cercherà di contattare il mail server destinatario e, una volta riuscito a stabilire una sessione con esso, gli passerà il messaggio usando lo stesso identico meccanismo che abbiamo appena visto applicare da parte del mail client. Che succedesse questo, in effetti, potevamo aspettarcelo; la novità è che, al nuovo server, il messaggio non verrà passato identico a come era stato preparato dal mail client nel passo precedente: al messaggio verranno aggiunti nuovi header (generalmente un paio), per lasciare traccia del fatto che sia transitato da quel server. Vediamo come diventa: Received: from mariorossi (ppp26-milano.nomerete.it [194.188.15.26]) by mail.nomerete.it (8.8.5/8.8.5) with SMTP id RU387493 for <fverdi@altrarete.it>; Wed, 15 Apr 1998 14:26:32 +0200 (METDST) From: mario.rossi@nomerete.it (Mario Rossi) To: fverdi@altrarete.it Date: Wed, 15 Apr 1998 14:24:06 +0200 Message-ID: <3754F6E5.BA67D052@nomerete.it> X-Mailer: Gorilla 3.2 (Win95; I) Subject: Richiesta informazioni sulle vs. iniziative Il seguito del messaggio è tutto come prima. Vediamo dunque che è stato inserito nel mezzo un header 'Message-ID:', mentre è stato inserito in testa un header 'Received:'. Sul Message-ID non c'è molto da dire: è una specie di numero di matricola che accompagnerà il messaggio per tutta la vita. La forma usuale di questo campo è del tipo <una-qualsiasi-stringa@nome-host> e l'host che lo genera ne deve solamente garantire l'unicità. Normalmente la stringa non ha alcun significato, pertanto ai fini che ci interessano questo campo non dà indicazioni utili. Ben diverso è il discorso a proposito dell'header 'Received:': questo header ha finalmente un valore oggettivo, ed è ciò su cui dobbiamo contare per riuscire a individuare il nostro spammer. Aggiungendo l'header Received: il server che ha veicolato il messaggio dice, in sostanza: "questo messaggio l'ho trasportato io, che lo avevo ricevuto dal seguente indirizzo". A pensarci bene, è stato una fortuna il fatto che, quando la rete nacque, fosse una rete militare: nell'impostazione architetturale e dei protocolli entrò così anche una speciale attenzione alla tracciabilità degli eventi di rete, al fatto che si potesse individuare dove si erano generati e per dove erano passati. Così oggi abbiamo ottime possibilità di risalire allo spammer: i protocolli di rete stanno dalla nostra parte, e questo gli spammer sembrano non volerlo capire (peggio per loro!). Ma prendiamo in esame il nostro header Received: 157<br />
<br />
 Received: from mariorossi (ppp26-milano.nomerete.it [194.188.15.26]) by mail.nomerete.it (8.8.5/8.8.5) with SMTP id RU387493 for <fverdi@altrarete.it>; Wed, 15 Apr 1998 14:26:32 +0200 (METDST) Il server che ha inserito l'header dichiara il proprio nome dopo la parola 'by'. Nella sostanza, l'header va letto come segue: "Questo messaggio è stato ricevuto su mail.nomerete.it, proveniente da qualcuno che si è presentato come mariorossi e che comunque aveva l'indirizzo IP 194.188.15.26. Tale indirizzo risulta corrispondere alla risorsa di nome ppp26-milano.nomerete.it" (Vedremo in successivi capitoli che cosa sia questo nome e come venga ricavato a partire dall'indirizzo IP.) Premesso che, a seconda di quale software sia in uso sul server, l'header potrebbe avere anche un aspetto leggermente diverso (cosa che, ovviamente, non ci semplifica la vita), la sintassi riportata nell'esempio è quella più facile a incontrarsi. Si noti che qui è presente una parola from non seguita dai due punti. Dopo questo from c'è il nome con cui chi ha passato il messaggio al server si è presentato, per mezzo del comando HELO. Quindi, se questo fosse un messaggio di spam e dovessimo scoprire da dove viene, potremmo ignorare tranquillamente il mariorossi indicato qui. Ciò che c'è tra parentesi è invece quel che si deve guardare: il server che ha messo questo header ci assicura di avere ricevuto il messaggio dalla risorsa il cui indirizzo IP è indicato tra parentesi quadre, e di cui è dato anche il nome. Nell'esempio ho inventato sia il nome che l'indirizzo IP, ma è in effetti frequente vedere nomi che, da come sono composti, fanno capire che si tratta di connessioni dial-up. Con un nome come quello dell'esempio si potrà ipotizzare che l'utente in questione, per inviare il messaggio, si sia connesso al punto di accesso di Milano del suo provider, che gli sia capitato il modem numero 26 e che, pertanto, gli sia stato assegnato l'indirizzo riportato lì. Tra le altre cose che vediamo qui c'è una serie di numeri tra parentesi tonde: (8.8.5/8.8.5). Questo ovviamente non è un indirizzo IP, ma solamente l'indicazione della versione del software installato sul server. Poi c'è 'SMTP id RU387493'. Questo è un numero di serie che il server ha assegnato alla transazione di inoltro del messaggio in questione. Infine c'è l'indicazione del destinatario e la data/ora. Ma non è finita. Il server vede che il dominio destinatario è 'altrarete.it' e, interrogato il DNS (di cui parleremo tra poco), scopre che il server a cui passare le e-mail dirette a quel dominio si chiama plutus.altrarete.it. Ecco allora un altro passaggio, al termine del quale il nostro messaggio sarà diventato così: Received: from nomerete.it (mail.nomerete.it [194.184.145.216]) by plutus.altrarete.it (8.8.5/8.8.5) with SMTP id 158<br />
<br />
 GC502624 for <fverdi@altrarete.it>; Wed, 15 Apr 1998 14:27:15 +0200 (METDST) Received: from mariorossi (ppp26-milano.nomerete.it [194.188.15.26]) by mail.nomerete.it (8.8.5/8.8.5) with SMTP id RU387493 for <fverdi@altrarete.it>; Wed, 15 Apr 1998 14:26:32 +0200 (METDST) From: mario.rossi@nomerete.it (Mario Rossi) To: fverdi@altrarete.it Date: Wed, 15 Apr 1998 14:24:06 +0200 Message-ID: <3754F6E5.BA67D052@nomerete.it> X-Mailer: Gorilla 3.2 (Win95; I) Subject: Richiesta informazioni sulle vs. iniziative Notate che il successivo server ad avere gestito il messaggio ha aggiunto il proprio 'Received:' in testa. Poniamo ora che la mailbox del destinatario sia su un altro server: occorre un ultimo passaggio. Il server su siamo giunti ora sarà configurato in modo da passare il messaggio alla sua destinazione. Pure l'ultimo server aggiungerà il suo 'Received:', così quando finalmente il destinatario riceverà la e-mail, si ritroverà qualcosa del genere: Received: from plutus (plutus.altrarete.it [202.113.12.45]) by mbox-b.altrarete.it (8.8.3/8.7.5) with SMTP id WH755911 for <fverdi@altrarete.it>; Wed, 15 Apr 1998 14:27:18 +0200 (METDST) Received: from nomerete.it (mail.nomerete.it [194.184.145.216]) by plutus.altrarete.it (8.8.5/8.8.5) with SMTP id GC502624 for <fverdi@altrarete.it>; Wed, 15 Apr 1998 14:27:15 +0200 (METDST) Received: from mariorossi (ppp26-milano.nomerete.it [194.188.15.26]) by mail.nomerete.it (8.8.5/8.8.5) with SMTP id RU387493 for <fverdi@altrarete.it>; Wed, 15 Apr 1998 14:26:32 +0200 (METDST) From: mario.rossi@nomerete.it (Mario Rossi) To: fverdi@altrarete.it Date: Wed, 15 Apr 1998 14:24:06 +0200 Message-ID: <3754F6E5.BA67D052@nomerete.it> X-Mailer: Gorilla 3.2 (Win95; I) 159<br />
<br />
 Subject: Richiesta informazioni sulle vs. iniziative La morale di questa storia è che, quando si riceve una e-mail, gli unici header significativi per individuarne la provenienza sono i 'Received:'. Occorre trovare, nel proprio mail client, la modalità per visualizzare tutti gli header (che, normalmente, non vengono presentati all'utente insieme al corpo del vero e proprio messaggio); quasi tutti i mail client comunque danno la possibilità di vedere gli header completi anche se, ovviamente, ognuno a modo proprio. Nel già citato sito di Davide Veneziano potete trovare le indicazioni su come ottenere gli header dai più conosciuti mail client. Se il vostro client non vi desse la possibilità di visualizzare gli header completi, cambiatelo: non potreste fare nulla per difendervi dallo spam. Se ve li visualizza in forma alterata o comunque pasticciata (qualche mailreader lo fa nell'inopportuno tentativo di renderli più leggibili), sarebbe bene ugualmente cambiare client al fine di non avere inutili difficoltà nel lavoro di analisi. L'ideale sarebbe un mailreader che consentisse di salvare o copiare in clipboard il messaggio completo ed in forma semplicemente testuale: tutti gli header, la riga di separazione e il testo. Una volta messi a nudo gli header, si inizierà a guardare i 'Received:' nell'ordine in cui compaiono (dall'alto al basso), il che equivale a percorrere la catena dei server a ritroso, dal ricevente fino al mittente. E' bene quindi familiarizzare innanzitutto con i primi header che, venendo aggiunti dai server su cui si trova la vostra mailbox, tenderanno ad avere una struttura abbastanza stabile nel tempo, salvo quando il fornitore della mailbox (in generale, ma non necessariamente, il vostro provider) cambiasse per varie ragioni la configurazione dei propri sistemi. Potreste quindi cominciare col prendere in esame qualche e-mail che vi sia stato "onestamente" spedito da sistemi e provider differenti da varie persone che conoscete. Confrontate gli header 'Received:' osservando fino a dove sono simili, da dove iniziano ad essere sensibilmente diversi e come vanno a finire. Già, perchè la catena degli header è significativa soprattutto verso la fine. L'esempio di prima era il più possibile lineare, ma si hanno spesso degli header diversi e non sempre semplici da interpretare. E' opportuno abituarsi anche ad header 'Received:' non significativi inseriti da vari software che elaborano il messaggio lungo la strada. Per esempio, Qmail inserisce un 'Received:' giusto per dire "ci sono anch'io": Received: (qmail 10377 invoked from network); 27 Nov 1998 17:57:28 +0100 Per questi motivi, ho raccolto gli header di un po' di e-mail 'regolari', ossia non spam, da me ricevuti. Sono esempi reali, che presentano una certa varietà di situazioni. Li ho messi in una pagina a parte, che trovate seguendo questo link, in quanto potreste preferire di non leggerli ora. Raccomanderei comunque che, prima di iniziare a ragionare su veri messaggi di spam, prendeste confidenza con ciò che si trova nelle e-mail regolari. Questo vi potrebbe aiutare a fare pratica sapendo già la soluzione. Soprattutto sarebbe bene che, oltre ai miei 160<br />
<br />
 esempi, ve ne procuraste di vostri: con ciò imparereste più rapidamente a conoscere gli header che il vostro provider aggiunge in testa ai messaggi in arrivo. In che modo vanno letti questi header ? Abbiamo visto che parecchi header sono decisamente inattendibili perché vengono propagati così come li ha forniti il computer del mittente. Quelli però che vengono aggiunti dopo hanno la garanzia implicita da parte dei server che li hanno aggiunti, si tratta di capire caso per caso quanto ci si possa fidare di ciascun server. Per esempio, potrebbe essere che il primo server nella catena dei passaggi appartenesse pure lui allo spammer; l'header 'Received:' potrebbe in questo caso essere perfino corretto, ma non sarebbe molto interessante: se abbiamo trovato il server, a quel punto abbiamo trovato anche lo spammer, l'importante è solo accorgersene. Sembra strano? Beh, gli spammer meglio organizzati sono anche provider di sè stessi. Si possono pure avere dei casi in cui un normale utente con connessione dial-up, tanto per confondere le acque, tira su sul proprio pc un server SMTP: se ne trovano anche per Windows, addirittura qualcuno gratuito. All'altro estremo della catena abbiamo invece gli header messi dal nostro stesso provider, e questi vivaddio sono attendibili per forza. Dovremo quindi procedere nella lettura degli header finché troveremo il primo (in ordine di tempo) degli header 'Received:' aggiunti dal nostro provider, ed aggrapparci al nome risorsa ed indirizzo IP che quell'header indica come provenienza esterna del messaggio. La risorsa potrebbe già essere un nodo dial-up o comunque il computer da cui il messaggio è stato inserito nella rete, ma lo è solo in una minoranza di casi. Come si diceva, per lo spammer è assai importante usare un server SMTP che non sia sul suo computer, visti i grossi volumi di copie che vengono spediti per ogni messaggio. Se effettivamente lo spammer ha usato un server SMTP, il primo degli header inseriti dal nostro provider menzionerà tale server come provenienza e, subito dopo, avremo un altro 'Received:'. Per ogni 'Received:' dovremo sincerarci della sua attendibilità nell'unico modo possibile, ossia verificando che sia confermato dall'header precedente (precedente nel messaggio, successivo nel tempo). Per ogni header si dovrà verificare se il server che lo ha messo (indicato dopo la parola 'by') è effettivamente quello che l'header precedente aveva dichiarato come provenienza. Siccome poi la provenienza, generalmente anche se non sempre, viene indicata nella duplice forma del nome risorsa e dell'indirizzo IP, sarà anche il caso di verificare se i due effettivamente si corrispondono. In altre parole, bisognerà ricostruire il quadro chiaro dei passi certi che il messaggio ha fatto, considerando che ogni passo deve avere una sua ragion d'essere. In particolare, se percorrendo a ritroso la strada compiuta dal messaggio si giungesse ad un nodo dial-up (in genere dal nome si riesce ad intuire che si tratta di un dial-up), allora eventuali successivi 'Received:' sarebbero privi di interesse: il nodo dial-up è il punto in cui il messaggio ha avuto effettivamente origine. Parte importante del quadro complessivo è anche costituita da un po' di notizie e informazioni sulle organizzazioni proprietarie dei computer che hanno veicolato il messaggio fino a noi. Da tutto questo deriva che, per indagare su un messaggio di spam non si può essere a tavolino: bisogna essere on-line, perché ci occorrono parecchie informazioni che in rete si trovano. I prossimi capitoli, che illustreranno casi pratici, tratteranno anche del reperimento di tali informazioni. 161<br />
<br />
 Dopo che ho interpretato gli header, riesco a trovare il nome del mittente ? Questa è forse la domanda che mi viene posta più spesso. Probabilmente perché, oltre allo spam, esiste pure un problema di molestie personali via email, problema che si può credere stia crescendo di diffusione col crescere del numero di utenti internet italiani. Si tratta di un problema del tutto diverso, del quale questo sito non si occupa. Alla domanda possiamo tuttavia rispondere. Poniamo dunque di avere concluso con successo l'interpretazione degli header. Ciò di cui disponiamo è quindi un indirizzo IP: può essere l'indirizzo al quale si trovava il mittente o può essere l'indirizzo di un server dietro il quale il mittente si nascondeva. Inoltre potrebbe succedere, a seconda dei casi, che avessimo pure un indirizzo di email al quale si sia constatato che risponde il mittente (ovvero un qualche sconosciuto che si vorrebbe identificare). Se prendiamo come punto di partenza l'indirizzo IP, quel che si riesce a fare (lo vedremo nelle successive pagine) è identificare la rete alla quale quell'indirizzo è stato assegnato. Della rete in questione possiamo anche trovare, in molti casi, l'indirizzo, il telefono e i nomi dei responsabili. Nulla però possiamo sapere su chi siano i loro utenti. Se la rete in questione è un provider per l'utenza privata, è anche probabile che i suoi indirizzi IP siano assegnati agli utenti in maniera dinamica, ossia in modo che si succedano nel tempo vari utenti sullo stesso indirizzo. In presenza di indirizzi dinamici, i pochi indizi che si possono fortunosamente raccogliere risultano normalmente insufficienti anche solo per delineare qualche sospetto. In questi casi, comunque, il provider in questione ha i mezzi tecnici per individuare l'utente che si trovava su un dato indirizzo ad un preciso istante di tempo. Trattandosi di un suo cliente, è a questo punto da pensarsi che su di lui abbia tutti i dati (nome, indirizzo, magari pure una fotocopia della carta di identità, se ha provveduto a richiedergliela per attivare il contratto). Inoltre, molti provider per l'utenza dial-up registrano l'identificativo chiamante per tutti i collegamenti, col che sanno anche da quale numero di telefono l'abbonato si è collegato in rete. Il problema è che tutti questi dati, a voi, il provider non li dirà mai. Per fortuna. Non dimentichiamo che la stragrande maggioranza degli utenti sono persone oneste, che non infastidiscono nessuno e che hanno tutto il diritto di tenere per sè il proprio nome, se così preferiscono. I provider quindi devono mantenere una doverosa riservatezza sulla identità dei loro clienti. Il problema si pone se un utente fa qualcosa di male: in caso di abusi di rete il provider può revocargli il servizio anche mantenendo riservato ogni dato, mentre in caso di reati perseguibili ai sensi di legge il provider dovrà fornire alla magistratura ogni informazione che questa gli richiedesse. Quindi in caso di molestie personali via email, se ritenete opportuno sporgere denuncia potete contare sul fatto che la magistratura è in grado di farsi dare il nome del molestatore (almeno se il provider in questione è italiano). Se non ci sono gli estremi per una denuncia, allora il mittente della mail resterà per forza anonimo. Se avete un indirizzo di mail di cui vorreste identificare l'utilizzatore, il discorso non è 162<br />
<br />
 molto diverso. La parte significativa, quella dopo la chiocciola, può farvi arrivare ad un server. Chi però acceda ad una certa casella che risiede su quel server, lo sa solo il provider che lo gestisce, al che (come direbbero i matematici) ricadiamo nel caso precedente. Su questo problema non credo proprio di saper dire altro. Nella prossima pagina torneremo ad occuparci di spam.<br />
<br />
Indice<br />
<br />
<< Precedente<br />
<br />
Successiva >><br />
<br />
Ultimo aggiornamento: 01 marzo 2002<br />
<br />
Leonardo Collinelli<br />
<br />
163<br />
<br />
 Ulteriori esempi di header di e-mail Tutti questi esempi (in cui sono stati pasticciati nomi e indirizzi per togliere ogni riferimento reale) sono tratti da mail inviatemi legittimamente, in cui il mittente non usava alcuna tecnica per nascondere la propria provenienza. Tutti i nomi e indirizzi sono comunque alterati, quindi qualora si provasse a verificarli online non quadrerebbero. Intendo inserire in questa pagina, nel futuro, altri esempi che mi capitassero e risultassero interessanti. 1) Vediamo come primo esempio un messaggio di prova che mi sono spedito dall'ufficio. In ufficio ho il computer connesso ad una rete locale interna; su tale rete funziona il sistema di posta aziendale in gateway con Internet. Ecco gli header che trovo nel messaggio: Return-Path: <Leonardo.Collinelli@nomeazienda.it> Received: from mail.secondonome-mio-isp.it (mail.mio-isp.it [194.243.154.49]) by mbox.terzonome-mio-isp.it (8.8.5/8.8.5) with ESMTP id LAA28360 for <mia-casella@box1.mio-isp.it>; Thu, 23 Apr 1998 11:17:21 +0200 (METDST) Received: from un-host.plutone.it (un-host.plutone.it [193.43.2.1]) by mail.secondonome-mio-isp.it (8.8.4/8.8.4) with ESMTP id LAA18670 for <mia-casella@mio-isp.it>; Thu, 23 Apr 1998 11:17:16 +0200 (MET DST) Received: from www.nomeazienda.it (www.nomeazienda.it [193.193.193.193]) by un-host.plutone.it (8.8.6/8.8.6/PLUTone 3.1) with ESMTP id LAA10957 for <mia-casella@mio-isp.it>; Thu, 23 Apr 1998 11:16:56 +0200 (MDT) Message-Id: <199804230916.LAA10957@un-host.plutone.it> Received: by GWENDY with Internet Mail Service (5.0.1458.49) id <JK00DSJL>; Thu, 23 Apr 1998 11:16:21 +0100 From: Leonardo Collinelli <Leonardo.Collinelli@nomeazienda. it> To: "'MeStessoSuMioIsp'" <mia-casella@mio-isp.it> 164<br />
<br />
 Subject: Prova Date: Thu, 23 Apr 1998 10:14:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) In questo esempio possiamo osservare un po' di cose: ●<br />
<br />
●<br />
<br />
●<br />
<br />
Il mio ISP fa uso di più nomi di domini, ma è sempre lui. Questo è opportuno saperlo da subito. Lo si potrebbe comunque accertare mediante interrogazione del DNS. Il mio ufficio, titolare del nome di dominio 'nomeazienda.it', non spedisce direttamente le e-mail all'esterno, ma le inoltra ad un apposito server di nome 'unhost.plutone.it'. Il dominio 'plutone.it' non appartiene al mio ufficio, ma al suo upstream provider, ossia al provider che fornisce la connettività Internet al mio ufficio (e che, evidentemente, effettua per esso questo servizio di relay della posta). L'ultimo header 'Received:' ha struttura completamente diversa dal consueto. Si tratta di un passaggio interno su rete locale, che viene semplicemente segnalato con il suo numero identificativo e con il nome del server che l'ha effettuato (GWENDY).<br />
<br />
2) Ecco adesso il giro inverso, ossia un mail che ho spedito dalla casella presso il mio ISP a quella che ho in ufficio. Received: from mail.mio-isp.it by www.nomeazienda.it with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1458.49) id 16MASVSB; Sat, 14 Feb 1998 17:38:20 +0100 Received: from hostname-miopc.mio-isp.it (Forli3-45.mio-isp. it [195.195.195.195]) by mail.mio-isp.it (8.8.4/8.8.5) with SMTP id RAA26554 for <leonardo.collinelli@nomeazienda.it>; Sat, 14 Feb 1998 17:35:49 +0100 (MET) Message-Id: <199802141635.RAA26554@mail.mio-isp.it> From: "Leonardo Collinelli" <miacasella@box1.mio-isp.it> To: leonardo.collinelli@nomeazienda.it Date: Sat, 14 Feb 1998 17:35:33 +0000 MIME-Version: 1.0 Content-type: Multipart/Mixed; boundary=Message-Boundary29679 Subject: Prova Priority: normal Qui va osservato il primo header 'Received:', inserito dal server che mi ha consegnato il messaggio in ufficio: adotta un formato non molto frequente, in cui il 'from' riporta solo il nome della risorsa di provenienza, omettendo sia l'identificativo fornito con l'HELO sia 165<br />
<br />
 l'indirizzo IP. Fortunatamente, quanto viene indicato è l'effettivo nome della risorsa di provenienza, cosa che consente di proseguire all'esame degli header successivi con la necessaria sicurezza. Ciononostante, header di questo formato sono tutto sommato più scomodi. Il secondo 'Received:', messo dal server SMTP del mio provider, ha invece il più rassicurante aspetto tradizionale, riportando l'identificativo fornito con l'HELO e, tra parentesi, la coppia nomerisorsa/indirizzo. In questo secondo 'Received:' osserviamo che: ●<br />
<br />
●<br />
<br />
l'identificativo riportato subito dopo la parola 'from' comprende l'host-name inserito nella configurazione del mio computer tramite le impostazioni del TCP/IP (nel mio caso, usando Windows95, l'impostazione era avvenuta da Pannello di controllo, Rete, selezionata la riga 'TCP/IP', tasto Proprietà, pagina Configurazione DNS). In molti altri casi si trova, dopo il medesimo from, la parola 'localhost' o 'default' o altro. dal nome risorsa indicato tra parentesi si intuisce che si tratta di un nodo dial-up, e si capisce anche chiaramente in quale città mi trovavo quando ho spedito il messaggio (escludendo che fossi da tutt'altra parte in interurbana, ovviamente). E' appena il caso di precisare che Forli3-45 non sono io, ma che ero io in quel momento; ogni volta che mi ricollego, pur usando sempre il punto d'accesso di Forlì, possono casualmente cambiare, ogni volta, sia il 3 che il 45<br />
<br />
3) Received: from mail.mio-isp.it by mbox.terzonome-mio-isp.it with ESMTP (1.39.111.2/16.2) id AA230180038; Mon, 2 Feb 1998 07:13:58 +0100 Return-Path: <xxx@xxx.com> Received: from mail001.mediayyyy.com (mail001.mediayyyy.com [205.205.205.9]) by mail.mio-isp.it (8.8.4/8.8.4) with SMTP id HAA04780 for <miacasella@mio-isp.it>; Mon, 2 Feb 1998 07:13:54 +0100 (MET) Message-Id: <199802020613.HAA04780@mail.mio-isp.it> Received: (qmail 17974 invoked from network); 2 Feb 1998 06:12:09 -0000 Received: from cm2081389919.cableco-xx.com (HELO ? 208.138.99.19?) (208.138.99.19) by mail001.mediayyyy.com with SMTP; 2 Feb 1998 06:12:09 0000 Si noti qui che, nel primo header, manca l'indicazione tra parentesi su quale fosse l'effettivo computer a contattare 'mbox.terzonome-mio-isp.it' per passargli il messaggio. In realtà, sapendo che sono tutte macchine del mio ISP, ciò non costituisce un problema. Però la cosa non è affatto simpatica; tant'è che, dopo qualche tempo, ho visto che era stata cambiata la configurazione delle macchine e/o del software in modo da eliminare l'inconveniente. 166<br />
<br />
 4) Received: from mail.mio-isp.it by mbox.terzonome-mio-isp.it with ESMTP (1.39.111.2/16.2) id AA028632235; Mon, 2 Mar 1998 08:03:55 +0100 Return-Path: <zzzz@kkkkworld.com> Received: from www14.jjjj.net (root@www14.jjjj.net [209.209.209.1]) by mail.mio-isp.it (8.8.4/8.8.4) with ESMTP id IAA04226 for <miacasella@mio-isp.it>; Mon, 2 Mar 1998 08:03:53 +0100 (MET) Received: from default (orange-port6.hhh.net [205.245.175.26]) by www14.jjjj.net (8.8.8/8.6.9) with SMTP id CAA08360 for <miacasella@mio-isp.it>; Mon, 2 Mar 1998 02:03:52 -0500 (EST) Message-Id: <3.0.1.32.19980302013117.006edc58@kkkkworld.com> Si noti qui che qualche header 'Received:' può anche non andare a capo, ma apparire su un'unica riga. Se però, per comodità di lettura, fosse inserito suddiviso su più righe, le righe di continuazione sono di regola indentate rispetto alla prima.<br />
<br />
Indice<br />
<br />
<< Precedente<br />
<br />
Ultimo aggiornamento: 26 agostoo 1998<br />
<br />
Leonardo Collinelli<br />
<br />
167<br />
<br />
 Spammer con sito web Caso pratico num. 5<br />
<br />
In molti casi, può anche essere che gli spammer siano "pesci piccoli" che, di notte in uno stanzino, fanno girare il loro software con un normale collegamento dial-up. Ogni tanto, costoro devono cercare un nuovo provider e, una volta esauriti tutti quelli della loro zona, si spera che considerino l'eventualità di cambiare mestiere. In questo caso vedremo degli spammer un po' più industrializzati e con una presenza in rete meglio organizzata. Un caso tecnicamente non più complesso dei precedenti (anzi, per certi aspetti più semplice), ma certamente più delicato sul piano delle azioni da intraprendere. Si tratta di un caso che evidenzia come, spesso, sia importante e decisivo lo sforzo collettivo e la pressione esercitata dalla comunità antispam. In questo caso ho ricevuto diversi messaggi di spam, che non sto a riprodurre tutti. Il primo di questi, però, merita senz'altro la riproduzione integrale: è interessante leggerlo, per rendersi conto fino a quale punto certuni possano arrivare. Return-Path: <ALEX@gisnet.net rel="nofollow"> Received: from fes3.cs.mio-isp.it (mail2.mio-isp.it [194.243. xxx.yyy]) by mbox.altronome-mioisp.it (8.8.5/8.8.5) with ESMTP id JAA25885; Fri, 24 Apr 1998 09:28:51 +0200 (METDST) From: ALEX@gisnet.net Received: from 153.35.239.202 (1Cust74.max13.san-francisco. ca.ms.uu.net [153.35.239.202]) by fes3.cs.mio-isp.it (8.8.4/8.8.4) with SMTP id JAA24820; Fri, 24 Apr 1998 09:28:42 +0200 (MET DST) Date: Fri, 24 Apr 1998 09:28:42 +0200 (MET DST) Message-Id: <199804240728.JAA24820@fes3.cs.mio-isp.it> To: .WKYS@fes3.cs.mio-isp.it Subject: 40 MILLION EMAIL ADDRESSES CHEAP PRICE!!! Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-UIDL: ee953a7b8cd8798f43436464d00bb190 40 MILLION EMAILS FOR SALE<br />
<br />
super low price! 168<br />
<br />
 Our Fresh Addresses Will Bring You Incredible Results!<br />
<br />
http://207.93.198.x/webhost If you REALLY want to get the word out regarding your services or products, Bulk Email is the BEST way to do so, PERIOD! Advertising in newsroups is good but you're competing with hundreds even THOUSANDS of other ads. Will your customer's see YOUR ad in the midst of all the others? Bulk Email will allow you to DIRECTLY contact your potential customers. They are much more likely to take the time to read about what you have to offer if it was as easy as reading it via email rather than searching through countless postings in newsgroups. There is a secret to effective Bulk Email...HIGH QUALITY LISTS! There are SO many companies offering bulk email lists that are months old and it's not uncommen for HALF of those addresses to be outdated and undeliverable. Also, most companies offer lists that they have compiled from addresses extracted from newsgroups, THE WORST PLACE TO GET ADDRESSES FROM! Why? Simple, most people that post messages in newsgroups KNOW that their addresses might be extracted so they use FAKE addresses resulting in undeliverable messages. You can now get FRESH, HIGH QUALITY lists of addresses that have NOT been extracted from newsgroups! Our lists are compiled of addresses that we have extracted from member directories and help forums where you CAN NOT use fake email addresses! Also, our lists are LESS than 1 month old and are CONSTANTLY updated to remove dupes and undeliverables! Our emails can be downloaded at a web site or be shipped to your home in disks. Our emails are in text form, one line per email. This form is compatible with Pegasus, Eudora, Microsoft email programs, and 169<br />
<br />
 many other popular email softwares. We believe that if you have a great product or service for everyone, you should let everyone know. Do it cost effectively today! Sending emails doesn't cost you one cent! In just one night, millions of people will know about your company or your corporation. Market your company by reaching 40,000,000 (40 million) fresh customers for only $79.00!!!!<br />
<br />
Special Sale! Buy the 40 Million email addresses today and receive Email Xxxxxx Professional Version FREE! Email Xxxxxx Pro is 4 programs in one! (This message is sent by Email Xxxxxx. You can too send out mass sales letters professionally.) Email Xxxxxx is an extremely fast mass emailer (150,000 emails per hour with modest Pentium) that does four things: 1) Collects email addresses from newsgroups, web sites, or from AOL member files by key words and by specific interests. 2) Mail out your sales letters with automated friendly addressing (example: Dear John, Dear Nancy, etc.) Ramdomizes from and to field. One push of a button does it all. Guarantee no cut and paste. 3) Have capability to remove email addresses of people who don't like emails. 4) Post your sales letters to THOUSANDS OF NEWSGROUPS WITH A PUSH OF A BUTTON --- within HALF AN HOUR!! Email Xxxxxx and Email Addresses are your best sales tools! If you have a good product, you will be rich in no time. Call today (415)nnn-n825.<br />
<br />
All for $79. Not a penny extra.<br />
<br />
Call today (415)nnn-n825. Technical support available 24 hours. Emails are updated regularly. We can accept Visa or Master Card. 170<br />
<br />
 http://207.93.198.x/webhost Or, simply print this form and fill it out. with $79 check or money order to: Alex Chiu PO BOX jkjkjkj San Francisco CA (415) nnn-n825<br />
<br />
Mail it along<br />
<br />
94116<br />
<br />
Upon the receipt of your payment, you will immediately be instructed via email or by phone on how to download the fresh email addresses.<br />
<br />
Name: _________________________________ Address: ________________________________________ _________________________________________________ Telephone number: ___________________________ Email address: ______________________________ ---------------------------------------------------------------------------------------------------------Don't want to email millions of people yourself? No problem. I can do it for you professionally! I mail out two million emails for you within 3 days for $129!! Tell me what kind of customer you would want, and I will set the target with my highly targeted list. A mere $129 service includes: Email two million people. (targeted prospects) Post advertisement on 2000 newsgroups. telephone recommendations and technical support on how to make money on the internet. I guarantee you this is a great way to start your own company on the internet. Few months later, you will be like me making $5000 a month with internet! Call (415) 171<br />
<br />
 nnn-n825 if you have any question.<br />
<br />
Tralasciamo il lato comico della cosa, ossia venire a proporre a me di diventare uno spammer, e passiamo agli aspetti tecnici. L'indagine degli header è molto semplice: il tipo era collegato su un dial-up della UU Net (uno dei maggiori provider americani), dalla zona di S. Francisco. Non ha usato relayer né altri server SMTP: il software di cui si è avvalso (e che offre in omaggio ai suoi clienti) effettua quindi tutte le operazioni necessarie per l'invio a tutti i destinatari. Software di questo genere (in pratica, una specie di server SMTP con funzioni specifiche per l'invio massiccio di spam) viene normalmente definito "rapid fire" o RFMS (rapid fire mail server program) o anche "direct-to-MX", in quanto agisce collegandosi direttamente al mail exchanger di ciascun destinatario. Si tratta di un tipo di programmi che, in certi periodi, ha conosciuto grande popolarità presso gli spammer, erroneamente convinti che bastasse non usare nessun server per essere impossibili da individuare. L'avvento delle liste dei blocchi di indirizzi IP adibiti a dial-up (di cui la prima fu MAPS-DUL) diede un primo colpo alla pratica del direct-to-MX, in quanto consentì di bloccare molto facilmente questo tipo di connessioni. Un altro grosso colpo venne dalla tendenza, adottata soprattutto da molti grossi provider americani, di attuare il "port 25 filtering", ossia bloccare a livello dei router di frontiera qualsiasi tentativo di connessione dai propri nodi dial-up alla porta 25 di qualsiasi indirizzo di altre reti. Il port 25 filtering è una soluzione discutibile, in quanto esistono anche usi legittimi di mailserver esterni alla rete del provider cui si è connessi, tuttavia ha consentito a varie reti di risolvere situazioni a cui l'abuse desk non riusciva più a far fronte.<br />
<br />
Riguardo ai reclami, è ovvio che dovremo scrivere alla UUnet (il cui indirizzo abuse non è standard: al tempo di questo spam era fraud@uu.net, tempo dopo è stato cambiato in abuse-mail@uu.net). Però stavolta c'è qualcosa di più. La cosa nuova è che, stavolta, nello spam viene pubblicizzato un sito web. Quando si riceve spam pubblicizzante un sito web, non basta colpire l'account da cui è stato inviato il messaggio. Bisogna anche informare l'organizzazione che ospita o che fornisce connettività al sito in questione, con l'obiettivo di ottenerne la chiusura o, almeno, la diffida a pubblicizzarlo mediante spam. Se infatti l'account usato per spammare venisse anche chiuso ma il sito rimanesse, sarebbe da prevedersi la continuazione dello spam tramite nuovi account usa e getta. E' pure importante visitare il sito per meglio capire chi si ha di fronte: si possono scoprire altre cose interessanti. Per esempio, se sul sito figurasse un banner della LinkExchange sarebbe il caso di informare anche quelli della LinkExchange, che revocherebbero la affiliazione a quel sito. Va naturalmente tenuto presente che la maggior parte dei servizi di free hosting non ammettono che i siti da loro ospitati siano pubblicizzati con spam: in questi casi non è impossibile ottenere una sollecita cancellazione del sito in questione. Anche eventuali mailbox indicate come contatto sulle pagine del sito pubblicizzato sono da colpire. Piccola curiosità: quando il sito di uno spammer viene chiuso, si suol dire che è stato reso 404 compliant, scherzando sul fatto che al tentativo di accederlo il browser visualizza un messaggio d'errore del web server (404 Requested page not found). 172<br />
<br />
 Nel nostro caso, mi sono trovato di fronte ad una pagina in cui, oltre alla foto di un giovane cinese (il nostro uomo), figuravano inviti ad entrare nel business dello spam e, in particolare, l'offerta di allestire un proprio sito presso di loro. E' il momento di capire chi c'è dietro: Trying 207.93.198 at ARIN AmeriWeb (NETBLK-NETCOM-BLK2-AMERIWEB) NETCOM-BLK2-AMERIWEB 207.93.198.0 - 207.93.198.255 NETCOM On-Line Communication Services, Inc. (NETBLK-NETCOMBLK2) NETCOM-BLK2 207.92.0.0 - 207.95.255.0 To single out one record, look it up with "!xxx", where xxx is the handle, shown in parenthesis following the name, which comes first.<br />
<br />
whois -h whois.arin.net !netblk-netcom-blk2-ameriweb ... AmeriWeb (NETBLK-NETCOM-BLK2-AMERIWEB) 572 West Market Street, Suite #6 Akron, OH 44303 US Netname: NETCOM-BLK2-AMERIWEB Netblock: 207.93.198.0 - 207.93.198.255 Coordinator: Eid, David (DE342-ARIN) david@LINKUS.COM 330-253-8787 (FAX) 330-253-8787 Record last updated on 23-Apr-98. Database last updated on 24-Apr-98 16:09:31 EDT. The ARIN Registration Services Host contains ONLY Internet Network Information: Networks, ASN's, and related POC's. Please use the whois server at rs.internic.net for DOMAIN related Information and nic.ddn.mil for MILNET Information.<br />
<br />
Dunque, come si può vedere confermato anche da un traceroute, chi fornisce connettività al 173<br />
<br />
 sito in questione è Netcom, un altro grosso provider americano. Visitando il sito della Netcom, fa bella mostra di sè una pagina con il regolamento antispam, il cui titolo è: "Zero tolerance": dunque dovremmo essere a cavallo. Vediamo un esempio di come scrivere il reclamo: fraud@uu.net Please deal [solite frasi...] abuse@netcom.com The web site advertised in this spam appears to be hosted or at least connected by you. So please get rid of these spammers. Thank you all [poi naturalmente il testo del messaggio completo di header] In casi come questo è consigliabile inserire nel report anche l'output dell'ARIN da cui sia evidente il collegamento in base al netblock. Per avere un quadro più completo sul nostro caso, occorre fare attenzione a quel LINKUS. COM che compare nell'output dell'ARIN. In un altro spam da me ricevuto pochi giorni dopo, era pubblicizzato un altro sito web il cui indirizzo ricadeva nel medesimo netblock di cui ci siamo appena occupati e per il cui dominio il database dell'InterNic riportava: Domain servers in listed order: NS1.LINKUS.COM NS2.LINKUS.COM<br />
<br />
207.93.198.6 207.93.198.7<br />
<br />
Ne abbiamo imparata un'altra: anche guardare chi fornisce servizio DNS agli spammer è importante. Il servizio DNS consente agli spammer di avere, per i loro siti, dei nomi che si possono portare dietro man mano che vengono cacciati da un provider all'altro: fornire servizio DNS ad uno spammer è altrettanto grave quanto fornirgli connettività. Nel nostro caso, LINKUS.COM risulta essere strettamente collegato (o addirittura, forse, essere la stessa cosa) con AmeriWeb, che è la vera centrale. A volte, può non essere molto semplice seguire questi collegamenti tra organizzazioni che hanno una parte nell'attività di spamming, provider seri e provider che non lo sono: il rischio è quello di inviare la segnalazione, se non allo spammer stesso, al suo migliore amico e sodale. Per essere più sicuri delle conclusioni a cui si giunge, è di molto aiuto vedere se altre vittime sono giunte agli stessi risultati. Ciò si può constatare leggendo i messaggi sul newsgroup news.admin. net-abuse.email (familiarmente detto n.a.na.e). Andando su DejaNews (che al tempo era l'archivio storico di tutti i post su usenet, ruolo poi passato a Google) e cercando, su n.a.na. e, i messaggi che hanno la parola LINKUS nel subject, se ne trovavano una infinità. Erano 174<br />
<br />
 infatti moltissimi i domini di spammer ospitati da LINKUS. Seguendo n.a.na.e nel tempo, si venne anche a sapere che Netcom, pressata dai moltissimi reclami in arrivo, aveva ad un bel momento disconnesso LINKUS, per poi doverlo riconnettere in seguito ad una ingiunzione del tribunale (TRO, Temporary Restraint Order), in attesa della sentenza finale. Al momento della riconnessione, la Netcom stessa postò su n.a.na.e spiegando la propria posizione e chiedendo di continuare a segnalare i casi, in modo da poter portare tali reclami davanti alla corte. Il caso era legalmente difficile poiché i furbacchiotti non inviavano lo spam tramite la connessione fornita da Netcom, ma lo facevano tramite accessi forniti da altre compagnie (nella fattispecie, come abbiamo visto, UU Net, ma non solo). Per ciò che riguarda la segnalazione inviata da me, ho ricevuto subito da entrambi conferma della ricezione del mio messaggio, con un testo standard. Il messaggio di UU Net indicava anche il "trouble ticket number" assegnato al caso da me riportato. Quando, dopo un paio di settimane, ho ricevuto un altro spam identico, nella comunicazione ad UU Net ho inserito questo messaggio: Please dial with enclosed spam, originated by resource 1Cust222.tnt3.sfo3.da.uu.net as shown by the 'Received:' header. Please consider that this same (well known) spammer has already sent me similar spam from your network (trouble ticket no. UU755602), less than two weeks ago. In questo caso ho ricevuto una risposta probabilmente non automatica che diceva: Dear Customer, We have received your correspondence regarding trouble ticket UU755602. Our records on this matter have been updated with this new information, and any appropriate action will be taken. Thank you. - UUNET Customer Support Dopo qualche tempo ho ricevuto la conferma finale che il caso era stato "investigato e gestito nella maniera prevista dagli accordi con i loro clienti". Si tratta di una frase che può significare tutto o niente, dipende da quanto è efficace la prassi che hanno previsto per gestire questi incidenti. Poiché non ci interessa entrare ora in questo argomento, limitiamoci a dire che il gruppo investigazione abusi della UUnet ha indagato sulla segnalazione giungendo, sia pure con tempi non velocissimi, alla conclusione che si tratta di un episodio su cui compete alla UUnet intervenire. Quanto a Netcom, la cosa è rimasta a lungo in alto mare. Seguendo n.a.na.e si constatava 175<br />
<br />
 che la pressione su Netcom era continua (arrivando fino a parlare di blacklist). Finalmente un giorno ho ricevuto questo e-mail: Hello, This is a general reply to complaints that have come in about linkus.com the past few days. The matter has been dismissed and Ameriweb (i.e. linkus.com) is no longer a Netcom customer. They will NOT be reconnected through our network. Thanks for your patience Matt NETCOM Policy Management Era il 15 giugno; la mia prima segnalazione a Netcom risaliva al 25 aprile. Dalle notizie immediatamente arrivate su n.a.na.e si apprese che Linkus aveva, alla fine, rinunciato a proseguire l'azione contro Netcom, facendo così decadere il TRO. Pochi giorni dopo erano già disponibili in rete gli scan di tutti i documenti processuali, per poter esaminare come le cose si erano svolte. Molti hanno rilevato che, da parte di Netcom, la difesa avrebbe potuto essere ben più decisa e che, forse, con maggiore "volontà politica" i risultati avrebbero potuto essere ben più pronti. Può darsi; però sta di fatto che, alla fine, questa zona franca per gli spammer non è potuta sopravvivere. Ovviamente, questa conclusione non si sarebbe avuta senza la sollevazione di un così gran numero di utenti e di postmaster. Un'altra cosa che si deve osservare è che, se le attenzioni degli antispammer si fossero rivolte solo alla connessione dial-up usata per spammare, una soluzione della vicenda probabilmente non si sarebbe mai avuta. Far saltare la connessione dial-up dello spammer è senz'altro molto utile e va fatto, tuttavia una priorità anche maggiore va attribuita all'hosting del sito e, se fornito da un altro soggetto, al servizio DNS. Questo perché, per uno spammer, è decisamente più begoso rimettere in piedi il sito trovando un altro servizio di hosting, piuttosto che procurarsi semplicemente un altro account dial-up.<br />
<br />
Indice<br />
<br />
<< Precedente<br />
<br />
Successiva >><br />
<br />
Ultimo aggiornamento: 26 dicembre 2001 176<br />
<br />
 Leonardo Collinelli<br />
<br />
177<br />
<br />
 Il problema dei relayer I relay multihop: caso pratico num. 4<br />
<br />
Ecco un nuovo caso di spam diffuso tramite relay. Come si vede dagli header, la situazione è un po' più intricata delle precedenti. Caso num. 4: relayer multihop From: <10@nntp6.atl.mindspring.net> To: <belfordgroup@****.com> Return-Path: 10@hotmail.com Received: from zmaj.etf.bg.ac.yu (zmaj.etf.bg.ac.yu [147.91.8.62]) by xxx.com (8.11.0/8.9.1) with ESMTP id f0D0Viu75089 for <***@xxx.com>; Fri, 12 Jan 2001 16:31:51 -0800 (PST) Received: from labtel.imp.bg.ac.yu (labtel.imp.bg.ac.yu [147.91.50.50]) by zmaj.etf.bg.ac.yu (8.9.3/8.9.3) with SMTP id AAA06269; Sat, 13 Jan 2001 00:49:24 +0100 Received: from [1cust64.tnt22.det3.da.uu.net] by labtel.imp.bg.ac. yu id aa15469; 13 Jan 71 22:18 MET Message-Id: <74816n.0n668n411cyx07kv3v@2bw25v87.fastone> Date: Fri, 12 Jan 2001 16:56:02 -0500 X-Mailer: L00kOut V2.73 X-UIDL: 4c8c7bb83d67d7a18a1548d4591a1b6f Status: U Subject: Free Dish Network Satellite & Free Installation Limited time offer! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit <B><I><FONT color=#cc0000><FONT size=+2></FONT></FONT></I></B> <P><B><I><FONT color=#cc0000><FONT size=+2>If youve ever considered switching from cable to satellite now is the time !!!</FONT></ FONT></I></B> [eccetera....] Il primo Received, inserito dal server su cui si trovava la mia mailbox, indica che la mail era pervenuta da 147.91.8.62, indirizzo a cui si trovava un server jugoslavo. Questo secondo server aveva messo il successivo Received, da cui si vede che la mail gli era giunta da un terzo server, pur esso jugoslavo e ad un indirizzo ip assai vicino, 147.91.50.50. Questo terzo server aveva a sua volta inserito l'ultimo Received nel quale figura, come provenienza, il tipico nome di un nodo dial-up della UUNet. 178<br />
<br />
 La cosa nuova rispetto ai casi precedenti è il fatto che, prima di giungere a destinazione, lo spam aveva attraversato non uno ma due server SMTP e che, verificato presso le varie blacklist di relay aperti, il server da cui avevo direttamente ricevuto lo spam (ossia 147.91.8.62) non risultava essere aperto, almeno non aperto come quelli che abbiamo visto nei casi precedenti, in quanto ai test diretti sul suo ip era risultato rifiutare il relay di terza parte. Purtuttavia, ciò che si doveva constatare era che lo spammer lo aveva comunque potuto usare per diffondere spazzatura, semplicemente usando come punto di immissione l'altro server a 147.91.50.50. Per ora non consideriamo il motivo per cui questo giro era possibile. È chiaro che non avrebbe dovuto essere possibile e che, da qualche parte, c'era un errore di configurazione, tuttavia ne parleremo dopo. Ora rimaniamo dal punto di vista di chi ha ricevuto uno spam con queste caratteristiche: esaminando lo spam si vede negli header questo doppio passaggio, ed è opportuno cercare un minimo di conferme, in modo da escludere che si tratti di header falsificati. Per confermare le apparenze è sufficiente, al solito, verificare che ciascun Received sia plausibile alla luce di quello che lo precede negli header. Inoltre, è bene poter verificare che la catena dei server in questione esista veramente e davvero sia configurata per funzionare in quel modo. La verifica è semplice: si può testare il punto di immissione sospetto (in questo caso 147.91.50.50) e vedere se il messaggio di test segue lo stesso percorso. Oppure, ancora meglio, si può trovare in rete il risultato di un test fatto da qualcuno dei sistemi automatizzati che censiscono i relay aperti. In effetti, quando si riceve spam via relay la probabilità di trovare il server già testato sul sito dell'una o dell'altra delle varie blacklist di relay aperti è normalmente alta. Nella fattispecie, effettuando una veloce ricerca sul sito di MAPS-RSS trovai una copia di quel medesimo spam ed un messaggio di test in cui figuravano questi header: Received: from zmaj.etf.bg.ac.yu (zmaj.etf.bg.ac.yu [147.91.8.62]) by kithrup.com (8.8.8/8.8.8) with ESMTP id XAA23916 for <user@kithrup.com>; Mon, 20 Nov 2000 23:10:48 -0800 (PST) (envelope-from <@dante.mail-abuse.org:unavailble@mnjazz.com>) Received: from labtel.imp.bg.ac.yu (labtel.imp.bg.ac.yu [147.91.50.50]) by zmaj.etf.bg.ac.yu (8.9.3/8.9.3) with SMTP id IAA15438 for <@zmaj.etf.bg.ac.yu:user@kithrup.com>; Tue, 21 Nov 2000 08:10:14 +0100 Date: Tue, 21 Nov 2000 08:10:14 +0100 Received: from dante.mail-abuse.org by labtel.imp.bg.ac.yu id aa11497; 22 Nov 70 7:37 MET Dunque header del tutto analoghi a quelli appena visti nello spam, salvo ovviamente il diverso punto di origine del messaggio. Un ulteriore test da me eseguito al momento produsse questi header: Received: from [147.91.8.62] (HELO zmaj.etf.bg.ac.yu) by mailserver1.d-system.it (CommuniGate Pro SMTP 3.2) with ESMTP id 1110250 for ****@***.it; Sat, 13 Jan 2001 14:00:31 +0000 Received: from labtel.imp.bg.ac.yu (labtel.imp.bg.ac.yu [147.91.50.50]) by zmaj.etf.bg.ac.yu (8.9.3/8.9.3) with SMTP id OAA08059 for <@zmaj.etf.bg.ac.yu:****@***.it>; Sat, 13 Jan 2001 14:04:58 +0100 179<br />
<br />
 Date: Sat, 13 Jan 2001 14:04:58 +0100 Received: from mdm91-n01-dialup.xxxxxx.it by labtel.imp.bg.ac.yu id aa08329; 14 Jan 71 13:26 MET L'unica differenza che si nota rispetto agli header dello spam è che, nei test, compare una clausola for <@zmaj.etf.bg.ac.yu:indirizzo@destinatario> nei Received evidenziati in blu, clausola non presente nello spam. Tale differenza è certamente dovuta al fatto che, mentre i test erano in entrambi i casi costituiti da un messaggio per un singolo destinatario, lo spam sicuramente aveva più di un destinatario (presumibilmente parecchie migliaia). Possiamo anche supporre che il messaggio di spam fosse stato trasferito in copia unica dal server di immissione al secondo e che il secondo, dopo aver inserito il proprio Received, avesse poi replicato il messaggio per ogni destinatario. Quindi a questo punto la situazione era chiara e sostenuta da molteplici conferme: il server 147.91.8.62 risultava non essere un relay aperto, mentre 147.91.50.50 lo era. Tuttavia le email in uscita da quest'ultimo non venivano direttamente passate a destinazione, ma fatte transitare attraverso il server precedente, il quale così risultava come finale provenienza degli spam. Un'altra cosa accertata mediante i test era che, nel Received inserito da 147.91.50.50, dopo la parola 'from' veniva indicato il vero reverse dns dell'ip di origine. Ci si troviamo dunque di fronte ad una situazione che, generalizzando, possiamo semplificare come nel seguente schema:<br />
<br />
180<br />
<br />
 Fig. 1 - Esempio di rete con più mail server, di cui uno è lo smarthost Abbiamo dunque una rete in cui esistono più server, eventualmente destinati a servire ciascuno un proprio bacino di utenza. Uno dei server (indicato nello schema come server principale e spesso detto "smarthost") è configurato per recapitare all'esterno le email in partenza; gli altri server sono configurati per passare le email in partenza sempre e solo allo smarthost, demandando ad esso la effettiva consegna a destinazione di ciascun messaggio. È facile che, in questi casi, i server secondari appartengano o alla stessa rete che gestisce il server principale, o a reti che di essa siano clienti. In ogni caso, quando tutto va bene una tale configurazione è corretta e non dà luogo a problemi di spam (i server secondari sono autorizzati a usare il server principale e, se tra i loro utenti ci fosse uno spammer, la rete titolare del server principale avrebbe certamente modo di intervenire e ottenerne l'estromissione). Il problema è che, perché tutto vada bene, occorre che non solo la configurazione del server principale sia in ordine, ma che lo sia anche quella di tutti i server secondari. Quando uno dei server secondari è malconfigurato, uno spammer può approfittarne come al solito. Nel seguente schema vediamo che lo spammer, dopo aver tentato senza successo di immettere i propri messaggi tramite il server principale e tramite il server secondario num. 1, trova infine aperto il server secondario num. 2. Il risultato finale non cambia: i destinatari vedranno provenire lo spam dall'ip del server principale.<br />
<br />
181<br />
<br />
 Fig. 2 - Esempio di server secondario insicuro, abusabile dagli spammer Per tornare al nostro caso pratico, a questo punto ho avvisato i gestori dei server in questione. C'è da dire che, nel corso del 2001, lo spam da relay è enormemente aumentato, così che molti antispammer si sono visti costretti, per ragioni di tempo, a rinunciare ad avvertire i gestori dei relay. Caso mai, è diventata consuetudine piuttosto provvedere a inserire direttamente nelle varie blacklist i server che si sono trovati aperti. Ormai non è ammissibile per nessuno ignorare che cosa comporti tenere un server con il relay di terza parte abilitato. Del resto, nella maggior parte dei casi in cui ciò avviene è frequente si tratti di server abbandonati o quasi, e che ben di rado sia facile o immediato individuare i contatti giusti (è poco realistico aspettarsi che qualcuno legga la casella postmaster di server in quelle condizioni). Purtuttavia, se si ha il tempo, un messaggio al contatto opportuno può rivelarsi utile per tutti. In questo caso ho indirizzato il mio avviso a 4 indirizzi contemporaneamente: postmaster ed abuse all'uno e all'altro server (di questi, solo l'indirizzo abuse al server secondario è risultato non definito). Va osservato che, pur essendomi fatto l'idea che entrambi i server appartenessero alla medesima università jugoslava (presumibilmente si trattava del server centrale e di quello di un dipartimento), non potevo avere idea se fossero oppure no gestiti dalle medesime persone. Ho scelto quindi di rivolgermi separatamente agli uni e agli altri ma con un unico messaggio inviato a tutti: 182<br />
<br />
 Dear postmaster at etf.bg.ac.yu, please take care that the server "labtel.imp.bg.ac.yu" gets fixed urgently as described below, since it causes your server at 147.91.8.62 to propagate spam email and to consequently risk being blacklisted.<br />
<br />
Dear postmaster at imp.bg.ac.yu, this is to let you know that the mail server labtel.imp.bg.ac.yu (ip address: 147.91.40.50) is open to third party relay, so it is consequently abused by spammers, as shown by the enclosed spam message. Please fix the server urgently to disable 3rd party relay. If you need further information about the relay problem and possible ways to fix it, I suggest the authoritative pages of MAPS: http://www.mail-abuse.org/tsi/ (for general info) http://www.mail-abuse.org/tsi/ar-fix.html (for technical help) Regards Leonardo Collinelli -------- Begin spam message with headers: (allegata qui una copia degli header dello spam) La risposta è giunta in tempi assai brevi: Dear Sir, we closed relaying for server labtel.imp.bg.ac.yu as soon as we got information about spaming. Thank you for your e-mail. Regards (firma) Per completare la storia del caso, va detto che ho segnalato lo spam pure ad UUNet. Al tempo in cui si verificò l'episodio, UUNet non era nei suoi momenti migliori e stava dando origine alla maggior parte dello spam che circolava per la rete. È quindi difficile dire se della segnalazione avranno fatto qualcosa. Tuttavia in questo caso l'inerzia da parte loro avrebbe avuto una giustificazione: gli header che io potevo produrre non erano una prova tale da poter "inchiodare" lo spammer. Come qualcuno avrà già notato, il Received inserito dal relay aperto conteneva solo il reverse DNS del nodo dial-up su cui si trovava lo spammer, non l'indirizzo ip vero e proprio. È vero che, come si era potuto verificare tramite i test, si trattava effettivamente del reverse DNS dell'ip di provenienza, ma è anche 183<br />
<br />
 noto (come abbiamo già spiegato) che un reverse DNS non può, per sua natura, essere considerato attendibile. In teoria lo spammer avrebbe potuto essere su tutt'altra rete, in cui un amministratore compiacente avrebbe potuto definirgli dei reverse DNS di comodo per farlo erroneamente apparire come se fosse stato su UUNet. È una ipotesi non probabile ma neanche impossibile. Ovviamente gli abuse desk queste cose le sanno, ragion per cui una segnalazione su casi del genere è comunque utile e può essere utilizzata come riscontro aggiuntivo da confermarsi con altra evidenza. Per esempio, è assai probabile che lo spammer, nel corso di una stessa "sessione di lavoro" si avvalga di differenti relay contemporaneamente, e che quindi la sua presenza su quell'ip risulti accertata comunque. Approfondimento Relay multihop su nodi dial-up Il caso appena visto può definirsi assai lineare. Situazioni del genere possono verificarsi non solo per via di come è organizzata la struttura di rete di una università e dei suoi dipartimenti, ma anche per tutti quei casi in cui, per esempio, si abbia una piccola azienda provvista di mail server proprio (con ip fisso) il quale, pur ricevendo direttamente le email in arrivo, si appoggi al server del provider per l'inoltro della posta in partenza. In tutti questi casi, presso il server che provoca il problema possono non esserci adeguate competenze per porre rimedio ed è pertanto incombenza del provider (ovvero del gestore del server principale) fornire assistenza (e soprattutto solleciti) a chi di dovere per giungere, in tempi rapidi, alla corretta configurazione dei server. Si è però cominciato a riscontrare dei casi non assimilabili a situazioni come quelle descritte. Immaginate qualcuno dei nostri maggiori provider nazionali i cui server si trovino a diffondere spam e che, come punti di immissione del relay multihop, si trovino nodi dial-up dei medesimi provider. È ovvio che, per i nodi dial-up, i mail server di quel medesimo provider debbano essere utilizzabili. Meno normale è che qualche utente dial-up faccia girare un mail server sulla propria connessione modem (cosa assolutamente inutile, molto pericolosa e da sconsigliare fortemente a chiunque). In realtà c'è ragione di pensare che, in molti casi in cui ciò accade, esista una qualche intesa o accordo con spammer d'oltre oceano: uno di questi casi fu documentato quando uno spammer americano offrì, pubblicizzandolo tramite spam, proprio un siffatto servizio di bulk-emailing via relay: dagli header si vedeva che tale spam era uscito nientemeno che da uno dei server principali di uno dei maggiori provider nazionali, dopo essere transitato da un dial-ip del medesimo provider. Con stratagemmi del genere gli spammer si assicurano, come mezzo di diffusione, dei server particolarmente potenti e provvisti di una capacità di banda enorme. Tornando a bomba, il punto è: come impedire che qualche utente, o scientemente o per sbadataggine, crei un punto di immissione aperto al relay di terza parte? Varie cose si possono fare per ridurre la portata dell'inconveniente, per esempio limitare ad un massimo ragionevole il numero di destinatari possibili per ogni messaggio originato da un dialup, oltre a tenere controllato il funzionamento dei server centrali. La risposta che dà maggiori garanzie può però solo essere a livello di infrastruttura di rete: nella configurazione dei router di frontiera si dovrebbe prevedere il blocco di sessioni smtp originate dall'esterno e dirette verso i dial-up. Inoltre, sarebbe raccomandabile bloccare sessioni smtp dall'esterno anche verso nodi ad ip fisso, stabilendo eccezioni solo per quei server che fossero stati controllati e dichiarati sicuri (e venissero, ovviamente, ricontrollati a sorpresa periodicamente e sovente). Se però, come spesso si riscontra, domina l'incuria, è da mettere in conto che incidenti da relay multihop possano sempre accadere.<br />
<br />
Considerazioni finali sul problema dei relay in generale In questi primi casi pratici, abbiamo visto varie situazioni in cui gli spammer riescono ad usare apparecchiature altrui per diffondere il proprio traffico. In questi casi si trattava di relay aperti, tuttavia altrettanto frequentemente si ha a che fare con proxy insicuri (dei quali abbiamo già accennato). Negli esempi che abbiamo passato in rassegna si è visto che il problema veniva segnalato a chi risultasse in condizioni di intervenire sulla configurazione dei server abusati, in modo che gli errori di configurazione venissero corretti e si evitasse quindi il ripetersi del problema. Effettivamente, quando lo spam da relay iniziò a diventare comune, queste segnalazioni avevano senso e, in una buona percentuale dei casi, giungevano al risultato voluto. 184<br />
<br />
 Poi però le cose sono cambiate: all'incirca dal 2001 il numero di server connessi alla rete ha iniziato ad incrementarsi ad un ritmo molto superiore a quanto avveniva in precedenza, ed il fenomeno è stato notevole anche in paesi ove la cultura tecnica e di funzionamento della rete non era ancora all'altezza delle necessità. Il risultato è stato che si sono resi disponibili agli spammer sempre più relay e proxy abusabili e che, anche a segnalarli, nulla si otteneva: se anche un server veniva sistemato, gli spammer ne avevano a portata di mano innumerevoli altri. Pertanto, già dal 2002, dedicare del tempo per segnalare opportunamente i relay e i proxy aperti ha iniziato ad essere eccessivamente dispendioso: si aveva, sempre di più, la sensazione che fosse la stessa cosa che cercare di vuotare il mare con un cucchiaino. Ecco allora che le strategie usate dagli antispammer sono cambiate: a fronte di un relay o proxy aperto, tipicamente ci si limita a verificare che l'indirizzo sia noto alle opportune liste di blocco (delle quali si parlerà più avanti). La segnalazione a chi può sistemare il server è sempre possibile e, in molti casi, può anche risultare utile, tuttavia per ragioni pratiche non è più un passo consigliato come lo era un tempo. L'indicazione ora è di cercare di colpire lo spammer su risorse per lui più costose e difficili da rimpiazzare (come si vedrà nei casi seguenti).<br />
<br />
Indice<br />
<br />
<< Precedente<br />
<br />
Successiva >><br />
<br />
Ultimo aggiornamento: 03 maggio 2003<br />
<br />
Leonardo Collinelli<br />
<br />
185<br />
<br />
 Il problema dei relayer Casi pratici num. 2 e 3<br />
<br />
Ecco due casi di spam che aprono un nuovo problema. Caso num. 3: relayer semplice Received: from mail.mioisp.it by mbox.altronome-mioisp.it with ESMTP (1.39.111.2/16.2) id AA033310986; Fri, 13 Feb 1998 21:16:35 +0100 Return-Path: <Online.Services@xxx.edu> Received: from drake.xxx.edu (drake.xxx.edu [137.155.yyy. zzz]) by mail.mioisp.it (8.8.4/8.8.5) with ESMTP id UAA17558 for <miacasella@mioisp.it>; Fri, 13 Feb 1998 20:42:21 +0100 (MET) From: Online.Services@xxx.edu Received: from xxx.edu (ppp-095.m2-9.tor.ican.net [142.154.18.95]) by drake.xxx.edu (8.8.5/8.6.9) with SMTP id OAA13346; Fri, 13 Feb 1998 14:25:35 -0500 (EST) Date: Fri, 13 Feb 98 14:30:26 EST To: Friend@public.com Subject: Important Message Message-Id: <> X-UIDL: ef520c88213c4d1639790944abb9467c Dear Potential Client, Are you an Accountant, are you a Lawyer, [eccetera....]<br />
<br />
are<br />
<br />
L'analisi non è difficile. Il server su cui risiedeva la mia mailbox dichiara, nel primo header, di aver ricevuto il messaggio da un altro server (sempre del mio provider) che, al momento, stava facendo da front-end per la posta in arrivo. Questo dichiara a sua volta di averlo ricevuto da xxx.edu, che è ovviamente una università americana. Trovato il sito www.xxx. edu l'ho visitato, trovando né più né meno quel che ci si può aspettare in un normale sito di una università. E da quando in qua, verrebbe da chiedersi, le università mandano spam? Come però è evidente dal seguito, lo spam non è stato originato dall'università: questa lo ha 186<br />
<br />
 ricevuto dalla risorsa ppp-095.m2-9.tor.ican.net. Verificato che l'indirizzo IP corrispondesse, ho visitato il sito della Ican Net, scoprendo che è un provider canadese, dotato tra l'altro di regolamento contro lo spam. E' anche evidente che il nome della risorsa è parlante: si tratta di una connessione PPP della zona di Toronto. Quindi il caso è risolto, si deve inviare la segnalazione alla Ican Net e, controllando sulla lista della già citata Abuse. net, si trova che la casella postale preposta ha il classico nome "abuse". E l'università? Va tutto bene così oppure è il caso di fare qualche osservazione anche su di loro? In effetti, per quanto ci si pensi, non viene in mente alcuna ragione valida per cui il server SMTP di una organizzazione debba fare servizio anche per gli utenti altrui. E' vero che il protocollo SMTP è pensato per consentire la trasmissione dei messaggi anche attraversando più server, ed è pure vero che, anni addietro, questo avveniva in molti casi e senza problemi. I problemi cominciarono quando gli spammer trovarono questa possibilità assai comoda per le loro attività. In effetti, quando si spediscono migliaia di copie di uno stesso messaggio a tanti destinatari, agire direttamente dal proprio pc è lungo e decisamente poco pratico. Molto più comodo è usare un server SMTP, che si fa carico del grosso del lavoro. Se però questo server fosse quello messo a disposizione dal proprio provider, lo spammer sarebbe facilmente individuabile. Usando il server di un altro soggetto, lo spammer si nasconde meglio e può riuscire (anche se non sempre) a sviare i sospetti. Qui per esempio ha indicato nel campo 'From:' un indirizzo davvero fraudolento come Online.Services@xxx. edu, per rafforzare l'impressione che lo spam fosse stato originato proprio dall'università. Questa tecnica è molto usata dagli spammer, e viene comunemente indicata come 3rd party relay, in quanto il server di un terzo soggetto (che nulla c'entra né col mittente né col destinatario) viene usato come relayer, ossia come propagatore di un messaggio SMTP. Se ricordate il già discusso problema dei proxy insicuri, noterete che il problema dei relay aperti è del tutto analogo: un server SMTP deve inoltrare messaggi solo per conto di utenti che siano autorizzati ad usarlo. Per controllare che l'utente sia autorizzato a usarlo, il server può adottare varie strategie (appartenenza dell'ip a certi netblock, autenticazione SMTP, autenticazione mediante POP-before-SMTP o eventualmente altri). Il problema sorge quando il server non effettua controlli, o effettua controlli inadeguati. Poiché questa funzione di relay terza parte si presta a commettere abusi, il software usato sui server SMTP prevede la possibilità di disabilitarla. Non tutti gli amministratori di sistema sono però consapevoli dell'esistenza di questo problema, né dei rischi a cui si espongono, veicolando messaggi sulla cui provenienza non hanno controllo. Un relay aperto viene individuato, presto o tardi, dagli spammer. Esistono appositi programmi automatici, che cercano sulla rete i relay aperti: è solo questione di tempo, e un server in quella condizione diventerà una sorta di buco nero da cui può arrivare di tutto. Come dice il sito mail-abuse.org, non appena ci si rendesse conto che uno dei propri server è abilitato a fare da relayer lo si deve immediatamente disconnettere dalla rete, finché non si sia provveduto a correggerne la configurazione. Va da sè che, se il software adottato non desse la possibilità di ovviare all'inconveniente, andrebbe senz'altro buttato nel pattume e 187<br />
<br />
 sostituito con un prodotto serio. Per completare il quadro delle conseguenze, va anche detto che gli indirizzi su cui si trovano relay aperti vengono inclusi in varie liste nere che moltissime reti adottano per bloccare la posta in arrivo. Quindi qualsiasi amministratore di rete dovrebbe periodicamente fare un bel controllo per essere certo di non avere relay aperti: il rischio, oltre che finire nelle black list e ricevere per giorni e giorni email furibonde dagli utenti spammati, è che, mentre il proprio server lavora per conto di uno sconosciuto rubagalline d'oltre oceano, si abbia la cdn congestionata da tale traffico (con conseguente disservizio per i propri utenti regolari). Tornando al nostro caso pratico, sarà doveroso informare il postmaster dell'università, con però una piccola questione preliminare da superare. Non è infatti da escludere che il postmaster in questione, magari avvertito da altri, abbia già provveduto (in tal caso non c'è motivo di scrivergli). Sarebbe quindi un utile completamento alla indagine verificare che il server in questione agisca effettivamente da relayer, anche perché così avremmo conferma che le conclusioni finora tratte siano corrette. Diciamo però subito che questa non è necessariamente una buona idea. In effetti, l'amministratore del sistema di cui ci si accinge a testare la possibilità di relay terza parte potrebbe non gradire. Ricordate che i server scrivono su log le transazioni che eseguono, con l'indirizzo IP da cui ogni transazione è stata eseguita. Ovviamente questa operazione verrebbe fatta nell'interesse di tutta la rete e, in modo particolare, anche del gestore del server; non è però da escludere che la cosa venga considerata invasiva o confusa con un tentativo di hackeraggio. Se siete dell'idea di effettuare comunque la prova, almeno attenetevi a queste due raccomandazioni: 1. Effettuate la prova esclusivamente su server dai quali avete ricevuto personalmente dello spam. In questo caso, è fuori dubbio che il suo amministratore di sistema sia in fallo, poiché configurando male il server ha provocato danno a voi e, probabilmente, anche a molti altri. Ad una eventuale risentita protesta ci sarebbe, almeno, questo argomento da opporre. In altre parole, non mettetevi a testare server a destra e a sinistra tanto per il gusto di farlo: finché non vi viene a danneggiare direttamente, la loro configurazione non è affar vostro. Negli ambienti antispam c'è consenso sul fatto che un primo test ad un server si possa considerare sollecitato, per via del messaggio di spam giunto da quel server, mentre successivi test sarebbero con ogni probabilità da considerarsi abuso. 2. Avuta conferma della presenza del problema, informatene subito il postmaster Vediamo come si fa a verificare lo stato di apertura di un relay, anche se non è difficile immaginarlo. Si tratta di inviare una e-mail a sè stesso, utilizzando il server da verificare. La sessione telnet potrebbe avere questo svolgimento: 220 abcd.efg.it ESMTP Sendmail 8.8.2/8.7.1; Sun, 8 Feb 1998 17:55:33 +0100 HELO relaycheck 250 abcd.efg.it Hello rev-dns.vostro.indir.it [xxx.yyy.zzz. kkk], pleased to meet you MAIL FROM:<myself@relaycheck> 188<br />
<br />
 250 myself@relaycheck... Sender ok RCPT TO:<vostra-mailbox@vostro-isp.it> 250 vostra-mailbox@vostro-isp.it... Recipient ok DATA 354 Enter mail, end with "." on a line by itself Subject: To myself for 3rd party relay check Test test . 250 FKT00378 Message accepted for delivery QUIT 221 abcd.efg.it closing connection Quando il server dice "Recipient ok" e, più ancora, "Message accepted for delivery" (o altri messaggi equivalenti) si ha una prima conferma, poiché può già in questi punti aversi un esplicito messaggio di rifiuto. Però il vero riscontro lo si può fare solo pochi secondi dopo, controllando la propria mailbox. Se il messaggio è arrivato, allora siamo di fronte ad un relay aperto. Non resta quindi che vedere la conclusione del nostro caso. Ho spedito una prima e-mail alla Ican Net, in cui ho evidenziato che lo spammer aveva fatto uso di un relayer: Dear Ican Net, please deal with following e-mail I've received: it is a commercial advertisement not requested by me and I don't want any more of it. The 'Received:' headers show it comes from ppp-095.m2-9.tor.ican.net, by way of server drake.xxx.edu, which is acting as a relayer (I notify as well the administrator at xxx.edu, to let him know that his server is being abused). I hope you will find, in message headers, the necessary information for finding out the originating user and taking adequate measures to avoid this can again happen. Thank you for your care about this. Best regards [firma] -------Begin spam message with full headers: Received: from........ All'università si può invece scrivere: Dear postmaster, 189<br />
<br />
 I have received unsolicited junk e-mail which has been relayed by your server, as shown by the 'Received:' headers of the message, enclosed below. Since your server is now acting as 3rd party relayer, it is most likely that more and more spammers are going to abuse it in order to carry out their actions. So, please configure urgently your server so that only your own users can send e-mail through it to those who are not your users. Should you need more information about the problem and possible solutions, I suggest the authoritative page of MAPS (http://www.mail-abuse.org/tsi/). Best regards [firma] -------Begin spam message with full headers: [messaggio completo di header come al solito] Il testo appena riportato è da considerarsi prolisso: era appropriato nel 1998, quando effettivamente molti postmaster non avevano idea di cosa fosse un relay aperto ed era quindi appropriato spiegarglielo. Oggi vale la pena di essere molto più sintetici. Non è sbagliato, in casi come questo, inviare una mail unica indirizzata a tutti i postmaster coinvolti, con un testo di questo tipo: abuse@rete-x.net Please deal ecc... come al solito abuse@rete-y.net please disable 3rd party relay, or other spammers will soon follow. (firma) -------- Begin spam message with full headers: (ecc...) In generale, più è grossa l'organizzazione a cui scrivete, più è appropriato essere essenziali. Tornando a noi, pochi giorni dopo ho ricevuto questo e-mail: The user responsible for the spam has been locked from our system. Thank you for informing us of their actions. -ICAN.net Abuse Team - abuse@ican.net - http://abuse.ican.net Notate che questo provider ha allestito un sito web apposta per la gestione degli abusi, in cui è possibile anche prendere visione dello stato in cui si trovano i casi segnalati. E' una scelta sicuramente ottima e che molti dovrebbero prendere ad esempio. 190<br />
<br />
 Non sentii invece più nulla dall'università. In effetti non sempre si ha risposta quando si segnala ad un postmaster l'esistenza del problema del relay terza parte sul suo server. Spesso però, specie quando la causa del relay aperto sta in banali sviste nella configurazione del server, ci si vede ringraziare per la segnalazione. Caso num. 4: relayer anonimo Ecco un altro messaggio passato attraverso un relayer (si trattava, in questo caso, di un server tedesco). Return-Path: <regebe62@aol.com> Received: from mail.altro-nome-mio-isp.it (mail.mio-isp.it [194.243.154.49]) by mbox.terzo-nome-mio-isp.it (8.8.5/8.8.5) with ESMTP id XAA17362 for <mia-mailbox@box1.mio-isp.it>; Wed, 15 Jul 1998 23:02:01 +0200 (METDST) Received: from xxxxxxxxx.de ([194.xxx.yyy.zzz]) by mail.altro-nome-mio-isp.it (8.8.4/8.8.4) with SMTP id XAA21024 for <mia-mailbox@mio-isp.it>; Wed, 15 Jul 1998 23:01:40 +0200 (MET DST) Received: from Ben by xxxxxxxxx.de (SMI-8.6/SMI-SVR4) id WAA04352; Wed, 15 Jul 1998 22:59:57 +0200 Date: Wed, 15 Jul 1998 22:59:57 +0200 To: regebe62@aol.com From: regebe62@aol.com (TF) Comments: Authenticated sender is <regebe62@aol.com> Reply-to: possibile-nome-del-pirla@hotmail.com Subject: Let Us Do It For You Message-Id: <199807151115LAA6543@Seth.xxxxxxxxx.de> X-UIDL: de6a22bce79a4e304c985efc340962b4<br />
<br />
YOUR HOME TOWN WILL DO 100% OF THE WORK FOR YOU [tagliamo il testo, lasciando le seguenti righe conclusive:] our research showed you would be interested in this. If this is not true <a ahref="mailto:possibile-nome-delpirla@hotmail.com" rel="nofollow">Click Here</a> and enter remove in the subject. Thank You. 191<br />
<br />
 Notato niente di particolare negli header? Facciamola corta, il problema è nell'header inserito da xxxxxxxxx.de: non dice da chi ha avuto il messaggio. Come noterete, sul server gira la "famigerata" versione 8.6 di sendmail. Al tempo in cui ricevetti questo spam, nel 1998, ricevere spam tramite relay anonimo era ancora una evenienza piuttosto rara. Da allora, probabilmente per la pressione che hanno iniziato a sentirsi addosso, sembra che gli spammer si siano messi a cercare specificamente i server in questa condizione, facendone uno dei loro veicoli preferiti. Sarà chiaro che in questo caso ci mancano gli elementi per individuare il punto in cui il messaggio è stato immesso in rete, così come deve essere chiaro che altri eventuali 'Received:' che figurassero dopo quello di xxxxxxxxx.de dovremo considerarli assolutamente inattendibili, tanto più che normalmente gli spammer entrano nei relay aperti accedendoli direttamente dalle loro connessioni dial-up. Osservazione: Nel caso in questione, il relay anonimo salta all'occhio anche grazie al fatto che lo spammer aveva usato una stringa di HELO riconoscibile come tale. Ma che dire di un caso come questo: Received: from 210.145.204.242 by mismanaged-server.co.jp (8.8.5/3.4W) with SMTP id QAA07607; Tue, 20 Jul 1999 16:36:40 +0900 (JST) Nella clausola 'from' sembra di vedere un indirizzo IP, invece è pure quella una stringa fasulla di HELO. Occorre quindi diffidare dei received in quella forma a meno che, testando il relay, non si veda che dopo il from viene davvero indicato l'indirizzo IP. In caso contrario, si rischierebbe di essere buttati su una falsa pista. A questo proposito si consideri che, su siti come quelli di MAPS-RSS o di ORBZ, ORDB o altri (dei quali si parlerà più avanti), è possibile in molti casi rinvenire, per il relay da cui proviene lo spam su cui si sta indagando, dei test già fatti, consultabili e assai utili per raffrontare il Received inserito dal relay con quello presente nei propri header. Ciò consente di interpretare il Received con maggiore sicurezza e senza perdite di tempo (si verifichi, comunque, che il test disponibile sia abbastanza recente).<br />
<br />
Tornando a noi, non possiamo dunque sapere chi sia il provider di questo spammer, ma abbiamo da scrivere una e-mail non meno necessaria. A chi? Ovviamente ai nostri amici di xxxxxxxxx.de. A questo proposito ho incontrato una prima difficoltà: l'indirizzo postmaster@xxxxxxxxx.de non era definito o, comunque, dava errore. Questa è un'altra cosa di discreta gravità, poiché è uno standard di rete che postmaster sia definito. Comunque, visitando il sito web della organizzazione in questione, ho visto indicato l'indirizzo "webmaster". Come detto in altra occasione, di norma con queste cose il webmaster non c'entra nulla, essendo però l'unico contatto nello staff di xxxxxxxxx.de che apparisse praticabile per farsi sentire, ho scelto di spedire al webmaster la lettera seguente: Subject: Serious problems about your mail server (sent to you because postmaster@xxxxxxxxx.de does not work) Dear postmaster, I've received unsolicited commercial email which came from your server (www.xxxxxxxxx.de), as shown in message headers enclosed below. 192<br />
<br />
 Please look at the 'Received:' header inserted by your server: Received: from Ben by xxxxxxxxx.de (SMI-8.6/SMI-SVR4) id WAA04352; Wed, 15 Jul 1998 22:59:57 +0200 your server does _not_ record the IP address of the sender ('Ben' is with evidence the fake string used by the spammer in the HELO command); so maybe the spammer is one of your users as well as someone from another network, and there is no way to find out who he is. Please consider that this misconfiguration of the server is very dangerous for your organization, since you could bear responsibility for abuses (eventually crimes) perpetrated through your server. In addition, your server is configured to act as 3rd party relayer. Please configure it urgently so that only your own users be enabled to send email through it, unless the recipient is an user of yours. If the server remains as it is actually, it is going to be abused by every spammer in known universe, and to be soon blacklisted, so that most networks in the world will discard SMTP traffic from it, without distinction between spam and legitimate traffic. If you need further information on the problem and possible solutions, I recommend you the authoritative page of MAPS: http://www.mail-abuse.org/tsi/ Thank you Best regards [firma] ----------- Begin spam message with full headers: Quando ho inviato questa e-mail erano le 21,20 di un venerdì sera (e dalla gravità dei problemi rilevati si capisce pure che era un venerdì 17). Tuttavia dai destinatari c'era ancora qualcuno al lavoro e, mentre ero ancora collegato, ho avuto risposta: Dear Leonardo Collinelli, 193<br />
<br />
 Thank you for sending us this important information. Even though I am surprised that the postmaster@xxxxxxxxx.de could not be addressed your choice was excelent to choose webmaster instead. I have forwarded your mail to the security department for immediate fix. I am surprised about that information and I will enforce security considerations within our company. I thought because of the firewall we use our system would be save. Well, as I learend today: You never know... Thanx again V. Xxxxxxx +++ V. Xxxxxxx +++ Head of Software Development Quindi, diamo per scontato che i tedeschi si metteranno a posto velocemente. Resta solo l'amaro in bocca che lo spammer la faccia franca. È vero che, se volesse, l'amministratore del relay anonimo potrebbe rintracciare l'ip dello spammer nei log del server (sperando che un server in quelle condizioni scriva un log) e provvedere lui a segnalarlo alla rete di provenienza, tuttavia non è detto che su questo si possa contare. Un momento! Qualcosa che possiamo bombardargli c'è: il testo del messaggio dice di indirizzare le richieste di remove (che, ripetiamolo, nessuno dovrebbe mai inviare) ad una casella su Hotmail. Notoriamente, Hotmail applica una inflessibile politica antispam, quindi il fatto che una loro casella sia usata come semplice punto di contatto in un messaggio di spam è (e giustamente) altrettanto grave che se lo spam fosse stato originato dalla casella stessa. Ecco quindi la segnalazione per abuse@hotmail.com: Subject: Hotmail mailbox used as spammer maildrop Dear Hotmail, please deal with enclosed unsolicited commercial e-mail, where the spammer solicits replies (and remove requests) to possibile-nome-del-pirla@hotmail.com Thank you and best regards Leonardo Collinelli ----------- Begin spam message with full headers: 194<br />
<br />
 E' giunta subito, spedita in automatico, una prima conferma di ricezione della segnalazione. Ritengo utile citarne un paio di frasi: We do not recommend replying to "Remove" addresses, as this only confirms that your email address is active, and directs more unwanted email to your account. Clicking a URL embedded in an unsolicited message may reveal your Hotmail address to that Web site. The Hotmail Department of Policy Enforcement is dedicated to eradicating spam, one villain at a time. Passati solo pochissimi minuti, è arrivato un secondo messaggio da Hotmail, contenente la piacevole frase: The account you reported HAS BEEN CLOSED.<br />
<br />
Indice<br />
<br />
<< Precedente<br />
<br />
Successiva >><br />
<br />
Ultimo aggiornamento: 04 maggio 2002<br />
<br />
Leonardo Collinelli<br />
<br />
195<br />
<br />
 Cosa scrivere nel reclamo Caso pratico n. 1<br />
<br />
Siamo giunti alla parte più avvincente della nostra guida all'autodifesa contro gli spammer. Se avete letto le pagine precedenti sapete interpretare il significato tecnico degli header delle e-mail e siete, pertanto, in grado di ricostruire il percorso che ogni messaggio ha seguito. Questo però non basta; occorre raccogliere ulteriore informazione e prendere la decisione che conta: a quali soggetti inviare il reclamo e in quali termini scriverlo. Tutto ciò sarà, probabilmente, meno noioso se visto attraverso qualche caso pratico. Tra gli spam che ho ricevuto ne ho quindi scelto alcuni, in modo da coprire una casistica il più possibile completa. Cominciamo con un caso abbastanza lineare, che si può definire da libro di testo. Return-Path: <bjohnson000@ameritech.net> Received: from mail.mioisp.it (mail.mioisp.it [194.243.154.49]) by mbox.altronome-mioisp.it (8.8.5/8.8.5) with ESMTP id HAA07541 for <miacasella@box1.mioisp.it>; Thu, 12 Mar 1998 07:44:01 +0100 (MET) From: bjohnson000@ameritech.net Received: from andromeda.oakland-info.com (andromeda.netquest. com [209.69.94.6]) by mail.mioisp.it (8.8.4/8.8.4) with ESMTP id HAA27396 for <miacasella@mioisp.it>; Thu, 12 Mar 1998 07:44:00 +0100 (MET) Message-Id: <199803120644.HAA27396@mail.mioisp.it> Received: from [209.69.95.51] by andromeda.oakland-info.com (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-37888U2500L250S0) with SMTP id AIY145; Thu, 12 Mar 1998 01:45:21 +0000 To: miacasella@mioisp.it Date: Thu, 12 Mar 98 01:39:22 -0500 Subject: QUIT SMOKING IN 7 DAYS GUARANTEED ! ONLY $49.95 OR MONEY BACK! X-UIDL: 24a072eb9985896dd35b250cd22e3e81 Status: U SMOKE AWAY<br />
<br />
March 11, 1998 196<br />
<br />
 Dear<br />
<br />
Friend,<br />
<br />
Are you really ready to quit smoking? ....[Tagliamo qui, il messaggio sarebbe piuttosto lungo] Questo è un caso abbastanza semplice, che non pone alcun problema. I primi due 'Received:' sono stati messi dai mailserver del mio isp, pertanto sono attendibili e, in particolare, è attendibile la provenienza indicata sul secondo di essi: andromeda.netquest.com [209.69.94.6] che si è presentato, nel comando HELO, come andromeda.oakland-info.com. Non è raro che i sistemi siano configurati per dare un HELO diverso dal loro nome di dominio, e ciò non significa necessariamente che la cosa sia sospetta. Cominceremo con la verifica (superflua ma precauzionale) che andromeda.netquest.com sia proprio corrispondente all'indirizzo 209.69.94.6. Un DNS lookup ce lo conferma immediatamente. Se guardiamo a chi sono assengati gli indirizzi in questione, il risultato è il seguente: Trying 209.69.94 at ARIN Kennedy Industries (NETBLK-KENNEDYIND-94-32) KENNEDYIND-94-32 209.69.94.32 - 209.69.94.63 Logic Objects Inc. (NETBLK-LOGICOBJECTS-94-96) LOGICOBJECTS-94-96 209.69.94.96 - 209.69.94.127 NetQuest Communications (NETBLK-NETQUEST-209-69-94) NETQUEST-20969-94 209.69.94.0 - 209.69.95.255 RUSTnet Internet Services (NETBLK-RUSTNET-BLK1) RUSTNET-BLK1 209.69.0.0 - 209.69.255.255 The Brads (NETBLK-THEBRADS-94-160) THEBRADS-94-160 209.69.94.160 - 209.69.94.191 To single out one record, look it up with "!xxx", where xxx is the handle, shown in parenthesis following the name, which comes first. The ARIN Registration Services Host contains ONLY Internet Network Information: Networks, ASN's, and related POC's. Please use the whois server at rs. internic.net for DOMAIN related Information and nic.ddn.mil for MILNET Information. Abbiamo quindi RUSTnet come assegnatario di tutti gli indirizzi che iniziano per 209.69; tra questi, tutti quelli che hanno come terzo numero 94 o 95 sono stati tutti sottoassegnati a NetQuest Communications, per finire con le altre tre compagnie indicate, che usano dei sottointervalli all'interno del blocco di NetQuest (della quale probabilmente sono clienti). Da qui si capisce che NetQuest deve essere un provider di discreta dimensione. Per farsene un'idea più precisa si cerca il relativo sito web. Non sempre è facile trovare il sito web essendo noto un nome di dominio ma, nella maggior parte dei casi, basta digitare semplicemente nel browser il nome di dominio o 197<br />
<br />
 magari premettergli "www.". In qualche caso, con il nome di dominio che si conosce non si trova alcun sito, e ancora più difficile è quando si avesse solo un netblock. Quando questo succede si deve ricorrere ai motori di ricerca. Nel nostro caso, comunque, non è necessario e, ad una veloce visita, il sito della NetQuest appare come ci si può aspettare che sia il normale sito di un provider. Per essere certi di avere informazioni complete, conviene fare una ricerca sull'archivio usenet di Google. Gli archivi delle segnalazioni di spam e delle relative discussioni (originate su newsgroup o su mailing list) sono uno strumento preziosissimo. È possibile infatti cercare se, nei newsgroup della gerarchia news.admin.net-abuse, risulta qualcosa a carico di entità coinvolte nel nostro caso. Potremmo anche trovare uno spam identico al nostro, già accompagnato da osservazioni valide a farci risparmiare tempo. Si farà quindi qualche ricerca, per esempio inserendo le parole più significative presenti nel subject dello spam, o la url di un eventuale sito web pubblicizzato nel messaggio, il numero di telefono che lo spammer fornisce per contattarlo e così via. Se si è già pervenuti al nome di un provider (in questo caso NetQuest), si proverà a cercare che cosa eventualmente se ne dica: ci sono molte reti spam-friendly che riescono a dare nel loro sito l'apparenza da organizzazione seria, e non sarebbe utile mandare reclami a chi sia colluso con gli spammer o sia noto che li protegge. Per sapere se si è in un caso simile, non c'è che cercare le esperienze altrui. Comunque, nel nostro caso constatiamo che su NetQuest non si dice nulla. Non notando quindi nulla che ci debba portare a diffidare, diamo anche un'occhiata all'header inserito dal server di NetQuest. Qui si nota che non è indicato il nome della risorsa di provenienza, ma c'è l'indirizzo IP, che risulta essere interno al blocco della stessa NetQuest. Non occorrerebbe ma, già che ci siamo, possiamo tentare un reverse DNS su tale indirizzo. Non è detto che il reverse DNS sia possibile ma, se anche non lo fosse, poco male. Comunque funziona e dà questo risultato: nslookup 209.69.95.51 Canonical name: dyn-95-51-pontiac.netquest.com Addresses: 209.69.95.51 .com is a domain of USA & International Commercial Searches for .com can be run at http://rs.internic.net/cgi-bin/whois Il nome che abbiamo ricavato (e che risulta verificato dal dns diretto) ha in tutto e per tutto la faccia di una connessione dial-up. A questo punto il quadro è chiaro: lo spammer ha usato un account presso la NetQuest per collegarsi in rete e, per l'invio dello spam, ha utilizzato il server SMTP che NetQuest mette a disposizione dei propri utenti. Assodato pertanto che dobbiamo reclamare a NetQuest, l'ultima parte dell'indagine deve portarci a determinare l'esatto indirizzo di e-mail a cui scrivere. Secondo la RFC2142 l'indirizzo dovrebbe seguire lo standard abuse@nomedominio, ma sarebbe troppo semplice se tutti seguissero questo standard. In pratica, molti provider hanno fatto a gara per inventare indirizzi fantasiosi. La cosa migliore da fare è guardare il sito web del provider in questione. Si dovranno cercare le pagine 198<br />
<br />
 che danno informazioni sull'azienda (possono avere titoli del tipo "About us" oppure "How to contact us" o simili); in particolare, qualora esista va sempre consultata la pagina di Acceptable User Policy (che può avere titoli assai vari come "Terms and Conditions", "Acceptable User Guidelines" o altro). In molti casi, su tali pagine si può reperire un indirizzo creato apposta per ricevere questo genere di segnalazioni. Se sul sito in questione non trovate nulla, potete consultare la lista degli indirizzi di segnalazione abusi per i principali provider, mantenuta dalla Abuse.net. Se comunque non trovate nessuna indicazione, l'indirizzo canonico a cui scrivere è postmaster@nomedominio; non è sbagliato inviare l'email con entrambi i destinatari abuse e postmaster (se eventualmente abuse non funzionasse, pazienza). Una soluzione più begosa ma migliore è di tentare l'invio direttamente ad abuse: se l'indirizzo risulta non definito si ripiega su postmaster. Sarebbe sbagliato utilizzare gli indirizzi normalmente indicati dai record del whois (per esempio il "techical contact" o, peggio ancora, il "billing contact"), come sarebbe sbagliato scrivere al webmaster. Nel nostro caso, poiché riguardo a NetQuest non risulta esistere un apposito indirizzo, la e-mail dovrà essere scritta al postmaster. Vale la pena di tenere presente che, in base alle regole, qualunque rete connessa ad Internet deve avere la mailbox postmaster valida e deve esserci qualcuno a leggerne la posta in arrivo: se l'indirizzo postmaster risultasse non contattabile per un sito italiano, varrebbe la pena di segnalare la cosa al nic.it: gli darebbero una bella lavata di testa. Adesso resta solo da decidere cosa scrivere nella nostra e-mail. Ho visto, in un sito antispam americano, un esempio di testo da adottare che conteneva un lungo predicozzo sul perché lo spam è male eccetera eccetera. Non sono d'accordo: chi legge queste segnalazioni non ha alcun bisogno del predicozzo, anzi, ha solo bisogno di non stare a perdere tempo e di riuscire a capire velocemente qual è la natura del problema. Vediamo quindi di sintetizzare i consigli più importanti: ●<br />
<br />
Siate brevi, limitatevi a dire solo il necessario E' appropriato indichiate che si tratta di un messaggio non sollecitato, che voi non avete richiesto e che non volete riceverne altri. Spiegate anche perché ritenete che il problema competa a loro. Altre chiacchiere sono fuori luogo. Specialmente quando scrivete ad un grosso provider, è probabile che poche persone debbano evadere una montagna di reclami che arrivano in continuazione. E' nostro interesse che queste persone possano fare il loro lavoro nella maniera più produttiva. Anche se, per quanto mi riguarda, preferisco comunque mettere due righe di introduzione, giusto per sintetizzare per quale motivo gli sto scrivendo, ritengo che in molti casi basterebbe semplicemente rigirargli il messaggio in questione, anche senza commenti.<br />
<br />
●<br />
<br />
Nel campo 'Oggetto:' (o 'Subject:') mettete poche parole che definiscano la situazione Per esempio, scrivendo al postmaster di ABCD.NET l'oggetto potrebbe essere: "Unsolicited commercial e-mail from ABCD.NET". Un'altra soluzione da considerare validissima e, nella grande maggioranza dei casi, preferibile, sarebbe di costruire un subject prendendo quello del messaggio di spam preceduto da "Fwd: ", trattandosi di un inoltro del messaggio. Questo consente a chi riceve la segnalazione di vedere subito di che spammer si tratta. 199<br />
<br />
 ●<br />
<br />
Siate cortesi Anche se lo spam vi ha irritato parecchio, non è il caso di dimenticare che la persona che leggerà la vostra e-mail non ha nessuna colpa. Anzi, è potenzialmente nostro alleato.<br />
<br />
●<br />
<br />
Evitate di fare illazioni o di trarre conclusioni arbitrarie Non dite nulla di cui non ci sia evidenza. Per esempio, non state a parlare di unsolicited bulk e-mail, anche se la locuzione è molto comune in qualunque trattazione sullo spam: unsolicited e-mail è incontestabile, commercial può essere evidente ma bulk significa "spedita in gran massa", vale a dire, a parecchi altri destinatari oltre che a voi. Per quanto questo sia probabile, non potete assolutamente saperlo. A maggior ragione non state a segnalare che lo spam in oggetto ha contenuto illegale, a meno che non abbiate ottima conoscenza della legislazione di quel particolare stato degli USA in cui ha sede il vostro interlocutore (e siate ben sicuri di quello che dite). Per esempio, è molto raro che il carattere pornografico di un messaggio lo renda illegale. Se lo è, spetterà a chi gestirà la vostra segnalazione accorgersene. L'importante è non perdere di vista che la gravità dello spam non deriva dal contenuto (sarebbe molto pericoloso per la libertà in rete mettersi a censurare in base ai contenuti), ma dal fatto di essere stato inviato non richiesto ad una mailbox che è vostra proprietà privata.<br />
<br />
●<br />
<br />
Mettete in evidenza tutte le aggravanti che avete riscontrato Esempi di aggravanti per una azione di spamming possono essere questi: ❍ ❍<br />
<br />
❍<br />
<br />
avere falsificato degli header; avere usato il server di una terza parte come relayer; (vedremo nel prossimo capitolo di che si tratti) essere un Make Money Fast (definito anche schema piramidale o schema di Ponzi); si tratta di vere e proprie truffe, illegali in molti paesi. E', tra l'altro, l'unico tipo di contenuto la cui cancellazione su Usenet sia legittima a vista. Come si diceva sopra, limitatevi ad evidenziare che si tratta di uno schema piramidale (basta mettere nel subject "Unsolicited MMF e-mail..."). L'organizzazione da cui lo spam è stato originato si darà verisimilmente molto da fare, anche per evitare l'eventualità di essere implicata nell'attuazione di una truffa.<br />
<br />
Nel caso che abbiate già ricevuto il medesimo spam tramite la loro rete (o comunque sia chiaro dal contenuto che lo spammer è il medesimo), fatelo presente. E' probabile che attribuiscano maggiore urgenza alla gestione degli spammer ostinati. Un altro abuso cui non sempre si presta attenzione ma che va segnalato è la simulazione della provenienza da un dominio realmente esistente e non coinvolto in altro modo. Per esempio, tempo addietro vari spammer incominciarono ad indicare nel campo 'From:' dei falsi indirizzi su hotmail.com, con il risultato che qualcuno si mise a bloccare ciò che appariva provenire da Hotmail. Quelli di Hotmail iniziarono allora a fare causa agli spammer che inserivano falsi riferimenti al dominio hotmail.com nelle loro junk email, ottenendo in tribunale piena soddisfazione (e risarcimento danni). Se quindi nel campo 'From:' vedete un indirizzo che fa riferimento ad un provider o fornitore di servizi di email che sapete esistente, anche se il messaggio non è giunto dalla loro rete vale senz'altro la pena di avvertirli. O 200<br />
<br />
 l'indirizzo corrisponde ad una mailbox reale usata dallo spammer come 'maildrop' (ossia per essere contattato), nel qual caso va fatta chiudere, oppure si tratta di una mailbox inesistente, nel qual caso il titolare del dominio potrebbe voler prendere opportuni provvedimenti. ●<br />
<br />
Evitate di dirgli che cosa devono fare E' fuori luogo dirgli, per esempio, di revocare l'accesso all'utente responsabile. Può essere che la loro prassi preveda, per la prima volta, la semplice ammonizione: non potete saperlo. Del resto, è il postmaster in questione a sapere di quale utente si tratti e come sia il caso di gestirlo. Limitatevi a chiedere che prendano provvedimenti per evitare che la cosa si ripeta.<br />
<br />
●<br />
<br />
Ricordatevi di allegare il testo dello spam completo di header Gli header del messaggio sono indispensabili: senza di essi il postmaster non può fare nulla. Conviene inserirli in fondo alla vostra e-mail, facendoli precedere da una riga di segnalazione. Dopo gli header va messo il vero e proprio testo del messaggio di spam. Tale testo non è indispensabile quanto gli header ma consiglierei senz'altro di non tralasciarlo.<br />
<br />
●<br />
<br />
Non lasciate passare del tempo: inviate subito la vostra segnalazione Occorre che il reclamo giunga a destinazione entro pochissimi giorni (3-4 al massimo) dalla data in cui lo spam è stato inviato.<br />
<br />
Ciò detto, vediamo il testo della segnalazione consigliabile per il caso in esame: Dear postmaster, please deal with following unsolicited e-mail I've recently received: it's a commercial advertisement not requested by me and I don't want any more of it. The 'Received:' headers show it comes from andromeda.netquest.com, maybe from resource 209.69.95.51 (dyn-95-51-pontiac.netquest.com). Thank you Best regards [firma] ---------------------------- Begin spam message with full headers: Return-Path: <bjohnson000@ameritech.net> [eccetera, segue il testo completo di header e messaggio] Traduzione: Egregio postmaster, si occupi per favore della seguente e-mail non sollecitata che ho recentemente ricevuto: è un annuncio commerciale non richiesto da me, e non ne voglio ricevere altri. Gli header 'Received:' mostrano che viene da xxxxx. Grazie. Distinti saluti<br />
<br />
Probabilmente, chi conosce l'inglese meglio di me avrà un po' obiezioni, ma anche così si è dimostrato efficace. Prima però di vedere il finale, poniamoci un'ultima domanda. 201<br />
<br />
 Cosa succede quando la nostra segnalazione viene ricevuta ? A volte lo veniamo a sapere a volte no. A seconda dell'organizzazione a cui si invia la segnalazione, può darsi che si riceva subito una risposta automatica. E' il caso, per dare qualche nome, di CompuServe, Netcom, UUnet. La risposta automatica ci conferma che la nostra segnalazione è giunta a destinazione, ma non ha particolare contenuto informativo. In qualche caso (UUnet) la risposta (automatica o no) comunica un numero di riferimento assegnato al problema, da utilizzare per ulteriori comunicazioni al riguardo: per esempio, se lo stesso spam vi viene inviato più volte, nelle segnalazioni successive includerete il riferimento in modo da consentirgli di decidere se gestire la cosa nell'ambito dello stesso incidente. Dopo la risposta automatica (sempre che ci sia stata), è probabile che non riceviate più nulla. Chi gestirà la faccenda farà uso del log che ogni provider deve tenere per registrare tutte le attività effettuate dagli utenti. Questi log non vengono tenuti per un tempo infinito, ed è questa la ragione per cui le segnalazioni devono essere tempestive. Nel caso in esame, il postmaster avrà verisimilmente cercato sul log quale userid risultava collegato, il giorno 12 marzo 98 alle ore 01:45:21 sul nodo dyn-95-51-pontiac.netquest.com. Può darsi che, per ulteriore conferma, abbia anche verificato l'effettuazione della transazione SMTP contraddistinta dall'id AIY145. A quel punto, l'accertamento sarà stato completo. Alcuni provider inviano una comunicazione finale all'autore della segnalazione, per confermare che si è provveduto; altri (la maggior parte) non si fanno più vivi in alcun modo, ma ciò non significa necessariamente che la faccenda sia stata trascurata. Certo, l'invio della comunicazione finale è una prassi che denota serietà e buona organizzazione e che mi sentirei di raccomandare ad ogni provider. Nel caso di NetQuest ho ricevuto, dopo due giorni, la seguente e-mail: The customer has been warned that another incident like this one, and we would cancel his account with our service. Please inform me if this happens again. Thanks.. _________________________________________________________________________ Lee A Keiser, President NetQuest Communications http://www.netquest.com Poiché è stata data evidenza che al cliente non viene consentito di continuare questo tipo di attività, l'esito di questo caso è stato senz'altro positivo.<br />
<br />
Indice<br />
<br />
<< Precedente<br />
<br />
Successiva >><br />
<br />
Ultimo aggiornamento: 09 settembre 2001<br />
<br />
Leonardo Collinelli<br />
<br />
202<br />
<br />
 Strumenti online<br />
<br />
Reset<br />
<br />
DNS<br />
<br />
(Specificare un nome host o un indirizzo IP)<br />
<br />
DIG<br />
<br />
(Specificare un nome dominio di qualsiasi tld o un nome host o un indirizzo IP) MX NS SOA TXT ALL Tipo query: NameServer (opzionale, normalmente non occorre indicare nulla): (se si indica il NameServer, la query sarà non recursiva) (in caso di dubbi su come usare questo strumento, ci sono alcune istruzioni qui sotto)<br />
<br />
Whois<br />
<br />
(Specificare un nome dominio .com, .net, . org, .edu, .it, .de, .uk, .jp, .fr, .be, .ch o .ca, oppure un handle nella forma !xxx) Attivare la casella se si tratta di un dominio su 3 livelli (come nei casi: dominio.nomecomune.it, dominio. siglaprovincia.it o come nei domini .uk o .jp)<br />
<br />
Abuse Net<br />
<br />
(Specificare un nome dominio in qualsiasi<br />
<br />
tld) Attivare la casella se si tratta di un dominio su 3 livelli (come nei casi: dominio.nomecomune.it, dominio. siglaprovincia.it o come nei domini .uk o .jp)<br />
<br />
Blocklist<br />
<br />
(Specificare un nome host o un indirizzo IP)<br />
<br />
IP su ARIN<br />
<br />
(Specificare un indirizzo IP oppure un handle nella forma: !xxx oppure un AS number nella forma ASnnn) 203<br />
<br />
 IP su RIPE<br />
<br />
(Specificare un indirizzo IP oppure un AS number nella forma ASnnn)<br />
<br />
IP su LACNIC<br />
<br />
(Specificare un indirizzo IP oppure un AS number nella forma ASnnn)<br />
<br />
IP su APNIC<br />
<br />
(Specificare un indirizzo IP oppure un AS number nella forma ASnnn)<br />
<br />
Nel caso vi interessi saperlo, l'attuale indirizzo IP vostro o del proxy con cui state navigando è: 80.116.122.33<br />
<br />
Note: ●<br />
<br />
●<br />
<br />
●<br />
<br />
●<br />
<br />
●<br />
<br />
Gli indirizzi IP vanno specificati nella notazione usuale dotted quad oppure in base 256 (in questo caso sono espressi con un numero intero da 8 a 10 cifre). Il dig può essere effettuato su un dominio al fine di scoprirne il mail-exchanger (MX), i server DNS che hanno autorità su di esso (NS), la zona di autority (SOA) e altre informazioni (si tenga conto che selezionando ALL la risposta non è l'insieme di tutte le informazioni delle altre query). Effettuando il dig su un indirizzo IP, le query più significative sono NS e SOA, in quanto consentono di scoprire chi ha l'autorità di definire i reverse DNS su tale indirizzo. Normalmente si dovrebbero ottenere le informazioni anche senza dirigere il dig su un particolare nameserver (lasciando vuoto l'apposito campo, le informazioni provengono dal nameserver di default per il webserver su cui risiede questo sito); in caso di dubbi sui risultati è possibile dirigere le query su altri nameserver (a questo proposito, saranno in generale da preferirsi i nameserver che hanno autorità sulle risorse di cui si cercano informazioni). È possibile verificare la presenza di un indirizzo ip nelle principali liste di blocco pubblicamente consultabili tramite query DNS (si fa presente che le blacklist di MAPS, ossia RBL, RSS e DUL, non sono liberamente consultabili via query DNS, quindi per verificare la presenza di un indirizzo IP in tali liste è necessario andare al sito di MAPS). In alternativa ad un indirizzo ip si può indicare un nome host: in questo caso il controllo verrà effettuato per tutti gli indirizzi ip ad esso corrispondenti. L'output di ARIN e certi whois di dominio può contenere degli identificativi tra parentesi, gli handle che identificano oggetti su cui è normalmente possibile ottenere ulteriori informazioni. A questo scopo si ripeta l'interrogazione inserendo l'handle preceduto da un punto esclamativo. Nelle interrogazioni Whois e Abuse Net sono supportati anche i domini su 3 livelli (tipici, 204<br />
<br />
 nel caso della Registration Authority italiana, per i domini geografici come per es. comune. modena.it oppure provincia.ra.it). I domini su tre livelli sono la norma sotto alcuni tld, in particolare i .uk inglesi e i .jp giapponesi. In questi casi, per effettuare la query sul dominio completo (e non solo su comune.it o siglaprovincia.it o co.uk o or.jp) occorre attivare la casella. Ovviamente, se si attiva la casella in presenza di un nome host con normale dominio a 2 livelli, non si otterrà alcuna risposta significativa.<br />
<br />
Indice Ultimo aggiornamento: 13 agosto 2002<br />
<br />
Leonardo Collinelli<br />
<br />
205<br />
<br />
 Dal mondo dello spam Testo delle notizie dall'1/8/2000 al 31/12/00<br />
<br />
001229 - Fine anno: cause contro MAPS; passo avanti della Commissione Europea La fine del 2000 per MAPS si caratterizza con una crescita del numero di cause legali intentate da reti i cui indirizzi erano stati listati in RBL. Dopo i casi di YesMail, Harris Interactive e Exactis, l'ultimo caso si è avuto a metà dicembre quando Media3 (servizio di web hosting del quale circa 1500 ip erano stati listati in RBL) ha tentato, senza successo, di ottenere dal giudice un TRO per imporre a MAPS la rimozione dei loro ip da RBL. Media3 era stata listata per via del gran numero di siti, ospitati sui suoi server, che offrivano software per spammer e servizi di bulk-email. Il giudice ha negato il TRO ma, meno comprensibilmente, ha proibito a MAPS di listare ulteriori ip di Media3 in RBL. Venendo in Europa, EuroCauce ha reso noto che la Commissione Europea ha proposto nuove disposizioni che richiederebbero il preventivo consenso del destinatario per inviare pubblicità in email, equiparando così la posta elettronica ai sistemi automatizzati di chiamata. Verrebbe in questo modo a valere per tutta l'Europa il principio già presente nella legislazione italiana (che ha recepito la attuale direttiva comunitaria sul commercio elettronico aggiungendo appunto la posta elettronica ai mezzi per il cui uso è richiesto il preventivo consenso del consumatore). Si segnala già una intensa attività di lobbying sul Parlamento Europeo da parte delle organizzazioni del marketing, le quali si oppongono alla proposta della Commissione, ritenendo di avere il diritto a dire loro l'ultima parola su ciò che deve arrivare nelle mailbox altrui. In definitiva, sembra che certo mondo aziendal-affaristico interessato a realizzare profitto con ogni mezzo, compresa una pratica squalificante come la junk-email, stia passando alla controffensiva, sia nelle aule dei tribunali che negli sgabuzzini dei legislatori. La classica immagine dello spammer come squallido personaggio sta da tempo venendo affiancata dall'immagine del nuovo spammer, spesso azienda in grado di pagare buoni avvocati e con "associazioni di categoria" in grado di fare lobby ad alti livelli. L'eredità che il 2000 si appresta a lasciare all'anno che seguirà è quindi preoccupante, e fa intravvedere un futuro prossimo in cui, ancora una volta, bisognerà lottare per affermare i più ovvi diritti di cittadini e utenti. 001209 - Prorogato l'ordine del giudice federale per sospendere il listing di 206<br />
<br />
 Exactis in RBL 24/7 Exactis, una compagnia a carico della quale risultano pratiche di invio email non conformi alle policy del MAPS, era stata listata in RBL qualche tempo fa, dopo che ben 12 nomination erano state sottomesse al MAPS. Rivoltisi al giudice, i legali di 24/7 avevano ottenuto un TRO (Temporary Restraining Order) che imponeva a MAPS di rimuovere i relativi indirizzi da RBL. Ora il TRO è stato prorogato, venendo fissata la data per il dibattimento nel 21 maggio 2001. Il giudice John Kane (di una corte distrettuale federale del Colorado) ha indicato che al MAPS è fatto divieto di aiutare o incoraggiare o indurre alcuno ad interferire con l'inoltro dei messaggi di email spediti da 24/7. È anche fatto divieto ad entrambe le parti di parlare del caso. Si sa tuttavia che al MAPS non sono particolarmente contrariati, in quanto la presenza di un TRO pare consenta di giungere al dibattimento in tempi molto più celeri. Resta da capire come possa conciliarsi con un normale diritto alla libertà di espressione un divieto, per quanto temporaneo, ad esprimere (sotto forma di record su un server DNS) il proprio parere sulle pratiche di rete di un qualsiasi soggetto. Nel frattempo, negli ambienti antispam circolano elenchi completi dei blocchi ip in uso a 24/7, e sono sempre più numerosi i gestori di rete che li aggiungono alle proprie blacklist, in modo che le mail originate da 24/7 vengano bloccate indipendentemente dal fatto che il listing in RBL ci sia o no. Si può pensare che, quand'anche la vicenda si chiudesse e 24/7, adeguate le proprie pratiche, uscisse definitivamente da RBL, non sarebbe semplice per essa riavere completa connettività in tempi brevi. 001108 - AT&T e PSI: conclusi (e velocemente rescissi) imbarazzanti contratti con spammer A breve distanza di tempo, sono stati scoperti contratti con cui due tra i maggiori ISP americani (AT&T e PSI Net, noti anche per essere proprietari, rispettivamente, dei blocchi di indirizzi ip 12.*.*.* e 38.*.*.*) si impegnavano a fornire, in deroga alle proprie stesse policy antispam, connessioni spam-friendly a determinati clienti. Il merito di entrambe le scoperte è dello Spamhaus project, curato da Steve Linford. Il caso di AT&T risale all'1 novembre. Il contratto di cui Steve Linford è venuto a conoscenza (e che ha prontamente reso pubblico sul sito dello Spamhaus project) prevedeva la fornitura di connettività a NevadaHosting. Nel contratto si indicava l'esplicita intenzione, da parte di NevadaHosting, di fornire hosting di siti web pubblicizzati mediante spam, con la precisazione che lo spam sarebbe stato diffuso tramite altre connessioni, diverse da quella fornita da AT&T, e con l'impegno che AT&T non avrebbe cancellato, malgrado tale spam, il servizio fornito a NevadaHosting. Il 7 novembre veniva reso noto da CNET il caso riguardante PSI Net. Qui il cliente era Cajunnet, e nel testo si dichiarava che Cajunnet avrebbe praticato, tramite la connessione fornita da PSI, l'invio di quantità massive di email a liste sia di opt-in che di opt-out, che 207<br />
<br />
 avrebbe tenuto su tale connessione dei siti pubblicizzati mediante la suddetta bulk email, e che tutti i relativi reclami ricevuti dall'abuse desk di PSI sarebbero stati semplicemente passati (unchanged) a Cajunnet. Il cliente versava inoltre la cifra di 27'000 dollari a fondo perduto, per coprire i maggiori rischi per PSI dovuti all'esecuzione del contratto stesso. La reazione dei due provider non si è fatta attendere. Entrambi hanno reso noti dei comunicati ufficiali, postandoli su news.admin.net-abuse.email. La nota diffusa da AT&T così recita: AT&T has reviewed the document posted at http://spamhaus.org/rokso/ nevadahosting.jpg. That document represents a revision to AT&T's standard contract that was entered into by a sales representative without proper authorization and is in conflict with AT&T's anti-spamming policies. The agreement has been terminated and the customer has been disconnected. It is not AT&T's policy or practice to enter into such agreements or to allow spam related activities. In fact, AT&T's policy, as set forth in its Acceptable Use Policy (http://www. ipservices.att.com/policy.cfm), is quite the opposite. Quanto alla risposta data da PSI: ... omissis ... First, PSINet no longer provides service to the customer mentioned in the article. Second, the "so-called pink contract" obtained by CNET was handled by a junior lawyer in PSINet's commercial contracts group who was handed a proposed addendum by a commercial marketer setting forth what purported to be stricter rules for compliance with our Net Abuse Policy. PSINet's Net Abuse Policy is not negotiable, and we will not knowingly enter into service agreements that provide a license to commit Policy violations. .... Il testo di PSI Net, molto più lungo, proseguiva indicando gli sforzi in corso da parte della compagnia per ridurre la quantità di spam diffusa dalla loro rete (es. il port 25 filtering), e prendeva alcuni impegni, tra cui il rafforzamento della net-abuse policy, la diffusione di un forte messaggio al proprio interno perché sia chiaro che la compagnia non intende fornire alcun genere di servizio agli spammer, una formazione specifica alle forze di vendita al fine di prevenire il ripetersi di simili episodi ed una formazione ulteriore alle persone dell'abuse desk, in modo che siano maggiormente preparate alle astuzie messe in atto dai marketer per tentare di aggirare la policy antispam. Anche se l'addossare ogni responsabilità a qualche ultima ruota del carro è sempre stata poco convinvente come prassi aziendale (che si tratti di un commerciale andato oltre quanto era autorizzato o di un giovane ed inesperto avvocato dell'ufficio contratti), bisogna 208<br />
<br />
 considerare positivo il fatto che i due ISP abbiano prontamente reagito dissociandosi da quanto accaduto. Ciò non toglie che certe precisazioni in realtà lascino parecchi punti non chiari (per esempio, il "proposed addendum" di PSI era poi stato firmato o no? quando esattamente è cessato il servizio a quel cliente? chi poteva pensare che quel proposed addendum consistesse di regole più severe per l'applicazione delle policy, specialmente dal momento che per tale trattamento il cliente pagava una significativa somma di denaro? ...). In particolare viene da chiedersi cosa sarebbe accaduto se nessuno avesse indagato e scoperto questi contratti o, naturalmente, se esiste il rischio che queste cose non siano fatti isolati e che se ne possano avere altri casi in futuro, da parte degli stessi soggetti o di altri. Per trarre conclusioni è, probabilmente, ancora presto. Di certo questi fatti rafforzano una nostra convinzione: il diritto di usare la rete (e la posta elettronica in particolare) nelle dovute condizioni di tranquillità va lentamente conquistato giorno dopo giorno, mentre può essere compromesso nel giro di poche ore. Di una diffusa sensibilità al problema degli abusi di rete, come della volontà e capacità di combatterli, ci sarà quindi sempre bisogno. È vero che, nel mondo aziendale e affaristico, potranno sempre manifestarsi tendenze a considerare ogni scrupolo di correttezza semplicemente un costo: ciò può avvenire per semplice avidità o per incapacità di vedere al di là del proprio naso. È comunque anche vero che, in genere, queste tendenze possono essere fermate. 001021 - Imponente episodio di spam politico in Italia Negli USA lo spam a contenuto politico, per quanto non frequente, non è una novità. Anche in Italia, in occasione di precedenti tornate elettorali, si era registrato qualche episodio, per lo più ascrivibile ad improvvide iniziative da parte degli entourage di qualche candidato. Quello che si è invece avuto, per diversi giorni, nella prima metà di ottobre, è stato il primo episodio di dimensioni ed organizzazione effettivamente preoccupanti. Riguardo alla cronaca, qui ci limitiamo a riassumere alcuni punti: si ebbe una prima ondata di spam tra il 4 e il 5 ottobre, conclusasi quando il provider che forniva la connessione intervenne a bloccarla. La cosa evidentemente non fu sufficiente per indurre i mittenti a porsi i dovuti interrogativi: trovata un'altra connessione a Padova, diffusero una nuova ondata tra il 10 e l'11 ottobre. Il messaggio aveva un titolo che iniziava con "Toc toc" (come se stesse bussando invece che essere già entrato) e conteneva, in un postscriptum, la frase "Questa email e' stata inviata nel rispetto della legge sulla privacy.". Tralasciamo il fatto che la legge 675 è molto complicata e che, pertanto, è il caso di essere molto cauti nel definire una qualsiasi azione come rispettosa di tale norma; ammettiamo pure che lo sia: bene, personalmente troviamo un simile disclaimer particolarmente irritante. Gli spammer americani professionisti usano tutti i momenti disclaimer in cui farfugliano di essere in conformità a qualche legge, di solito inesistente. Al nostro orecchio tutti questi disclaimer suonano come se dicessero: "La legge ci consente di effettuare questo mailing. Quindi tu, che ti piaccia o no, questo messaggio te lo devi beccare. Capito?". Le prevedibili proteste da parte di numerosi destinatari delle email sembrarono aver colto di sorpresa gli organizzatori, i quali almeno in un primo tempo parvero assai poco inclini a riconoscere l'errore commesso (cosa che ha certo aggravato le conseguenze di questo incidente in termini di immagine). In particolare, nel corso di una trasmissione radiofonica 209<br />
<br />
 nella tarda serata del 18 ottobre la posizione da loro espressa fu tesa a minimizzare le reazioni negative avutesi da parte degli utenti raggiunti dallo spam, riferendo che "solo" 600 persone avevano inviato una email di protesta. Certamente molti altri avranno protestato solo ai provider tramite i quali lo spam è stato diffuso, senza farsi vivi con i mittenti al fine di non confermare implicitamente la validità del proprio indirizzo di email; supporremmo infine che una grande maggioranza dei destinatari, o per la difficoltà nel leggere gli header o per mancanza di tempo, abbia preferito cancellare il messaggio, magari profferendo nel frattempo qualche parola poco gentile. Comunque, se anche le persone infastidite fossero state solo 600 (o anche molte meno, naturalmente), a noi non pare affatto poco. Altri punti emersi nel corso della trasmissione radiofonica sono stati i seguenti: ●<br />
<br />
●<br />
<br />
"Non abbiamo iscritto ad una mailing list, è stato mandato un messaggio singolo (a parte qualche caso in cui, per errore, il messaggio è arrivato doppio)". Questa è una giustificazione che si sente spesso accampare da parte degli spammer americani (quante volte abbiamo visto frasi come: "This is a ONE-TIME mailing!"). Ovviamente occorre pensare a cosa accadrebbe in rete se chiunque avesse (a proprio giudizio, ben inteso) qualcosa da dire mandasse un messaggio singolo a centinaia di migliaia di indirizzi di email raccolti qua e là. "Il messaggio prevedeva il meccanismo di unsubscribe". Questa osservazione, pur essa accampata usualmente dagli spammer americani, è caso mai in contraddizione con la precedente (non si trattava di un messaggio singolo?). Anche se questa posizione (il cosidetto opt-out) è da sempre la favorita da parte delle lobby del marketing on-line, in rete si è da lungo tempo stabilito un consenso sul principio secondo cui questa idea, di concedere a chiunque un "morso gratis" alla proprietà altrui, non può essere accettata. Oltre al non poter immaginare alcuna ragione valida per cui l'utente debba accettare questo "sacrificio" su richiesta di chicchessia, sono i numeri stessi in gioco sulla rete a far sì che l'opt-out avrebbe, come conseguenza, la morte di un mezzo di comunicazione individuale utilissimo quale è la posta elettronica. E poi, a tantissimi utenti di posta elettronica non interessa affatto, una volta ricevuto a proprie spese lo spam, sentirsi dire che, se chiedono gentilmente al mittente di essere cancellati, questo vedrà eventualmente di accontentarli. Ciò che interessa è poter decidere: di iscriversi e, soprattutto, di NON iscriversi. Ultima cosa che ci chiediamo: se hanno messo un unsubscribe, forse si aspettavano che quel tipo di messaggio potesse risultare sgradito? Parrebbe di sì, anche a giudicare dal "mi scusi ancora" che compare nel testo del messaggio subito prima della firma. Ma se è così, allora, perché lo hanno spedito ugualmente?<br />
<br />
Ci auguriamo che questo episodio si chiuda senza ricadute e, soprattutto, che non abbia a verificarsi ciò che ora tutti temono; cioè che altri partiti o movimenti di vario genere pensino bene di provare la stessa strada, provocando incidenti analoghi. Anni fa il popolo italiano, votando a stragrande maggioranza un referendum, abolì il finanziamento pubblico dei partiti politici. Ci piace l'idea che nessun cittadino si trovi, neppure indirettamente in quanto contribuente, a finanziare tutti i partiti compresi quelli che non gli aggradano. Non ci piace per nulla che i partiti inizino a farsi finanziare le loro campagne pubblicitarie direttamente dai singoli cittadini il cui indirizzo di email finisse nelle loro liste. Un 210<br />
<br />
 messaggio non richiesto in email non è "pubblicità a basso costo", come qualcuno ha detto nel corso di questa vicenda. È solo pubblicità a spese altrui. 001015 - Cambia nome la zona DNS di MAPS DUL Per interrogare MAPS DUL, la lista di nodi dialup utilissima per fermare gli spam di tipo direct-to-MX, fino a qualche tempo fa si eseguivano le query sulla zona dul.maps.vix.com. Ora la zona si chiama: dialups.mail-abuse.org Non si rilevano cambiamenti riguardo ai nomi delle zone per MAPS RBL ed RSS.<br />
<br />
Indice<br />
<br />
Indice Notizie<br />
<br />
Ultimo aggiornamento: 29 dicembre 2000<br />
<br />
Leonardo Collinelli<br />
<br />
211<br />
<br />
 Notizie dal mondo dello spam Cosa sta succedendo<br />
<br />
Questa pagina raccoglie notizie su fatti potenzialmente importanti (o anche solo curiosi) in materia di abusi di rete e lotta allo spam. I fatti descritti sono comunque raccontati attraverso la visione (di parte) di chi mantiene queste pagine. Questa pagina viene aggiornata a seconda delle disponibilità di tempo. È pertanto possibile che notizie anche degne di menzione vengano saltate. Si fa inoltre presente che i link contenuti nelle notizie (attuali al momento della pubblicazione) possono diventare non più validi in tempi successivi.<br />
<br />
26-ott-03 Al Senato USA passa la S877: siamo alle solite. Conclusa la battaglia legale di un gruppo di spammer contro Spamhaus.org e 19-ott-03 altri antispammer. 27-set-03<br />
<br />
Continuano gli attacchi d.d.o.s: chiude anche UPL di Monkeys.com. Torna in servizio OpenRBL.org.<br />
<br />
06-set-03<br />
<br />
Svolta nella battaglia legale promossa da EMARKETERSAMERICA.ORG contro Spamhaus.org e altri antispammer.<br />
<br />
31-ago-03 Attacchi d.d.o.s. contro il sito di SPEWS e contro Osirusoft. 27-apr-03 Spamhaus.org e altri antispammer citati in giudizio in Florida. 31-dic-02 Il punto della situazione a fine 2002. 14-ott-02 L'antispammer australiano Joey McNicol vince in tribunale contro T3 Direct. 31-mag-02 L'Europa ha deciso: sarà OPT-IN. 23-mar-02 ORBZ chiuso. 17-giu-01 ORBS chiuso. È ora attivo ORBS UK 01-apr-01 HR718: un'altra deludente proposta di legge anti(?)spam al Congresso USA 18-feb-01 Proposta di legge antispam in Ohio 16-gen-01 Nuova legge antispam in Norvegia 14-gen-01<br />
<br />
Lo spammer del momento: vari rivenditori americani di impianti TV via satellite<br />
<br />
29-dic-00 Fine anno: cause contro MAPS; passo avanti della Commissione Europea Prorogato l'ordine del giudice federale per sospendere il listing di Exactis in 09-dic-00 RBL 212<br />
<br />
 08-nov-00<br />
<br />
AT&T e PSI: conclusi (e velocemente rescissi) imbarazzanti contratti con spammer<br />
<br />
21-ott-00 Imponente episodio di spam politico in Italia 15-ott-00 Cambia nome la zona DNS di MAPS DUL 27-lug-00 Già chiusa la vicenda Yesmail vs MAPS 22-lug-00 Primo commento ufficiale di Paul Vixie sulla vicenda Yesmail 19-lug-00 HR3113 approvata dalla House of Representatives 16-lug-00 Tribunale USA ordina al MAPS di rimuovere Yesmail dall'RBL 13-lug-00 Si aggrava il listing di buongiorno.it in RBL 05-giu-00 Spammer arrestato in California 01-mag-00 Nuova legge pro-spam in Svezia 15-apr-00 Nuovi indirizzi per la segnalazione di abusi ad America On Line 01-apr-00 America On Line passa al peering preferenziale con AboveNet 25-mar-00 Nuova proposta di legge federale antispam in USA 18-mar-00 Sconcertante sentenza di un giudice nello stato di Washington 18-mar-00 La sorgente di spam del momento: i cinesi di 163.net 19-gen-00 Sospesa la Usenet Death Penalty per @Home 12-gen-00 Decretata la Usenet Death Penalty per @Home 04-nov-99 Hotmail inizia ad usare RBL per filtrare le email in arrivo 03-nov-99 La DMA inasprisce la propria posizione in senso pro-spam 20-set-99 RRSS verso l'incorporazione nel progetto MAPS 30-lug-99 Network Solutions proposta per l'RBL 16-lug-99 Legge antispam approvata in Austria 12-lug-99 RealNetworks di nuovo nell'RBL 25-giu-99 Nuova legge antispam in arrivo nel North Carolina 13-mag-99 Bloccata in Texas la legge contro la junk email 06-mag-99 Il Parlamento Europeo boccia il divieto alla posta commerciale non sollecitata 22-apr-99 Passerà all'esame del Parlamento Europeo una direttiva basata sull'opt-out 27-mar-99 Murkowski ci riprova (e l'Europa rischia di prendere esempio da lui) 24-feb-99 Approvata legge antispam in Virginia 31-gen-99 ORCA DUL viene inglobato nel MAPS 20-gen-99 ORBS nuovamente operativo 19-gen-99 Anche in Texas si sta preparando una legge contro la junk email 31-dic-98 Situazione di fine anno 1998 30-nov-98 ORBS Chiuso 213<br />
<br />
 23-ott-98 Italia On Line annuncia l'imminente adozione di una politica antispam 21-ott-98 UDP su Telecom Italia Net ? 24-set-98 Congresso USA: eliminato l'emendamento pro-spam :-))) 22-set-98 Prossimamente in discussione alla Camera USA la legge pro-spam 08-set-98 Lo spammer del momento: TCPS 05-set-98 UUNet supera il milione di reclami ricevuti 04-set-98 UUNet cambia gli indirizzi per la segnalazione abusi 28-ago-98 Legge antispam in California 06-ago-98 Procede al Congresso USA l'iter di una legge pro-spam<br />
<br />
Indice Ultimo aggiornamento: 26 ottobre 2003<br />
<br />
Leonardo Collinelli<br />
<br />
214<br />
<br />
 Dal mondo dello spam Testo delle notizie dall'1/1/2003<br />
<br />
031026 - Al Senato USA passa la S877: siamo alle solite. Mentre l'Europa sta procedendo con convinzione sulla strada dell'opt-in, con la nuova direttiva già implementata nelle legislazioni nazionali di diversi paesi membri (tra cui l'Italia), evidentemente i legislatori USA sono ancora lontani dal rendersi conto della gravità del problema. Da anni ormai vengono infatti presentate proposte di legge federale che otterrebbero solo di rendere la vita più facile agli spammer e che, per fortuna, finora sono sempre decadute senza diventare legge. Questa S877, in sostanza, proibisce solo lo spam con caratteristiche fraudolente: se la comunicazione commerciale è veritiera e non ci sono header falsificati, si può spammare a volontà. È poi previsto il classico opt-out (sembra consentito anche l'opt-out preventivo a livello di intero dominio, cosa sorprendente perché in passato le lobby del marketing si erano sempre ferocemente opposte al domainwide opt-out; probabilmente il trucco sta nel fatto che la creazione della lista di opt-out preventivo non è obbligatoriamente prescritta). Viene poi proibito agli Stati di varare leggi antispam più restrittive, cosa che, per esempio, farebbe decadere una buona legge antispam recentemente varata in California. Viene pure negato il "private right of action" contro gli spammer da parte degli utenti, lasciando la possibilità di perseguire gli spammer solo alle agenzie federali (peraltro prive dei fondi per fare alcunché). Sono proibite infine alcune pratiche come il rastrellamento di indirizzi di email via robot o la loro generazione mediante dictionary attack. 031019 - Conclusa la battaglia legale di un gruppo di spammer contro Spamhaus.org e altri antispammer. È giunta all'epilogo, almeno per ora, la vicenda dei cui precedenti passi si riferisce più sotto in questa stessa pagina. Il giudice ha infatti accolto la richiesta di "voluntary dismissal with prejudice" che alcuni spammer, anonimamente raggruppati dietro il legale che li ha rappresentati in questa vicenda, avevano presentato per tentare di uscire dalla battaglia legale con i minori danni possibili. Anche se, in questo modo, gli spammer si sono sostanzialmente arresi, comunque la conclusione (se rimane questa) non è particolarmente soddisfacente. Restano infatti, per gli antispammer, i costi legali che si sono dovuti fin qui sobbarcare (malgrado il loro avvocato, il bravissimo Pete Wellborn, che odia gli spammer e ne ha già sconfitti parecchi in tribunale, abbia applicato ai suoi assistiti le migliori condizioni possibili). Per ulteriori dettagli si rimanda all'annuncio dato da Steve Linford in 215<br />
<br />
 un messaggio usenet. 030927 - Continuano gli attacchi d.d.o.s: chiude anche UPL di Monkeys.com. Torna in servizio OpenRBL.org Gli attacchi distributed denial of service contro le liste di blocco sono ormai permanenti e di sempre maggiore portata. Creare problemi agli spammer è ormai la stessa cosa che fare degli sgarbi alla criminalità organizzata: si viene eliminati dalla rete (quando non si viene anche minacciati fisicamente). È di questi ultimi giorni la chiusura della lista UPL di Monkeys.com, il sito creato e gestito da Ronald F. Guilmette. Si deve a Guilmette la codifica di una definizione di spam che ha incontrato ampio consenso in rete, come si deve a lui l'idea di una lista (dismessa da tempo) di siti a cui si trovavano dei formmail insicuri, nonché la messa a disposizione di una versione modificata di formmail non abusabile dagli spammer. Il progetto principale di Guilmette era però UPL (Unsecured Proxies List), una lista che censiva un grosso numero di indirizzi ip a cui si trovavano proxy aperti di varia natura. Inoltre, UPL catalogava anche indirizzi ip che risultavano avere agito nel tentativo di cercare e usare i proxy al fine di inviare spam. Sappiamo che il proxy insicuro, a differenza dell'open relay smtp, anonimizza il vero ip da cui opera lo spammer, sicché il destinatario finale dello spam non è in grado di scoprirlo. Guilmette appunto scopriva e rendeva noti i veri indirizzi da cui operavano i criminali informatici che stanno dietro allo spam via proxy, cosa che poteva fare tenendo in esercizio dei proxypot. Che Guilmette sia stato indotto a cessare completamente le sue attività antispam è particolarmente triste e preoccupante. Preoccupante anche il fatto che, rivoltosi alle autorità di polizia e all'FBI, Guilmette non abbia assolutamente ottenuto alcun interessamento a quanto stava avvenendo. Riguardo agli aspetti operativi conseguenti a questa chiusura, la zona dns da cui era servita UPL è stata svuotata, avendo così l'effetto di rimuovere tutti i listing. Coloro che usavano UPL devono quindi toglierla dalla configurazione dei loro server appena possibile, tuttavia non rischiano di iniziare improvvisamente a rigettare tutte le email come successe a fine agosto a coloro che stavano usando Osirusoft. Per bloccare i proxy aperti continuano ad essere disponibili varie altre liste eccellenti, tuttavia c'è da chiedersi quali saranno le prossime a venire attaccate. È degli ultimi giorni anche il ritorno in funzione di OpenRBL.org, il sito più consigliabile per cercare, dato un indirizzo ip, su quali liste di blocco sia correntemente inserito. OpenRBL è uno strumento prezioso per qualsiasi antispammer ed era da tempo sotto attacco. Ora lo si può nuovamente usare grazie ad una rete di una dozzina di proxy che sono stati messi a disposizione in varie parti del mondo, così che ora un eventuale attacco dovrebbe richiedere tali e tante risorse da essere difficilmente praticabile. Si segnala anche la disponibilità di un mirror europeo alla url http://eu.openrbl.org/. 030906 - Svolta nella battaglia legale promossa da EMARKETERSAMERICA. ORG contro Spamhaus.org e altri antispammer. 216<br />
<br />
 La vicenda, del cui inizio si riferisce più sotto in questa pagina, fa registrare interessanti novità. Il querelante, avendo ormai chiaro che le cose si stanno mettendo male, ha presentato alla corte una "NOTICE of voluntary dismissal with prejudice". In parole povere, è come se avesse detto: ho scherzato, chiudiamo pure tutto qui e mi impegno a non ripresentare in futuro questa querela. Tuttavia gli antispammer coinvolti nella vicenda sembrano intenzionati a non considerare affatto il caso chiuso e, anzi, a procedere per il recupero di spese e danni. Questo anche al fine di stabilire un precedente che abbia un significativo valore dissuasivo per tutti gli spammer che, in futuro, accarezzassero l'idea di citare in giudizio gli antispammer e, in particolare, gli operatori di liste di blocco. 030831 - Attacchi d.d.o.s. contro il sito di SPEWS e contro Osirusoft. Non è una novità che le organizzazioni antispam subiscano spesso attacchi tipo distributed denial of service, tipicamente dei flood da migliaia di macchine insicure o infestate da trojan. Per mantenere raggiungibili i propri siti e le proprie zone dns, le organizzazioni antispam devono prendere opportune precauzioni, a cominciare dall'uso di connessioni a grossa capacità di banda. Steve Linford, per esempio, ha avuto occasione di raccontare che, già dall'inizio di giugno, gli attacchi ddos (con picchi fino a 100 MByte/sec e provenienti da innumerevoli proxy zombie) colpiscono costantemente anche la rete di Spamhaus.org (senza tuttavia riuscire a impedirne il funzionamento, dato che Spamhaus si aspetta questo tipo di attenzioni e si avvale quindi di una rete progettata e dimensionata apposta per resistere).<br />
<br />
Il sito di SPEWS in particolare è preso di mira già da molto tempo, risultando spesso irraggiungibile. Ovviamente questo non impedisce la distribuzione e l'uso di SPEWS come lista di blocco, in quanto SPEWS è distribuita in varie forme da più sorgenti, tuttavia questi attacchi hanno reso meno semplice accedere ai file di evidenza per vedere le spiegazioni relative ai vari listing. Quanto a Osirusoft, gestita da Joe Jared, è stata per lungo tempo la principale fonte di diffusione di SPEWS via dns, ed ha reso disponibili allo stesso modo anche altre liste (come Spamsites o la lista di proxy insicuri curata da Maximiliano Kolus in Argentina), oltre a mantenere dei listing propri. Già da mesi Osirusoft stava avendo problemi di affidabilità (che ne rendevano sconsigliabile l'utilizzo in ambienti di produzione) e, da luglio, gli attacchi ddos si sono pesantemente accaniti contro la rete di Jared, che funzionava su una semplice connessione dsl. Il 26 scorso si è avuto l'epilogo: le zone dns di Osirusoft hanno iniziato a rispondere affermativamente alle query su qualsiasi indirizzo e, poco tempo dopo, sono state chiuse definitivamente. A Jared, che a questo punto si deve considerare uscito dal mondo delle liste di blocco, va comunque la gratitudine degli antispammer per il lavoro che ha svolto, mettendo varie dnsbl a disposizione di tutti fin dal 2001. 030427 - Spamhaus.org e altri antispammer citati in giudizio in Florida. 217<br />
<br />
 Circa a metà aprile è stata presentata, alla Corte Distrettuale competente per il sud della Florida, una querela contro Spamhaus.org (l'organizzazione, con sede in Inghilterra, che cura la famosa blacklist SBL), contro Spews.org e contro numerosi altri antispammer americani. Il querelante si è qualificato come "EMARKETERSAMERICA.ORG, INC., A Florida Non Profic Corporation" e l'unica persona il cui nome viene attualmente indicato come riferimento per tale organizzazione è un legale di Boca Raton (città della Florida il cui nome non suona affatto nuovo a chi si sia occupato di spam almeno per qualche tempo). L'oggetto della causa ricorda molto altre controversie analoghe già viste in precedenza: riassumendo i punti principali, i soggetti querelati vengono accusati di "vendere prodotti che bloccano la trasmissione elettronica e le comunicazioni di cittadini e aziende americani" e di "rendere intenzionalmente disponibile informazione nel dichiarato sforzo di interrompere e bloccare il traffico Internet di individui e aziende in regola con la legge". Chiunque abbia cognizione di cosa sono e come funzionano le blacklist non avrà difficoltà a vedere l'infondatezza delle accuse, a cominciare per esempio dal fatto che Spamhaus.org non mette in vendita nulla (anzi svolge a titolo volontario un grosso lavoro il cui risultato è generosamente messo a disposizione di chiunque sia interessato a conoscerlo o ad usarlo), o dal fatto che nessuna blacklist potrà mai bloccare il traffico di email alla fonte (dato che una blacklist non è altro che l'espressione di un parere che chiunque, per ciò che lo riguarda, può decidere di usare o no, nel modo che crede). Ci sono poi numerosi aspetti paradossali (non si capisce, per esempio, come potrebbe una Corte Distrettuale del sud della Florida avere giurisdizione sull'Inghilterra, unica nazione ove Spamhaus.org ha sede). Si segnala intanto che una prima richiesta dei ricorrenti per ottenere un TRO (ingiunzione temporanea) è stata rigettata dalla Corte. Spamhaus.org ha pubblicato sul proprio sito una risposta puntuale alle contestazioni mosse da EMARKETERSAMERICA.ORG. Non c'è bisogno di dire quale sia la posizione presa dalla comunità antispam internazionale, che da questa vicenda è certamente più divertita che allarmata. È stata intanto attivata una raccolta di fondi (coordinata da Mark Ferguson) per la difesa legale degli antispammer citati in giudizio.<br />
<br />
Indice<br />
<br />
Indice Notizie<br />
<br />
Ultimo aggiornamento: 26 ottobre 2003<br />
<br />
Leonardo Collinelli<br />
<br />
218<br />
<br />
 Dal mondo dello spam Testo delle notizie dall'1/3/2002 al 31/12/2002<br />
<br />
021231 - Il punto della situazione a fine 2002. Spam in crescita A conclusione del 2002, si deve rilevare che l'anno appena trascorso ha visto una recrudescenza eclatante del fenomeno dello spam, sia in termini quantitativi che di aggressività. Innanzitutto, i numeri che sono aumentati: ad oggi appare ragionevole stimare che, su un server di mail dedicato a caselle di normali utenti consumer, la parcentuale di spam sull'intero traffico in arrivo non sia lontana dal 30-35%, con punte che possono in certe giornate anche essere molto di più. Questa crescita è stata certamente facilitata dalla tendenza di un certo numero di provider in tutto il mondo a tollerare le attività spammatorie dei propri clienti, evitando di agire in maniera efficace a fronte delle segnalazioni ricevute o addirittura ignorandole. A questo si è affiancato il fatto che, nel corso del 2002, è stata evidente una grossa crescita nella diffusione dell'uso della rete in numerose nazioni al di fuori di Europa e USA. Si tratta di paesi come Corea del Sud, Cina, Brasile ecc.., in cui sono diventati disponibili in brevissimo tempo molti fornitori di accesso e servizi di rete. Purtroppo però, la cultura dell'uso corretto della rete e la cultura della sicurezza informatica impiegheranno molto più tempo per diventare disponibili ovunque. Il risultato è che ad oggi gli spammer sia italiani che americani fanno un uso massiccio delle reti di quei paesi, sia per sfruttare gli innumerevoli server insicuri che vi si continua a trovare (relay e proxy aperti), sia per acquistarvi servizi veri e propri (es. hosting). Tra l'altro, in quei paesi non mancano spammer locali: questo è stato anche l'anno in cui gli utenti italiani si sono visti arrivare quantità industriali di junk-email illeggibili, per lo più in caratteri coreani. Pur con qualche eccezione, le esperienze con i relativi abuse desk sono in genere risultate assai insoddisfacenti. Il 2002 è anche stato l'anno che ha visto l'esplosione dei dialer, ossia quei piccoli programmi che, prospettando la possibilità di scaricare per esempio loghi e suonerie per i cellulari, prendono il controllo del modem dell'utente e lo connettono, spesso in maniera subdola, a linee telefoniche ad alto costo. Si può dire che la quasi totalità dello spam di origine italiana in circolazione negli ultimi mesi fosse mirata proprio all'attivazione di dialer sui computer dei malcapitati utenti. Questo è stato reso possibile dalla comparsa, sulle linee telefoniche italiane, delle numerazioni a tariffazione speciale. A nostro avviso, questa modalità di vendita di servizi ha l'effetto di bypassare i normali "circuiti di 219<br />
<br />
 protezione" che il consumatore ha sviluppato, negli anni, al fine di sapersi orientare al meglio nei propri acquisti. Inoltre, il mezzo si presta in maniera ottimale alla effettuazione di truffe di vario genere, sia mediante artifici tecnici che psicologici, per esempio facendo leva sulla curiosità o ingenuità dei ragazzi e, sovente, ingannando per bene anche gli adulti (vedansi i numerosi casi di spam che annunciavano cartoline elettroniche o messaggi personali che in realtà non esistevano, ma che erano da vedersi naturalmente mediante dialer). A proposito delle numerazioni telefoniche usate dai dialer, può interessare sapere che, rivolgendosi a Telecom Italia, è attualmente possibile ottenere la disabilitazione permanente delle numerazioni con prefisso 166 e 899. Purtroppo però il trucco c'è: alla data odierna non è possibile ottenere la disabilitazione dei 709 e 892. Ovviamente, i dialer originariamente comparsi per numerazioni 899 si sono oramai tutti convertiti ai 709, quindi le disabilitazioni effettivamente possibili sono, in buona sostanza, ininfluenti (ci permettiamo di pensare che, se l'operato dell'Authority delle Comunicazioni fosse all'altezza dei faraonici emolumenti percepiti dai suoi componenti, questo genere di situazioni non si verificherebbe). La lotta antispam oggi Cominciamo con quanto accaduto riguardo alle leggi che ci possano tutelare dallo spam. Va senz'altro ricordata l'importante decisione assunta in sede europea, ossia obbligare tutti i paesi membri ad inserire nella propria legislazione il divieto all'invio di posta elettronica commerciale senza il preventivo consenso del destinatario. Ora si deve attendere che la normativa venga recepita in tutti i paesi e, soprattutto, si attende di vedere quanto verrà fatta rispettare. L'Italia ha subito iniziato male, con la comparsa di un decreto del Ministero delle Attività Produttive che, nella sostanza, va contro la nuova direttiva europea rispolverando l'idea (vecchia, inefficace e priva di senso), del cosidetto listone di opt-out preventivo. Ci auguriamo che di questa insana trovata non si risenta più parlare, e che la nuova direttiva europea venga rigorosamente applicata. Il 2002 è anche stato l'anno in cui gli utenti, grazie alla pionieristica esperienza di Massimo Cavazzini, hanno iniziato a rivolgersi all'Autorità Garante per la protezione dei dati personali, sporgendo ricorso contro l'illecito trattamento dei dati che è sempre alla base dell'invio di spam. Le prospettive di questo fronte di lotta sono certamente interessanti, anche se le cose non appaiono del tutto facili. La giurisprudenza del Garante, per esempio, non è sempre del tutto comprensibile e le sanzioni inflitte agli spammer non appaiono, in molti casi, di sufficiente entità. Si tratta comunque di un percorso che sta ancora venendo esplorato e da cui potrebbero giungere ulteriori notizie. Intanto è stato interessante vedere quale sia stata la reazione degli spammer, che si sono trovati per la prima volta a dover rendere conto del loro operato di fronte alla legge. Hanno per lo più reagito in tutt'altra maniera che recedendo dal loro comportamento al fine di rientrare nella legalità. Quello che si è visto sono stati artifici come il rifiutare le raccomandate con cui venivano spedite le istanze preliminari all'effettuazione dei ricorsi, o come il rendere l'identità dei soggetti coinvolti il più possibile difficile a scoprirsi (es. con domini intestati a persone inesistenti ad indirizzi inesistenti). In altre parole, anche lo spammer italiano segue i tratti dello spammer tipico che si conoscono da anni: preferisce tenersi nell'ombra, anonimo (non è un caso che molto spam italiano arrivi tramite proxy aperti brasiliani) e sempre pronto a usare 220<br />
<br />
 qualsiasi mezzo per portare avanti la propria attività ed evitare di risponderne. Il 2002 è infine stato l'anno che ha visto consolidarsi il principale strumento finora inventato per bloccare concretamente l'arrivo di spam nelle caselle degli utenti, ossia le blacklist. Sono infatti nate e si sono affermate varie blacklist utili per i principali obiettivi necessari. Per esempio esistono blacklist per tenere alla larga i proxy e i relay aperti, esistono finalmente anche buone liste di ip assegnati in maniera dinamica e, soprattutto, esistono liste dedicate alle sorgenti di spam e alle reti che accettano gli spammer come clienti. Grazie a tali liste (in particolare SBL e Spews), la fornitura di servizi di rete agli spammer, tipicamente assai remunerativa, è oggi diventato un genere di affare piuttosto rischioso, che può portare la rete spam-friendly a perdere i clienti legittimi e a diventare, a tutti gli effetti, una sorta di fogna con cui nessuno intende più scambiare traffico. Data l'efficacia di queste blacklist nel proteggere le caselle degli utenti, non c'è alcun dubbio sul fatto che vadano assolutamente usate e che oggi in particolare, dopo il panorama preoccupante che abbiamo appena delineato, sia particolarmente stupido non usarle. Purtroppo, in questo i provider italiani per utenza consumer sono tradizionalmente indietro. Qualcosa comunque si sta muovendo: da qualche mese, uno dei maggiori provider italiani (Libero-Infostrada) ha iniziato ad utilizzare SBL, anche se non conosciamo esattamente con quali modalità (se mediante il rifiuto in fase di dialogo smtp, come andrebbe senz'altro consigliato, o mediante semplice marcatura dei messaggi). Occorre a questo punto precisare che, certamente, SBL è una lista gestita con particolare attenzione e competenza e che risulta essere decisamente a bassissimo rischio di rigetto di email legittime; inoltre i suoi effetti riescono ad essere particolarmente incisivi per ottenere la cessazione dei servizi a importanti spammer. Secondo noi, insomma, qualsiasi server di email collegato alla rete internet dovrebbe fare uso di SBL. Tuttavia, per una protezione completa delle caselle di posta, il suo uso va combinato con quello di blacklist di vari altri tipi. Su questo, ancora, salvo pregevoli eccezioni i provider italiani non ci sentono. Concludiamo dunque esortando, ancora una volta, gli utenti a premere sui propri provider perché queste possibilità oggi disponibili vengano utilizzate, e, quando possibile, a preferire nelle proprie scelte quei provider che già lo fanno. 021014 - L'antispammer australiano Joey McNicol vince in tribunale contro T3 Direct. La vicenda di Joey McNicol, da tempo seguita con particolare attenzione da un gran numero di antispammer in tutto il mondo, è giunta positivamente a conclusione nella mattinata di oggi. McNicol era stato citato in tribunale da T3 Direct, azienda australiana di direct marketing nota per praticare lo spamming e, per questo, inclusa in importanti blacklist internazionali come SBL e SPEWS. Vedasi a questo proposito il link http://spews. org/html/S1488.html. T3 Direct aveva accusato McNicol di avere ottenuto il listing di T3 in SPEWS e, di conseguenza, reclamava un ingente risarcimento per danni e mancati introiti. L'accusa era manifestamente priva di fondamento anche perché, come molti sanno, SPEWS non accetta nomination. Purtuttavia, la vicenda costituiva un serio problema per McNicol, costretto a sostenere personalmente forti spese per la propria difesa (nella comunità antispam internazionale venivano anche raccolti fondi per aiutarlo) e, comunque, rischiava 221<br />
<br />
 di costituire un pericoloso precedente in caso di verdetto sfavorevole. Il tribunale di Perth ha respinto le argomentazioni di T3 Direct come "speculative e basate su proposizioni (quelle dell'accusa) che si sa non essere vere", stabilendo che non c'era prova né per dimostrare che McNicol avesse contattato SPEWS né per dimostrare che, quand'anche ciò fosse avvenuto, sarebbe stato illegale. In attesa di avere maggiori dettagli, la notizia ha portato notevole soddisfazione e sollievo per gli antispammer di tutto il mondo, oltre che fornire ulteriore evidenza al fatto che le liste di blocco funzionano e sono, ad oggi, la principale e più efficace arma con cui combattere la piaga dello spam. 020531 - L'Europa ha deciso: sarà OPT-IN. Il percorso è stato lungo e tormentato, costellato di delusioni che culminarono quando, nel novembre 2001, il Parlamento Europeo adottò un testo in cui si lasciava ad ogni stato membro la scelta se adottare l'opt-in o l'opt-out. Le speranze per gli utenti di posta elettronica si riaprirono quando, circa un mese dopo, il Consiglio Europeo rifiutò le conclusioni cui era giunto il Parlamento e propose un testo di compromesso, basato sull'optin con una eccezione (il caso in cui l'indirizzo di email fosse stato ottenuto direttamente dal suo titolare in occasione di un acquisto di prodotti o servizi da parte di quest'ultimo). A quel punto venne avviata una fase di trattative per far sì che Parlamento e Consiglio giungessero a concordare una soluzione accettata da entrambi. La trattativa ha avuto successo ed ha portato all'odierna approvazione di un testo che, per ciò che riguarda lo spam, è sostanzialmente uguale alla proposta del Consiglio. La soluzione adottata ha soddisfatto le istanze di chi (soprattutto associazioni dei provider e organizzazioni antispam) aveva richiesto la messa al bando dello spam a livello europeo. In primo luogo occorre citare EuroCauce, che ha molto lavorato in questi anni per giungere al risultato odierno. Anche se passeranno ancora molti mesi prima che questa decisione si traduca in leggi emanate dagli Stati membri (si parla di fine 2003), quanto appena accaduto è estremamente importante, specialmente se si considera la rapida crescita del fenomeno spam negli ultimi mesi, crescita che si è vista pure in Europa e che non apparirebbe semplice arginare senza il supporto della legge. Per ulteriori informazioni si può fare riferimento all'apposita pagina sul sito di EuroCauce. Vedasi anche il comunicato emesso da Cauce a livello internazionale. Purtroppo nulla del genere ancora sembra pensabile negli USA, dove i legislatori federali continuano a sfornare progetti di legge fortemente ostili ai diritti di utenti e consumatori. Tra le speranze c'è quindi pure che la scelta appena compiuta dall'Europa possa influenzare positivamente la situazione degli USA. 020323 - ORBZ chiuso. Non c'è pace per le blacklist di relay aperti. Dopo le sfortunate vicende di ORBS e di ORBS UK (chiuso, quest'ultimo, nel dicembre 2001), anche ORBZ ha cessato, si spera temporaneamente, le proprie attività. La cosa è particolarmente spiacevole, soprattutto 222<br />
<br />
 perché ORBZ era una lista ben gestita, affidabile ed il cui utilizzo risultava assai valido per proteggere i mail server dallo spam. Il problema si è verificato quando i sistemi di ORBZ hanno eseguito un test sul mail server dell'amministrazione comunale di Battle Creek (Michigan). Il server in questione era un Lotus Domino la cui manutenzione risultava carente; in particolare, i sistemisti responsabili per il server non avevano applicato le necessarie correzioni (rese disponibili dal produttore già da molti mesi) per risolvere un noto malfunzionamento. Il malfunzionamento consiste in un crash del server quando questo non riesce a rispedire al mittente una email "bounced" (ulteriori informazioni qui e qui). Il test che ORBZ ha compiuto, assolutamente inoffensivo in normali circostanze, ha quindi provocato un crash del mail server. Ovviamente, il medesimo crash avrebbe potuto essere causato da chiunque, in qualsiasi parte del mondo, avesse spedito a quel server una mail che avesse causato un bounce non rispedibile (per es., con un envelope sender che puntasse a [127.0.0.1]) ed ha del grottesco il fatto che, anziché preoccuparsi di migliorare la gestione del proprio software in modo tale da evitare il ripetersi di problemi simili, l'amministrazione di Battle Creek abbia precipitosamente pensato di sporgere denuncia penale contro il gestore di ORBZ, il giovane Ian Gulliver (New York). Di fronte al rischio di gravi conseguenze penali, Gulliver ha preferito chiudere ORBZ, rendendo noto che chiunque disponesse di copie del database di ORBZ era libero di farne qualsiasi uso. Fortunatamente, Gulliver ha trovato vasto appoggio da parte della comunità antispammer ed assistenza legale gratuita. L'incidente è stato rapidamente chiarito e l'amministrazione di Battle Creek ha ritirato la denuncia, riconoscendo che Gulliver stava agendo a fin di bene e rimarcando che, al momento dell'incidente, loro non potevano saperlo e ritenevano quindi di essere stati oggetto di un attacco vero e proprio. In un comunicato ufficiale del 22 marzo, il responsabile dell'amministrazione ha riconosciuto che esistevano grosse carenze nella gestione dei sistemi ed ha assicurato che verranno prese internamente tutte le dovute azioni correttive per risanare la situazione. Ha infine chiesto a Gulliver di riprendere il servizio che ORBZ stava fornendo. Sul sito di ORBZ è infine comparso un comunicato in cui si annuncia la possibilità che il sistema ritorni in funzione, tra qualche tempo, con qualche modifica al modo di funzionare.<br />
<br />
Indice<br />
<br />
Indice Notizie<br />
<br />
Ultimo aggiornamento: 31 dicembre 2002<br />
<br />
Leonardo Collinelli<br />
<br />
223<br />
<br />
 Dal mondo dello spam Testo delle notizie dall'1/1/2001 al 28/2/2002<br />
<br />
010617 - ORBS chiuso. È ora attivo ORBS UK Non c'è ad oggi sufficiente chiarezza sugli accadimenti che hanno portato alla chiusura di ORBS, il celebre quanto controverso sistema di ricerca attiva e censimento dei relay aperti. Di certo c'è che l'attuale gestore, Alan Brown, che vive e opera in Nuova Zelanda, ha comunicato il 23 maggio di avere ricevuto dalla magistratura del suo paese una ingiunzione a rimuovere dal database di ORBS i blocchi di ip appartenenti a "Telecom NZ" e "Actrix". L'azione legale sarebbe stata promossa dalle due compagnie, che si sarebbero viste includere in ORBS pur senza avere in funzione alcun relay aperto. Brown ha dato notizia dell'ingiunzione comunicando, in un post su news.admin.net-abuse.email, gli esatti netblock interessati dalla vicenda (cosa che potrebbe avere reso più difficile la sua posizione in giudizio). Qualche giorno dopo le zone dns e lo stesso sito web di ORBS sono spariti, e lo stesso Brown ha comunicato che la chiusura di ORBS non era in relazione alcuna con l'azione legale intrapresa da Telecom NZ e Actrix. Nulla si sa sull'eventuale possibilità che ORBS torni in funzione, tuttavia lo si ritiene a questo punto poco probabile. ORBS era gestito da Alan Brown da quando, alcuni anni fa, il provider canadese BCTel aveva deciso di rifiutare la connettività al sistema che, a quel tempo, era gestito da Alan Hodgson (vedasi il resoconto di allora). La gestione Brown era stata spesso oggetto di accuse per avere incluso deliberatamente nella blacklist server che non erano relay aperti. Anche se sull'utilità di ORBS come strumento di blocco si potevano esprimere varie riserve, tuttavia non si può negare che ORBS mettesse a disposizione di tutti gli antispammer una banca dati assai aggiornata, contenente decine di migliaia di relay aperti e, soprattutto, la possibilità di consultare i messaggi di test in base ai quali gli stessi erano risultati aperti. Il venire meno di ORBS ha quindi provocato un vuoto che era interesse di tutti che venisse riempito al più presto, magari senza quegli inconvenienti che ne hanno impedito un più diffuso utilizzo. Pertanto, il 9 giugno è entrato in funzione ORBS UK, gestito da Paul Cummins e basato, inizialmente, su un dump dell'ultimo database di ORBS. Il sistema è ancora in costruzione. In particolare, nel sito web http://orbs.gst-group.co.uk/ si trovano le istruzioni per l'uso ma non ancora la possibilità di consultare il database dei messaggi di test. Cummins ha annunciato l'intenzione di gestire ORBS UK con la dovuta serietà e trasparenza e, tra i suoi primi atti, c'è stata la rimozione dei listing di Telecom NZ e Actrix, che dopo adeguata 224<br />
<br />
 verifica sono stati riconosciuti come incongrui. 010401 - HR718: un'altra deludente proposta di legge anti(?)spam al Congresso USA Già da parecchi giorni si parla dell'ultima proposta di legge in materia di spam che, tuttora, sta procedendo col proprio iter alla House of Representatives, dove è indicata come HR718 e pomposamente denominata "Anti-spamming Act of 2001". Purtroppo, il copione per tutte queste proposte di legge è sempre il medesimo. Il Congresso USA, a quanto pare, non intenderà mai varare una disciplina che effettivamente salvaguardi i consumatori e gli utenti di rete affermando il loro diritto a decidere cosa, effettivamente, possa arrivare nelle loro mailbox. Evidentemente dobbiamo rassegnarci al fatto che verranno sempre considerati più meritevoli di tutela gli interessi del mondo del commercio e del marketing. Assistiamo così al periodico apparire di proposte di legge che, già alla nascita, sono strutturalmente inefficaci nel portare un effettivo beneficio agli utenti. Tanto per incominciare si osserva che anche la HR718, come molte altre precedenti iniziative di legge, prevede di istituzionalizzare quell'imbroglio noto come "opt-out". Inoltre notiamo da tempo che, all'apparire di qualunque proposta di legge in materia di spam, può casualmente trovarvisi qualche punto che, in concreto, è condivisibile e può essere utile. Nel caso della HR718 la disposizione utile, presente nella versione del 14 febbraio scorso, rendava illegale (e passibile di sanzioni) l'invio di email commerciali non sollecitate qualora ciò avvenisse in violazione delle policy del provider usato per trasmetterle. In passato abbiamo sempre visto succedere che, durante i vari passaggi delle leggi (comitato, subcomitato, camera, senato eccetera), tutte le disposizioni effettivamente utili ai consumatori venissero accuratamente eliminate o, comunque, completamente neutralizzate. Così è successo anche stavolta con la HR718. Pertanto CAUCE, che aveva appoggiato la HR718 nella sua prima versione, lo scorso 28 marzo ha diffuso un comunicato in cui ritira il proprio appoggio e mette in guardia dalle nefaste conseguenze che si avrebbero qualora la HR718 diventasse legge. 010218 - Proposta di legge antispam in Ohio All'assemblea legislativa dello stato americano dell'Ohio è stata recentemente depositata una proposta di legge, firmata dal senatore Amstutz e contraddistinta dalla sigla SB-8. Il testo si rivela interessante, in quanto sostiene giuridicamente le policy stabilite dai provider in materia di invio di email a contenuto commerciale, e prevede che i destinatari dello spam inviato in violazione ad esse possano agire in giudizio contro i mittenti. Allo spammer potrà essere ingiunto di risarcire i danni effettivamente subiti dal destinatario oppure 10 dollari per ogni messaggio di spam inviato (quello dei due importi che risultasse essere maggiore). Sono poi previsti divieti all'uso e alla distribuzione di software progettato per falsificare l'origine o le informazioni di routing dei mailing. Anche se vari punti della proposta di legge appaiono perfettibili, complessivamente il testo è ritenuto buono. 225<br />
<br />
 010116 - Nuova legge antispam in Norvegia Entrerà in vigore l'1 marzo 2001 in Norvegia una nuova legge che metterà al bando l'invio di email commerciali non sollecitate, prevedendo per i contravventori forti multe e, eventualmente, anche il carcere fino a 6 mesi (data la moderata entità delle pene detentive nel sistema penale norvegese, si può dire che 6 mesi siano una sanzione assai significativa). Va detto che, sul fronte della difesa dei consumatori, la Norvegia è sicuramente un paese molto avanti, dotato di un Ispettorato per la protezione dei dati e di un Consumer ombudsman assai competenti e attivi. Il fatto che ora la Norvegia abbia una legge esplicita e particolarmente severa contro lo spam (aggiungendosi così ad altri paesi europei come Finlandia, Danimarca, Germania, Austria e Italia) può certamente aiutare a creare (anche se la Norvegia non fa parte della UE) un clima favorevole agli sforzi di coloro che cercano di giungere a normative europee dello stesso segno. È infatti in corso l'iter di una proposta di normativa in tal senso, presentata dal commissario finlandese Liikanen (il quale si dice abbia avuto modo di constatare personalmente, nella propria mailbox, quali siano i risultati pratici dell'opt-out). 010114 - Lo spammer del momento: vari rivenditori americani di impianti TV via satellite Da mesi si sta infittendo la diffusione di spam in cui si promuovono impianti TV via satellite (es. titoli come "Free Dish Network Satellite & Free Installation Limited time"). Si tratta di spam che normalmente giungono tramite relay aperti (spesso anonimizzanti) trovati in vari angoli del mondo; di solito i messaggi contengono tag html e, come mezzo di contatto, indicano dei numeri di telefono toll-free americani. La maggior parte dei casi sono stati ricollegati all'attività di certi rivenditori dei prodotti Echostar, così ad Echostar molti antispammer hanno iniziato a reclamare. Finché i reclami provenivano da utenti individuali, le risposte ottenute erano tutt'altro che soddisfacenti (cose del tipo: "si tratta di un valido reseller, non intendiamo perderlo" oppure "non abbiamo controllo sulle pratiche di marketing adottate dai nostri reseller" oppure "non stanno facendo niente di illegale" oppure "rivolgetevi direttamente a loro per farvi togliere dalle liste"). È cambiata la musica quando il MAPS, subissato da nomination e da tonnellate di evidenza, li ha contattati. Alla fine Echostar ha convenuto di emettere in data 10 gennaio una normativa commerciale, immediatamente efficace per i suoi rivenditori, in cui viene proibito lo spam, impegnandosi anche ad attivare un indirizzo apposito per la segnalazione degli abusi. A partire dall'1 febbraio, Echostar dovrebbe iniziare a revocare i contratti di distribuzione ai rivenditori che provocassero reclami. Ci si può pertanto aspettare che, ancora per qualche tempo, questi spam continuino. Dovrebbero comunque diminuire e, a partire dalla fine del mese, sparire o quasi (sperabilmente, se la situazione non si complica).<br />
<br />
Indice<br />
<br />
Indice Notizie 226<br />
<br />
 Ultimo aggiornamento: 17 giugno 2001<br />
<br />
Leonardo Collinelli<br />
<br />
227<br />
<br />
 Dal mondo dello spam Testo delle notizie dall'1/8/1998 al 31/12/1998<br />
<br />
981231 - Situazione di fine anno 1998 Tentiamo un bilancio dell'anno che si chiude per ciò che riguarda la lotta allo spam. Sulla scena internazionale, la cosa migliore è lo scampato pericolo relativo alla legge Murkowski-Torricelli che, se fosse stata approvata, avrebbe costretto a trovare contromisure ed avrebbe certamente reso gli spammer molto più arroganti. Le novità avutesi in USA dal punto di vista legislativo sono state tutte positive, con alcuni Stati che si sono dotati di legislazione antispam ed altri che sembra si accingano a farlo (si è parlato della Virginia). Qualche spammer ha già avuto non piacevoli appuntamenti nelle aule di giustizia. Un'altra notizia positiva è l'inizio del dialogo tra la comunità antispammer e la DMA (Direct Marketing Association, che conta circa 4400 associati in USA ed altri 49 paesi), verso la quale gli antispammer nutrono da tempo una diffidenza piuttosto pesante. Nonostante le posizioni restino tuttora distanti su molti punti, la DMA ha almeno ammesso che l'opt-in (ossia, email inviate solo ha chi le abbia esplicitamente richieste) sia la direzione in cui andare: la DMA ha riconosciuto che i programmi di opt-in si sono da tempo rivelati particolarmente efficaci ed ha accettato di indicarla ai propri associati come metodo da preferirsi; ciononostante continuerà ad appoggiare legislazioni basate sull'inaccettabile principio dell'opt-out. Per ciò che riguarda il comportamento dei principali soggetti presenti in rete, alcuni provider si sono distinti per un comportamento esemplare. In particolare vale la pena di citare (anche se non è l'unica) Pacific Bell. Altro soggetto che sembra incamminato verso comportmenti positivi è Microsoft. Passando ai non complimenti risulta che, in questi ultimi tempi, le maggiori lamentele siano state espresse nei confronti di UUnet e BellSouth. Sulla scena italiana appare evidente una cosa: fino a non molti mesi fa, la preoccupazione dei provider verso gli abusi di rete è stata prerogativa di pochi. La situazione non poteva reggere a lungo: lo spam italiano cresce al crescere della diffusione della rete, e ne è termometro il piazzamento (in continua ascesa) dei news server italiani nella classifica dei Top100 dello SpamHippo. La vicenda della minacciata UDP a Telecom Italia Net (ora accantonata dopo che la compagnia ha dato garanzie di cambiare la propria condotta in fatto di repressione abusi) ha certo dato una scossa salutare ad una situazione che minacciava di precipitare. Altri provider, soprattutto (ma non solo) di piccole dimensioni, 228<br />
<br />
 stanno dimostrando una incoraggiante sensibilità verso il problema. Bisogna avere chiaro che siamo solo all'inizio e che, in queste cose, occorrono mesi di sforzi per effettuare dei progressi ma basta un paio di giorni per ritornare indietro. Un auspicio conclusivo potrebbe essere di avere presto un successore di ORBS, il sistema di censimento dei relay aperti che, pur essendosi rivelato utile per bloccare molto spam, è stato chiuso a fine novembre. Il successore potrebbe essere IMRSS. 981130 - ORBS Chiuso L'ORBS (Open Relay Blocking System), che stava riscuotendo abbondante successo presso numerose reti che intendevano bloccare il traffico proveniente da relay aperti, è ora costretto a chiudere. La cosa è dovuta alla posizione di BC Tel, la compagnia telefonica provider dell'organizzazione curata da Alan Hodgson a Vancouver (Canada). Secondo la compagnia, testare i relay aperti senza il consenso dei rispettivi gestori sarebbe abuso di rete. Ovviamente, questo significa per ORBS trovare un altro provider o dovere chiudere e purtroppo, nella zona di Vancouver tutti o quasi i provider hanno BC Tel come up-stream. Il sito http://www.dorkslayers.com/ già non è più operativo, pure la zona DNS è stata cancellata. Per la lotta allo spam si tratta di una pessima notizia: ORBS censiva da 47'000 a 50'000 relay aperti all'incirca. 981023 - Italia On Line annuncia l'imminente adozione di una politica antispam La vicenda (tuttora in attesa di attuazione) della UDP su TIN sta favorendo una crescita della sensibilità dei provider italiani al problema degli abusi di rete. Italia On Line (uno tra i maggiori ISP italiani per numero di utenti) sta attivando strumenti per raccogliere le segnalazioni rigurdanti abusi commessi dai suoi utenti. 981021 - UDP su Telecom Italia Net ? Telecom Italia Net, il più grande provider italiano, è nell'occhio del ciclone per via dell'assenza di una politica di repressione abusi. Ovviamente la stragrande maggioranza dei suoi utenti (stimabili attorno ai 150000) si comporta correttamente; purtroppo però pochissimi sconsiderati a cui venga lasciata mano libera possono arrecare un fastidio immenso agli utilizzatori dei newsgroup. Dopo tentativi infruttuosi di ottenere da TIN un diverso atteggiamento, sta quindi venendo considerata (da parte degli amministratori di vari newsserver italiani) l'ipotesi della UDP, per la cui attuazione si parla (dopo lo slittamento della data inizialmente indicata di venerdì 23 ottobre) di metà novembre. La UDP (Usenet Death Penalty) consiste nel fatto che molti newsserver partecipanti alla rete Usenet inizierebbero, a partire da una data stabilita, a rifiutare dai feed in arrivo tutti i messaggi originati dal server cui la UDP si applica. In questo modo, gli utenti del provider colpito dal provvedimento potrebbero continuare ad usare il loro server come normalmente, con la sola differenza che i messaggi da loro postati non giungerebbero mai sui server degli altri 229<br />
<br />
 provider. Si tratta dell'unica forma di efficace autodifesa finora conosciuta, da parte delle reti danneggiate dall'invio di usenet spam originato da provider che (come finora è stato per Telecom Italia Net) rifiutano di prendere i provvedimenti del caso contro i propri utenti scorretti. La speranza di tutti è che, come spesso è successo in passato in occasione di applicazioni della UDP (finora mai in Italia), i motivi per attuare il provvedimento vengano meno prima che giunga la data dell'attuazione. 980924 - Congresso USA: eliminato l'emendamento pro-spam :-))) Sono servite le pressioni dei consumatori di rete americani e delle loro associazioni (F.R.E. E. e CAUCE), che hanno scritto e telefonato in massa ai loro rappresentanti per evitare l'approvazione di una legge che, di fatto, avrebbe legittimato la unsolicited commercial email. Il testo della HR3888, che andrà in votazione alla Camera dei Rappresentanti, non conterrà il famigerato Titolo IV (emendamento Murkowski-Torricelli). Al suo posto si avrà questo testo: TITLE II--SPAMMING SEC. 201. SENSE OF THE CONGRESS. It is the sense of the Congress that-(1) in order to avoid interference with the rapid development and expansion of commerce over the Internet, the Congress should decline to enact regulatory legislation with respect to unfair or intrusive practices on the Internet that the private sector can, given a sufficient opportunity, deter or prevent; and (2) it is the responsibility of the private sector to use that opportunity promptly to adopt, implement, and enforce measures to deter and prevent the improper use of unsolicited commercial electronic mail. Questa soluzione è da apprezzare anche perché delinea un dovere (per quanto non regolamentato) da parte dei provider di adottare misure rivolte alla prevenzione/repressione degli abusi di email. In definitiva, il testo così formulato legittima ulteriormente i reclami da inoltrare ai provider in caso di junk email. Va detto che il risultato ottenuto non è ancora al sicuro: infatti la HR3888 dovrà essere unificata alla analoga legge approvata dal Senato (S1618), che ancora contiene l'emendamento Murkowski. Si ritiene comunque che l'emendamento debba cadere definitivamente. 980922 - Prossimamente in discussione alla Camera USA la legge pro-spam Per il prossimo 28 settembre la Camera dei rappresentanti USA ha all'ordine del giorno la 230<br />
<br />
 legge pro-spam, già approvata dal senato come riportato in questa stessa pagina. 980908 - Lo spammer del momento: TCPS Se avete ricevuto email con il subject: "Are You Being Investigated" oppure: "World Record Sex", avete già fatto conoscenza con TCPS. Si tratta di uno spammer particolarmente aggressivo e insistente, che si avvale soprattutto di nodi dial-up della UUNet e di mailbox prese su Hotmail, Juno o altri servizi analoghi. Il comportamento di TCPS non ha precedenti quanto a spregiudicatezza. In USA stanno cercando di fermarli non solo grazie agli sforzi di Juno (anche impegnata in una causa contro TCPS) e di Hotmail, che chiudono mailbox una dopo l'altra, o grazie a provvedimenti presi da UUNet, che ha recentemente chiuso i server relay*.uu.net all'uso da parte dei dial-up, ma anche con denunce alle autorità dello stato di New York, per violazioni di legge di cui TCPS viene accusata (per esempio la diffuzione di annunci porno a minori). Riguardo a TCPS è stata redatta una apposita FAQ (postata su news.admin.net-abuse.email). 980905 - UUNet supera il milione di reclami ricevuti Circa attorno alle 17,35 GMT, UUNet ha assegnato (non si sa a chi) il trouble ticket UU1000000. Si tratta di una numerazione interna dei reclami ricevuti all'indirizzo fraud@uu.net. Ogniqualvolta si riporti un caso di junk-email al suddetto indirizzo, il personale (attivo 24 ore su 24 tutti i giorni, come annunciato dal loro responsabile in un post) assegna il numero e lo include in una email di conferma inviata all'autore del reclamo, con l'indicazione di riportare tale numero in eventuali successive comunicazioni riguardanti l'incidente in questione. L'evento era atteso da tempo, ed ogni progresso verso l'affascinante numero pieno di zeri veniva registrato nel tentativo di prevedere il giorno e l'ora in cui fosse stato raggiunto. 980904 - UUNet cambia gli indirizzi per la segnalazione abusi Si potrebbe osservare che gli standard sono un'idea talmente popolare che ognuno si fa i propri. In effetti, pur essendo prevista dagli standard di rete la nomenclatura abuse@nomedominio, UUnet si distingue per avere adottato indirizzi piuttosto imprevedibili, quali fraud@uu.net per segnalare abusi di email e spam-complaint@uu.net per segnalare spam su newsgroup. Ora, come ha spiegato John Bradshaw, responsabile del reparto "Security & Internet Abuse Investigations" di UUNet, si passerà ai seguenti nomi di mailbox: abuse-mail Mail abuse issues abuse-news Usenet abuse issues security Break-ins, DOS, Copyright, Port Scan, etc. 231<br />
<br />
 I vecchi indirizzi, tuttora riportati nella pagina "Use Policy" del sito di UUNet, rimangono comunque attivi, anche se non è stato precisato per quanto tempo. UUNet ha anche attivato una mailbox col classico nome abuse, scrivendo alla quale si ottiene una risposta automatica che indica gli indirizzi corretti, invitando a riscrivere ad essi. 980828 - Legge antispam in California Approvata una legge che proibisce di falsificare gli header e di inviare email in violazione alle AUP dei provider utilizzati. Ai provider è data facoltà di citare in giudizio gli spammer ed ottenere da loro 50 dollari per ogni email spedita, più ulteriori 25000 dollari per spese legali. 980806 - Procede al Congresso USA l'iter di una legge pro-spam Dopo l'approvazione del Senato, il Telecommunications, Trade, & Consumer Protection subcommittee della Camera dei rappresentanti ha approvato la legge HR3888, nata dalla applicazione, ad una legge anti-slamming, di un odioso emendamento dei senatori Murkowski e Torricelli, poi appoggiato dal rappresentante Tauzin. Tale emendamento di fatto legittima l'invio di junk-email, sotto condizioni assolutamente ininfluenti: diventa reato falsificare gli header, viene prescritto che la junk-email contenga la stringa "This message is unsolicited commercial email." nel corpo del messaggio (non negli header), viene prescritto agli spammer di indicare in chiaro il proprio nome/indirizzo e gli viene proibito di continuare l'invio di messaggi a coloro che gli avessero inviato richiesta di remove. Come ulteriore beffa, la legge proibisce ai singoli stati USA di approvare normative anti-spam più restrittive; fortunatamente sembra però che le leggi già approvate in alcuni stati (Washington e Nevada) siano comunque salve. Si tratta di una legge assurda, che potrebbe essere dovuta ad una profonda ignoranza della vita in rete e del problema dello spam, se non fosse più verisimile pensare ad interessi lobbistici legati ai junk-emailer, sufficientemente potenti da dirigere le scelte dei parlamentari USA a danno dei consumatori. Nonostante la legge non sia ancora in vigore (deve essere votata dalla Camera e firmata, eventualmente, dal Presidente), molti spammer hanno già iniziato ad appellarsi ad essa. Girano infatti delle junk-email che iniziano con un testo come il seguente: This message is sent in compliance of the new e-mail bill: SECTION 301, Paragraph (a)(2)(C) of s. 1618 Tale annotazione va e andrà ignorata. Si consiglia di procedere comunque a riportare la cosa al postmaster competente, come consuetudine. E soprattutto non mandate nessuna richiesta di remove.<br />
<br />
Indice<br />
<br />
Indice Notizie 232<br />
<br />
 Ultimo aggiornamento: 01 dicembre 1998<br />
<br />
Leonardo Collinelli<br />
<br />
233<br />
<br />
 Dal mondo dello spam Testo delle notizie dall'1/4/2000 al 31/7/2000<br />
<br />
000727 - Già chiusa la vicenda Yesmail vs MAPS Yesmail e MAPS hanno annunciato di avere raggiunto un accordo, in seguito al quale il Temporary Restraining Order viene annullato, la vertenza viene sospesa e il listing di Yesmail in RBL non avrà luogo. Paul Vixie ha dichiarato che, nei colloqui avuti con i responsabili di Yesmail, si sarebbe evidenziata l'intenzione di questi ultimi di adottare policy che escludono la candidabilità di Yesmail all'RBL. Starebbe procedendo un lavoro congiunto tra i due soggetti, finalizzato a concludere un accordo che, nelle speranze di Vixie, dovrebbe diventare un modello per qualsiasi compagnia operante nel settore del marketing per email. Una dichiarazione di identico tenore è stata rilasciata dal CEO di Yesmail. 000722 - Primo commento ufficiale di Paul Vixie sulla vicenda Yesmail Si è avuta una prima udienza presso la Corte Distrettuale dell'Illinois competente per la vertenza Yesmail vs MAPS (vedasi a questo proposito la notizia precedente). Il giudice ha mantenuto in vigore il TRO, ossia l'ordinanza temporanea che impone a MAPS di non listare Yesmail nell'RBL, autorizzando tuttavia MAPS ad esprimere la propria posizione sulla vertenza. Paul Vixie, in un comunicato disponibile sulla homepage del MAPS, ha quindi dichiarato di essere pronto a difendere in tribunale la legalità delle sue operazioni (è peraltro noto che MAPS, da sempre, si è dichiarato interessato a testare in tribunale la legalità delle pratiche di blackholing) ed ha rivendicato: ●<br />
<br />
●<br />
<br />
il diritto per MAPS, come per chiunque altro, di mantenere un database di aziende le cui pratiche di comportamento siano non conformi ad una policy da esso stabilita; di consentire a chiunque di effettuare query sul database in questione.<br />
<br />
Va anche tenuto presente che MAPS non divulga e non cede ad alcuno l'elenco delle aziende listate in RBL: vengono solo trasferite le zone DNS (in pratica, elenchi di indirizzi IP) ed esclusivamente a soggetti che abbiano firmato, con MAPS, un apposito accordo di non-disclosure. L'unico tipo di query effettivamente possibile a chiunque è su singoli 234<br />
<br />
 indirizzi IP. Vixie ha fatto presente che, col diffondersi di pratiche di mercato in base alle quali il valore delle aziende è strettamente correlato al numero di sottoscrittori di newsletter o mailing list, diventa sempre più importante per la protezione degli utenti internet garantire che non si possa diventare sottoscrittori contro la propria volontà, ma solo per propria libera scelta. Vixie ha infine osservato che, dopo la rimozione di Yesmail dall'RBL in conseguenza del TRO, moltissimi amministratori di rete hanno provveduto in proprio a blacklistare, per i sistemi di cui ciascuno ha responsabilità, tutti i blocchi IP di Yesmail. Si può a questo proposito osservare che, a fronte di un normale listing in RBL, Yesmail avrebbe potuto risolvere i propri problemi sull'iscrizione alle mailing list e farsi rimuovere dall'RBL, ripristinando così al 100% ed in tempi brevi la propria connettività. Ora dovrà ottenere, eventualmente, la rimozione del blocco da parte di ciascuna delle reti che stanno bloccando Yesmail di propria iniziativa, cosa che appare quanto meno più complessa e difficile. 000719 - HR3113 approvata dalla House of Representatives La proposta di legge HR3113, originariamente presentata dal rappresentante Wilson e approvata nel marzo scorso dal competente sottocomitato della House, è stata approvata anche dall'assemblea. Pertanto ora la HR3113 giungerà al Senato, dove dovrà essere riunificata ad altri disegni di legge sul medesimo argomento. Se un testo verrà approvato da entrambe le camere del Congresso, giungerà alla firma del presidente degli USA e andrà ad integrare l'US CODE (il codice delle leggi federali americane). Purtroppo, l'efficacia delle disposizioni della HR3113 è stata notevolmente guastata rispetto al testo che fu approvato dal sottocomitato. In particolare: ●<br />
<br />
●<br />
<br />
●<br />
<br />
È stata tolta la prescrizione di standardizzare, al fine di rendere possibile il filtraggio automatico, il modo con cui gli spam devono essere contrassegnati: ora si dice semplicemente che l'identificazione deve essere data in un modo che sia "clear and conspicuous to the recipient". È stata tolta la norma che rende illegale l'immissione di spam entro server che, all'apertura della connessione, visualizzino nel banner il testo "NO UCE". Ora si rimanda ad uno standard che venga adottato dagli organismi competenti per gli standard Internet (come per esempio la IETF) e che sia poi approvato da una apposita commissione. Teoricamente potrebbe essere ugualmente raggiunto il risultato necessario, tuttavia la cosa è stata resa non più immediata. Anziché specificare, come nella precedente versione, che la HR3113 non impedisce agli Stati di adottare legislazioni più restrittive, ora si vietano leggi statali non conformi alla HR3113, lasciando nella potestà degli Stati solo aspetti di importanza non decisiva.<br />
<br />
L'unica buona notizia è il mantenimento del Private Right of Action (PROA) a vantaggio non solo dei provider ma anche degli utenti, i quali potranno rivolgersi alle corti statali o, in 235<br />
<br />
 mancanza di leggi statali, alle corti federali, al fine di perseguire gli spammer ed ottenere i risarcimenti previsti dalla legge. Il testo della HR3113 nella sua attuale formulazione è disponibile, in formato PDF, sul sito di Cauce. Cauce ha espresso un giudizio positivo, esprimendo solo la preoccupazione per ciò che potrebbe ancora avvenire nei successivi passaggi previsti al Congresso. 000716 - Tribunale USA ordina al MAPS di rimuovere Yesmail dall'RBL Yesmail.com è una azienda, con sede a Chicago, che gestisce newsletter commerciali per argomenti, alle quali gli utenti interessati possono iscriversi. I problemi tra Yesmail e MAPS si sono avuti per via del fatto che è possibile, almeno in alcuni casi, iscrivere indirizzi senza un meccanismo di conferma, rendendo così possibili abusi quali iscrizioni fraudolente. Il MAPS ha chiesto a Yesmail di rendere il meccanismo di conferma obbligatorio per qualsiasi iscrizione e, non avendo ottenuto in tal senso una disponibilità ritenuta sufficiente, ha proceduto al listing in RBL. Yesmail si è rivolta alla Northern District Court of Illinois, ottenendo un TRO (=Temporary Restraining Order), ossia una ordinanza che, in attesa del giudizio nel merito, ingiunge al MAPS di sospendere il listing degli ip di Yesmail. Il MAPS, in un breve comunicato, ha confermato l'esistenza del TRO senza rilasciare altri commenti. Per il giudizio di merito, il primo nella storia di MAPS, è prevista una udienza il 18 luglio. Nel frattempo, molti amministratori di reti stanno provvedendo a bloccare il traffico proveniente dai blocchi di Yesmail, anche in assenza del listing in RBL. Anche se l'effettiva decisione della corte deve ancora venire, sconcerta il fatto che un simile TRO sia stato concesso. Ci manca solo più che un giudice imponga a qualcuno di ricevere obbligatoriamente le email di qualcun altro. 000713 - Si aggrava il listing di buongiorno.it in RBL Molti utenti italiani conoscono buongiorno.it/send.it per essersi trovati, loro malgrado, iscritti alle mailing list gestite da tale organizzazione. È oggi inammissibile che una mailing list accetti iscrizioni senza prevedere un meccanismo di conferma, in quanto si renderebbero possibili abusi di email anche gravi. Per lungo tempo i responsabili di buongiorno.it hanno ricevuto reclami da molti utenti vittime di iscrizioni fraudolente alle mailing list in questione, tuttavia non hanno provveduto a risolvere il problema. Il 9 giugno la cosa giunse all'attenzione del MAPS, che contattò in email i responsabili di Buongiorno e del loro provider (Inet), richiedendo entro 24 ore un piano per la correzione del problema. A tale richiesta non fu data alcuna risposta, così il 12 giugno i server di buongiorno.it/send. it (punti di origine delle mailing list) furono listati in RBL. Anche a questo punto, non si ebbe alcun intervento sul problema e, nei giorni scorsi, si constatò che i mailserver in questione erano stati spostati su altri indirizzi ip del medesimo blocco, in modo da aggirare il listing in RBL. Si tratta di tentativi non nuovi nella storia dell'RBL, che la prassi del MAPS prevede di gestire passando dal listing dei singoli ip a quello dell'intero blocco. A fronte di una nuova nomination inviata da utenti italiani per segnalare quanto accaduto, è così stato interamente listato il blocco 212.239.17.0 (come del resto era prevedibile). 236<br />
<br />
 Questa vicenda porta a due considerazioni: anche se si tratta di un caso isolato, è preoccupante vedere attive in Italia realtà intenzionate a non rispettare gli obblighi di corretto comportamento in rete, fino a giungere a bassi trucchetti (lo spostamento degli ip dei mailserver), nel tentativo di forzare comunicazioni non richieste al di là dei blocchi legittimamente posti dalle reti che non intendono riceverle. È invece molto positivo vedere la crescente popolarità di RBL tra l'utenza e gli amministratori di rete italiani. Sperabilmente, nel futuro si dovrebbe andare in crescendo, anche nel nostro paese, sia con l'utilizzo delle blacklist del MAPS come mezzo di filtraggio, sia con il contributo attivo al loro mantenimento, segnalando coloro che, in base alle policy del MAPS, dovrebbero esservi listati. 000605 - Spammer arrestato in California Questa volta Jason Garon, uno spammer quarantaseienne di Mission Viejo (California), l'ha fatta grossa e si è veramente cacciato nei guai. Ha spedito, a utenti di America On Line, milioni di email contenenti pubblicità a siti porno e schemi tipo "soldi facili". Per la colossale spammata si è avvalso del server di uno studio grafico di New York, causandone la paralisi e danni che sono stati valutati a circa 18'000 dollari (tra fermo macchina e interventi per il ripristino del funzionamento). Il fatto più grave di fronte alla legge è comunque l'avere falsificato, come indirizzo mittente, il dominio di ibm.net (a conferma della regola n. 2, secondo la quale gli spammer non sono, in genere, esempi di massima furbizia). Con la collaborazione degli operatori coinvolti (AOL, IBM e AT&T), gli investigatori della contea di Orange sono potuti risalire all'appartamento dello spammer. Dopo essere stato arrestato, Garon è stato rilasciato senza cauzione. Verrà processato a settembre. A quanto risulta sarebbe questo il primo caso in USA di incriminazione per "Internet forgery" (ossia falsificazione su Internet). 000501 - Nuova legge pro-spam in Svezia Entra in vigore oggi una nuova legge svedese, in base alla quale viene esplicitamente considerato legale inviare email commerciali non richieste. Gli utenti che non volessero riceverne dovrebbero iscriversi ad un apposito registro (peraltro non ancora istituito). Viene fatto notare che gli utenti svedesi detestano ricevere spam non meno di tutti gli altri (dal sondaggio compiuto da un quotidiano risulta che il 95% è contrario) e che nessun provider svedese si è pronunciato in favore di questo tipo di soluzione legislativa. Viene anche fatto notare come questa legge sia stata approvata senza aperta discussione, alla chetichella o quasi, e non ci sono molti dubbi sul fatto che tutto si deva all'azione lobbistica da parte del mondo della pubblicità nei confronti dei legislatori svedesi. Nick Nicholas (uno dei massimi dirigenti del MAPS) ha fatto notare che la presenza di leggi di qualsivoglia tipo non ha alcun effetto sui criteri seguiti dal MAPS nel valutare il comportamento dei soggetti presenti in rete e nel decidere i listing in RBL. Pertanto, un ipotetico provider svedese che consentisse ai propri utenti di spammare non potrebbe 237<br />
<br />
 accampare la presenza della legge quale giustificazione, e non potrebbe evitare di essere listato in RBL. Viene anche considerato di svolgere opera di informazione in modo che gli svedesi siano incoraggiati a sottomettere nomination all'RBL ogniqualvolta ciò si rendesse opportuno. 000415 - Nuovi indirizzi per la segnalazione di abusi ad America On Line Già dalla fine di marzo AOL ha modificato, in seguito a cambiamenti organizzativi, i propri indirizzi per la segnalazione di abusi. Pertanto sono state chiuse le caselle abuse che si utilizzavano in precedenza (sia quella @aol.com che quella @aol.net). Gli indirizzi da usare ora sono i seguenti (per tutti si sottointende il @aol.com):<br />
<br />
tosemail1<br />
<br />
Tutte le segnalazioni per unsolicited email ed email spam in genere Attenzione: l'ultimo carattere di 'tosemail1' è un 1 (uno).<br />
<br />
tosusenet<br />
<br />
Tutte le segnalazioni per spam sui newsgroup usenet<br />
<br />
Tutte le segnalazioni per incidenti di Internet security (quindi TOSGeneral hacking report, mailbomb, attacchi denial of service, port scan ecc.) e per casi di molestie/minacce a persone TosWeb tosirc<br />
<br />
Tutte le segnalazioni per pagine web su siti AOL non conformi alla policy Tutte le segnalazioni per abusi su IRC<br />
<br />
Jay Levitt, responsabile abusi di AOL, ha motivato questi cambiamenti (non accolti con particolare soddisfazione dagli antispammer), spiegando che lo scopo è fare in modo che le segnalazioni arrivino alle persone più opportune per occuparsene, non rendere le cose meno semplici. Ha spiegato che i differenti tipi di incidenti richiedono differenti tipi di training, di investigazione e di azione e che, dato l'enorme numero di utenti AOL (di un ordine di grandezza superiore a quello degli altri maggiori provider americani), anche i problemi organizzativi da risolvere sono particolari. Levitt ha infine assicurato che ora AOL dispone di molto più personale per la gestione abusi, che assicura servizio continuo 24x7x365. 000401 - America On Line passa al peering preferenziale con AboveNet AOL ha annunciato (già il 22 febbraio) di aver iniziato ad utilizzare il backbone di AboveNet in via preferenziale. La cosa ha molto rilievo dal punto di vista della lotta allo spam in email, poiché AboveNet è il più noto (anche se non l'unico) carrier che fa uso di RBL in formato BGP sui suoi router. Questo significa che AboveNet non trasporta nessun pacchetto ip da indirizzi listati nel MAPS-RBL, qualunque sia il protocollo (quindi non vengono bloccate solo le email, ma anche il traffico a siti web, server DNS ecc..). Il fatto 238<br />
<br />
 che un provider delle dimensioni di AOL abbia ora il filtro dell'RBL sui propri routing rende quindi il listing in RBL particolarmente efficace per scoraggiare quella minoranza di reti che tollerano o supportano lo spam.<br />
<br />
Indice<br />
<br />
Indice Notizie<br />
<br />
Ultimo aggiornamento: 27 luglio 2000<br />
<br />
Leonardo Collinelli<br />
<br />
239<br />
<br />
 Dal mondo dello spam Testo delle notizie dall'1/9/1999 al 31/3/2000<br />
<br />
000325 - Nuova proposta di legge federale antispam in USA È codificata come HR3113 una nuova proposta di legge federale che, votata all'unanimità dal Commerce Subcommittee on Telecommunications, Trade and Consumer Protection della Camera dei Rappresentanti americana, deve ancora affrontare un lungo iter legislativo durante il quale tutto può ancora succedere. A differenza che con precedenti infelici proposte, tutte fortunatamente naufragate, questa volta l'atteggiamento della comunità antispam è prevalentemente positivo, anche se comunque improntato alla prudenza. Alla url http://www.suespammers.org/us/hr3113.shtml si può leggere l'ultima versione. Il testo, che raccoglie il lavoro dei rappresentanti Wilson (R-NM), Miller (R-CA) e Green (D-TX), contiene ancora alcune cose decisamente criticabili; per esempio, si dice nelle premesse che "l'unsolicited commercial email può essere un importante meccanismo attraverso il quale le aziende fanno pubblicità ed attirano clienti nell'ambiente on-line". Ancora, si occupa solo delle email aventi contenuto commerciale (il che esclude, per esempio, i non rari spam a carattere religioso o politico). Infine, i divieti riguardano solo l'invio di spam a destinatari negli USA, lasciando libero quindi l'invio di spam all'estero. Tuttavia, nella proposta di legge esistono alcuni punti positivi che costituiscono assoluta novità: ●<br />
<br />
●<br />
<br />
●<br />
<br />
rende illegale inviare spam a server che, all'apertura della connessione sulla porta standard per l'invio di email, emettano automaticamente un messaggio in cui compaia il testo NO UCE. La portata di questa disposizione è notevole, anche perché riconosce finalmente il diritto, per il proprietario di un server, di mettere su di esso una sorta di cartello "proprietà privata vietato entrare"; stabilisce il Private Right of Action (nella fattispecie, il diritto di fare causa agli spammer) non solo da parte dei provider, ma anche degli individui. Si tratta di un punto molto importante, poiché le leggi che riconoscono il PROA solo ai provider e non anche agli utenti si sono già ampiamente dimostrate assai meno efficaci; espressamente prevede che agli Stati non è impedito di emanare o mantenere leggi proprie sull'argomento, alle quali questa legge federale andrebbe quindi in aggiunta e non in sostituzione. Si potrebbero pertanto avere Stati in cui la regolamentazione fosse più restrittiva.<br />
<br />
La DMA risulta particolarmente irritata da queste disposizioni e si può prevedere che, per neutralizzare ogni punto significativo di questa proposta di legge prima che venga 240<br />
<br />
 approvata, metterà in gioco tutto il proprio peso lobbistico (della DMA si parla in questa stessa pagina). 000318 - Sconcertante sentenza di un giudice nello stato di Washington Lo stato di Washington fu uno dei primi stati USA a darsi una legge antispam. Si tratta di una buona legge, che attribuisce agli utenti danneggiati la facoltà di esigere consistenti risarcimenti in denaro dai mittenti di spam con header falsificati o contenenti informazioni fuorvianti. Alcuni giorni fa, un giudice di quello stato ha dato ragione ad uno spammer (che era stato querelato in base alla legge in questione) motivando che la legge sarebbe "indebitamente restrittiva e onerosa" e imporrebbe alle aziende oneri eccessivi, non giustificabili con i benefici portati ai consumatori. La sentenza non costituisce precedente e sembra certo che lo stato impugnerà tale sentenza in appello. Nel frattempo molti fanno ironicamente notare quanto sia ridicolo il concetto secondo cui la messa fuori legge di pratiche ingannevoli e disoneste possa essere definita "eccessivamente onerosa". 000318 - La sorgente di spam del momento: i cinesi di 163.net Se vi arrivano degli spam pieni di caratteri non visualizzabili, è molto probabile che ad un esame degli header risultino di provenienza cinese, ed è facile che la sorgente sia per l'esattezza 163.net. Naturalmente da quelle stesse macchine proviene pure spam di matrice occidentale. Il volume dello spam cinese è divenuto ragguardevole già dall'inizio dell'anno e non sembra che i reclami spediti agli amministratori di reti come 163.net (ed alcune altre) siano mai stati presi in alcuna considerazione. Vari ip cinesi sono già stati listati in RBL. Steve Linford, che ha redatto una vera e propria faq sullo spam cinese, segnala che, oltre a 163.net, grossi problemi vengono da alcune altre reti (soprattutto netease.com e cninfo.net) e che molti degli indirizzi postmaster in questione sono stati disabilitati per evitare di ricevere reclami. Pare addirittura che all'indirizzo abuse di 163.net tempo fa rispondesse uno spammer americano residente in Cina. Riguardo alla difesa da questo spam (chi lo riceve ne riceve in quantità industriali) sembra non ci siano molte altre soluzioni oltre al blocco degli ip di provenienza, tutti di China Telecom (upstream per le reti menzionate poco sopra). Tra i range di ip il cui blocco dà maggiori benefici vengono indicati soprattutto 202.96.0.0 - 202.111.255.255 e, sia pure per una minore quantità di spam, 61.128.0.0 - 61.143.255.255. Non appare invece condivisibile la scelta di certuni che intendono bloccare indiscriminatamente tutti gli ip assegnati a reti cinesi: non tutti i cinesi spammano, e dalla Cina esiste anche traffico di mail legittime. Occorre, come sempre in queste cose, discriminare tra "buoni" e "cattivi", perché solo così chi ha scelto di stare in rete senza rispetto del prossimo dovrà alla fine rendersi conto di essersi cacciato in una situazione insostenibile e decidere di cambiare nettamente comportamento. 000119 - Sospesa la Usenet Death Penalty per @Home La notizia è stata ufficialmente annunciata da un post di David Ritz, principale promotore dell'iniziativa. Essendosi riscontrata nei giorni scorsi una nettissima diminuzione nel 241<br />
<br />
 quantitativo di spam originato da @Home (pare che i cancel siano scesi al 10% rispetto al volume che avevano prima di dicembre 1999), la UDP non è stata avviata. @Home rimane comunque in stato di probation per i prossimi 30 giorni: in caso il volume di spam tornasse ai livelli precedentemente avutisi, la UDP entrerebbe in effetto senza preavviso. 000112 - Decretata la Usenet Death Penalty per @Home @Home Network è un importante provider americano (intestatario del blocco ip di classe A 24.*.*.*) che fornisce soprattutto connessione via cavo; si tratta di una modalità di accesso ad alta velocità, per connessioni permanenti o quasi ed a costo accessibile per utenti domestici (qualcosa, insomma, che noi italiani continueremo a sognare ancora a lungo). Da tempo i news server di @Home sono diventati sorgenti di grosse quantità di spam; a questo proposito i proponenti la UDP hanno fornito statistiche ricavate dai cancel di Andrew Gierth e dai report giornalieri dello SpamHippo. Secondo la compagnia, alla causa del problema sarebbe la presenza, nei sistemi di molti utenti della loro rete, di problemi di sicurezza (Back Orifice o altri programmi analoghi) che consentirebbero a spammer esterni di raggiungere i news server di @Home Network per il tramite di utenti inconsapevoli. Certamente questi problemi di sicurezza sono una grossa minaccia per usenet, tuttavia i proponenti fanno anche notare la presenza di spammer pure tra l'utenza ordinaria di @Home, osservando che non si ha evidenza che contro di essi vengano presi adeguati provvedimenti. In mancanza di fatti nuovi, avrà inizio una UDP attiva in data 19 Jan 2000 01:00:00 GMT, e riguarderà tutti i messaggi che abbiano nel Path *.*.*.home.com.POSTED (i siti che non intendessero partecipare potranno escludere lo pseudosito homeudp!). 991106 - Hotmail inizia ad usare RBL per filtrare le email in arrivo Mediante un annuncio di Randy Delucchi, MSN Hotmail ha fatto sapere di avere appena messo in opera il filtraggio tramite RBL. La notizia è stata accolta con soddisfazione, soprattutto da parte degli utenti del famoso servizio di email web-based i quali, grazie a questa implementazione, riceveranno meno spam. Si spera ora che il prossimo passo sia l'utilizzo delle altre due liste fornite dal MAPS (in particolare DUL), che potrebbero portare benefici ancor più rilevanti. E ovviamente si spera che l'esempio di Hotmail venga seguito da un numero sempre maggiore di email provider. Quanto al ben noto problema presentato da alcuni server di Hotmail (che non inseriscono un proprio header "Received:" nelle email ricevute, rendendo di fatto impossibile tracciarne la provenienza), Delucchi ha assicurato che ci stanno lavorando, anche se non gli era possibile indicare date per la soluzione. 991103 - La DMA inasprisce la propria posizione in senso pro-spam Da quando si parla di spam, la DMA (Direct Marketer Association) ha sempre sostenuto 242<br />
<br />
 l'uso delle email non sollecitate come strumento di marketing, rifiutando le argomentazioni della comunità antispam. La DMA ha inoltre sempre sfruttato la propria influenza sui legislatori americani (guadagnata anche grazie a contributi per le campagne elettorali) riuscendo spesso a impedire la messa in atto di legislazioni che riconoscessero, agli utenti di rete, il diritto di decidere che cosa deve entrare nelle loro mailbox e cosa no. Nel dicembre 98 si era avuto un incontro tra la DMA e una delegazione composta da varie persone di spicco nel mondo della lotta allo spam (per esempio Paul Vixie, Nick Nicholas e Afterburner). L'incontro era parso positivo in quanto la DMA, pur non accettando di sostenere regolamentazioni basate sull'opt-in invece che sull'opt-out, aveva comunque riconosciuto che l'opt-in era una soluzione interessante e si impegnava a raccomandarla ai propri associati. Aveva inoltre convenuto che, parlando di opt-out, il titolare di qualsiasi dominio avesse il diritto di effettuare l'opt-out preventivo dell'intero suo dominio. Ora c'è stata una retromarcia: nell'audizione al Subcommittee on Telecommunications, Trade & Consumer Protection della Camera dei Rappresentanti, i rappresentanti della DMA sono ritornati sulle posizioni più retrive, dichiarando che l'unica soluzione per loro accettabile è l'opt-out individuale dei singoli utenti. La vicenda, con i relativi antefatti, è descritta in maniera assai esauriente alla pagina http://mail-abuse.org/rbl/anti-dma.htm. 990920 - RRSS verso l'incorporazione nel progetto MAPS Come già accaduto tempo fa con ORCA-DUL (ora MAPS-DUL), sta nuovamente per accadere che una idea valida, sorta su iniziativa individuale e apprezzata dalla comunità antispam, venga accettata dal MAPS, in modo che possa essere portata avanti in maniera più organizzata e sia quindi maggiormente conosciuta e disponibile agli amministratori di rete di tutto il mondo. L'annuncio è stato dato, sia pure informalmente, da Paul Vixie. La cosa è in fieri, e richiederà certamente qualche tempo per giungere a compimento. Vixie ha anche accennato all'intenzione di allestire una versione di RBL che includa anche RSS (RRSS si chiamerà MAPS-RSS) e DUL, in modo che coloro che intendono servirsi di tutte e tre le liste possano farlo con un traffico DNS meno voluminoso. Ulteriori informazioni alla nuova url http://www.mail-abuse.org/rss/. La ragion d'essere dell'RRSS sta in una duplice considerazione relativa al problema dei relay aperti, che trova un nuovo approccio tra RBL e ORBS: l'RBL si pone l'obbiettivo di ridurre il numero di reti che si comportano in maniera irresponsabile, pertanto si troverà un relay aperto in RBL solo nei casi, percentualmente non numerosi, in cui il gestore insista a tenerlo aperto, per scelta o per incuria. Molto spam viene però da reti che non sono irresponsabili o non ne sono sorgente in maniera persistente, mancando così dei requisiti per essere listate in RBL. Questo fa sì che il solo RBL non possa bastare per chi intenda fermare un'alta percentuale di spam. ORBS non ha la stessa filosofia, si limita a listare qualsiasi relay aperto (eventualmente andandoli a cercare o accettando semplici segnalazioni che vengono evase in automatico), fornendo così una grossa lista di indirizzi di relay aperti. La funzione di tale lista è comunque riconosciuta come utile (sia come blocco dello spam che come mezzo di pressione per far sì che anche gli amministratori più pigri si pongano il problema). Molti tuttavia ritengono l'approccio troppo drastico, o non gradiscono il principio per cui anche server mai manifestatisi possano venire testati al fine 243<br />
<br />
 di vedere se sono malconfigurati, e poi inseriti in blackist anche se si tratta di sorgenti di spam solo potenziali. L'approccio scelto da Al Iverson, il creatore di RRSS (che continuerà a seguire il progetto in qualità di coordinatore del MAPS-RRS), è quindi differente: vengono testati e inseriti nella black list solo server dai quali sia stata documentata la provenienza di spam (in tal caso, il test appare legittimato da oggettivi dati di fatto). I relay elencati da RRSS sono quindi tutti già conosciuti e utilizzati dagli spammer e, pertanto, il blocco del loro traffico può dare sensibili benefici in termini di spam evitato. Sempre in materia di relay, vanno segnalate le difficoltà in cui si trova IMRSS (altro sistema per la rilevazione automatica dei relay aperti), disconnesso dal provider che considerava abuso la pratica dell'active probing. IMRSS è quindi temporaneamente fermo e in cerca di nuova connettività, vicenda simile a quella attraversata da ORBS tempo addietro. MAPS-RSS, e Iverson in particolare, ha quindi il merito di aver tracciato una strada che, nell'ambito della sicura legittimità di comportamento, mette in condizione di verificare e neutralizzare in buona parte gli effetti dei relay aperti.<br />
<br />
Indice<br />
<br />
Indice Notizie<br />
<br />
Ultimo aggiornamento: 25 marzo 2000<br />
<br />
Leonardo Collinelli<br />
<br />
244<br />
<br />
 Dal mondo dello spam Testo delle notizie dall'1/1/1999 al 31/7/1999<br />
<br />
990730 - Network Solutions proposta per l'RBL Network solutions è la compagnia (fino a qualche tempo fa conosciuta come Internic) che è stata per lungo tempo monopolista per la registrazione dei domini sotto i tld .com, .org, .net e .edu. Recentemente la registrazione di tali domini è divenuta prerogativa anche di vari altri soggetti in regime di concorrenza, tuttavia Network Solutions (NSI) ha tuttora la maggior base di clienti e, di conseguenza, un enorme database di contatti (normalmente 3 per ogni dominio). I problemi sono iniziati quando molte persone registrate come contatto hanno segnalato di aver ricevuto da Network Solutions email pubblicitarie non richieste e non attinenti il rapporto commerciale tra loro e NSI. In particolare, un ISP americano che si era visto arrivare pubblicità di suoi concorrenti ha fornito documentazione al MAPS, che ha poi raccolto simili segnalazioni anche da altri. NSI ha sostenuto di essere legittimata ad inviare le email in questione, stante la preesistente relazione di affari tra NSI ed i suoi clienti, ed ha indicato l'esistenza di istruzioni, contenute nelle email in questione, per consentire ai destinatari di richiedere la cessazione dei mailing. NSI ha inoltre rivolto pesanti minacce di natura legale nei confronti del MAPS nel caso in cui, per effetto dell'inclusione nella blacklist, NSI risultasse impossibilitata a comunicare con i propri clienti. Un altro ordine di preoccupazioni suscitate dal possibile blacklist di NSI è di natura tecnica: l'uso di RBL in forma BGP blocca non solo le email, ma qualunque tipo di traffico con i siti listati, e si potrebbero quindi ipotizzare blocchi nella risoluzione dei nomi di dominio o nell'accesso ai servizi whois. Il MAPS appare quindi intenzionato a muoversi con molta cautela, scegliendo accuratamente gli eventuali indirizzi da includere in blacklist; tuttavia sembra anche intenzionato a non passare sopra alle pratiche di mailing di NSI, che molti considerano non accettabili. Quanto ai rischi legali, non appaiono particolarmente fondati, data la natura assolutamente volontaria dell'uso di RBL e di qualsiasi blacklist pubblica in generale. 990716 - Legge antispam approvata in Austria Il parlamento austriaco ha approvato all'unanimità una modifica alla legge sulle telecomunicazioni, introducendo così il divieto di inviare junk email senza l'espresso consenso del destinatario. È notevole la soddisfazione dell'EuroISPA, la associazione dei 245<br />
<br />
 provider europei che ha unito i propri sforzi a quelli della comunità antispam. La notizia è importante anche perché viene ad ormai poco tempo dalla ripresa dell'esame, presso il Parlamento Europeo, della famigerata direttiva pro-spam. Si spera (e rappresentanti del governo austriaco se ne sono detti convinti) che questa notizia possa influire sull'esito dei lavori della Commissione Europea e sul parere degli europarlamentari. 990712 - RealNetworks di nuovo nell'RBL La compagnia che produce il famoso RealPlayer si trova, per la seconda volta, listata nell'RBL. All'origine del provvedimento il fatto che, come sarebbe stato documentato, la comagnia invia email pubblicitarie anche a coloro che avessero espresso la volontà di non riceverne. La compagnia (un cui importante asset pare essere proprio la grossa lista di indirizzi di email che ha accumulato nel tempo, corrispondenti a circa 67-70 milioni di utenti), ha reagito addossando la responsabilità dei disguidi a persone che, biasimevolmente, compilando il form per il download dei loro software indicherebbero indirizzi di email altrui. Si tratta di una spiegazione che, quand'anche venisse ritenuta plausibile, non consentirebbe di valutare la cosa con differenti presupposti, essendo comunque dovere di chiunque gestisca una mailing list verificare la validità di ogni iscrizione mediante un sistema di conferma. Molto verisimilmente, i 12 server di RealNetworks che sono stati inseriti in RBL non verranno tolti fino a quando la compagnia non presenterà un piano convincente e dettagliato per la soluzione del problema. 990625 - Nuova legge antispam in arrivo nel North Carolina Entrerà in vigore il prossimo primo dicembre una nuova legge antispam nello stato americano del North Carolina. La legge in questione assomiglia in parte a quella entrata in vigore recentemente nel vicino stato della Virginia, anche se appare meno incisiva in quanto prevede, oltre ad altri tipici reati di computer crime, la sola proibizione della falsificazione degli header avvenuta in concomitanza con l'invio di unsolicited bulk email a contenuto commerciale. Il testo completo è disponibile alla seguente url: http://www.ncga. state.nc.us/html1999/bills/ratified/senate/sbil0288.full.html. 990513 - Bloccata in Texas la legge contro la junk email Ad opera del senatore Frank Madla (democratico di San Antonio), la proposta di legge n. 106 dello stato del Texas (un ottimo testo, che avrebbe proibito ogni forma di annuncio commerciale che provochi costi al destinatario) non è stata ammessa alla discussione al Senate Subcommittee On Technology and Business Growth. A quanto risulta, ciò significa che per almeno due anni la legge in questione non potrà essere approvata. 990506 - Il Parlamento Europeo boccia il divieto alla posta commerciale non sollecitata È andato in votazione un emendamento che avrebbe proibito in Europa l'invio di posta 246<br />
<br />
 commerciale non sollecitata. L'emendamento è stato bocciato: 137 i voti a favore, 266 quelli contro. È possibile trovare i dettagli su tale risultato nel sito di Eurocauce all url: http://www.euro.cauce.org/vote_result.html. A tale url sono elencati gli europarlamentari dei vari gruppi che hanno votato in un modo e nell'altro: gli italiani non sono molti, ma qualche nome è riconoscibile. Si suggerisce a tutti, in vista delle prossime elezioni europee, di leggere con attenzione gli elenchi dei candidati della propria circoscrizione, in modo da poter decidere se dare la propria fiducia a chi fa gli interessi dei cittadini consumatori o a chi, forse per disinformazione (ma l'ignoranza non può essere una scusa), preferisce tutelare gli interessi del mondo degli affari. Sarebbe anche utile contattare i propri candidati per chiedere la loro posizione su questo problema. Va tenuto presente che, negli USA, fu possibile nel settembre 98 bloccare l'emendamento Murkowski grazie al fatto che molti utenti americani tempestarono di telefonate i loro rappresentanti, dicendogli chiaramente che non li avrebbero più votati se avessero sostenuto l'emendamento che legittimava lo spam. 990422 - Passerà all'esame del Parlamento Europeo una direttiva basata sull'opt-out Dopo l'approvazione da parte della Commissione Affari Legali, in cui l'unica soluzione accettabile (opt-in) è stata messa in minoranza, il testo che andrà all'aula (ove ogni diversa soluzione è ancora teoricamente possibile) prevede che le email commerciali non sollecitate dovranno essere semplicemente contrassegnate come tali e che gli stati membri dovranno garantire che i consumatori di rete possano iscriversi ad un "registro di opt-out", in modo da potersi con ciò dichiarare contro la ricezione di spam. L'idea della lista di opt-out non è affatto nuova: negli USA sono state tentate più volte delle global remove list, i cui risultati sono sempre stati fallimentari (iscriversi significava semplicemente ricevere più spam). Le speranze che il buon senso possa ricomparire sono, per quanto ridotte, ancora vive. Per questo, in vista del passaggio parlamentare nel prossimo autunno, continua a rimanere online, per chi ancora non avesse aderito, la petizione antispam di Politik-digital (ora anche in italiano alla url http://www.politik-digital.de/spam/it/). 990327 - Murkowski ci riprova (e l'Europa rischia di prendere esempio da lui) Il senatore Murkowski (repubblicano dell'Alaska) ha presentato un nuovo disegno di legge (S.759) che, ricalcando i contenuti del precedente (S.1618, naufragato nel settembre scorso), mira a rendere la vita più facile e più sicura per i bulk emailer, a danno ovviamente dei consumatori di rete. Non tragga in inganno il titolo (che lo stesso Murkowski suggerisce) di "Inbox Privacy Act". Sperando che il suddetto senatore trovi presto qualcosa di meglio per occupare il proprio tempo, prepariamoci ad una nuova stagione di polemiche negli USA e agli spammer che inseriranno nei loro messaggi inutili riferimenti alla S.759, come se fosse già una legge vigente. Chi fosse interessato al testo completo della S.759 lo troverà qui. Con l'occasione teniamo presente che l'Unione Europea potrebbe presto provocare analogo 247<br />
<br />
 danno varando una direttiva (per ora proposta dalla Commissione) che di fatto fornirebbe una legittimazione alla pratica dell'email commerciale non sollecitata. Il testo della direttiva proposta dice infatti all'articolo 7: "Gli Stati membri prevedono nella loro legislazione che la comunicazione commerciale non sollecitata per posta elettronica sia identificata come tale, in modo chiaro e inequivocabile, fin dal momento in cui il destinatario la riceve;" Si raccomanda quindi di firmare la petizione di cui a http://www.politik-digital.de/spam/ en/. Il problema di questa pericolosa proposta di direttiva europea viene trattato anche da EuroCAUCE. 990224 - Approvata legge antispam in Virginia Con voto unanime, l'Assemblea Generale della Virginia (lo stato USA in cui hanno sede America On Line e PSI.net) ha dato il via ad una nuova legge antispam. La nuova legge (HB1714, presentata dal delegato John H. Hust) non proibisce lo spam in quanto tale e non può quindi essere considerata la migliore legge possibile, tuttavia contiene alcuni punti assai interessanti: 1. Inserisce nei reati previsti dal Virginia Computer Crime Act il concetto di trespass, ossia introdursi senza autorizzazione nella proprietà (in questo caso il computer) altrui, limitatamente al caso in cui ciò avvenga falsificando header o altra informazione relativa alla trasmissione del messaggio ed in combinazione con l'invio di unsolicited bulk email. 2. Inserisce nei computer crime pure il reato di possedere o distribuire software appositamente fatto per facilitare l'invio di bulk email (spamware). 3. Stabilisce che i provider non possano incorrere in conseguenze legali per i provvedimenti che prendessero al fine di impedire la bulk email. Ai provider viene inoltre garantita la possibilità di imporre limitazioni più stringenti di quelle introdotte dalla legge. 4. Quantifica i risarcimenti in denaro che i danneggiati (utenti e provider) possono richiedere ai contravventori (i danni subiti oppure la cifra inferiore tra: 10 dollari per ogni messaggio oppure 25000 dollari al giorno). Il punto più significativo è il richiamo al concetto di trespass, che corrisponde ad una corretta visione del problema dal punto di vista dell'utente consumatore; si può quindi senz'altro concludere che leggi come questa della Virginia siano da considerare molto positivamente. Con la Virginia, gli stati USA dotati di una legislazione antispam (in qualche caso buona in altri no) salgono a 18. 990131 - ORCA DUL viene inglobato nel MAPS 248<br />
<br />
 ORCA DUL, il sistema che fornisce, sotto forma di una zona DNS, un elenco di indirizzi che i principali provider USA assegnano ai nodi dial-up, è ora disponibile nell'ambito del MAPS. Il MAPS è certamente il più conosciuto e diffuso progetto volto a fornire a chiunque una pratica possibilità di difendere la propria rete dagli abusi in email. Il fatto che MAPS abbia inglobato ORCA DUL è certamente una dimostrazione della validità dell'idea e contribuirà a rendere molto più difficile la vita degli spammer. Sul sito del MAPS, una apposita sezione descrive il rationale del nuovo servizio e le modalità per utilizzarlo. Va tenuto presente che, a differenza del più noto RBL, DUL non elenca reti che si comportino male: elenca semplicemente nodi dial-up (anche di reti con ottima reputazione). Questo per consentire di configurare i mail server in modo da non accettare connessioni dirette da tali nodi. In altre parole si assume che, per mandare email, ciascuno utilizzi il server SMTP del proprio provider e che non esistano ragioni (a parte mandare spam) per cui un nodo dial-up debba connettersi direttamente a server SMTP di altre reti. Chi utilizza ORCA-DUL (purtroppo ancora pochi in Italia) dovrà quindi adeguare il proprio sistema per spostare le inquiry dal dominio DNS dul.orca.bc.ca al nuovo dul.maps.vix.com; il vecchio dominio dul. orca.bc.ca verrà dismesso quando il gestore riterrà che tutti si siano adeguati. Per esempi d'uso (soprattutto relativi a SendMail) si veda http://maps.vix.com/dul/examples.htm. 990120 - ORBS nuovamente operativo ORBS, la più famosa lista di relay aperti che molte reti in tutto il mondo utilizzano (riuscendo così a tenere lontano un buon quantitativo di spam), è finalmente tornato. ORBS era stato chiuso a fine novembre 98 per decisione dell'up-stream provider, BCTEL, che considerava abuso l'effettuazione dei test di relay sui server di altre reti. ORBS ha ora trovato una nuova casa in Nuova Zelanda, lontano dall'insofferente backbone di BCTEL. La url è cambiata ed è ora http://www.orbs.org/. Il funzionamento è quello di sempre (qualche cenno è qui) e chiunque gestisca un mail server può configurarlo (qualora il software utilizzato lo consenta) in modo da accettare connessioni solo da indirizzi IP che non siano elencati in nessuna delle liste di MAPS RBL, di ORBS o di ORCA DUL. Nei quasi due mesi trascorsi senza ORBS gli spammer hanno avuto vita più facile nel trovare relay aperti, mentre gli amministratori di rete hanno trovato più difficoltà a difendere le mailbox sui propri server. Si sono avuti su news.admin.net-abuse.email molti post che annunciavano relay aperti e si parlava già di istituire un newsgroup apposito. 990113 - Anche in Texas si sta preparando una legge contro la junk email Nello stato del Texas è stato presentato un disegno di legge del senatore Carlos Truan per proibire ogni forma di pubblicità non sollecitata che sia cost-shifted, ossia tale da provocare un costo al destinatario. Se la legge sarà approvata nella sua attuale formulazione, suggerita dal F.R.E.E., proibirà nello stato del Texas i junk fax (per altro già al bando negli USA), il telemarketing verso telefoni cellulari e, soprattutto, la junk email. Un passo particolarmente significativo del disegno di legge è il seguente: 249<br />
<br />
 Sec. 42.011. CERTAIN ADVERTISEMENTS PROHIBITED. (a) A person may not initiate a telecommunication for the delivery of an advertisement if the delivery causes the recipient of the advertisement or a service provider who stores or transfers the advertisement to incur a fee, expense, or other damages. La proposta di legge prevede che gli utenti che riceveranno junk email potranno promuovere azione legale contro lo spammer e chiedere un risarcimento di 500 dollari per ogni violazione, ovvero per l'ammontare del danno ricevuto se questo risultasse superiore. Il presidente del F.R.E.E. (sul cui sito sono disponibili ulteriori dettagli) ha osservato con soddisfazione che si tratta di un passo concreto contro l'argomentazione, spesso sostenuta dai junk emailer, che vietare lo spam sia lesivo della libertà di parola (tutelata dal primo emendamento della Costituzione americana); argomentazione priva di fondamento, perché non esiste alcun diritto a costringere chicchessia a pagare per la libertà di parola di qualcun altro. Leggi come questa possono aiutare a conservare per il futuro uno dei principali servizi ora disponibili attraverso Internet, la posta elettronica, che l'attacco sempre più aggressivo dei junk emailer rischia di rendere inservibile nell'arco di non moltissimi anni.<br />
<br />
Indice<br />
<br />
Indice Notizie<br />
<br />
Ultimo aggiornamento: 04 agosto 1999<br />
<br />
Leonardo Collinelli<br />
<br />
250<br />
<br />
 Consigli per i provider È opportuno per un provider interessarsi al problema dello spam? Senza alcun dubbio. Prima di accennare a qualcosa di ciò che i provider possono fare, vorrei dare loro un po' di buone ragioni concrete. A questo scopo mi appoggerei ad uno studio specifico, condotto da un istituto assai celebre che si occupa di indagini di mercato nel mondo della tecnologia dell'informazione. La ricerca è stata condotta proprio per chiarire il punto più importante: il modo in cui il problema dello spam viene affrontato da parte di un provider influisce sul successo di quel provider nel mantenere la propria clientela? I riferimenti esatti all'istituto e alla ricerca in questione potete trovarli in questo file.<br />
<br />
Data l'autorevolezza della fonte, la lettura delle 14 pagine di tale report si raccomanda senz'altro. Per immediatezza riassumo qui i punti più significativi. ●<br />
<br />
●<br />
<br />
La posta commerciale non sollecitata sta rapidamente crescendo e non risparmia più nessuno, colpendo sia gli utilizzatori casalinghi di Internet che l'utenza aziendale. Il numero di utenti della posta elettronica crescerà considerevolmente nei prossimi anni, costituendo un target sempre più attraente per i junk emailer e rendendo i loro mailing sempre più frequenti, voluminosi e aggressivi. Il problema potrebbe diventare ingestibile, e gli ISP vedranno crescere i loro costi e lo scontento dei loro clienti. Il report indaga innanzitutto sulla percezione che gli utenti hanno dello spam, il loro atteggiamento in proposito ed il loro tipo di reazione. Attraverso alcuni grossi ISP americani è stato diffuso tra gli utenti un questionario al quale si sono ottenute circa 13000 risposte. Limitandoci agli aspetti più interessanti dei risultati si nota che: ❍ Il 91% di coloro che hanno risposto riceve almeno 1 spam per settimana, il 31% ne riceve più di 10. ❍ Quanto più a lungo l'utente resta cliente del medesimo provider, tanto maggiore è la probabilità che riceva spam e tanto maggiore è la quantità di spam che riceve. ❍ Agli utenti piace o no ricevere spam? ■ il 63% risponde di detestarlo fortemente ■ il 20% ne è variamente infastidito (siamo così all'83%). Tolti i neutrali, si ha poi un 2% a cui lo spam non dispiace e un 1% a cui piace molto. ❍ Richiesti di indicare la principale ragione per cui non gradiscono lo spam, 251<br />
<br />
 ■ ■ ■<br />
<br />
●<br />
<br />
●<br />
<br />
●<br />
<br />
il 42% indica il tempo che fa perdere (e il tempo è denaro), il 32% lo vede come una invasione della propria privacy. il 15% fa riferimento ai contenuti offensivi.<br />
<br />
Passiamo al modo in cui gli utenti reagiscono. Una domanda chiede a chi sono soliti reclamare per gli spam ricevuti (essendo ammesse risposte multiple, le percentuali superano il totale di 100): ❍ il 64% protesta con il mittente, ossia con lo spammer ❍ il 53% si lamenta col proprio provider ❍ il 34% reclama al provider dello spammer ❍ il 25% protesta con le aziende pubblicizzate ❍ il 24% si lamenta con familiari e amici. Si può osservare che i più seguono la scelta (inutile e spesso dannosa) di reclamare allo spammer. Quel 53% che reclama al proprio provider costituisce un costo in termini di customer care (qualcuno dovrà dedicare del tempo per rispondere). Il report fa notare l'importanza di quel 24% di utenti, quasi uno su quattro, che si lamentano in famiglia e con gli amici: è un chiaro segno di scontentezza del servizio, e ci si può aspettare che in tali chiacchierate con gli amici questi scontenti facciano pure il nome del proprio provider (con conseguente pubblicità non positiva). Più della metà degli interpellati ha dichiarato di avere cambiato provider in passato. Ad essi è stato quindi chiesto per quale motivo avessero cambiato, ottenendo le seguenti interessanti risposte: ❍ il 34% per difficoltà nell'accesso ❍ il 17% per ragioni di costo ❍ l'8% per via delle linee spesso occupate ❍ il 7% per causa dello spam ❍ il 7% per via della lentezza dei collegamenti ❍ il 6% per lo scadente servizio di relazioni coi clienti Il report fa notare che i problemi relativi all'accesso, alle linee occupate e alla lentezza saranno sempre meglio risolti con l'impiego di tecnologie che sono in continuo miglioramento e di cui tutti i provider beneficeranno. A quel punto, tra i fattori di competizione che rimarranno, comincerà a divenire sempre più rilevante anche il modo in cui il provider gestisce lo spam e l'efficacia con cui protegge da esso i propri utenti. A questo punto è stato chiesto agli utenti se, per causa dello spam, sarebbero propensi a cambiare provider in futuro o, addirittura, ad abbandonare Internet. Il 91% ha detto di non avere alcuna intenzione di abbandonare Internet, ma il 36% si è detto dispostissimo a cambiare provider al fine di ridurre lo spam ricevuto. L'analisi ha allora preso di mira quel 64% di utenti che si è detto non disposto, oggi, a cambiare provider per via dello spam, chiedendo ad essi di quale entità dovrebbe essere l'aumento nello spam ricevuto per indurli a cambiare idea (e quindi anche 252<br />
<br />
 provider). Risultato: se lo spam aumentasse del 50% rispetto alla situazione attuale, il 22% di questi utenti cambierebbe provider. Percentuale che salirebbe al 40% se invece lo spam raddoppiasse e al 49% se triplicasse. Tenendo conto che il 60% degli interpellati riceve, alla settimana, solo 10 spam o meno, quegli incrementi necessari appaiono poco voluminosi e quindi possibili ad accadere da un giorno all'altro. Un altro dato significativo è che il 70% circa degli utenti sarebbe disposto a pagare almeno un dollaro di sovrapprezzo mensile di al fine di usufruire di adeguato filtraggio antispam. ●<br />
<br />
Il 40% degli utenti vorrebbe che lo spam fosse messo al bando e il 25% che fosse regolamentato. A questo 65% complessivo è stato chiesto a chi dovrebbe spettare, secondo loro, il compito di provvedere a ciò. Il 73,8% di essi ha indicato il proprio provider, distaccando alla grande il 13,5% che ha indicato le autorità governative. Richiesti di valutare quanto efficace sia il loro provider nel limitare lo spam, il 40% ha risposto "bene" o "molto bene". Per il 60% invece il risultato è da mediocre a molto scadente.<br />
<br />
●<br />
<br />
Il report si conclude con dettagliate valutazioni numeriche sui costi che gli ISP rischiano di dover subire per via del turn-over degli utenti che cambierebbero provider alla ricerca di mailbox meglio difese. Sono presenti anche valutazioni dei costi di varia natura (hardware, banda, personale) causati dalla necessità di gestire lo spam.<br />
<br />
Per trarre delle conclusioni, ai provider mi sentirei di dire: Fate qualcosa. Lo spam sta rendendo peggiore il prodotto che voi vendete, e sta vanificando in buona misura i vostri sforzi per fornire un servizio buono a costi contenuti.<br />
<br />
Cosa dovrebbe fare un provider I provider americani, tranne alcuni, tendono a considerare il problema meritevole di attenzione. Quando qualcuno di loro viene criticato per inefficacia, il problema è in molti casi transitorio: può essere il sottodimensionamento del reparto che gestisce le violazioni alla policy (poche persone oberate di lavoro non possono impedire, in certi periodi, l'accumularsi di reclami inevasi). Quanto all'Italia, il problema era all'inizio trascurato ma, nel tempo, il consenso sulla necessità di impedire gli abusi si è sempre più esteso. Ora proviamo a vedere un elenco di cose che si devono raccomandare ad ogni provider. 1. Dotarsi di un proprio regolamento di servizio. Di buoni regolamenti, che prevedano un quadro completo di comportamenti non ammissibili, se ne possono trovare in rete (per esempio, ci se ne può far consigliare su news.admin.net-abuse. email, posto che si provveda poi agli opportuni aggiustamenti in base al diritto 253<br />
<br />
 italiano). Occorrerebbe richiamare il regolamento nei contratti firmati dagli abbonati, in modo che ne fosse accettata a priori la applicazione. Il tutto dovrebbe essere scritto con la necessaria consulenza legale, in modo che in caso di violazioni non ci fossero appigli che consentissero, al contravventore, di aprire un contenzioso legale. Tra i comportamenti vietati ci deve essere innanzitutto l'invio mediante email di ogni genere di pubblicità o avvisi non richiesti dai destinatari (prescrivendo che documentazione di tali richieste dei destinatari debba essere conservata ed esibita in caso di contestazioni); si dovranno ugualmente vietare gli spam su newsgroup, nonché le chain-letter e simili, comunque diffuse. Tali comportamenti dovranno essere vietati anche se effettuati tramite altri provider, qualora pubblicizzino pagine ospitate dal servizio oggetto del contratto. Deve inoltre essere prescritto, ai clienti che intendessero usare il servizio per diffondere newsletter e/o mailing list, di adottare un meccanismo di conferma per qualunque richiesta di iscrizione a tali newsletter o mailing list. Poi, così come si proibisce di solito l'uso del servizio per distribuire software pirata, si deve proibire la promozione o distribuzione di software mirato all'invio di junk email o di spam su Usenet (i prodotti spesso indicati come spamware), servizi di bulk email e programmi mirati a provocare attacchi di tipo denial of service, mailbomb e simili. Il regolamento d'uso del servizio deve essere infine reso pubblico tramite una apposita pagina web. 2. Non consentire a nessuno l'accesso al servizio senza avere accertato le generalità del richiedente. Per lungo tempo, una tra le più grandi iatture della rete è stata la diffusione in edicola di riviste cui erano allegati abbonamenti gratuiti (per es. di 15 giorni) che, come era stato accertato, consentivano di accedere alla rete senza dare alcuna prova della propria identità. Problema analogo si pone con l'accesso internet cosidetto gratuito. È ovvio che qualsiasi spammer riuscirebbe sempre ad essere in rete se potesse accendere un nuovo abbonamento gratuito ogni volta che gli fosse revocato l'accesso. E' quindi indispensabile che i clienti vengano sempre identificati. Anche se si intende concedere un abbonamento di prova di due giorni, bisogna farsi inviare via fax la carta di identità del richiedente, o adottare altre procedure che diano il medesimo risultato finale. Bisogna proprio evitare di accettare un cliente che avesse già dato problemi in passato. In Italia risulta che provider di primaria importanza già adottino con successo il bando degli utenti indesiderabili, identificandoli in base all'identificativo chiamante della linea usata per le connessioni dial-up. 3. Aprire una casella abuse@nomedominio. Se si utilizzano più nomi dominio un'alias abuse va creato per ciascuno di essi. Si evitino nomi di caselle insoliti e si adotti abuse, che tutti provano per primo. Sarebbe poi utile comunicare tale indirizzo alla Abuse Net per l'inserimento nella loro lista pubblica dei contatti per segnalazione abusi (hanno una apposita mailbox update). Sarebbe anche opportuno indicare l'indirizzo abusi nella pagina web contenente il regolamento d'uso dei servizi e, se esiste, anche nella pagina che riepiloga tutti i contatti con i quali è possibile comunicare con l'azienda. Non si raccomanderà mai abbastanza di tenere presente che coloro che segnalano abusi ad un provider gli stanno facendo un favore e che, di conseguenza, è interesse di ogni provider facilitare al massimo tale opera di segnalazione. È inammissibile pretendere che le segnalazioni passino, per esempio, 254<br />
<br />
 tramite un form web: chi lo fa (si conoscono un paio di casi al mondo) viene giustamente messo alla berlina su RFC-Ignorant e va, prima o poi, incontro a vari inconvenienti. È pure altamente raccomandabile fornire una qualche forma di riscontro a coloro che inviano segnalazioni. 4. Configurare con molta attenzione il proprio software. Scoprire, il giorno in cui se ne avesse la necessità, che un server non include nel log i record necessari a individuare gli autori degli abusi è cosa assai spiacevole. Almeno altrettanto spiacevole è scoprire di avere un relay aperto il giorno in cui ci si trovasse la CDN congestionata, mentre il server lavora alacremente per conto di uno spammer americano (tralasciamo le centinaia di email furibonde che per giorni continuerebbero ad arrivare da ogni parte del mondo). Fate soprattutto attenzione ad ogni upgrade di software ai mail server: provate prima ogni nuovo release su una macchina di test, verificando dall'esterno che il relay non sia abilitato. Tenete presente che, per giungere ad escludere che un server accetti relay di terze parti, occorrono test multipli piuttosto sofisticati. Abuse.net e mail-abuse.org forniscono tool online adeguati allo scopo. 5. Individuare alcune persone che si occupino delle segnalazioni ricevute. Questo dovrebbe accompagnarsi all'adozione di soluzioni tecniche che consentissero alle persone in questione di operare speditamente nella trattazione degli incidenti (per esempio, prevedendo la disponibilità immediata dei log e adottando software gestionale di supporto, per esempio per registrare i reclami ricevuti, aggregarli per incidente e per utente ecc..). Le medesime persone sarebbero pure nelle migliori condizioni per occuparsi anche della assistenza ai clienti che fossero oggetto di abusi di rete. Naturalmente, bisognerebbe fare in modo che queste persone disponessero della formazione opportuna (punto su cui, in genere, gli imprenditori italiani sono assai poco sensibili): a costoro verrebbe infatti richiesto di masticare come niente protocolli di rete (soprattutto IP, TCP, SMTP, NNTP), DNS, le varie problematiche relative alla cancellazione dei messaggi Usenet, per finire all'individuazione di attacchi denial of service, ping storming eccetera. C'è da dire che la maggior parte dell'informazione necessaria può essere reperita direttamente in rete. Tali persone dovrebbero essere in numero sufficiente per non essere oberate di lavoro e per fare in modo che abbiano il tempo di seguire quotidianamente i principali forum dedicati agli abusi di rete. Un ulteriore consiglio: queste persone siano istruite in modo che si occupino degli abusi di rete e si tengano fuori dalle beghe tra utenti. Sono infatti stati riportati casi in cui certi abuse desk hanno redarguito o minacciato provvedimenti contro utenti che avevano semplicemente discusso in toni un po' sopra le righe. Sia chiaro che il compito dell'abuse desk non ha nulla a che vedere con quello di un insegnante d'asilo. 6. Adottare misure di protezione verso le mailbox dei propri utenti. Dato che il problema dello spam è in crescita, gli utenti iniziano ad aspettarsi che i loro provider facciano qualcosa per fermarlo. Quanto meno, l'utente che si vede arrivare uno spam che sarebbe stato facilmente bloccabile (per esempio, giunto direttamente dal netblock di una grossa e famosa spamhaus o da un plurilistato proxy aperto in Corea), è sempre meno disposto a subirlo e piuttosto si chiede se, negli uffici del suo provider, esistano o meno forme di vita intelligente. È quindi importante porsi al più 255<br />
<br />
 presto il problema, e certamente le misure più efficaci, che possono immediatamente sgravare gli utenti di molto spam bloccabile, sono le blacklist. Tempo fa consigliavamo di configurare il sistema in modo da avvalersi automaticamente di MAPS RBL, DUL e RSS. Ora la scelta è più articolata: ci sono molte altre possibilità ma anche, di conseguenza, una maggiore responsabilizzazione per le scelte che si fanno. Rimandiamo alle pagine in cui trattiamo le blacklist e, soprattutto, alle opportune aree di discussione, che seguono l'attualità molto più in tempo di quanto possa fare questo sito. Dato che l'uso di queste liste è normalmente piuttosto semplice dal punto di vista tecnico, non c'è proprio alcun motivo per rinunciare ad avvalersene. Se il software del vostro server non consente di sfruttare queste liste, considerate seriamente di cambiarlo o, eventualmente, di ricevere la posta in arrivo su una macchina di front-end che effettui il filtraggio (un sistema Linux o *BSD con un MTA sicuro e configurabile come Postfix può essere a questo scopo una soluzione ottima ed economica). Qualunque scelta si faccia in materia di blacklist, si preveda in ogni caso la possibilità di aggiungere una lista nera propria e anche una whitelist, con cui stabilire eccezioni alle blacklist utilizzate. Riguardo alla blacklist locale, la cosa migliore è metterla assieme in base alle proprie esperienze, soprattutto per quanto riguarda gli spammer italiani. Andrebbe sfruttato il gruppo di discussione italiano (it.news.net-abuse), in cui le notizie relative agli spammer italiani possono giungere prima che altrove. Altrettanto dicasi per le utilissime mailing list del NIC.it, che realizzano un archivio degli spam provenienti da domini italiani. Inoltre sarebbe bene fornire ai propri utenti filtri personalizzabili attivi sul server della posta in arrivo. L'utente dovrebbe poter decidere di far respingere direttamente dal server tutte le e-mail che soddisfano o non soddisfano a certe condizioni (per esempio, che in certi header compaiano certe stringhe). Si dovrebbe infine considerare l'opportunità di richiamare, nei contratti di adesione al servizio, il fatto che la connettività relativa alla posta elettronica in arrivo sia limitata per via dell'utilizzo di blacklist, scelte a discrezione dei responsabili del servizio. In altre parole, gli utenti devono avere chiaro che non tutti potranno inviargli email. Ci sono comunque soluzioni software che consentono, agli utenti di un server, di operare scelte individuali sulle blacklist da adottare, ciascuno per la propria casella. Quello che consigliamo di evitare sono quel tipo di regole che agiscono "in silenzio", accettando apparentemente la transazione smtp in arrivo e, poi, scartando il messaggio se questo viene considerato essere spam. Ci pare prevalente in rete l'opinione, peraltro anche da noi pienamente condivisa, secondo cui è fondamentale che, per le email respinte, si abbia una chiara segnalazione di errore già durante la transazione smtp: in questo modo, il mittente di una email legittima che venisse respinta come spam potrebbe, quanto meno, rendersene conto al più presto. Sui punti qui elencati e su altri ancora esiste un documento utilissimo pubblicato dal RIPE: "Good Practice for combating Unsolicited Bulk Email" (ripe-206). Direi senz'altro che la prima cosa da fare è leggerlo per bene e più volte, poi darsi l'obiettivo di metterlo in pratica nel minor tempo possibile e senza tralasciare nulla.<br />
<br />
Esistono esperienze interessanti di attività antispam da parte di 256<br />
<br />
 provider italiani? Sì, c'è chi già si è mosso. Un esempio significativo da citare (il primo di cui venni a conoscenza) è la sezione antispam del sito di Spin. La visita del relativo link si raccomanda. Qui vorrei rimarcare alcune di quelle che mi sono sembrate le idee migliori messe in atto da Spin. ●<br />
<br />
●<br />
<br />
●<br />
<br />
●<br />
<br />
Innanzitutto fanno informazione (e di qualità) sul problema spam nei confronti dei loro utenti. I loro utenti hanno quindi modo di conoscere tutto su questo problema, compresi i modi per combatterlo e gli errori da non commettere. Vengono anche spiegate le condizioni a cui è possibile effettuare mailing di massa in maniera legittima. Sono in funzione filtri basati sulle blacklist del MAPS (tutte e tre RBL, DUL e RSS), su altre liste internazionali di primaria importanza (tra cui Spews.org, Spamhaus.org, Spamsites.org) e su una lista nera propria. La cosa viene spiegata e agli utenti viene comunque lasciata la possibilità di richiedere un indirizzo non protetto da filtri. Oltre alla casella abuse, è stata allestita anche una casella spam, alla quale i clienti possono scrivere per chiedere chiarimenti e assistenza in merito al problema dello spam. Per consentire ai clienti di usare il più liberamente possibile la propria mailbox senza essere progressivamente sommersi da sempre maggiori ondate di spam, è previsto che essi possano richiedere delle alias "da battaglia" e che possano farsele cambiare in qualunque momento (ossia, quando iniziassero a ricevere spam). Questo tipo di soluzione può contribuire enormemente a migliorare l'esperienza di rete di un utente, e mi sentirei di raccomandarla a qualunque provider. La cosa più pratica per un utente sarebbe di disporre di varie alias per usi diversi e che egli stesso se le potesse modificare mediante un form web protetto da password.<br />
<br />
È senz'altro incoraggiante che la sensibilità al problema stia crescendo presso i provider italiani e che la strada sia ormai stata aperta (e partendo su livelli di qualità che nulla hanno da invidiare ai provider americani). È vero che questo tipo di impegno ha un costo nell'immediato, tuttavia ci si deve anche chiedere qual è il costo in cui si incorrerebbe, nel medio-lungo termine, scegliendo di non fare nulla. Gli utenti diventeranno sempre più sensibili a certi aspetti della professionalità del servizio che acquistano, e queste cose iniziano già ad essere molto determinanti per formarsi una valutazione in tal senso.<br />
<br />
Indice<br />
<br />
<< Precedente<br />
<br />
Successiva >><br />
<br />
Ultimo aggiornamento: 24 dicembre 2002 257<br />
<br />
 Leonardo Collinelli<br />
<br />
258<br />
<br />
 La ricerca in questione e` del Gartner Group. Il titolo esatto e` il seguente: "ISPs and Spam: The impact of Spam on Customer Retention and Acquisition", Engagement #1802565, 14 giugno 1999. Il testo completo del report, in formato PDF, e` stato da me trovato nel novembre 99 sul sito di BrightMail, la cui url e` http://www.brightmail.com/ (da li` seguendo i link alla sezione dedicata agli ISP). Non mi e` possibile fornire qui il documento da scaricare, in quanto il Gartner Group consente di citare i contenuti e la fonte (pur se richiede che quest'ultima non sia inserita nel testo principale) ma non consente link per il download del documento.<br />
<br />
259<br />
<br />
 Devo farmi pubblicità in rete: come faccio senza spammare? Siamo in anni di intenso sviluppo di Internet, di aumento del numero di utenti e di imprese che stabiliscono la loro presenza in rete. Pertanto ci saranno certamente, ogni giorno o quasi, persone che si porranno questa domanda: Se non si può spammare, come è possibile allora farsi pubblicità? Tempo addietro, un visitatore di questo sito ha posto la domanda al sottoscritto. Nella convinzione che possa essere utile anche per altri, riporto qui la mail inviatami (con qualche leggera modifica al fine di rendere non identificabile il mittente) e, nel seguito, la mia risposta. È ovvio che sull'argomento del marketing in rete si potrebbero scrivere grossi libri, e che questa pagina è ben lontana dal dare la risposta definitiva (che probabilmente, del resto, non esiste). Spero comunque che aiuti a inquadrare il problema e sia utile, soprattutto, per evitare di partire in un modo sicuramente sbagliato da ogni punto di vista. L'azienda della quale sono socio ha un ruolo abbastanza importante nella grafica, nella prestampa, nella stampa digitale etc sul mercato locale. Il quale sta cominciando a starci stretto e così avremmo deciso di allargarci sia a livello nazionale che internazionale. Visto che stiamo per investire un bel po' di milioni per mettere in piedi un sito come si deve, vorremmo farci conoscere non solo attraverso le search engines, delle quali tutti conoscono i pregi per l'utente e i difetti per chi vuol farsi trovare, ma anche attraverso un e-mailing indirizzato a clienti (aziende e istituzioni, ovviamente - non privati) potenziali in tutto il mondo. Per non urtare i nervi a nessuno, non rischiare la galera (in Virginia, USA, mi pare) e comunque per poter avere una certa "redemption" (risposta utile), sto cercando di capire qualcosa sulle rispettabilissime campagne antispam. Non ci riesco molto bene, fosse solo per il motivo che a mio avviso Internet ha potuto assumere l'importanza che ha oggi e quella quasi inimmaginabile che avrà domani, anche grazie a leggi commerciali; se Yahoo riesce a pagare i suoi collaboratori è perché ha delle entrate pubblicitarie, o no? È assolutamente vero che la privacy deve essere rispettata, ma mi sembra eccessivo voler impedire la promozione di attività commerciali. Devo forse raggiungere il marketing manager di un'azienda in Nuova Zelanda via Raccomandata (per giunta con le Poste Italiane) o attraverso un fax che la segretaria butterà via senza pietà? Per favore mi aiuti a capire. Grazie per la collaborazione 260<br />
<br />
 Ecco ora la mia risposta. Non escludo che i link qui forniti possano cambiare nel tempo, tuttavia sono solo esempi, non essenziali per i concetti sostenuti. Non mi preoccuperò pertanto di mantenerne la validità.<br />
<br />
Gentile signore, ritengo che la preoccupazione su come dare adeguata pubblicità alla Sua attività, cercando al tempo stesso di fare le cose in maniera corretta, sia apprezzabile, e cercherò di darle qualche elemento su cui riflettere e qualche riferimento per ulteriori approfondimenti. Cercherò nei limiti del possibile, dato che della rete sono un semplice utente, ho una competenza assai limitata sul marketing e non mi sono mai posto di studiare a fondo l'argomento del marketing in rete. Prima di tutto, mi sembra utile stabilire un po' di concetti di base, cercando di eliminare alcuni comuni equivoci riguardanti Internet. Il primo equivoco da chiarire riguarda la natura della rete: non si tratta di una struttura pubblica come la strada, che è lì apposta per servire noi. Si tratta invece di un insieme di reti private, che si sono interconnesse sulla base di un principio cooperativo, di mutuo e volontario scambio del traffico: nessuno dei partecipanti a Internet ha obblighi verso alcun altro, a parte il caso in cui esista un contratto debitamente sottoscritto. Per esempio, io posso visualizzare un sito web grazie al fatto che il server su cui il sito risiede accetta di fornire le relative pagine a chi, con un browser, ne faccia richiesta secondo i protocolli di rete; altrettanto dicasi per il fatto che possiamo scambiare queste email. Quindi, il primo punto da avere chiaro è che, a parte il proprio computer, a parte i server del proprio provider (col quale si ha un tanto di contratto che dà diritto di usarli), tutto il resto della rete è casa d'altri, sono proprietà private nelle quali si è ammessi solo per consuetudine e fintantoché i legittimi proprietari delle reti su cui navighiamo o a cui mandiamo posta ritengono per loro conveniente che sia così. Il discorso vale anche per le mailbox. Per la propria mailbox ciascuno paga: si paga il proprio provider che fornisce la connettività ed il necessario spazio disco, si paga la connessione telefonica per scaricare la posta, si paga il proprio computer, il software e quant'altro (non ultimo, ha un costo particolarmente forte anche il proprio tempo, in cui si devono visionare le email in arrivo). L'assunto di cui io sono convinto (si può ovviamente contestare, ma mi sembrerebbe difficile farlo senza far cadere un po' di grossi pilastri della società in cui viviamo) è che chi paga per una risorsa sia l'unica persona legittimata a stabilire che uso si debba fare per quella risorsa. È quindi sensato ritenere che una mailbox sia legittimamente utilizzata solo nell'interesse di colui che ne sostiene le spese, e che di questo interesse non faccia parte il contribuire alla diffusione del messaggio pubblicitario di qualcuno. Proseguendo, nessuno ha diritto di stabilire di propria iniziativa che il titolare della mailbox xxx@yyy.com sia interessato a ricevere email pubblicitarie relative non importa a che cosa, e indipendentemente da dove si sia trovato il suo indirizzo di email; a meno che, 261<br />
<br />
 naturalmente, il signor xxx@yyy.com non abbia reso evidente che desidera ricevere tali messaggi (per esempio, io ho reso evidente nel mio sito che sono interessato a ricevere osservazioni sul sito stesso o critiche o richieste di chiarimenti sull'argomento e così via). Se il destinatario di email non richieste è una azienda, la sostanza delle cose non cambia. Leggendo la Sua email, mi sembra di capire che Lei non sia destinato a diventare uno spammer nel senso che siamo soliti dare alla parola, ma che possa rischiare di commettere qualche errore di buon comportamento che, pur con tutta la buona fede da parte Sua, potrebbe mettere in pericolo lo sviluppo della Sua attività o, quanto meno, l'immagine. Farei quindi basta qui con le considerazioni di "teoria", e passerei a discutere qualche frase che trovo nella email. >a mio avviso Internet ha potuto assumere l'importanza che ha oggi e >quella quasi inimmaginabile che avrà domani, anche grazie a leggi >commerciali; se Yahoo riesce a pagare i suoi collaboratori è perché >ha delle entrate pubblicitarie, o no? Secondo me, sicuramente la pubblicità in rete è, quando corretta, una cosa più che utile. Non sono però dell'idea che l'importanza attuale e futura della rete sia dovuta alle attività commerciali. La rete è nata in ambito accademico e istituzionale, per poi allargarsi a milioni di individui che oggi, giorno per giorno, riempiono la rete di materiale: dalle discussioni in aree pubbliche su migliaia di argomenti, al rendere disponibili i loro lavori sulle cose di cui ciascuno si interessa (poco o molto che questi lavori valgano), e senza farlo per altra ragione che per la soddisfazione di essere letti e partecipare a questo continuo scambio che arricchisce tutti. Cresciuta così (ed essendo in buona parte ancora così), la rete è giusto che si allarghi al mondo del commercio: l'opportunità è formidabile sia per il commercio che per la rete stessa. Secondo me chi vuol fare commercio in rete deve prima di tutto convincersi del quadro che ho appena sintetizzato. Chi si saprà accostare alla rete capendo questo spirito dello scambio, capendo che occorre preparare della "sostanza" (qualcosa che per il pubblico abbia valore) e metterla a disposizione gratuitamente, sarà considerato più convincente di altri nel proporre i propri prodotti/servizi, e farà soldi. Quanto alle entrate pubblicitarie di Yahoo, non c'è bisogno di convincermi: se si considera il mio sito ed i banner che compaiono su ogni pagina, è evidente che devo alla pubblicità il fatto di aver avuto una scelta così vasta e di qualità nel trovare un servizio di hosting gratuito. È altrettanto evidente che qualunque utente di rete, compreso me, usa Yahoo, AltaVista e altri simili strumenti (indispensabili per trovare quel che si cerca) e può usarli gratis grazie ai banner pubblicitari. Quindi sono il primo a dire: ben venga la pubblicità in rete; sia però chiaro che la pubblicità benefica è quella pagata da colui che ne trae beneficio e svolta dove è appropriato che sia. La posta non sollecitata, che abbia o no contenuto 262<br />
<br />
 commerciale, è solo una forma di parassitismo delle risorse di rete, che non giova a nessuno se non al mittente (salvo gli inconvenienti cui questo può andare incontro) e provoca, su scala mondiale e per anno, dei costi spaventosi a carico di tutti gli altri. È sacrosanto il fatto che, per la rete, sia importante saper attirare investimenti pubblicitari, quanto è fuori dubbio che sufficienti dosi delle varie forme di spam la possono uccidere. >È assolutamente vero che la privacy deve essere rispettata, ma mi >sembra eccessivo voler impedire la promozione di attività commerciali. Infatti non si fa questione di contenuto. Le email non sollecitate e lo spam su newsgroup offendono per il modo in cui ostacolano la comunicazione e l'uso della rete da parte degli altri utenti, e questo vale sia che il contenuto sia commerciale, sia che racconti delle edificanti gesta di religiosi o che faccia conoscere gli orrori commessi da un regime dittatoriale o altro: la sostanza può anche essere nobilissima, ma sempre di abuso di rete si tratta. Quanto al volere impedire la promozione di attività commerciali, bisogna che facciamo uso del buon senso per delimitare correttamente i concetti: se qualcuno entrasse in casa mia (ma penso anche in casa Sua) e tentasse di affiggere un manifesto pubblicitario sulla tappezzeria del salotto, è fuori dubbio che se ne andrebbe subito di corsa a calci nel sedere, e vorrei proprio vedere con che faccia mi si potrebbe dire che sto ostacolando la libertà di promozione delle attività commerciali. >Devo forse raggiungere il marketing manager di un'azienda in Nuova >Zelanda via Raccomandata (per giunta con le Poste Italiane) o >attraverso un fax che la segretaria butterà via senza pietà? Il fax sarebbe una pessima idea, quando non concordato col destinatario, in quanto pure il fax comporta, come ovvio, dei costi per il ricevente. Non parliamo neanche dell'eventualità che, per ricevere il Suo inatteso fax pubblicitario, il destinatario non riuscisse a riceverne in tempo uno con la conferma d'ordine di un cliente (non per niente in USA il junk fax è illegale). È assai probabile, come Lei dice, che il fax verrebbe cestinato senza pietà, ma se è per questo non vedo quale migliore sorte potrebbe avere una email, che verisimilmente verrebbe cancellata non appena comparisse (o, più probabilmente, subito dopo essere stata inviata al Suo provider). Quanto alla raccomandata direi che, se Lei avesse buoni motivi per pensare che, inviandola, si avesse un 70% di probabilità di chiudere la vendita, il costo postale non sarebbe un problema. Se una simile previsione non c'è, a maggior ragione non si combinerebbe nulla neppure con la email non richiesta; al massimo, si troverebbe a ricevere una sgradevole telefonata dal Suo provider (che se è un provider che sa fare il suo mestiere non desidera affatto di finire nei filtri antispam di mezzo mondo). 263<br />
<br />
 >Visto che stiamo per investire un bel po' di milioni per mettere in >piedi un sito come si deve, vorremmo farci conoscere non solo >attraverso le search engines, delle quali tutti conoscono i pregi per >l'utente e i difetti per chi vuol farsi trovare, A mio modo di vedere, la costruzione di un sito è certamente la prima cosa da fare e, costruendolo, bisognerebbe cercare di realizzarvi soprattutto dei buoni motivi per visitarlo (che sono poi gli stessi motivi per cui gli autori di altri siti potrebbero linkarlo, portando così ulteriore traffico). È il discorso che facevo poc'anzi: metterci della sostanza, non solo la celebrazione dei propri prodotti. Fare in modo che chi ha certi bisogni trovi utile passare di lì, indipendentemente dal comprare poi qualchecosa. Quale possa essere la sostanza nel Suo caso, ovviamente non lo so, essendo io perfetto ignorante del mondo della grafica: avere le idee spetta a Lei e alle persone che lavorano con Lei, e se le vostre idee saranno buone, non dubiti che chi è interessato vi troverà. >anche attraverso un e-mailing indirizzato a clienti (aziende e >istituzioni, ovviamente - non privati) potenziali in tutto il mondo Provi a pensare cosa succederebbe se tutti i potenziali fornitori di quelle aziende (in rete ce ne saranno milioni) facessero un emailing... >per poter avere una certa "redemption" (risposta utile) ecco, qui ci siamo, quello che conta è avere una risposta utile. E c'è modo di farlo senza urtare i nervi a nessuno, per usare le Sue parole. Passerei a darLe qualche riferimento sul web ove potrà raccogliere informazioni utili. Cominciamo da http://www.whew.com/Spammers/nospam.shtml Si tratta di pagine realizzate da Leah Roberts, una signora la cui opera come cacciatrice di spam è imponente e che, sul problema, è certamente una delle persone meglio documentate nel mondo. Ravvisando l'esistenza di una esigenza reale importante da soddisfare nell'interesse di tutti, la Roberts ha raccolto molte indicazioni e link a risorse per farsi pubblicità in rete a costo zero. Vale la pena di esplorare le sue pagine e cercare di capire che cosa più o meno si adatta alle vostre esigenze. http://spam.abuse.net/good-marketing.html Qui si trovano alcuni link soprattutto a risorse basate sulla cosidetta opt-in, ossia mailing list che vengono inviate solo ed esclusivamente a coloro che ne abbiano fatto esplicita richiesta. Anche la DMA (Direct Marketing Association) americana, pur se a denti stretti e 264<br />
<br />
 con molte contorsioni e retromarce, era alla fine giunta ad ammettere che, anche solo volendo guardare all'efficacia del risultato da raggiungere, è l'opt-in la strategia consigliata. Opt-in significa essere sicuri che le email non sono sgradite (dato che sono state richieste dai destinatari) e che quindi non si avrà alcun problema con il proprio provider. Ma soprattutto, significa avere un tasso di risposta utile che, con il semplice invio non sollecitato, ci si potrebbe solo sognare. Non le so parlare a fondo delle liste di opt-in, tuttavia seguendo qualche link sono capitato, per esempio, sul sito della IDG ( http://www.idglist.com/ ) dove ho visto l'esistenza anche di liste finalizzate al contatto business to business (il Suo caso). Tra le liste gestite dalla IDG ne vedo una che si chiama Publish, che ha una audience di 83000 manager e quadri e si dichiara ottimale per chi avesse da offrire cataloghi elettronici di qualità e simili; ovvio che si debba approfondire per capire se fa o no al caso vostro, io non sono in grado di valutarlo, ma ho la sensazione che la potenza di questo genere di soluzioni diventi sempre più eclatante man mano che si forma la massa critica. Un altro link che ho seguito, e che mi ha impressionato, è quello di PostmasterDirect, una delle più famose organizzazioni di liste di opt-in, dove si vede un mostruoso elenco di oltre 1500 liste su tutti gli argomenti in cui ci si può imbattere nell'umana esistenza (ovviamente si trovano anche Publishers-Print, Publishing Industry, Fine Art Prints, Artwork Poster Paintings and Print ecc). Quindi i mezzi ci sono, hanno grandi potenzialità e costi per lo meno molto bassi. L'unico errore che si può fare sarebbe mandare spam. Sarebbe un errore perché la junk email infastidisce enormemente la stragrande maggioranza dei destinatari, e i danni per le imprese che inopinatamente vi facessero ricorso sarebbero enormi: la loro immagine presso il pubblico verrebbe portata al livello tipico di coloro che, solitamente, si avvalgono di questa soluzione. Si tratta per lo più di imprese improvvisate e non affidabili, con cui nessuno in genere si sentirebbe tranquillo di concludere affari, imbonitori di infimo ordine che puntano, per il loro effimero successo commerciale, sui punti esclamativi e sul tasto caps lock. A mio avviso, gli operatori che intendono svolgere seriamente commercio in rete dovrebbero adoperarsi per combattere il malcostume della junk email: sarebbe loro interesse, perché il dilagare dello spam provoca nella gente una diffidenza verso TUTTO il commercio in rete, a lungo andare anche verso quello legittimo e svolto con correttezza. Venendo ai saluti, spero di averLe dato degli elementi di riflessione abbastanza interessanti. Sono certo che non sentirò parlare della Sua azienda su it.news.net-abuse, e Le auguro di avere successo nella espansione di mercato che state iniziando. Per il momento, La saluto cordialmente Leonardo Collinelli 265<br />
<br />
 Indice<br />
<br />
<< Precedente<br />
<br />
Successiva >><br />
<br />
Ultimo aggiornamento: 23 aprile 2000<br />
<br />
Leonardo Collinelli<br />
<br />
266<br />
<br />
 Un'altra grana: le catene a contenuto pietoso-commovente Tentiamo ora di occuparci di un argomento difficile. Si tratta di un problema in cui non abbiamo a che fare con gli spammer, ma con persone di solito in assoluta buona fede. Proprio questo rende la cosa più difficile. Si tratta del fatto che di tanto in tanto si incontra, o in messaggi di email (tipicamente a catena sul modello di quelle di Sant'Antonio) o in post su newsgroup, un tipo di contenuti particolare. È quello che racconta casi umani in cui qualcuno, per esempio perché colpito da qualche disgrazia o malattia, avrebbe urgente bisogno di aiuto. Può darsi si parli di qualcuno che necessiti di un urgente trapianto di midollo, o di un malato terminale che semplicemente abbisogni di umano conforto per i suoi ultimi giorni. Questo tipo di messaggi crea più problemi del normale spam per varie ragioni. Soprattutto perché, toccando in maniera particolare la sensibilità più profonda di ciascuno, induce molte persone, anche persone di sicura correttezza e intelligenza, a pensare che certe cose debbano passare sopra a qualunque convenzione sul corretto comportamento, e che di fronte a casi come quello descritto nessuno possa opporre argomenti validi (tanto meno quello del proprio incomodo). Quanto a coloro che, invece, non approvano la diffusione di questo tipo di catene, è frequente che scelgano di non protestare. Infatti nella società, anche al di là della vita in rete, si manifesta talvolta una sorta di buonismo, spesso pronto a trasformarsi in ferocia verso chi non vuole allinearsi su certe posizioni. Questo porta molti a temere che, protestando per aver ricevuto un simile messaggio, sia assai probabile venire presi a male parole o criticati dai più. Riguardo al tipo di messaggi in questione, ci sono da dire varie cose: ●<br />
<br />
●<br />
<br />
●<br />
<br />
Nella quasi totalità dei casi si tratta di falsi, di vecchie burle che continuano a girare per la rete indefinitamente (non stiamo a dire quanto queste burle siano odiose: gli ignoti ideatori toccano i sentimenti umani più profondi, al fine di farci sopra una grassa risata); In almeno un caso noto, in cui non si trattava di falso, l'effetto è stato negativo (è famoso il caso di un ragazzo ammalato che chiedeva di ricevere cartoline: dopo la sua morte i familiari continuarono per anni a ricevere cartoline, tenendo così inutilmente vivo il dolore); Per cose come la ricerca di donatori di organi o molte altre portate all'evidenza da questi messaggi, non si può certo contare sull'intervento di qualche sconosciuto, che si trova chissà dove, non conosce né il caso né il problema e che presumibilmente ha 267<br />
<br />
 per la testa altre cose e altri problemi. Su queste cose esistono persone competenti, che operano entro organizzazioni specializzate e che, a fronte di necessità, sanno quali canali seguire per cercare aiuto (non certo aprire una catena di Sant'Antonio). Osserveremmo infine alcune altre cose: ●<br />
<br />
●<br />
<br />
●<br />
<br />
Anche ammesso di avere un messaggio importante da divulgare, affidarsi ad una catena in email o comunque indirizzarsi a sconosciuti assomiglia un po' al recarsi sulla carreggiata dell'autostrada per urlare il messaggio ai veicoli che sfrecciano. Si otterrebbe solo di provocare incidenti e farsi travolgere. Volendo fare qualcosa per chi si trova in situazioni dolorose, esiste la strada del volontariato, difficile e di cui pochi sono capaci. Sbagliano coloro che pensano di potersi rendere comunque utili semplicemente cliccando con il mouse dalla loro poltrona ergonomica. Purtroppo capita a tutti di conoscere, direttamente o indirettamente, persone o famiglie a cui siano capitate sventure. Se ogni caso dovesse generare catene o messaggi su newsgroup, è chiaro che si finirebbe col rendere inservibile la rete come mezzo di comunicazione, senza purtuttavia concludere nulla a beneficio di alcuno. Realisticamente bisogna vedere che, mediante una catena di email, raggiungere qualcuno che possa dare aiuto è solo una illusione. Di norma si raggiungeranno solo persone che, nel migliore dei casi, non saranno in grado di far nulla se non, eventualmente, propagare il messaggio ad altre persone altrettanto non competenti e non in grado di intervenire. Se qualcuno, di fronte all'angoscia di chi si trova ad affrontare certi drammi, pensa che nessuno abbia diritto di negare ad altri la speranza, per quanto infinitesima e illusoria essa sia, è chiaramente difficile o impossibile prendersi la responsabilità morale di dargli torto. Si potrà giusto osservare che questa speranza viene riposta in un mezzo di comunicazione (come la posta elettronica o i newsgroup) che non potrebbe più funzionare, per niente e per nessuno, se usato in maniera impropria. Non è questione che la rete non voglia aiutare. È solo che la rete non può dare quel che, fuori di essa, nella cosidetta "vita reale", non si può avere (o si può avere solo con grosse difficoltà).<br />
<br />
Veniamo ora a dare qualche suggerimento (del tutto soggettivo) su come comportarsi quando si riceve uno di questi messaggi. Se vi arriva da uno sconosciuto (che magari ha raccolto da qualche parte il vostro indirizzo di email), va bene chiedere l'intervento del suo postmaster come per normali casi di spam. Che vogliate contattare il mittente personalmente (ammesso che il mittente sia indicato correttamente nel messaggio) è altrettanto ok, posto che non si tratta in questi casi di spammer professionisti ma solo di persone che hanno sbagliato per ignoranza o leggerezza. In questo caso, tuttavia, non ci sono garanzie di avere sempre una reazione sensata: potrebbe capitarvi di trovarvi coinvolti in una discussione dai toni antipatici. Più frequentemente, questo tipo di messaggi può venire da persone conosciute, che hanno il vostro indirizzo nell'address book per il fatto di essere (o essere state) in corrispondenza 268<br />
<br />
 con voi. Costoro hanno evidentemente pensato che un simile messaggio, se non gradito, vi potesse risultare quanto meno accettabile. In questi casi, lasciate perdere i postmaster: trattandosi di un vostro amico o conoscente, la cosa riguarda voi due, quindi è tra voi che ve la dovete vedere. Gli abuse desk non c'entrano niente. Segnalerei, per ragionare più a fondo su questo problema, la pagina http://dep.eco.uniroma1. it/econometria/hoax1.htm, dove l'argomento viene analizzato con notevole acutezza. Passiamo ora a vedere un caso concreto accaduto al sottoscritto. Ecco il messaggio ricevuto: From: [il vero nome e indirizzo di email del mittente] To: [16 nomi e indirizzi di email in chiaro, dei quali uno era mio] ----- Original Message ----From: [un precedente mittente a me sconosciuto] To: [23 nomi e indirizzi di email in chiaro, dei quali uno era la persona che aveva inoltrato a me il messaggio] Subject: I: I: brutto ma vero... ----- Original Message ----From: [altro indirizzo di email] To: [il precedente mittente di cui sopra] Subject: Fwd: I: brutto ma vero... ----- Original Message ----From: [nome] To: [altro nome] Subject: brutto ma vero... Hai mai ascoltato il ticchettio della pioggia? Qualche volta hai seguito il volo di una farfalla? O osservato il tramontare del sole? Fermati. Non ballare in fretta. Il tempo è poco. La musica non durerà a lungo. [....] Qualche volta per mancanza di tatto hai lasciato che un caro amico morisse senza averlo chiamato per dirgli "ciao"? Fermati. Non ballare in fretta. Il tempo è poco. [....] L'unica cosa che vi viene chiesta è solo un po' del vostro tempo, per inviare questo messaggio. C'è solo bisogno di un po' 269<br />
<br />
 d'amore per mandare questa e-mail. Per favore, passate questo messaggio a tutti quelli che conoscete. E' l'ultimo desiderio di una bambina, che presto lascerà questo mondo, dato che è vittima di una terribile malattia: il CANCRO. Grazie per il vostro sforzo. Questa non è una catena, ma una scelta di tutti noi per salvare una piccola vita che si sta spegnendo per una seria e fatale forma di cancro. [....] Per ogni persona che riceverà questa e-mail la Società Americana del Cancro donerà 3 centesimi di dollaro per il trattamento ed il piano di recupero. Una persona ne ha inviate già 500. Aiutatemi. Se potete inviatela a tutte le persone che conoscete. Riflettete e non siate egoisti! Dedicare 5 minuti per inviare questo messaggio è di vitale importanza: tutto questo potrebbe accadere a ciascuno di noi. Ecco ora qualche stralcio della risposta inviata al mittente (che conteneva varie altre considerazioni già presenti in questa pagina): Xxyyzz, che ti prende? Sei stato tu a mandarmi la chain letter riportata qui in fondo? Spero di no, perché propagare queste chain letter è una cosa tutt'altro che intelligente, per parecchie ragioni di cui alcune sono queste: - per ciò che riguarda il contenuto, nella stragrande maggioranza dei casi si tratta di hoax, ossia di falsi, burle che girano anche per anni sulla rete, grazie a quelli che ci credono. In particolare, questo testo (con la Società americana del cancro che darebbe un tot per ogni persona raggiunta da questa email) è un noto hoax. Non solo si tratta di una assurdità evidente, ma risulta anche che la Società in questione abbia ufficialmente dichiarato di non avere nulla a che fare con questa catena (e che quanto scritto nel messaggio al suo riguardo non è assolutamente vero). 270<br />
<br />
 Se vuoi approfondire leggi pure qui: http://www.hoaxkill.com/chainletters.html http://urbanlegends.about.com/science/urbanlegends/library/bljess.htm [....] Vedo anche un altro particolare: hai lasciato tutti i destinatari in chiaro, così con il girare della lettera tutti questi indirizzi finiranno prima o poi, inevitabilmente, nelle mani di qualcuno interessato a spammarli o, peggio ancora, a venderli a chi cerca indirizzi da spammare. [....] Ora ti chiederei (la scelta tuttavia spetta a te) di contattare le altre persone a cui hai inviato il messaggio, spiegandogli che sei caduto in un equivoco e chiedendogli di non propagare a nessuno il messaggio in questione (se questi tuoi conoscenti avessero dei guai con il loro provider, poi avrebbero qualche motivo per prendersela con te). Il destinatario di questa risposta (evidentemente persona intelligente e corretta) mi riscrisse, spiegando che non sapeva di questo genere di fregature e che ci era sempre cascato, rispedendole nella convinzione che potessero essere utili. Disse anche che avrebbe spiegato la cosa ai suoi contatti. Per finire, allegava una divertente parodia delle catene di Sant'Antonio, della quale vale la pena riportare il capoverso iniziale: ** Ti prego, aiutaci a salvare una creatura! :-) ** Evaristo e' un bambino italiano del tutto normale che ha la sfortuna di vivere in un mondo di idioti che scrivono catene di sant'antonio tutto il giorno. Il costo dell'operazione per asportare a Evaristo il 98% del cervello, armonizzandolo con il resto della popolazione e consentendo quindi anche a lui di partecipare alle catene di sant'antonio, e' di lire 195 + iva. [....] ..e la conclusione: Un tizio che conosco non ha diffuso questa mail e ha disimparato a andare in bicicletta. Quindi mi raccomando: spedisci questa mail a tutta la tua list. Se lo fai sarai fortunato, altrimenti vengo a casa tua e ti carico di mazzate. Tuo Sant'Antonio. 271<br />
<br />
 Indice<br />
<br />
<< Precedente<br />
<br />
Successiva >><br />
<br />
Ultimo aggiornamento: 23 marzo 2002<br />
<br />
Leonardo Collinelli<br />
<br />
272<br />
<br />
 Chi sono<br />
<br />
Questa è certamente una pagina del tutto inutile. Tuttavia, se qualcuno è arrivato fin qui mi sembra educato raccontare qualcosa di me. Sono nato nel 1959 a Forlì, nella meravigliosa terra di Romagna, dove vivo tuttora. Mi sono liberato degli studi abbastanza alla svelta, seguendo il liceo Classico e terminando, nel 1984, con la laurea in Ingegneria Elettronica, con lode, presso l'Università degli Studi di Bologna. Per trovare lavoro, fortunatamente, non ho avuto necessità di aspettare: sono entrato quasi subito in IBM, dove sono rimasto circa due anni, lavorando al sistema informativo interno. Poi sono passato a Gruppo Formula, azienda certo molto meno grande, specialmente quando vi entrai, ma con una reputazione sul mercato assai solida (e mantenutasi negli anni) riguardo alla qualità dei prodotti e servizi forniti. Lì mi trovo tuttora. In fatto di tecnologie ho avuto occasione di vedere un po' di tutto. Dalle schede pazientemente perforate quando ero studente, ai grandi mainframe IBM con sistema operativo MVS e rete SNA (quanto di più diverso da Internet si possa immaginare). Ho poi avuto occasione di lavorare per alcuni anni nell'area degli strumenti di sviluppo per architetture client/server, principalmente tenendo corsi che mi portavano, di settimana in settimana, nelle più disparate città italiane (cosa che tutto sommato mi va bene, perché troverei opprimente passare tutte le giornate in un ufficio). Ho pure avuto occasione di occuparmi di prodotti per help-desk e di CRM (ossia i software per supportare le attività di vendita e, più in generale, i contatti di una azienda con i suoi clienti). Qualcosa mi dice che ne vedrò ancora di tutti i colori. Quando non sono in giro, oltre ad accendere il modem mi piace fare varie altre cose: ●<br />
<br />
ascoltare musica classica la mia musica preferita è quella della prima metà del settecento, con forte curiosità verso il seicento ed i periodi precedenti. Ciò non mi ha impedito, comunque, di apprezzare oltre ogni misura il Requiem di Fauré. Se capitate sui Classical Midi Archives o sulla Classical Midi Connection trovate qualche brano in formato MIDI, sequenzializzato da me (musica clavicembalistica e organistica di Bach, di Rameau e di Zipoli, musica per altri strumenti per ora solo di Spohr). 273<br />
<br />
 ●<br />
<br />
●<br />
<br />
leggere compro più libri di quanti mi riesca di leggere (ma non sono sicuro che ciò deponga a mio sfavore). ogni tanto, fare qualche camminata nell'entroterra forlivese mi considero fortunato ad abitare a poca distanza dal Parco delle Foreste Casentinesi. Inoltre, a soli 30 chilometri da casa mia ci sono le spiagge di Cesenatico e Cervia (cosa che d'estate fa comodo, anche se le mie preferenze in fatto di vacanza sono più per la montagna che per il mare).<br />
<br />
Leonardo Collinelli<br />
<br />
Ultimo aggiornamento: 01 novembre 2001<br />
<br />
274<br />
<br />
 Ricerca nel sito<br />
<br />
Tutte le parole Cerca<br />
<br />
Reset<br />
<br />
Indicare le parole da cercare separate da spazio. Se si indicano tutte minuscole la ricerca sarà indifferente a maiuscole e minuscole (con anche una sola maiuscola la ricerca diventerà sensibile a maiuscole/minuscole). Per cercare stringhe contenenti spazi indicarle tra doppi apici (es.: "abuse net"). Per cercare parole di cui si intenda specificare solo i primi caratteri, usare l'asterisco (es.: spam trova solo la parola spam, spam* trova sia spam che spammer che spamware ecc..). Nota finale: questa funzione, dipendentemente dal carico del server, può non essere velocissima.<br />
<br />
Indice Ultimo aggiornamento: 03 gennaio 1999<br />
<br />
Leonardo Collinelli<br />
<br />
275<br />
<br />
 					    </div>
		</div>
            </div>
	        	    <div class="row hidden-xs">
    		<div class="col-md-12">
    		    <h2></h2>
    		    <hr />
    		</div>
		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/comunismo-italiano.html">
		<img src="https://epdf.tips/img/300x300/comunismo-italiano_5b2cf44eb7d7bc4933a3b2c1.jpg" alt="Comunismo [italiano]" />
		<h3 class="note-title">Comunismo [italiano]</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/comunismo-italiano.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/it-italiano-pdf-5eccd93400038.html">
		<img src="https://epdf.tips/img/300x300/it-italiano_5eccd934097c47770a8b5878.jpg" alt="It (Italiano)" />
		<h3 class="note-title">It (Italiano)</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/it-italiano-pdf-5eccd93400038.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/vocabolario-italiano-tigrai-e-tigrai-italiano.html">
		<img src="https://epdf.tips/img/300x300/vocabolario-italiano-tigrai-e-tigrai-italiano_5b2cf86eb7d7bc46333a3e39.jpg" alt="Vocabolario Italiano-Tigrai e Tigrai-Italiano" />
		<h3 class="note-title">Vocabolario Italiano-Tigrai e Tigrai-Italiano</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/vocabolario-italiano-tigrai-e-tigrai-italiano.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/james-sacra-pagina-series.html">
		<img src="https://epdf.tips/img/300x300/james-sacra-pagina-series_5acec16db7d7bc0d07fc9bf5.jpg" alt="James (Sacra Pagina Series)" />
		<h3 class="note-title">James (Sacra Pagina Series)</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/james-sacra-pagina-series.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/it-italiano.html">
		<img src="https://epdf.tips/img/300x300/it-italiano_5b2cf83cb7d7bc46333a3e38.jpg" alt="It (Italiano)" />
		<h3 class="note-title">It (Italiano)</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/it-italiano.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/nero-italiano.html">
		<img src="https://epdf.tips/img/300x300/nero-italiano_5b2cf44ab7d7bc4933a3b2c0.jpg" alt="Nero Italiano" />
		<h3 class="note-title">Nero Italiano</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/nero-italiano.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/first-corinthians-sacra-pagina-series.html">
		<img src="https://epdf.tips/img/300x300/first-corinthians-sacra-pagina-series_5ab5c41ab7d7bcdc1f228cb8.jpg" alt="First Corinthians (Sacra Pagina Series)" />
		<h3 class="note-title">First Corinthians (Sacra Pagina Series)</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/first-corinthians-sacra-pagina-series.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/fueddariu-sardu-campidanesu-italiano-5ea8085e56f46.html">
		<img src="https://epdf.tips/img/300x300/fueddariu-sardu-campidanesu-italiano_5ea8085e097c4749648b4e9a.jpg" alt="Fueddariu sardu campidanesu-italiano" />
		<h3 class="note-title">Fueddariu sardu campidanesu-italiano</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/fueddariu-sardu-campidanesu-italiano-5ea8085e56f46.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/il-neoparmenidismo-italiano.html">
		<img src="https://epdf.tips/img/300x300/il-neoparmenidismo-italiano_5b2cf42db7d7bc4933a3b2be.jpg" alt="Il Neoparmenidismo Italiano" />
		<h3 class="note-title">Il Neoparmenidismo Italiano</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/il-neoparmenidismo-italiano.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/diccionario-italiano-galego-5ea7b38f0d932.html">
		<img src="https://epdf.tips/img/300x300/diccionario-italiano-galego_5ea7b38f097c47d2248b572c.jpg" alt="Diccionario italiano-galego" />
		<h3 class="note-title">Diccionario italiano-galego</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/diccionario-italiano-galego-5ea7b38f0d932.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/italiano-per-economisti.html">
		<img src="https://epdf.tips/img/300x300/italiano-per-economisti_5b2cf532b7d7bc4933a3b2c3.jpg" alt="Italiano per economisti" />
		<h3 class="note-title">Italiano per economisti</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/italiano-per-economisti.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/diccionario-italiano-galego.html">
		<img src="https://epdf.tips/img/300x300/diccionario-italiano-galego_5b641dffb7d7bca9778e7359.jpg" alt="Diccionario italiano-galego" />
		<h3 class="note-title">Diccionario italiano-galego</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/diccionario-italiano-galego.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/el-renacimiento-italiano.html">
		<img src="https://epdf.tips/img/300x300/el-renacimiento-italiano_5b2cf534b7d7bc46333a3e34.jpg" alt="El Renacimiento italiano" />
		<h3 class="note-title">El Renacimiento italiano</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/el-renacimiento-italiano.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/fueddariu-sardu-campidanesu-italiano.html">
		<img src="https://epdf.tips/img/300x300/fueddariu-sardu-campidanesu-italiano_5b2cf812b7d7bc46333a3e37.jpg" alt="Fueddariu sardu campidanesu-italiano" />
		<h3 class="note-title">Fueddariu sardu campidanesu-italiano</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/fueddariu-sardu-campidanesu-italiano.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/parliaments-as-peacebuilders-in-conflict-affected-countries-pagina-252.html">
		<img src="https://epdf.tips/img/300x300/parliaments-as-peacebuilders-in-conflict-affected-_5ac956eeb7d7bc5834514392.jpg" alt="Parliaments as peacebuilders in conflict-affected countries, Pagina 252" />
		<h3 class="note-title">Parliaments as peacebuilders in conflict-affected countries, Pagina 252</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/parliaments-as-peacebuilders-in-conflict-affected-countries-pagina-252.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/pasta-per-due-italiano-facile.html">
		<img src="https://epdf.tips/img/300x300/pasta-per-due-italiano-facile_5b2cf7c7b7d7bc4933a3b2c7.jpg" alt="Pasta Per Due (Italiano Facile)" />
		<h3 class="note-title">Pasta Per Due (Italiano Facile)</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/pasta-per-due-italiano-facile.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/evangelio-de-bernabe-frag-italiano.html">
		<img src="https://epdf.tips/img/300x300/evangelio-de-bernabe-frag-italiano_5b2cf451b7d7bc4933a3b2c2.jpg" alt="Evangelio De Bernabe (frag Italiano)" />
		<h3 class="note-title">Evangelio De Bernabe (frag Italiano)</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/evangelio-de-bernabe-frag-italiano.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/ambiguita-tra-italiano-e-inglese.html">
		<img src="https://epdf.tips/img/300x300/ambiguita-tra-italiano-e-inglese_5b847deab7d7bce87fd8de62.jpg" alt="Ambiguitá tra italiano e inglese" />
		<h3 class="note-title">Ambiguitá tra italiano e inglese</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/ambiguita-tra-italiano-e-inglese.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/espresso-3-corso-di-italiano.html">
		<img src="https://epdf.tips/img/300x300/espresso-3-corso-di-italiano_5b85ece8b7d7bcd361b27cd5.jpg" alt="Espresso 3: Corso di Italiano" />
		<h3 class="note-title">Espresso 3: Corso di Italiano</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/espresso-3-corso-di-italiano.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/un-amico-italiano-eat-pray-love-in-rome.html">
		<img src="https://epdf.tips/img/300x300/un-amico-italiano-eat-pray-love-in-rome_5b3fbb55b7d7bc0207ba6a90.jpg" alt="Un Amico Italiano- Eat, Pray, Love in Rome" />
		<h3 class="note-title">Un Amico Italiano- Eat, Pray, Love in Rome</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/un-amico-italiano-eat-pray-love-in-rome.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/il-nazionalismo-italiano-biblioteca-universale-laterza.html">
		<img src="https://epdf.tips/img/300x300/il-nazionalismo-italiano-biblioteca-universale-lat_5b6218f1b7d7bccc469b3912.jpg" alt="Il nazionalismo Italiano (Biblioteca universale Laterza)" />
		<h3 class="note-title">Il nazionalismo Italiano (Biblioteca universale Laterza)</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/il-nazionalismo-italiano-biblioteca-universale-laterza.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/i-tre-tiranni-archivio-del-teatro-italiano.html">
		<img src="https://epdf.tips/img/300x300/i-tre-tiranni-archivio-del-teatro-italiano_5b7c9fcbb7d7bcfb102b51da.jpg" alt="I tre tiranni (Archivio del teatro italiano)" />
		<h3 class="note-title">I tre tiranni (Archivio del teatro italiano)</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/i-tre-tiranni-archivio-del-teatro-italiano.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/un-amico-italiano-eat-pray-love-in-rome-5ea7aeb86bce7.html">
		<img src="https://epdf.tips/img/300x300/un-amico-italiano-eat-pray-love-in-rome_5ea7aeb8097c47d2248b5420.jpg" alt="Un Amico Italiano- Eat, Pray, Love in Rome" />
		<h3 class="note-title">Un Amico Italiano- Eat, Pray, Love in Rome</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/un-amico-italiano-eat-pray-love-in-rome-5ea7aeb86bce7.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/ponti-italiano-terzo-millennio-intermediate-italian.html">
		<img src="https://epdf.tips/img/300x300/ponti-italiano-terzo-millennio-intermediate-italia_5b2cf632b7d7bc46333a3e35.jpg" alt="Ponti: Italiano Terzo Millennio: Intermediate Italian" />
		<h3 class="note-title">Ponti: Italiano Terzo Millennio: Intermediate Italian</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/ponti-italiano-terzo-millennio-intermediate-italian.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/racconto-italiano-di-ignoto-del-novecento.html">
		<img src="https://epdf.tips/img/300x300/racconto-italiano-di-ignoto-del-novecento_5b2cf545b7d7bc4933a3b2c4.jpg" alt="Racconto italiano di ignoto del novecento" />
		<h3 class="note-title">Racconto italiano di ignoto del novecento</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/racconto-italiano-di-ignoto-del-novecento.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/nuovo-progetto-italiano-vol1-dieci-racconti.html">
		<img src="https://epdf.tips/img/300x300/nuovo-progetto-italiano-vol1-dieci-racconti_5b2cf92bb7d7bc4933a3b2c8.jpg" alt="Nuovo Progetto italiano, Vol.1 : Dieci Racconti" />
		<h3 class="note-title">Nuovo Progetto italiano, Vol.1 : Dieci Racconti</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/nuovo-progetto-italiano-vol1-dieci-racconti.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/magyar-olasz-kisszotar-dizionario-ungherese-italiano.html">
		<img src="https://epdf.tips/img/300x300/magyar-olasz-kisszotar-dizionario-ungherese-italia_5b2cf8a9b7d7bc46333a3e3a.jpg" alt="Magyar-olasz kisszotar   Dizionario Ungherese-Italiano" />
		<h3 class="note-title">Magyar-olasz kisszotar   Dizionario Ungherese-Italiano</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/magyar-olasz-kisszotar-dizionario-ungherese-italiano.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/parliamo-italiano-a-communicative-approach-fourth-edition.html">
		<img src="https://epdf.tips/img/300x300/parliamo-italiano-a-communicative-approach-fourth-_5b2cf632b7d7bc4833491f50.jpg" alt="Parliamo Italiano: A Communicative Approach, Fourth Edition" />
		<h3 class="note-title">Parliamo Italiano: A Communicative Approach, Fourth Edition</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/parliamo-italiano-a-communicative-approach-fourth-edition.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/poor-peoples-knowledge-promoting-intellectual-property-in-developing-countries-p.html">
		<img src="https://epdf.tips/img/300x300/poor-peoples-knowledge-promoting-intellectual-prop_5af7b978b7d7bc0e2cada5dd.jpg" alt="Poor people's knowledge: promoting intellectual property in developing countries, Pagina 823" />
		<h3 class="note-title">Poor people's knowledge: promoting intellectual property in developing countries, Pagina 823</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/poor-peoples-knowledge-promoting-intellectual-property-in-developing-countries-p.html">Read more</a>
	</div>
    </div>
</div>		    			<div class="col-lg-2 col-md-3">
    <div class="note">
	<div class="note-meta-thumb">	
	    <a href="https://epdf.tips/-dizionario-fraseologico-italiano-russo.html">
		<img src="https://epdf.tips/img/300x300/-dizionario-fraseologico-italiano-russo_5b2cf7dab7d7bc46333a3e36.jpg" alt="Итальянско-русский фразеологический словарь - Dizionario Fraseologico Italiano-Russo" />
		<h3 class="note-title">Итальянско-русский фразеологический словарь - Dizionario Fraseologico Italiano-Russo</h3>
	    </a>
	</div>
	<div class="note-action">
	    <a class="more-link" href="https://epdf.tips/-dizionario-fraseologico-italiano-russo.html">Read more</a>
	</div>
    </div>
</div>		        	    </div> 
	            </div>
	<div class="col-lg-3 col-md-4 col-xs-12">
            <div class="panel-recommend panel panel-primary">
                <div class="panel-heading">
                    <h4 class="panel-title">Recommend Documents</h4>
                </div>
		<div class="panel-body">
		    						    <div class="row m-0">
    <div class="col-md-3 col-xs-3 pl-0 text-center">
	<a href="https://epdf.tips/comunismo-italiano.html">
	    <img src="https://epdf.tips/img/60x80/comunismo-italiano_5b2cf44eb7d7bc4933a3b2c1.jpg" alt="" width="100%" />
	</a>
    </div>
    <div class="col-md-9 col-xs-9 p-0">
	<label>
	    <a href="https://epdf.tips/comunismo-italiano.html">
		Comunismo [italiano]	    </a>
	</label>
	<div class="note-meta">
	    <div class="note-desc"></div>
	</div>
    </div>
    <div class="clearfix"></div>
    <hr class="mt-15 mb-15" />
</div>						    <div class="row m-0">
    <div class="col-md-3 col-xs-3 pl-0 text-center">
	<a href="https://epdf.tips/it-italiano-pdf-5eccd93400038.html">
	    <img src="https://epdf.tips/img/60x80/it-italiano_5eccd934097c47770a8b5878.jpg" alt="" width="100%" />
	</a>
    </div>
    <div class="col-md-9 col-xs-9 p-0">
	<label>
	    <a href="https://epdf.tips/it-italiano-pdf-5eccd93400038.html">
		It (Italiano)	    </a>
	</label>
	<div class="note-meta">
	    <div class="note-desc">Generated by ABC Amber LIT Converter, http://www.processtext.com/abclit.html

STEPHEN KING IT (It, 1986)

Dedico questo ...</div>
	</div>
    </div>
    <div class="clearfix"></div>
    <hr class="mt-15 mb-15" />
</div>						    <div class="row m-0">
    <div class="col-md-3 col-xs-3 pl-0 text-center">
	<a href="https://epdf.tips/vocabolario-italiano-tigrai-e-tigrai-italiano.html">
	    <img src="https://epdf.tips/img/60x80/vocabolario-italiano-tigrai-e-tigrai-italiano_5b2cf86eb7d7bc46333a3e39.jpg" alt="" width="100%" />
	</a>
    </div>
    <div class="col-md-9 col-xs-9 p-0">
	<label>
	    <a href="https://epdf.tips/vocabolario-italiano-tigrai-e-tigrai-italiano.html">
		Vocabolario Italiano-Tigrai e Tigrai-Italiano	    </a>
	</label>
	<div class="note-meta">
	    <div class="note-desc">A propos de ce livre Ceci est une copie numérique d’un ouvrage conservé depuis des générations dans les rayonnages d’une...</div>
	</div>
    </div>
    <div class="clearfix"></div>
    <hr class="mt-15 mb-15" />
</div>						    <div class="row m-0">
    <div class="col-md-3 col-xs-3 pl-0 text-center">
	<a href="https://epdf.tips/james-sacra-pagina-series.html">
	    <img src="https://epdf.tips/img/60x80/james-sacra-pagina-series_5acec16db7d7bc0d07fc9bf5.jpg" alt="" width="100%" />
	</a>
    </div>
    <div class="col-md-9 col-xs-9 p-0">
	<label>
	    <a href="https://epdf.tips/james-sacra-pagina-series.html">
		James (Sacra Pagina Series)	    </a>
	</label>
	<div class="note-meta">
	    <div class="note-desc">SAC

U.S. $39.95

James Patrick 1. Hartin The letter of James is one of the most neglected writings of the New Testamen...</div>
	</div>
    </div>
    <div class="clearfix"></div>
    <hr class="mt-15 mb-15" />
</div>						    <div class="row m-0">
    <div class="col-md-3 col-xs-3 pl-0 text-center">
	<a href="https://epdf.tips/it-italiano.html">
	    <img src="https://epdf.tips/img/60x80/it-italiano_5b2cf83cb7d7bc46333a3e38.jpg" alt="" width="100%" />
	</a>
    </div>
    <div class="col-md-9 col-xs-9 p-0">
	<label>
	    <a href="https://epdf.tips/it-italiano.html">
		It (Italiano)	    </a>
	</label>
	<div class="note-meta">
	    <div class="note-desc">Generated by ABC Amber LIT Converter, http://www.processtext.com/abclit.html

STEPHEN KING IT (It, 1986)

Dedico questo ...</div>
	</div>
    </div>
    <div class="clearfix"></div>
    <hr class="mt-15 mb-15" />
</div>						    <div class="row m-0">
    <div class="col-md-3 col-xs-3 pl-0 text-center">
	<a href="https://epdf.tips/nero-italiano.html">
	    <img src="https://epdf.tips/img/60x80/nero-italiano_5b2cf44ab7d7bc4933a3b2c0.jpg" alt="" width="100%" />
	</a>
    </div>
    <div class="col-md-9 col-xs-9 p-0">
	<label>
	    <a href="https://epdf.tips/nero-italiano.html">
		Nero Italiano	    </a>
	</label>
	<div class="note-meta">
	    <div class="note-desc">Giampietro Stocco Nero italiano (2003) NOTA: Quest'opera è frutto integrale di fantasia. Ogni riferimento a persone real...</div>
	</div>
    </div>
    <div class="clearfix"></div>
    <hr class="mt-15 mb-15" />
</div>						    <div class="row m-0">
    <div class="col-md-3 col-xs-3 pl-0 text-center">
	<a href="https://epdf.tips/first-corinthians-sacra-pagina-series.html">
	    <img src="https://epdf.tips/img/60x80/first-corinthians-sacra-pagina-series_5ab5c41ab7d7bcdc1f228cb8.jpg" alt="" width="100%" />
	</a>
    </div>
    <div class="col-md-9 col-xs-9 p-0">
	<label>
	    <a href="https://epdf.tips/first-corinthians-sacra-pagina-series.html">
		First Corinthians (Sacra Pagina Series)	    </a>
	</label>
	<div class="note-meta">
	    <div class="note-desc">FIRST CORINTHIANS

Sacra Pagina Series Volume 7

First Corinthians Raymond R Collins

Daniel J. Harrington, s.j. Edito...</div>
	</div>
    </div>
    <div class="clearfix"></div>
    <hr class="mt-15 mb-15" />
</div>						    <div class="row m-0">
    <div class="col-md-3 col-xs-3 pl-0 text-center">
	<a href="https://epdf.tips/fueddariu-sardu-campidanesu-italiano-5ea8085e56f46.html">
	    <img src="https://epdf.tips/img/60x80/fueddariu-sardu-campidanesu-italiano_5ea8085e097c4749648b4e9a.jpg" alt="" width="100%" />
	</a>
    </div>
    <div class="col-md-9 col-xs-9 p-0">
	<label>
	    <a href="https://epdf.tips/fueddariu-sardu-campidanesu-italiano-5ea8085e56f46.html">
		Fueddariu sardu campidanesu-italiano	    </a>
	</label>
	<div class="note-meta">
	    <div class="note-desc">A Mamai A Babbai A Gratziella A Elisabeta

© Domus de Janas Giovanni Melis: Fueddariu Sardu Campidanesu - Italianu ISB...</div>
	</div>
    </div>
    <div class="clearfix"></div>
    <hr class="mt-15 mb-15" />
</div>						    <div class="row m-0">
    <div class="col-md-3 col-xs-3 pl-0 text-center">
	<a href="https://epdf.tips/il-neoparmenidismo-italiano.html">
	    <img src="https://epdf.tips/img/60x80/il-neoparmenidismo-italiano_5b2cf42db7d7bc4933a3b2be.jpg" alt="" width="100%" />
	</a>
    </div>
    <div class="col-md-9 col-xs-9 p-0">
	<label>
	    <a href="https://epdf.tips/il-neoparmenidismo-italiano.html">
		Il Neoparmenidismo Italiano	    </a>
	</label>
	<div class="note-meta">
	    <div class="note-desc"></div>
	</div>
    </div>
    <div class="clearfix"></div>
    <hr class="mt-15 mb-15" />
</div>						    <div class="row m-0">
    <div class="col-md-3 col-xs-3 pl-0 text-center">
	<a href="https://epdf.tips/diccionario-italiano-galego-5ea7b38f0d932.html">
	    <img src="https://epdf.tips/img/60x80/diccionario-italiano-galego_5ea7b38f097c47d2248b572c.jpg" alt="" width="100%" />
	</a>
    </div>
    <div class="col-md-9 col-xs-9 p-0">
	<label>
	    <a href="https://epdf.tips/diccionario-italiano-galego-5ea7b38f0d932.html">
		Diccionario italiano-galego	    </a>
	</label>
	<div class="note-meta">
	    <div class="note-desc">DICCIONARIO ITALIANO - GALEGO

Edita: XUNTA DE GALICIA CONSELLERÍA DE EDUCACIÓN E ORDENACIÓN UNIVERSITARIA CE...</div>
	</div>
    </div>
    <div class="clearfix"></div>
    <hr class="mt-15 mb-15" />
</div>					    		</div>
            </div>
        </div>

</div>
</div>

<div class="modal fade" id="report" tabindex="-1" role="dialog" aria-hidden="true">
    <div class="modal-dialog">
	<div class="modal-content">
	    <form role="form" method="post" action="https://epdf.tips/report/pagina-antispam-in-italiano" style="border: none;">
		<div class="modal-header">
		    <button type="button" class="close" data-dismiss="modal" aria-hidden="true">×</button>
		    <h4 class="modal-title">Report "Pagina Antispam In Italiano"</h4>
		</div>
		<div class="modal-body">
		    <div class="form-group">
			<label>Your name</label>
			<input type="text" name="name" required="required" class="form-control" />
		    </div>
		    <div class="form-group">
			<label>Email</label>
			<input type="email" name="email" required="required" class="form-control" />
		    </div>
		    <div class="form-group">
			<label>Reason</label>
			<select name="reason" required="required" class="form-control">
			    <option value="">-Select Reason-</option>
			    <option value="pornographic" selected="selected">Pornographic</option>
			    <option value="defamatory">Defamatory</option>
			    <option value="illegal">Illegal/Unlawful</option>
			    <option value="spam">Spam</option>
			    <option value="others">Other Terms Of Service Violation</option>
			    <option value="copyright">File a copyright complaint</option>
			</select>
		    </div>
		    <div class="form-group">
			<label>Description</label>
			<textarea name="description" required="required" rows="3" class="form-control" style="border: 1px solid #cccccc;">

Our partners will collect data and use cookies for ad personalization and measurement. Learn how we and our ad partner Google, collect and use data. Agree & close