Lezioni sulla lettura degli header

Fondamenti



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 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à.

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@prima-rete-esempio.com (Mario Rossi)
To: fverdi@seconda-rete-esempio.com
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

In questo esempio è importante osservare che, prima del testo del messaggio vero e proprio, si hanno alcune righe scritte nella forma:

      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 e-mail 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.

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.

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.

220 mail.prima-rete-esempio.com ESMTP server (Post.Office v3.1.2 release (PO203-101c)...) ready Wed, 15 Apr 1998 14:26:31 +0200
HELO mariorossi
250 mail.prima-rete-esempio.com
MAIL FROM:<mrossi@prima-rete-esempio.com>
250 Sender <mrossi@prima-rete-esempio.com> Ok
RCPT TO:<fverdi@seconda-rete-esempio.com>
250 Recipient <fverdi@seconda-rete-esempio.com> Ok
DATA
354 Ok Send data ending with <CRLF>.<CRLF>
From: mrossi@prima-rete-esempio.com (Mario Rossi)
To: fverdi@seconda-rete-esempio.com
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.prima-rete-esempio.com
QUIT
221 mail.prima-rete-esempio.com 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.

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/.

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.prima-rete-esempio.com [194.188.15.26])
         by mail.prima-rete-esempio.com (8.8.5/8.8.5) with SMTP id RU387493
         for <fverdi@seconda-rete-esempio.com>; Wed, 15 Apr 1998 14:26:32 +0200 (METDST)
From: mario.rossi@prima-rete-esempio.com (Mario Rossi)
To: fverdi@seconda-rete-esempio.com
Date: Wed, 15 Apr 1998 14:24:06 +0200
Message-ID: <3754F6E5.BA67D052@prima-rete-esempio.com>
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:

Received: from mariorossi (ppp26-milano.prima-rete-esempio.com [194.188.15.26])
         by mail.prima-rete-esempio.com (8.8.5/8.8.5) with SMTP id RU387493
         for <fverdi@seconda-rete-esempio.com>; 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.prima-rete-esempio.com, 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.prima-rete-esempio.com"
(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 è 'seconda-rete-esempio.com' 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.seconda-rete-esempio.com. Ecco allora un altro passaggio, al termine del quale il nostro messaggio sarà diventato così:

Received: from prima-rete-esempio.com (mail.prima-rete-esempio.com [194.184.145.216])
         by plutus.seconda-rete-esempio.com (8.8.5/8.8.5) with SMTP id GC502624
         for <fverdi@seconda-rete-esempio.com>; Wed, 15 Apr 1998 14:27:15 +0200 (METDST)
Received: from mariorossi (ppp26-milano.prima-rete-esempio.com [194.188.15.26])
         by mail.prima-rete-esempio.com (8.8.5/8.8.5) with SMTP id RU387493
         for <fverdi@seconda-rete-esempio.com>; Wed, 15 Apr 1998 14:26:32 +0200 (METDST)
From: mario.rossi@prima-rete-esempio.com (Mario Rossi)
To: fverdi@seconda-rete-esempio.com
Date: Wed, 15 Apr 1998 14:24:06 +0200
Message-ID: <3754F6E5.BA67D052@prima-rete-esempio.com>
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.seconda-rete-esempio.com [202.113.12.45])
         by mbox-b.seconda-rete-esempio.com (8.8.3/8.7.5) with SMTP id WH755911
         for <fverdi@seconda-rete-esempio.com>; Wed, 15 Apr 1998 14:27:18 +0200 (METDST)
Received: from prima-rete-esempio.com (mail.prima-rete-esempio.com [194.184.145.216])
         by plutus.seconda-rete-esempio.com (8.8.5/8.8.5) with SMTP id GC502624
         for <fverdi@seconda-rete-esempio.com>; Wed, 15 Apr 1998 14:27:15 +0200 (METDST)
Received: from mariorossi (ppp26-milano.prima-rete-esempio.com [194.188.15.26])
         by mail.prima-rete-esempio.com (8.8.5/8.8.5) with SMTP id RU387493
         for <fverdi@seconda-rete-esempio.com>; Wed, 15 Apr 1998 14:26:32 +0200 (METDST)
From: mario.rossi@prima-rete-esempio.com (Mario Rossi)
To: fverdi@seconda-rete-esempio.com
Date: Wed, 15 Apr 1998 14:24:06 +0200
Message-ID: <3754F6E5.BA67D052@prima-rete-esempio.com>
X-Mailer: Gorilla 3.2 (Win95; I)
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 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.


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 è 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.


Indice    << Precedente    Successiva >>

Ultimo aggiornamento: 05 gennaio 2004

Leonardo Collinelli

e-mail