|
|
<- SL: Backup - Copertina - La documentazione libera si fa in tre -> |
|
Sistemi Liberi
L'articoloSi 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. |
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.
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.
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:
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.
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:
umberto-salsi@libero.itdodo@websic.commono@qui.linux.itmail.libero.itDi 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 hostnameReceived, per cui è meglio evitare di scegliere
nomi imbarazzanti.MAIL FROM:<mittente>RCPT TO:<destinatario>DATAQUITNegli 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.
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.
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.
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.
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.
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: €
- Ecco come lo visualizza il tuo browser: €
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.
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.
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.
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.
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.
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-IDARTICLE nGROUP gruppoLIST
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 hhmmssPOSTDATA 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
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.
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.
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!
www.rfc-editor.org -
Sito ufficiale dove vengono pubblicati e archiviati i documenti RFC.www.unicode.org).www.ietf.org -
Sito dell'IETF.www.rsasecurity.com).
L'autoreUmberto 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 -> |
|