Negli scorsi giorni si sono celebrati i compleanni di Giulia G. (29 settembre) e di Daniele (4 ottobre).
Invece di inviare il solito tradizionale messaggio di auguri o un banale SMS ho pensato di giocare ai loro danni un perfido tiro mancino inviando un’e-mail da parte del Berluska (e nel caso di Dani, anche una da parte di Water Vertroni). Devo dire che Giulia se n’è ammascata subito… fatto sta che dai messaggi era impossibile risalire direttamente al mittente. A patto, appunto, di non avere confidenza con la mia nota favaggine… ma solo attraverso astute supposizioni e con l’aiuto d’ineffabile intuito femminile.

Con il diffondersi dello Spam e del Phishing è ormai noto a gran parte dell’utenza di Internet, anche a coloro che hanno meno dimestichezza con il mezzo informatico, che la veridicità del mittente è assolutamente non attendibile.

Ho inviato e-mail a Giulia e Dani aventi come mittente silvio.berlusconi@forza-italia.it e walter.veltroni@lanuovastagione.it il cui contenuto palesemente fasullo e scherzoso ritengo mi ponga al riparo dall’aver commesso reati telematici.
- Ma come è possibile spedire mail in nome e per conto di altri? - qualcuno potrebbe legittimamente chiedere… e in effetti è una cosa talmente semplice, eppure spesso trovo chi si stupisce di tale semplicità.
Teoricamente è sufficiente configurare il proprio programma di posta elettronica con il falso mittente e il gioco è fatto. Questo metodo è, in linea di massima, non applicabile per tutti coloro che utilizzano sistemi di webmail.
Nel caso specifico, non ho modificato impostazioni del mio programma, ma ho parlato direttamente col server SMTP. La qual cosa può risultare particolarmente utile anche in caso di debug… Spammer e phishers utilizzano programmi o script dedicati, ma il sistema è analogo: si tratta solo di inviare al server incaricato della consegna della posta elettronica, e solitamente fornito dal proprio provider, la richiesta di spedire il messaggio con le prerogative desiderate (mittente, destinatario, soggetto e contenuto). Ovvero esattamente ciò che fa un programma di posta elettronica quando invia un messaggio.

La pagina italiana della Wikipedia a proposito del protocollo SMTP è molto semplice e piuttosto esaustiva al riguardo.

Senza entrare nel dettaglio di concetti come protocollo TCP, porta e quant’altro… vediamo un po’ come funziona. Gli unici concetti di cui non si può proprio fare a meno sono quelli di client (ovvero, il sistema che vuole mandare il messaggio di posta) e server (il sistema che è designato a occuparsi della consegna).
Digitando il comando

dal prompt dei comandi di Windows, o da Avvio » Esegui, si stabilisce quella che viene chiamata una connessione con il server di posta elettronica, in questo caso, di Tiscali.
C’è da dire che il client telnet di Windows non è molto adatto a questo tipo di utilizzo, dato che non consente l’uso del tasto backspace per cancellare i caratteri sulla riga, o, meglio, invia direttamente al server anche il carattere backspace (^H) e non ci si possono quindi permettere errori di battitura nel caso di una sessione interattiva, a patto di non essere disposti a ridigitare tutta la riga.
Comunque, dopo aver stabilito una connessione, ecco una tipica sessione SMTP (ovvero un dialogo tra client e server, in cui le scritte in rosso sono inviate dal server verso il client, e viceversa per quelle in verde; queste ultime sono cioè quelle che possono essere scritte manualmente tramite il programma telnet):

Alla riga 1, il server, dopo aver accettato la connessione, manda il suo messaggio di benvenuto.
Al quale il cliente risponde, obbligatoriamente, con il messaggio EHLO (alla riga 2). Nella versione più semplice e antica del protocollo il messaggio è semplicemente HELO (ciao) e il client può inviarlo qualora si trovi a dialogare con un server che non supporta il comando EHLO. La parola “pippo” dopo il comando dovrebbe essere sostituita da qualcosa di più significativo e serve a identificare il client agli occhi del server.
Nelle righe da 3 a 9 il server risponde al comando EHLO elencando le estensioni supportate del protocollo SMTP, ovvero una serie di possibilità e di caratteristiche del protocollo SMTP implementate da quello specifico server con cui il client sta parlando.
A questo punto, a riga 10, comincia la sessione vera e propria: il client invia un comando MAIL FROM seguito da un indirizzo di posta elettronica. Sta qualificando l’indirizzo di posta elettronica del mittente. In questa sessione di esempio è stato commesso un errore, dato che l’indirizzo specificato non è un indirizzo valido, e infatti il server alla riga 11 dice proprio che c’è un errore nei parametri che seguono il comando MAIL FROM.
Alla riga 12 il client ci riprova, e stavolta con successo, tant’è che, a riga 14 invia il comando RCPT TO, specificando come destinatario il mio account di posta elettronica Gmail.
A riga 15 per il server va tutto bene, ed ecco quindi che si procede con il comando DATA (riga 16), ovvero, diciamo al server che a questo punto vogliamo mandare il vero e proprio messaggio di posta elettronica.
A riga 17 il server ci informa che dobbiamo terminare il nostro messaggio con un “.” (un punto) su una riga.
Nelle righe da 18 a 22 il client specifica il messaggio di posta, e a riga 23 lo chiude con il “.”.
Riga 24: il server ci dice che ha accettato il nostro messaggio e…
Riga 25: saluti e fine della storia.

Si noti come è composto il messaggio di posta elettronica vero e e proprio. Ha una parte iniziale, detta instestazione (righe 18-20), formata da campi che hanno un nome (From, To, Subject) e un valore (Ciccio Bello <silvio.berlusconi@forza-italia.com>, Gianni <gianni@pinotto.it>, Saluti) separati da “:” e spazio. La riga 21 è vuota e separa le instestazioni dal corpo del messaggio, che, in questo caso, sta tutto in una riga (22).
Nell’intestazione il campo “To” ha come valore Gianni <gianni@pinotto.it> che non ha niente a che vedere con il vero destinatario del messaggio. Quest’ultimo si vedrà quindi recapitare un messaggio che apparentemente non è destinato a lui, ma che è comunque finito nella sua casella. In altre parole, il server cercherà di consegnare il messaggio a tutti i destinatari specificati dai comandi RCPT TO, ma questo non significa che all’interno del messaggio stesso i destinatari debbano essere gli stessi. Questo è il meccanismo su cui si basano le Bcc (Blind Carbon Copy) o Ccn (Copia carbone nascosta) per cui è possibile inviare messaggi di posta elettronica senza che chi li riceve possa essere a conoscenza di altri eventuali destinatari.

To be continued…

Questo articolo è stato inserito Domenica 14 Ottobre 2007 @ 02:14 ed è archiviato in Digital life. Puoi seguire i commenti a questo articolo attraverso il feed RSS 2.0. Commenti e trackback non sono consentiti.