<- SL: Backup - Copertina - La documentazione libera si fa in tre ->

Sistemi Liberi


Protocolli Internet - Seconda puntata

di Umberto Salsi


L'articolo

Si introducono i protocolli per l'invio della posta elettronica e degli articoli dei newsgroup, compreso il formato dei messaggi, l'inclusione di allegati e documenti multimediali, l'uso degli alfabeti internazionali e di come queste conoscenze possano tornare utili al sistemista per configurare i sistemi, al programmatore come introduzione ai protocolli, e all'utente evoluto che voglia approfondire le possibilità e i limiti del mezzo.

Indice

Introduzione
RFC 822: come ti formatto il messaggio Internet
Come ti produco il messaggio Internet
RFC 821: SMTP per l'invio della posta
SMTPologia avanzata
Come ti intercetto la posta elettronica (e non solo)
Codifica ISO-8859
ISO 10646: Universal Character Set
Codifica Unicode
RFC 2279: Codifica UTF-8
RFC 2152: Codifica UTF-7
Codifica Uuencode
Codifica Base-64
RFC 2045: Codifica MIME
RFC 977: NNTP
Mini-test di autovalutazione
Conclusioni
Bibliografia
L'autore

Introduzione

In questa seconda puntata ci occuperemo di due strumenti fondamentali di comunicazione disponibili in Internet: la posta elettronica e i newsgroup. Vedremo che le due strategie di comunicazione sfruttano un formato comune per la rappresentazione dei messaggi, e introdurremo i protocolli SMTP e NNTP. Vedremo anche come sia possibile inserire nei messaggi dei contenuti multimediali. Gli argomenti sono veramente tanti: ci limiteremo solo a una panoramica, puntando alla comprensione dei concetti fondamentali e rimandando alla bibliografia per gli approfondimenti.

Il nostro strumento fondamentale per condurre le prove sarà ancora il fido client telnet. Chi avesse trovato ostico il discorso fatto nella puntata precedente, troverà che questa volta i concetti si ripetono e che quindi, al di là dei nuovi protocolli che verranno introdotti, lo sforzo di comprensione dovrebbe essere minore e la lettura più agevole. Ho anche cercato di ridurre al minimo la teoria per esporre solo gli elementi indispensabili e passare subito agli esempi e alla sperimentazione sul campo. Naturalmente l'unica fonte autorevole e definitiva restano i documenti RFC citati, la cui attenta lettura è indispensabile per poter realizzare applicazioni reali.

RFC 822: come ti formatto il messaggio Internet

Datato 1982, questo RFC si propone di mettere ordine tra la miriade di formati di messaggi al tempo esistenti nelle varie reti e nei vari sistemi. Leggendo l'RFC questo sforzo è chiaramente percepibile dalla varietà delle forme nelle quali si poteva esprimere l'indirizzo di posta elettronica, cioè quello che per noi oggi ha la classica struttura utente@dominio. In realtà questo formato doveva essere adattabile sia alla posta elettronica, sia agli altri strumenti di comunicazione che si andavano delineando, come USENET. Pertanto quando parlo di email, di articolo, o più genericamente di messaggio, intendo sempre la stessa cosa. Le varie forme di messaggio differiscono per via della presenza o meno di determinate informazioni nella intestazione, ma per il resto la loro struttura è sempre la stessa.

Ancora una volta, si doveva scegliere la forma più adatta per rappresentare il messaggio, qualunque fosse la rete o il sistema che avrebbe dovuto attraversare nel suo viaggio dal mittente al destinatario. La scelta cadde, ovviamente, su un formato testuale ASCII, concepito in modo che fosse facilmente analizzabile da parte dei programmi, ma contemporaneamente che fosse anche leggibile all'uomo.

Un messaggio nel senso dell'RFC 822 è dunque un testo composto da righe terminate dalla sequenza di caratteri CR e LF, contenenti codici ASCII. Alfabeti esotici e file binari sono, a questo punto della nostra trattazione, esclusi da questo formato.

Attenzione!
Lo scorso aprile 2001 è stato pubblicato l'RFC 2822 che sostituisce l'RFC 822. Tuttavia "822" è citato così frequentemente nella letteratura ed è così noto, che è diventato una specie di "numero magico", sotto al quale tutti riconoscono il formato dei messaggi Internet, un numero così importante che anche l'editore ha aspettato a pubblicare questo documento in modo che il suo numero, 2822, richiamasse quello del suo predecessore. Ecco perché anche in questo mio articolo parlerò sempre di RFC 822, pur tenendo conto degli aggiornamenti e delle precisazioni del formato dei messaggi Internet che sono maturate nei quasi 20 anni trascorsi dalla prima versione.

Vediamo allora come si presenta un tipico messaggio email:

    Message-ID: <3C0D5E3F005FC9EA@ims2c.libero.it>
            (added by postmaster@libero.it)
    Date: Wed, 26 Dec 2001 21:19:45 CET
    In-Reply-To: <3C28E260.6080703@qui.linux.it>
    References: <20011225193905.6E7AA2B6E8@qui.linux.it>
            <3C28E260.6080703@qui.linux.it>
    From: Umberto Salsi <umberto-salsi@libero.it>
    To: dodo@websic.com, mono@qui.linux.it
    Subject: Re: Ho finito l'articolo per il PLUTO!

    Anch'io ho finito la formattazione dell'articolo: adesso mi sembra
    che appaia bene un po' in tutti i browser. Anche la stampa e' ok.
    Direi che ci siamo: si pubblica?

    Ciao,
    - Umb

Si riconosce facilmente la struttura del messaggio: le prime righe sono l'intestazione, poi c'è una riga vuota, e quindi segue il corpo del messaggio in linguaggio naturale.

L'intestazione contiene le informazioni tecniche necessarie per l'invio e il riconoscimento del messaggio. In generale ogni riga contiene un certo campo di intestazione costituito dal nome del campo (come ad esempio Subject), dal carattere ":", e quindi dal corpo del campo che si estende fino alla fine della riga (come ad esempio Re: Ho finito l'articolo per il PLUTO!). Il corpo di alcuni campi può estendersi anche su più righe: le righe di continuazione devono obbligatoriamente cominciare con uno spazio o con un codice di tabulazione HT; per ricostruire la riga intera originale, la coppia CR+LF della riga precedente e il primo carattere di spaziatura della riga di continuazione devono essere interpretati dai programmi come un unico carattere di spaziatura. Nel nostro esempio il campo Message-ID e References hanno una riga di continuazione. Viceversa, si possono spezzare i corpi dei campi della intestazione solo in corrispondenza degli spazi.

La riga di separazione tra l'intestazione e il corpo del messaggio deve essere vuota, cioè non deve contenere caratteri salvo che la coppia CR+LF. Basterebbe uno spazio, invisibile, per contrassegnare questa riga come continuazione della precedente, falsando la corretta interpretazione della intestazione del messaggio.

Il corpo del messaggio contiene il messaggio in prosa. L'RFC 822 non impone alcuna particolare limitazione al contenuto del corpo, né per quanto riguarda il numero di righe, né per quanto riguarda la lunghezza del corpo. L'RFC 2822 impone un limite massimo di 998 caratteri per riga, ma raccomanda non più di 78 caratteri esclusi CR+LF per favorire la visualizzazione sotto le diverse interfacce utente. La filosofia generale sottostante ai protocolli definiti negli RFC è perciò la seguente: siate permissivi in ciò che i vostri programmi sono in grado di poter interpretare, e siate rigorosi in ciò che essi producono.

Ritorniamo all'intestazione, e descriviamo i principali campi che vi possono apparire. L'RFC 822 dice che questi campi possono apparire scritti indifferentemente in lettere maiuscole o in lettere minuscole, tuttavia raccomanda che, quando si formatta un messaggio, venga rispettata l'ortografia suggerita nel documento, e che anche qui rispetteremo.

L'RFC 822 prevede anche un meccanismo generale per inserire commenti in prosa nel corpo di un campo di intestazione, commenti che il software dovrebbe ignorare. Sono regole un po' ingarbugliate. Qui vediamo solo il tipo di commento che appare più frequentemente, e cioè il nome proprio della persona associato al suo indirizzo email. Ecco alcune delle forme possibili:

    tizio@qualcosa.it
    Tizio Tiziani <tizio@qualcosa.it>
    tizio@qualcosa.it (Tizio Tiziani)

Nel seguito, ovunque dirò che è possibile inserire un indirizzo email, si può inserire una qualsiasi di queste soluzioni.

From: riporta l'indirizzo (o gli indirizzi separati da virgole) del mittente (o dei mittenti) del messaggio. E' raro che un messaggio venga redatto a quattro mani, per cui qui di solito si troverà un solo indirizzo. Tuttavia nel caso di più indirizzi deve apparire anche un campo Sender:, che riporta l'indirizzo del mittente effettivo del messaggio.

To: l'indirizzo (o gli indirizzi separati da virgole) del destinatario (o dei destinatari) del messaggio.

Cc: il campo copia-carbone, ovvero "per conoscenza", funziona esattamente come il precedente. La differenza è puramente etica.

Bcc: il campo blind carbon copy (copia carbone cieca) funziona esattamente come i campi To e Cc. L'unica differenza è che questo campo non viene mai trasmesso con il messaggio, per cui gli indirizzi in esso contenuti non appaiono ai destinatari e rimangono quindi riservati. E' facile immaginare gli usi legittimi e meno legittimi di questo strumento. Uso legittimo: inviare gli auguri di buon anno nuovo a tutti i clienti, senza che ciascuno possa conoscere gli altri. Uso illegittimo: inviare spam.

Reply-To: contiene l'indirizzo, o gli indirizzi, ai quali vogliamo siano dirette eventuali risposte al messaggio. Di norma le risposte vanno indirizzate al mittente il cui indirizzo compare nel campo From:, ma un po' di fantasia può suggerire vari utilizzi utili di questa possibilità. Ad esempio: che succede inserendo nel campo Reply-To l'indirizzo dello stesso destinatario? Che succede mettendoci un indirizzo inesistente? O quello della Guardia di Finanza? Oppure junk@mioisp.it?
P.S.: se il vostro corrispondente poi si arrabbia, io non c'entro...

Message-ID: contiene l'identificativo univoco del messaggio. Si tratta di una stringa che il server SMTP calcola basandosi tipicamente sul nome di dominio, sul tempo e su un numero progressivo. Questo permette anche di tracciare gli spostamenti del messaggio (come registrati dei log file dei server) e diagnosticare eventuali problemi nella propagazione.

In-Reply-To: riporta l'ID del messaggio o dei messaggi dei quali questo messaggio costituisce la replica.

References: riporta l'elenco degli ID dei messaggi di cui questo messaggio costituisce il seguito, anche se non costituisce necessariamente una replica a tutti questi. Dall'esame di questi ID, i programmi client possono ricostruire il corretto albero di lettura ("thread") e presentare i messaggi in una forma strutturata che ne evidenza le correlazioni.

Subject: è l'oggetto del messaggio, una specie di riassunto che permette di identificarlo rapidamente negli elenchi. Suggerimento: scegliere bene l'oggetto favorisce la lettura del messaggio da parte del destinatario e la sua reperibilità successiva: non trascurare mai questo fatto se volete che il vostro messaggio venga letto (e ri-letto).

Date: contiene la data in cui il messaggio è stato finito di scrivere, che spesso coincide con la data di invio. Se la data manca, il server SMTP l'appone automaticamente. Tipicamente questa data viene apposta dal programma client del vostro computer, quindi una raccomandazione: controllate bene l'orologio, la data e il fuso orario del vostro PC se non volete fare la figura degli eternauti.

X-abcdefg: i campi che iniziano con i caratteri "X-" si considerano sperimentali, vengono trasmessi regolarmente, ma di norma vengono ignorati dai sistemi. Qualcuno li usa per inserire informazioni, altri ci mettono la pubblicità, altri ancora tentano di inserire la fotografia dell'autore del messaggio (X-Face). Da usare con fantasia.

Questo elenco è solo una minima parte di campi che possono apparire nella intestazione di un messaggio. Un elenco completo, e corredato da spiegazioni e riferimenti, lo si trova nell'RFC 2076, che è da tenere a portata di mano le prime volte che si va a curiosare nelle intestazioni dei messaggi.

Come ti produco il messaggio Internet

Generare un messaggio Internet direttamente come testo e rispettando la corretta sintassi non è molto pratico per l'uso quotidiano, e neppure è alla portata degli utilizzatori meno esperti di tecnologia. Ecco perché esistono vari programmi per la gestione della messaggistica Internet (email e newsgroup) che guidano l'utilizzatore nella redazione del messaggio.

Nel caso delle interfacce grafiche, tipicamente viene proposta una maschera di input già suddivisa in campi, che l'utilizzatore deve riempire. Un esempio schematico potrebbe essere quello della figura 1:

E-Mail Composer
To:
Cc:
Subject:

Figura 1. Interfaccia grafica per la redazione di un messaggio Internet.

L'utilizzatore compila i vari campi di input secondo necessità e alla fine preme il bottone SEND per inviare il messaggio. Il programma di posta valida i singoli campi, e quindi formatta il messaggio secondo le regole dell'RFC 822. Ottenuto il testo ASCII, il messaggio viene infine spedito usando il protocollo SMTP oppure NNTP, come descriveremo nei prossimi paragrafi.

Spesso i programmi di posta elettronica prevedono anche la possibilità di includere alcuni dei campi di intestazione generalmente non previsti a livello della interfaccia grafica. Altri permettono di configurare con una certa libertà il layout della maschera di input, e permettono di inserire campi arbitrari. Altri ancora si limitano a consentire di aggiungere al messaggio già formattato un certo testo che l'utilizzatore deve fornire.

RFC 821: SMTP per l'invio della posta

In questo RFC incontriamo ancora una volta il nostro Jon Postel che nel 1982 (anno molto prolifico, evidentemente) ci spiega il protocollo SMTP (simple mail transfer protocol). Che si possa effettivamente definire "simple" non garantisco, soprattutto alla luce delle varie revisioni ed estensioni che ne sono seguite. Il documento RFC 822 rimane tuttora valido, ed è lo standard di base per il protocollo SMTP.

Lo scopo del protocollo è quello di trasportare un messaggio da una macchina X a una macchina Y. Questo protocollo viene usato dal nostro client di posta per inviarla al server SMTP del nostro ISP, e a sua volta questo server userà ancora SMTP per recapitare il messaggio a destinazione. Il protocollo viaggia su TCP in forma testuale ASCII, e l'interazione tra i due computer avviene in modo simile a quella che abbiamo visto per il protocollo POP-3.

Attenzione!
Lo scorso aprile 2001 è stato pubblicato l'RFC 2821 che sostituisce l'RFC 821. Valgono le stesse considerazioni già fatte per l'RFC 822, per cui non mi ripeterò. Rispetto alla precedente, questa nuova versione si limita a consolidare, aggiornare e chiarire, ma non aggiunge nè cambia alcuna delle funzionalità dell'RFC 821, come precisa l'introduzione del documento. Inoltre, alcune delle funzionalità previste nell'821 sono ormai in disuso nell'Internet moderna, così portando alla semplificazione di alcuni aspetti.

Passiamo subito alla pratica. Per fare gli esperimenti useremo ancora il telnet, questa volta sulla porta smtp, ossia la numero 25. Come server potremo usare la nostra stessa macchina, oppure potremo usare il server SMTP del nostro ISP. Adesso che conosciamo la struttura dei messaggi, le cose dovrebbero essere più semplici. Ecco l'interazione che avviene per inviare il messaggio d'esempio visto nel paragrafo precedente. Riassumiamo i termini della questione:

Di solito i messaggi vengono inviati ad un unico indirizzo, ma in questo caso ho voluto rendere le cose più interessanti e, spero, più istruttive, inviando lo stesso messaggio a due indirizzi:

    $ telnet mail.libero.it smtp
    Trying 195.123.94.65...
    Connected to localhost.localdomain.
    Escape character is '^]'.
    220 smtp3.libero.it ESMTP Service (6.0.032) ready
    HELO localhost
    250 smtp3.libero.it
    MAIL FROM:<umberto-salsi@libero.it>
    250 MAIL FROM:<umberto-salsi@libero.it> OK
    RCPT TO:<dodo@websic.com>
    250 RCPT TO:<dodo@websic.com> OK
    RCPT TO:<mono@qui.linux.it>
    250 RCPT TO:<mono@qui.linux.it> OK
    DATA
    354 Start mail input; end with <CRLF>.<CRLF>
    Date: Wed, 26 Dec 2001 21:19:45 CET
    In-Reply-To: <3C28E260.6080703@qui.linux.it>
    References: <20011225193905.6E7AA2B6E8@qui.linux.it>
        <3C28E260.6080703@qui.linux.it>
    From: Umberto Salsi <umberto-salsi@libero.it>
    To: dodo@websic.com, mono@qui.linux.it
    Subject: Re: Ho finito l'articolo per il PLUTO!

    Anch'io ho finito la formattazione dell'articolo: adesso mi sembra
    che appaia bene un po' in tutti i browser. Anche la stampa e' ok.
    Direi che ci siamo: si pubblica?

    Ciao,
    - Umb
    .
    250 <3C0D5E3F005FC9EA> Mail accepted
    QUIT
    221 smtp3.libero.it QUIT
    Connection closed by foreign host.

    $

Il protocollo SMTP è più complesso e articolato del protocollo POP-3, per cui il server ritorna sempre delle righe composte da un codice numerico a tre cifre e da una descrizione in prosa. Il codice numerico codifica il successo o il fallimento del comando inviato dal client, ed è ad uso e consumo dei programmi. Il documento RFC 821 riporta l'elenco completo dei codici e della loro semantica. Poiché stiamo lavorando interattivamente, possiamo limitarci a leggere i messaggi in prosa, che sono abbastanza espliciti. Vediamo, nell'ordine, i vari comandi ed esaminiamone l'effetto:

HELO hostname
Il primo comando che usiamo dichiara al server semplicemente il nome del nostro computer, di norma ha puro scopo informativo, e in generale il server nemmeno verifica che si tratti di un hostname registrato. Tuttavia, questo nome apparirà nelle intestazioni Received, per cui è meglio evitare di scegliere nomi imbarazzanti.
Il server ci risponde semplicemente col suo nome, e il comando si esaurisce qui.
MAIL FROM:<mittente>
Qui dichiariamo il nostro indirizzo di posta elettronica. Di solito il server fa i suoi controlli per verificare che sia valido. Inoltre è a questo indirizzo che verranno segnalati eventuali disguidi verificatisi durante il recapito, per cui se siamo interessati a sapere che ne è stato del nostro messaggio, qui è meglio mettere il nostro vero indirizzo.
Il server ci rassicura con il suo OK, e possiamo andare avanti.
RCPT TO:<destinatario>
Con questo comando informiamo il server dell'indirizzo del destinatario del messaggio. Anche qui il server può fare le sue verifiche preventive sull'indirizzo indicato. Nel nostro caso il server ci risponde con un altro bell'OK. Possiamo continuare e specificare altri destinatari, nel caso volessimo recapitare lo stesso messaggio a più persone, come avviene nel nostro esempio.
DATA
Questo comando istruisce il server che stiamo per trasmettere il messaggio vero e proprio. Il server si premura di ricordarci che dovremo terminare il messaggio scrivendo una linea costituita da un solo punto. Quello che non può precisare in questa nota telegrafica è che tutte le righe del messaggio che dovessero cominciare con un punto, dovranno essere fatte precedere da un altro punto. Si tratta della stessa convenzione utilizzata dal server POP-3 che abbiamo già visto, ma questa volta applicata al contrario: siamo noi a dover garantire il rispetto di questa regola. Ovviamente, i programmi di posta elettronica faranno altrettanto. Nel nostro messaggio di esempio non ci sono righe che cominciano con un punto, per cui qui non vediamo in azione questo accorgimento. Completato il messaggio, inviata la riga di chiusura costituita da un solo punto, il server ci risponde che il messaggio è stato accettato per il recapito.
QUIT
Siccome non abbiamo altro da fare in questo collegamento, non ci rimane che salutare e chiudere la connessione con un rispettoso QUIT.

Negli istanti successivi, il server SMTP si preoccuperà di identificare i server responsabili della gestione delle mailbox dei destinatari, li contatterà uno ad uno e tenterà di trasmettere loro il messaggio.

Se, per una qualunque motivo, la trasmissione non fosse possibile, il server ripeterà altri tentativi a distanza di tempo, notificando periodicamente al mittente gli eventuali problemi riscontrati. Al termine di tutti i tentativi, che possono proseguire anche per alcuni giorni in dipendenza della configurazione del server, se ancora il messaggio non fosse stato recapitato con successo a uno o più dei destinatari, il server notificherà al mittente l'esito negativo delle operazioni e la motivazione di tale insuccesso (server remoto down, linee sovraccariche, ecc.).

Non so voi, ma io ci trovo un qualcosa di commovente nella premura con la quale lavorano i server SMTP. Del resto la posta elettronica è un servizio a bassa velocità ma che richiede una alta affidabilità, per cui merita tanta attenzione.

Suggerimento banale: per fare altri esperimenti conviene configurare un server SMTP sul proprio computer (sendmail, postfix, qmail, ...) e fare le prove in locale, evitando così pasticci. In alternativa, fare gli esperimenti inviando la posta a sè stessi: sembrerà strano, ma il ciclo di invio (SMTP) e download (POP-3) del messaggio esercita tutti protocolli di posta elettronica che abbiamo visto, senza bisogno di inviare messaggi di prova a destra e a manca.

Suggerimento per gli utilizzatori di Windows: come abbiamo detto la puntata scorsa, il client telnet incluso col sistema operativo non effettua l'eco locale. Tentare in queste condizioni di riprodurre l'interazione dell'esempio è una esperienza frustrante, perché il protocollo SMTP è più complesso. Meglio procurarsi PuTTY o Teraterm in sostituzione di questo telnet.

SMTPologia avanzata

Alcune considerazioni prima di chiudere questo rapido sorvolo sul protocollo SMTP. La prima è relativa al concetto di busta (envelope). Con questo termine si indicano le informazioni impartite al server SMTP prima di inviare il messaggio, e cioè gli indirizzi del mittente e dei destinatari, esattamente le informazioni che troviamo anche nella buste cartacee per la posta. Gli indirizzi della busta sono le uniche informazioni su cui il server si basa per recapitare il messaggio: in effetti, il server ignora il contenuto stesso del messaggio e gli indirizzi che vi compaiono.

Un'altra considerazione importante è che il server SMTP di norma è in grado di ottimizzare l'invio della posta a parecchi indirizzi email residenti nello stesso server: in questi casi il server trasmette al suo collega server una sola copia del messaggio, specificando nella busta gli indirizzi di interesse. Il server remoto provvede poi a duplicare il messaggio nelle varie mailbox dei propri utenti. L'effetto netto è che attraverso le intasatissime autostrade dell'informazione il messaggio è transitato una sola volta per tutti questi utenti, con beneficio generale.
Quindi, ad esempio, se tra i destinatari compaiono tizio@qualcosa.it e caio@qualcosa.it, al server SMTP del dominio qualcosa.it verrà inviata una sola copia del messaggio, specificando nella busta i due indirizzi. Ecco perché è meglio inviare un messaggio con cento indirizzi piuttosto che cento messaggi uguali ad altrettanti indirizzi.

Ultima curiosità: supponiamo di volere inviare un messaggio email a un generico indirizzo tizio@qualcosa.it: osserviamo che qualcosa.it probabilmente non corrisponde a un computer ben determinato, ma tipicamente sarà solo il dominio di secondo livello sotto il quale sono registrate parecchie macchine. Come fa allora il server SMTP ad individuare il suo collega server? Curiosamente questo problema viene risolto a livello dei server DNS: il nostro fido server SMTP interroga i vari server DNS e raccoglie le informazioni relative al dominio qualcosa.it, i cosiddetti "record MX". Tra queste informazioni apparirà anche l'indicazione del server SMTP predisposto ad accogliere tutta la posta per quel dominio. Non approfondiamo ulteriormente l'argomento, ma spero che basti per rendere l'idea di come si realizza il prodigio.

Come ti intercetto la posta elettronica (e non solo)

Esistono vari enti che si occupano di intercettazioni sistematiche delle comunicazioni che avvengono via Internet, via telefono, via fax, via telex, ecc. Tra queste ricordiamo Echelon (USA, Gran Bretagna, Nuova Zelanda, Australia, Canada), Enfopol (Europa), SORM (Russia), SCS (NSA+CIA), ASIO (Australia), "Franchelon" (Francia), BND (Germania), ed altre che adesso non mi vengono. Le tecnologie utilizzate sono le più disparate: black box nelle centrali telefoniche, antenne radio, satelliti e altri sistemi futuribili e super segreti.

Pare che possano anche analizzare automaticamente il parlato nelle normali conversazioni telefoniche da apparecchio fisso e da telefono cellulare, consentendo quindi la digitalizzazione e il successivo incrocio delle informazioni con potenti computer. Tra i pare e i si dice, sembra che i sistemi di sorveglianza via satellite siano talmente precisi da poter identificare gli spostamenti di una persona al suolo: sorridere, prego!

Plausibilmente, possiamo immaginare che questi signori eseguano anche scansioni sistematiche del WEB, sicché con questo articolo ci siamo garantiti anche noi un buon posizionamento nel loro sistema automatico di scansione. Di sicuro mi aspetto che i sistemi impiegati possano essere talmente sofisticati o talmente banali che neppure ci immaginiamo: la realtà spesso è più sorprendente della fantasia.

Esistono informazioni certe che alcuni di questi organismi hanno operato non solo per motivi di difesa e prevenzione legittimi, ma che siano stati impiegati anche in ambito politico ed economico per favorire determinati interessi. E' facile intuire le distorsioni che ne possono seguire alle libertà democratiche, al diritto alla privacy, ma anche alle leggi economiche e ai principi della concorrenza. Non approfondisco questo tema, perché qui ci occuperemo solo degli aspetti tecnici della questione.

Il problema della intercettazione della posta è abbastanza grave: i protocolli POP-3 e SMTP abbiamo visto che trasmettono in chiaro tutti i messaggi, che sono perciò facilmente intercettabili sia al momento dell'invio (via SMTP) sia al momento della ricezione (via POP-3).

L'unica soluzione pratica che al momento mi sento di suggerire è quella di fare uso massiccio delle tecniche di crttazione a chiave asimmetrica, in modo che il messaggio sia intelleggibile esclusivamente all'interno del computer di chi lo invia e di chi lo riceve. In tal senso esistono diversi programmi. Ecco i più popolari:

- GnuPG www.gnupg.org è disponibile per i sistemi simil-Unix, GNU/Linux e Windows; oltre che l'interfaccia a linea di comando sono previste anche interfacce grafiche per i vari ambienti e l'integrazione con alcuni programmi di posta elettronica;

- PGP www.pgp.com è disponibile per vari sistemi operativi con l'interfaccia a riga di comando; mi risulta che l'interfaccia grafica sia disponibile solo per l'ambiente Windows.

Auspicabilmente in futuro i programmi di posta elettronica saranno dotati di una migliore integrazione col sistema di crittazione e firma digitale, riducendo la tecnologia sottostante a pochi bottoni facilmente utilizzabili. Solo l'impiego diffuso di queste tecnologie può ristabilire un giusto equilibrio tra il diritto alla riservatezza dei cittadini, e la necessità degli inquirenti di poter indagare e perseguire i reati.

Purtroppo questo sistema non è perfetto: la crittazione viene eseguita solo sul corpo del messaggio, mentre continua a rimanere in chiaro l'intestazione e quindi il mittente e il destinatario.

Il tema appena sfiorato in questo paragrafo è di estrema attualità ed è anche piuttosto complesso. Per approfondire l'argomento posso suggerire le letture suggerite in bibliografia.

Codifica ISO 8859

Finora abbiamo usato esclusivamente l'insieme dei caratteri ASCII per codificare i nostri testi, lasciando in sospeso il problema degli alfabeti non-US. La soluzione a questo problema ha trovato due strade: la prima via sfrutta l'estensione a 8 bit dei codici ASCII, la seconda via deve invece estendere la rappresentazione dei caratteri utilizzando un numero maggiore di bit.

Lo standard ISO 8859 definisce vari insiemi di caratteri (in breve: charset) codificati a 8 bit. I primi 128 codici sono i soliti caratteri ASCII, mentre i successivi 128 codici vengono utilizzati per codificare vari caratteri più o meno esotici, a seconda del charset scelto.

Tra i charset definiti da questo standard sono comprese tutte le lingue occidentali, il cirillico, il greco, l'ebraico e l'arabo. In particolare il charset ISO-8859-1 comprende le lingue italiana, francese, spagnola e tedesca, così soddisfacendo gran parte delle esigenze del mondo occidentale. Recentemente alla serie ISO-8859-* è stato aggiunto l'ISO-8859-15 che include il simbolo dell'Euro, la nuova moneta europea. Ma attenzione: l'ISO pubblica solo la corrispondenza tra il codice binario del byte e la descrizione del carattere che esso rappresenta; per potere effettivamente visualizzare i caratteri bisogna procurarsi i rispettivi font conformi a questi standard.

Questo standard ha il vantaggio di richiedere minimi cambiamenti all'hardware e al software dei computer, perché si tratta solo della definizione dei charset ASCII estesi di cui abbiamo parlato nella prima puntata. Purtroppo risultano esclusi i sistemi di scrittura come il cinese, che con le sue migliaia di simboli non potrebbe mai stare in un solo byte, ed inoltre non si possono mescolare nello stesso testo due alfabeti diversi, per esempio il latino e il cirillico.

ISO 10646: Universal Character Set

Una soluzione più generale alle limitazioni che abbiamo visto richiede necessariamente di usare un numero maggiore di bit per codificare tutti i charset del mondo. Questo è l'obiettivo ambizioso dello standard UCS (Universal Character Set) definito dallo standard ISO 10464. L'UCS usa una codifica a 31 bit per carattere e comprende tutti i charset del mondo, inclusi greco, ebraico, cirillico, arabo, cinese, katakana, ecc. Sono in corso i lavori per includere charset più esotici, come il tibetano e il geroglifico.

Codifica Unicode

In realtà al momento solo i primi 16 bit dell'UCS sono utilizzati, per cui è stata definita una implementazione ridotta all'uopo. L'Unicode, definito dal Consorzio Unicode (www.unicode.org), è una implementazione dell'UCS che usa questa soluzione a 16 bit, ed è stata adottata, ad esempio, nei sistemi operativi di Microsoft e nel linguaggio di programmazione Java.

Forse torna utile perché di attualità vedere come il simbolo Euro viene codificato nei vari sistemi:

- Unicode: 8364 (0x20AC)
- ISO 8859-15: 164 (0xA4)
- Sorgente HTML: &#8364;
- Ecco come lo visualizza il tuo browser:

RFC 2279: Codifica UTF-8

Nell'ambiente Unix e similari, incluso il software GNU, viene solitamente implementata la codifica UTF-8 dell'Unicode. L'UTF-8 usa una codifica a lunghezza variabile da uno a tre byte per carattere; i caratteri ASCII sono rappresentati con un byte nel modo solito, mentre quando si "accende" l'ottavo bit si attiva la codifica multi-byte (spiegato molto a spanne, ma dovrebbe dare l'idea). Questa soluzione permette di mantenere la compatibilità con la maggior parte delle librerie di manipolazione delle stringhe, che erano concepite per l'uso con caratteri di 8 bit, e preserva anche l'ordinamento alfabetico. La documentazione GNU della libreria standard fornisce ulteriori dettagli per il programmatore che voglia integrare pienamente questa implementazione dell'Unicode nei suoi programmi.

RFC 2152: Codifica UTF-7

Il protocollo SMTP e i sistemi di smistamento della posta elettronica garantiscono il supporto solo per messaggi codificati in ASCII, e dunque rappresentati a 7 bit per byte. L'UTF-8, che usa 8 bit per byte, è adatto per la rappresentazione dei testi nella memoria dei computer, ma non è generalmente accettabile in un email.

L'RFC 2152 definisce quindi l'UTF-7, una particolare codifica dell'Unicode che sfrutta esclusivamente i codici ASCII: il carattere + precede la codifica "Base64 modificata" del codice Unicode a 16 bit. Si tratta di una soluzione poco efficiente dal punto di vista della memorizzazione e della elaborazione, ma altamente compatibile con tutti i protocolli e sistemi di trasmissione.

Codifica Uuencode

Superato lo scoglio della rappresentazione dei vari alfabeti internazionali, rimane aperto il problema dell'invio di file binari dentro a un email. Ricordiamo ancora una volta che un file binario, come una immagine, contiene tutto lo spettro di possibili valori per i byte che lo compongono, sicché non può certo essere trasmesso via SMTP o via POP-3 senza interferire disastrosamente con le convenzioni definite da questi protocolli. Il problema si risolve solo definendo un algoritmo in grado di eseguire in modo reversibile la codifica da binario ad ASCII e viceversa.

Per inserire un file binario nel corpo di un messaggio si può usare la codifica del programma uuencode, programma originariamente a corredo del sistema UUCP. La pagina del manuale on-line del comando dà maggiori dettagli. Qui diremo solo che il programma codifica gruppi di tre byte in gruppi di 4 caratteri ASCII scelti fra un sottoinsieme di 64 caratteri ASCII stampabili, e inoltre aggiunge la caratteristica intestazione begin che specifica i flag dei permessi del file e il nome del file stesso. Lo spreco di byte complessivo è intorno al 33% in più. Ecco un esempio:

    begin 644 figura.png
    MB5!.1PT*&@H````-24A$4@```!`````0`0`````WB,+,````-4E$051XVF,0
    MZV8H6\U0-IM!8#7#__\,1]P9KEYGN!+.<#T<Q`:*[)9BF%W%L-J*87,]D`T`
    4O2H2?,H(B"``````245.1*Y"8((`
    `
    end

Questo brano di testo, inserito nel corpo di un messaggio, attraversa indenne qualsiasi sistema e protocollo che supporta ASCII, e viene solitamente riconosciuto in modo automatico dai programmi client di posta elettronica, e presentato come allegato. In caso contrario bisogna estrarre dal messaggio le righe che vanno dal begin all'end e darle in pasto a uudecode.

In definitiva, l'uuencode fornisce una soluzione semplice e largamente riconosciuta al problema dell'inserimento di file binari nell'email.

Codifica Base-64

Il Base-64 è un altro sistema di conversione da file binario a testo ASCII e viceversa. Usa una tecnica simile all'uuencode, ma si presta meglio per codificare file binari per l'uso con MIME. Anche qui gruppi di 3 byte vengono codificati in gruppi di 4 caratteri ASCII, aumentando le dimensioni dell'allegato di circa il 33%. Lo stesso file di prima codificato in questo modo apparirebbe così:

    iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAQAAAAA3iMLMAAAANUlEQVR42mMQ
    62YoW81QNptBYDXD//8MR9wZrl5nuBLOcD0cxAaK7JZimF3FsNqKYXM9kA0A
    vSoSfMoIiCAAAAAASUVORK5CYII=

Il set di caratteri ASCII scelto per la codifica è quanto di più innocuo e conservativo si possa immaginare: lettere maiuscole e minuscole, cifre, il punto e lo slash /, per un totale di 64 simboli, come richiesto.
Il comando uuencode realizza anche questa codifica usando il flag -m. In alternativa si può usare anche il comando mimencode a corredo del pacchetto metamail.
Il client di posta non può riconoscere automaticamente questo codice perché è indistinguibile dal normale testo del messaggio; solo con le opportune intestazioni MIME diventa utile, come vedremo.

RFC 2045: Codifica MIME

Il collante di tutte le soluzioni di rappresentazione viste fin qua è il MIME. Questo formato di rappresentazione dei messaggi permette di superare molte limitazioni del formato RFC 822, pur rimanendo con esso assolutamente compatibile (gli autori usano la parola "ortogonale"). In pratica, è la quadratura del cerchio. Ecco una sintesi di quello che permette di fare MIME:

La documentazione del formato MIME è piuttosto voluminosa e complessa, e si articola in cinque documenti principali che vanno dall'RFC 2045 all'RFC 2049. In questo articolo provo a sintetizzarne soltanto i concetti principali attraverso alcuni esempi. Inoltre questi esempi non sono fine a sè stessi, ma si possono utilizzare in applicazioni concrete, senza dover studiare questo formato in tutti i dettagli.

Inviare un messaggio HTML. Capita spesso al sistemista e al programmatore di dover generare email in modo automatico, per esempio per segnalare ad un utente o a un cliente informazioni statistiche degli accessi al suo sito WEB, oppure per segnalargli il superamento della quota per la sua mailbox. Per ottenere un risultato più elegante potremmo inviargli un documento HTML, che fa la sua bella figura. Ecco come confezionare il messaggio:

    MIME-Version: 1.0
    Content-Type: text/html
    From: root@webfarm.it
    To: tizio@qualcosa.it
    Subject: AVVISO di superamento quota disco

    <HTML><BODY bgcolor="#ff3030"><H1>ATTENZIONE!</H1>
    <P>La tua mailbox ha superato la dimensione massima
    consentita di <B>10 MB</B>. Per favore, provvedi
    prima possibile a svuotarla, altrimenti per motivi
    tecnici saremo costretti a <B>cancellare tutto il
    contenuto entro 24 ore!</B></P>
    <P>Per maggiori informazioni sulle condizioni del
    servizio, leggi il
    <A href="http://webfarm.it/contratto">contratto di
    fornitura</A>.
    </BODY></HTML>

Ho evidenziato in grassetto le due righe chiave di tutto il meccanismo: l'intestazione MIME-Version: 1.0 è obbligatoria e indica che il messaggio è in formato MIME versione 1.0. La riga seguente Content-Type: text/html indica che il corpo del messaggio è di tipo testo e di sottotipo HTML, pertanto la dicitura text/html è il tipo MIME di questo messaggio. Siccome non abbiamo specificato diversamente, il messaggio si considera codificato a 7 bit usando il charset ASCII.

Una volta scritto il messaggio in un file di testo, per inviarlo basta il comando cat lettera.txt | sendmail -t ed ecco fatto!

Inviare un messaggio con una immagine. Usando i vari tipi MIME registrati, potremo inviare anche altri tipi di informazioni, per esempio la nostra solita figura:

    MIME-Version: 1.0
    Content-Type: image/png
    Content-Transfer-Encoding: base64
    From: root@webfarm.it
    To: tizio@qualcosa.it
    Subject: Una bella figurina per te!

    iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAQAAAAA3iMLMAAAANUlEQVR42mMQ
    62YoW81QNptBYDXD//8MR9wZrl5nuBLOcD0cxAaK7JZimF3FsNqKYXM9kA0A
    vSoSfMoIiCAAAAAASUVORK5CYII=

Oltre alla solita MIME-Version, questa volta l'intestazione Content-Type specifica il tipo MIME image/png. Come è facile immaginare, esistono anche i tipi MIME image/jpeg, image/gif, ecc. con il loro ovvio significato. La terza riga Content-Transfer-Encoding è una novità: dichiara che i dati sono codificati in Base64.

Messaggio a più parti alternative. E' sempre più frequente trovare in circolazione questo tipo di messaggi dopo l'affermarsi del client di posta Outlook Express di Microsoft. Questo programma viene configurato per default con l'opzione MIME (l'altra possibilità mi pare che sia l'Uuencode), e in questo caso il programma formatta tutti i messaggi con un formato MIME di tipo multipart/alternative. Il concetto alla base di questo tipo MIME è il seguente: non tutti i client di posta hanno le stesse possibilità di visualizzazione. Per esempio, alcuni sono in grado di mostrare un documento HTML, altri possono mostrare solo testo. Il formato a più parti alternative permette di inserire lo stesso contenuto in più forme diverse, lasciando al client la possibilità di scegliere il formato preferito tra quelli disponibili. Come esempio ripropongo l'email di notifica spazio esaurito che prima avevamo scritto solo come HTML. Qui lo scriveremo anche come testo ASCII:

    MIME-Version: 1.0
    Content-Type: multipart/alternative;
        boundary="ZQZQZQ"
    From: root@webfarm.it
    To: tizio@qualcosa.it
    Subject: AVVISO di superamento quota disco

    Questo e' un messaggio in piu' parti alternative. Se stai leggendo
    queste righe, significa che il tuo client di posta non supporta il
    formato MIME. Cio' e' un bene, cosi' puoi vedere come funzionano
    veramente le cose. :-)

    --ZQZQZQ
    Content-Type: text/plain

    ATTENZIONE!
    La tua maibox ha superato la dimensione massima consentita
    di 10 MB. Per favore, provvedi prima possibile a svuotarla,
    altrimenti per motivi tecnici saremo costretti a cancellare
    tutto il contenuto entro 24 ore! Per maggiori informazioni
    sulle condizioni del servizio, leggi il contratto
    di fornitura (http://webfarm.it/contratto).

    --ZQZQZQ
    Content-Type: text/html
    
    <HTML><BODY bgcolor="#ff3030"><H1>ATTENZIONE!</H1>
    <P>La tua mailbox ha superato la dimensione massima
    consentita di <B>10 MB</B>. Per favore, provvedi
    prima possibile a svuotarla, altrimenti per motivi
    tecnici saremo costretti a <B>cancellare tutto il
    contenuto entro 24 ore!</B></P>
    <P>Per maggiori informazioni sulle condizioni del
    servizio, leggi il
    <A href="http://webfarm.it/contratto">contratto di
    fornitura</A>.
    </BODY></HTML>
    --ZQZQZQ--

Lo stesso contenuto del messaggio viene quindi rappresentato in due forme diverse. Quando l'utilizzatore redige un messaggio non si accorge della doppia rappresentazione, ma si limita ad utilizzare le funzionalità rese disponibili dalla interfaccia che gli viene presentata. Al momento dell'invio, il programma produce la forma HTML e la forma testo dello stesso messaggio. Nel mio esempio i due testi non sono perfettamente equivalenti: il link ipertestuale in questo caso deve essere riprodotto diversamente, e nella forma testo ho riprodotto l'URL per intero dentro alle parentesi. Descriviamo passo passo come funziona questa rappresentazione:

- Nella intestazione abbiamo la solita linea MIME-Version, e poi la linea Content-Type. Questa volta il tipo è multipart/alternative. Subito dopo il tipo ho aggiunto in una riga di continuazione il parametro boundary="ZQZQZQ"; questo parametro serve a dichiarare la stringa di separazione delle varie parti che costituiscono il corpo del messaggio. Questa stringa deve essere univoca, e per evitare collisioni i programmi tendono a renderla molto lunga e con una sequenza casuale di cifre, lettere e altri simboli. Tuttavia per favorire la leggibilità qui ho scelto la stringa ZQZQZQ.

- Il corpo del messaggio comincia con il testo "Questo e' un messaggio in piu' parti alternative. [...]": questa sorta di preambolo è consentito dalle specifiche MIME, ma secondo le stesse specifiche, se presente, deve essere ignorato dai programmi conformi al MIME e quindi non deve essere presentato all'utilizzatore. Ho sfruttato questa possibilità per aggiungere un avviso che sarà leggibile a coloro che non dispongono di un client con supporto MIME, che così potranno capire la ragione della (per loro) strana formattazione del messaggio.

- Ogni sezione MIME nel corpo inizia con la riga di separazione, costruita con due segni - (meno) seguiti dalla stringa di boundary che ho specificato nell'intestazione. Subito dopo c'è l'intestazione MIME che dichiara il tipo dei dati di questa sezione, una riga vuota, e quindi i dati stessi della sezione. La sezione termina dove compare la successiva riga di separazione.

- Al termine del messaggio bisogna inserire la riga di separazione seguita da altri due segni ``-'' (meno).

La cosa più interessante è che ogni sezione MIME nel corpo del messaggio assume la stessa forma di un messaggio, con la sua intestazione, la riga vuota, e il corpo. In effetti MIME consente dichiarazioni ricorsive: ogni sezione può essere del tipo multiparte e contenere quindi un altro messaggio MIME.

Messaggio con allegato. Questo problema lo lascio per esercizio al lettore, che dovrà trovare la risposta senza andare a leggere alcuna documentazione!
(Suggerimento: usa il metodo sperimentale: invia a te stesso un messaggio in formato MIME con allegato, ed esamina il risultato).

Riguardo all'uso di font alternativi nella intestazione, il MIME consente l'uso di vari charset, incluso ISO e UTF-8: i caratteri non ASCII dovranno essere avvolti dentro a una particolare sequenza di caratteri come in questo spezzone di esempio:

    Subject: =?ISO-8859-1?Q?Propriet=E0?= del formato MIME

A causa della presenza della lettera accentata "à", che non fa parte del charset ASCII, il client di posta ha codificato l'oggetto del messaggio specificando il charset ISO-8859-1, ha circondato la parola in questione con una serie di strani caratteri, e quindi ha codificando la lettera accentata con il suo valore esadecimale E0.

E' possibile anche usare un charset non ASCII nel corpo del messaggio introducendo un parametro apposito nel campo di intestazione Content-Type:

    ContentType: text/plain; charset="ISO-8859-1"

Con queste ultime annotazioni telegrafiche chiudo il discorso sul formato MIME. Ricordo solo che lo stesso formato viene utilizzato anche dal protocollo HTTP per il WEB: in quel caso il canale è sempre pulito a 8 bit per byte.

RFC 977: NNTP

Datato 1986, questo RFC descrive il protocollo Network News Transfer Protocol, un sistema distribuito per lo scambio di messaggi a tema (piaciuta la definizione?). Ogni "argomento a tema" è contrassegnato da un nome di newsgroup, o brevemente gruppo. Questi nomi sono strutturati, ed hanno una forma del tipo it.comp.os.linux.iniziare abbastanza autoesplicativa del tema trattato: italia, computer, operating system, linux, iniziare. Ciascun gruppo contiene i vari messaggi, detti articoli, che hanno un formato conforme all'RFC 822. Diversamente da un email, alcuni campi di intestazione perdono di significato e, se presenti, vengono ignorati dai newsserver (come To:, Cc:, Bcc: e Reply-To) mentre nuovi campi di intestazione sono stati introdotti per tenere conto del nuovo mezzo (RFC 1036). Ecco i principali:

From, Date, Subject, Message-ID: questi campi della intestazione conservano il loro significato come per l'email.

Newsgroups: riporta il nome del gruppo dove il messaggio appare. Si possono indicare anche più gruppi separati da una virgola (cross-post): in tal caso tipicamente il newsserver mantiene una sola copia del messaggio, ottimizzando lo spazio disco.

Followup-To: riporta l'elenco dei gruppi dove si desiderano vengano riportate le eventuali risposte a questo articolo, qualora questo elenco differisca da quello specificato nell'elenco di Newsgroups. La parola riservata poster indica che le risposte devono essere inviate via email al mittente, deducibile dal campo Reply-To o, in mancanza, dal campo From.

Expires: se presente, riporta la data oltre la quale si desidera che l'articolo venga rimosso dai newsserver. In alternativa i newsserver ripuliscono la loro memoria a cadenze decise in fase di configurazione (da alcuni giorni a parecchi mesi).

References: riporta l'elenco degli ID degli articoli dei quali questo articolo costituisce la continuazione, e permette ai programmi client di ordinare gli alberi di lettura.

Control: il corpo di questo campo trasporta messaggi di natura "tecnica" per la gestione dei newsserver, e di norma non deve essere usato dal normale utilizzatore. Unica eccezione è la richiesta di cancellazione di un articolo erroneamente postato (v. l'RFC per i dettagli).

Approved: nei gruppi moderati, riporta l'indirizzo email del moderatore che ha filtrato questo articolo. Nei gruppi moderati, infatti, gli articoli postati su di un newsserver non appaiono immediatamente, ma vengono preventivamente inoltrati via email al moderatore.

Il protocollo di comunicazione tra un programma client e un newsserver è più articolato dell'SMTP, ma ancora una volta l'interazione avviene attraverso uno scambio di comandi espressi in forma testuale, riproducibili col nostro fido telnet. Vediamo i comandi principali che useremo negli esempi:

ARTICLE message-ID
ARTICLE n
Richiede al server il messaggio avente l'ID specificato oppure avente il numero specificato. Il server distingue le due forme perché l'ID è un codice compreso tra le parentesi angolari, mentre il numero è costituito solo da cifre. La prima forma ha valore assoluto tra i vari server, mentre nella seconda forma il numero assegnato all'articolo ha significato locale al server interrogato.
GROUP gruppo
Istruisce il server che d'ora in poi siamo interessati ad interrogare la raccolta degli articoli presenti nel gruppo gruppo. In questo modo il protocollo risparmia al client di dover specificare il gruppo per ogni comando dato, riducendo il traffico in rete.
LIST
Questo comando ritorna l'elenco di tutti i gruppi disponibili su quel server. Una volta terminato l'elenco, il server ritorna una riga contenente un solo punto, nel rispetto di una tradizione che ci dovrebbe essere ormai familiare. Siccome molti server dispongono di migliaia di gruppi, possiamo aspettarci un elenco davvero lungo. Ogni gruppo viene riportato in una riga nella forma seguente:
    gruppo ultimo primo p
dove ultimo è il numero dell'ultimo articolo disponibile, primo è il numero del primo articolo disponibile, e p vale m se il gruppo è moderato, oppure vale y se non è moderato. Poiché il volume di traffico generato da questo comando è piuttosto elevato, i programmi client lo invocano solo al primo collegamento col server, e quindi memorizzano localmente in un file il risultato ottenuto. Successivamente il client userà il comando NEWSGROUPS per ottenere l'elenco dei nuovi gruppi eventualmente resisi disponibili sul server, ed aggiornerà di conseguenza il suo elenco locale. Questo elenco è proprio quello che il programma mostra all'utilizzatore quando questi desidera "sottoscrivere" i gruppi di interesse. In realtà questa sottoscrizione non comporta alcun atto formale: si tratta semplicemente di istruire il programma su quali sono i gruppi da scaricare al prossimo collegamento.
NEWSGROUPS yymmdd hhmmss
Ritorna l'elenco dei gruppi creati dopo la data e l'ora specificati (ora di Greenwich). Notare che vanno specificate solo le ultime due cifre dell'anno, per cui 86 significa 1986, 02 significa 2002, ecc. Cosa succederà dal 2050 in poi al momento non è dato a sapere. Preoccupati?
POST
Similmente al comando DATA che abbiamo visto nel protocollo SMTP, questo comando precede l'invio del nostro articolo verso il server. L'articolo deve essere formattato secondo le convenzioni che abbiamo visto, le linee che dovessero cominciare con un punto devono essere fatte precedere da un altro punto per evitare ambiguità, e al termine dell'articolo bisogna inviare una linea che contiene un solo punto (però, che originaloni questi redattori di RFC!).
QUIT
Comanda al server di chiudere la connessione TCP.

Abbiamo visto che il protocollo POP-3 è facilmente sfruttabile anche via telnet, e ritorna utile in alcune occasioni. Già più difficilotto l'SMTP, ma ci si può ancora ragionare. Con l'NNTP, invece, tocchiamo l'apice del masochismo, e il divertimento si moltiplica! Ecco l'esercizio che faremo: 1) scriveremo un articolo, 2) lo inseriremo nell'apposito gruppo per i test it.test, 3) lo andremo a rileggere, 4) e quindi lo cancelleremo con un messaggio di controllo. Useremo ancora il nostro fido telnet ma, per l'occasione, al dump dello schermo alternerò i miei commenti in prosa. Ecco il nostro articolo:

    From: umberto-salsi@libero.it
    Newsgroups: it.test
    Date: Thu, 06 Dec 2001 14:03:57 GMT
    Subject: Era una notte buia e tempestosa...

    ...e allora sono rimasto a letto!

Bene, telnet ce l'abbiamo, il messaggio ce l'abbiamo, le istruzioni per l'uso anche, dunque allacciamo le cinture e partiamo:

    $ telnet powernews.libero.it nntp
    Trying 193.70.192.103...
    Connected to powernews.libero.it.
    Escape character is '^]'.
    200 Welcome to Libero - Infostrada news server (Twister v1.2.0)
    GROUP it.test
    211 36298 2 37003 it.test

Prima di inviare l'articolo ho voluto controllare un po' la situazione del gruppo it.test, in modo da poterla poi confrontare dopo. In risposta al mio comando GROUP il server ritorna una serie di numeri: 211 è il codice di stato, 36298 è il numero di articoli presenti nel gruppo, 2 è il numero del primo articolo mentre 37003 è il numero dell'ultimo. Teniamo bene in mente questo numero, perché è istruttivo confrontarlo col numero che il server attribuirà al messaggio che stiamo per postare:

    POST
    340 Send Article to be Posted
    From: umberto-salsi@libero.it
    Newsgroups: it.test
    Date: Thu, 06 Dec 2001 14:03:57 GMT
    Subject: Era una notte buia e tempestosa...
    
    ....e allora sono rimasto a letto!
    .
    240 Article Posted

Notare che ho messo 4 punti di ellissi. Domanda: perché?
Bene, l'articolo è "posted". In conseguenza del campo di intestazione Newsgroups, questo messaggio apparirà a tutti coloro che andranno a leggere il gruppo o i gruppi lì specificati. Andiamo subito a vedere se il messaggio è stato veramente digerito:

    GROUP it.test
    211 36298 2 37004 it.test

Adesso l'ultimo articolo del gruppo è il numero 37004: scommettiamo che è proprio il mio?

    ARTICLE 37004
    220 37004 <xfH_7.23394$%B.814418@twister2.libero.it>
    Path: twister2.libero.it!cyclone2.libero.it!twister2.libero.it.POSTED!not-for-mail
    From: umberto-salsi@libero.it
    Newsgroups: it.test
    Subject: Era una notte buia e tempestosa...
    Lines: 1
    Message-ID: <xfH_7.23394$%B.814418@twister2.libero.it>
    Date: Tue, 08 Jan 2002 18:54:21 GMT
    NNTP-Posting-Host: 151.26.153.232
    X-Complaints-To: abuse@libero.it
    X-Trace: twister2.libero.it 1010516061 151.26.153.232 (Tue, 08 Jan 2002 19:54:21 MET)
    NNTP-Posting-Date: Tue, 08 Jan 2002 19:54:21 MET
    Organization: [Infostrada]
    Xref: cyclone2.libero.it it.test:37004

    ....e allora sono rimasto a letto!
    .

Bene, tutto come previsto: l'articolo è disponibile alla lettura del mondo intero. Spiace, adesso, dover cancellare questa perla di saggezza, ma dovrò farlo per tenere fede all'impegno didattico che mi sono assunto. Pazienza. Prendo nota dell'ID che mi ha attribuito il server e confeziono il seguente messaggio di cancellazione:

    POST
    340 Send Article to be Posted
    From: umberto-salsi@libero.it
    Newsgroups: it.test
    Date: Thu, 06 Dec 2001 14:03:57 GMT
    Control: cancel <xfH_7.23394$%B.814418@twister2.libero.it>
    Subject: Era una notte buia e tempestosa...
    
    .
    240 Article Posted

Il corpo del messaggio l'ho omesso: quello che conta sono il campo Control e l'indirizzo del mittente. Piccolo controllo:

    GROUP it.test
    211 36298 2 37004 it.test
    ARTICLE 37004
    423 No Such Article In Group
    QUIT
    205 GoodBye
    Connection closed by foreign host.

Et voilà, l'articolo c'era e adesso non c'è più, al suo posto c'è un bel buco.

Avvertenze:

- Nei miei esempi l'articolo appena postato risulta immediatamente disponibile alla consultazione. Non sempre le cose sono così immediate. Innanzitutto alcuni gruppi sono moderati, il chè significa che il nostro articolo non apparirà fintanto che il moderatore, tipicamente un umano, non avrà provveduto ad approvarlo. Questa eventualità la si desume dalla risposta al comando LIST, dove abbiamo visto compare anche un flag che marca i gruppi moderati.

- Inoltre, alcuni newsserver raccolgono gli articoli postati, ma li integrano nel loro data base solo in un secondo tempo, magari dopo un ritardo che può andare da pochi secondi ad alcuni minuti. Questo ritardo non è prevedibile, ma varia da sistema a sistema. Ricordiamoci che i newsgroup non sono una chat-line.

- Alcuni programmi client per i newsgroup si aspettano di ritrovare l'articolo appena postato entro pochi secondi, in modo da ricavare il message ID che il server ha assegnato a questo messaggio; l'ID viene poi memorizzato dal programma per suo uso interno. Questa è una funzionalità avanzata molto interessante, ma che può avere alcune controindicazioni: se il programma non trova il messaggio appena postato entro il tempo massimo previsto, presume un problema di trasmissione e ri-posta l'articolo più e più volte, con le conseguenze facilmente immaginabili.

- L'uso dei newsgroup comporta il rivolgersi a platee magari molto vaste ed eterogenee di persone, per cui il rigoroso rispetto della netiquette e delle comuni regole di civiltà sono requisiti indispensabili per ogni partecipante.

Mini-test di autovalutazione

Gli argomenti esposti in questi due articoli sono veramente tanti, e volerli esplorare a fondo probabilmente richiederebbe mesi di studio. Tuttavia alla conclusione di questa introduzione ai principali protocolli di Internet spero di avere suscitato nel lettore, oltre alla normale fatica e noia dello studio, anche qualche idea e qualche suggestione. Se è così, ecco un mini-test di autovalutazione. Prova a rispondere a queste domande, senza barare:

- Non s'è capito un accidente.
Rispondere: [Sì] [No]

- Ho inviato un email a tizio@qualcosa.it...
Rispondere: [Sì] [No]

- ...ma è successo qualcosa che non ci si capisce niente, e non ha funzionato!
Rispondere: [Sì] [No]

- Ho letto tutto, ma proprio tutto, questo articolo e anche il precedente.
Rispondere: [Sì] [No]

- Ho provato tutti gli esempi di interazione con telnet...
Rispondere: [Sì] [No]

- ...ma il computer mi risponde sempre BAD COMMAND OR FILE NAME.
Rispondere: [Sì] [No]

- Però! ganzo 'sto telnet! Proviamolo con altri protocolli!
Rispondere: [L'ho pensato] [Non l'ho pensato] [Ma insomma, cos'è 'sto telnet?]

- Esprimi, con parole tue, i pregi di questa opera.
Scrivere entro lo spazio predisposto:
[_________________________________________________________________]
[_________________________________________________________________]
[_________________________________________________________________]
[_________________________________________________________________]

- Esprimi, con parole tue, i difetti di questa opera.
Scrivere entro lo spazio predisposto:
[_____]

Hai risposto a tutte le domande? Bene. Adesso concentrati, prendi un calcolatore tascabile e procedi così: somma i punteggi relativi alle risposte affermative, sottrai le risposte negative, moltiplica per 3.14 ed estrai la radice quadrata, aggiungi un numero a casaccio e, se negativo, indica 0; a questo punto ignora il risultato che hai ottenuto, e valuta da solo le tue risposte.

Conclusioni

Con questo secondo articolo si conclude la mini-serie dedicata ai protocolli fondamentali. Non mi nascondo che l'argomento che ho trattato è molto vasto e complesso, per cui non mi illudo di essere stato esaustivo, nè tantomeno infallibile. Ecco perché ho già predisposto una pagina WEB all'indirizzo http://digilander.iol.it/salsi/erratacorrige dove ospitare le inevitabili correzioni e le integrazioni che si dovessero rendere necessarie. Ovviamente, si tratta di una vile manovra scaramantica.

Non mi rimane che augurarmi di essere stato utile a qualcuno, e invito a riflettere su quanto sia stato produttivo nell'interesse generale adottare protocolli di rete pubblici.

Lunga vita agli RFC!

Bibliografia

www.rfc-editor.org - Sito ufficiale dove vengono pubblicati e archiviati i documenti RFC.
RFC 854 - Specifiche del protocollo Telnet.
RFC 977 - Specifiche del protocollo NNTP.
RFC 1036 - Standard for interchange of USENET messages.
RFC 1216 - Protocollo ULS (ultra-low speed) e Poste Italiane.
RFC 1641 - Using Unicode with MIME.
RFC 1700 - Numeri assegnati ai protocolli IP e alle porte TCP, elenco dei tipi MIME e dei charset registrati.
RFC 1855 - Netiquette.
RFC 1939 - Specifiche del protocollo POP-3.
RFC 2026 - The Internet standards process.
RFC 2045, 2046, 2047, 2048, 2049 - Specifiche del formato MIME. Vedi anche RFC 2231.
RFC 2076 - Elenco dei campi di intestazione dei messaggi Internet, con descrizione e riferimenti.
UNICODE: The Unicode Consortium (www.unicode.org).
RFC 2152 - UTF-7 - A mail-safe transformation format of Unicode.
RFC 2279 - UTF-8, a transformation format of Unicode and ISO 10646.
RFC 2821 - Specifiche del protocollo SMTP (ex RFC 821).
RFC 2822 - Specifiche di formato per i messaggi Internet (ex RFC 822).
RFC 3160 - The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force.
www.ietf.org - Sito dell'IETF.
Autori vari, Segreti spie codici cifrati - Crittografia: la storia, le tecniche, gli aspetti giuridici, Ed. Apogeo, 1999, ISBN 88-7303-483-7.
S.Singh, Codici & Segreti, Ed. Rizzoli, 1999, ISBN 88-17-86213-4.
RSA Laboratories, RSA Laboratories Frequently Asked Questions About Today's Cryptography, Version 4.1, Ed. RSA Security Inc., 2000 (disponibile on-line su www.rsasecurity.com).


L'autore

Umberto Salsi <umberto-salsi@libero.it> ha scritto il suo primo programma nel 1981: un potente ciclo FOR stampava su schermo i numeri da 1 a 10000. Folgorato da questo successo, da allora non ha più smesso di seviziare computer nel software e nell'hardware, e di queste pratiche ne ha fatto il suo lavoro e il suo hobby. Nel 1992 scopre Internet e il mondo delle reti telematiche. Nel 1996 incontra GNU/Linux, ed è un'altra infatuazione.


<- SL: Backup - Copertina - La documentazione libera si fa in tre ->