USENET

Tratto dalla Tesi di diploma "Il lessico dei Newsgroups di argomento religioso: lo studio di quattro casi esemplari con applicazione dello Spad-T®"

Cos’è Usenet   Indice

<< Usenet riguarda le persone […] Usenet è l’insieme delle persone che sanno cos’è Usenet >>. [ Dern, 1995: 197]

NetNews, più comunemente chiamata Usenet, è un sistema condiviso (sharing system) di messaggi che provengono da tutto il mondo in un formato standard. In poche parole Usenet è una comunità mondiale di bacheche elettroniche (BBS), strettamente associate ad Internet, le cui informazioni sono costituite da singoli messaggi, ciascuno dei quali può essere letto e condiviso da molti utenti. I messaggi sono organizzati in gruppi di argomenti o "Newsgroup".

Usenet comprende molti computer in molte organizzazioni e sedi diverse.

Gli utenti di Usenet leggono e forniscono contributi (affiggono messaggi) nella sede Usenet locale. Ogni sede Usenet distribuisce le affissioni dei suoi clienti alle altre sedi Usenet in base ai vari parametri di configurazione impliciti ed espliciti e a sua volta riceve affissioni dalle altre sedi.

Tramite Usenet milioni di utenti di computer in tutto il mondo condividono informazioni, presentano domande e risposte, conducono discussioni tra più utenti.

Esistono pacchetti software speciali per gli utenti di Usenet (Newsreader per la lettura e l’affissione di messaggi).

<< Usenet non è un’organizzazione. Nessuna persona o gruppo ha autorità su Usenet nel suo insieme. Nessuno controlla chi riceve un contributo, quali articoli sono propagati nelle varie sedi, chi può affiggere gli articoli o qualsiasi altra cosa. Non esiste un’azienda Usenet, né un gruppo di utenti Usenet: ogni utente è solo >>. [ Dern, 1995: 198].

I messaggi Usenet viaggiano con qualsiasi mezzo, che può essere UUCP (Unix to Unix copy), in cui i computer effettuano chiamate da modem a modem e inoltrano le copie di tutti i messaggi appropriati, oppure attraverso Internet e anche via radio, dischetto, nastro di backup e CD-Rom.

Le origini di Usenet   Indice

Usenet nacque nel 1979 quando due studenti della Duke University nella Carolina del Nord – Tom Truscott e Jim Ellis – pensarono di collegare i rispettivi computer per scambiare informazioni avvalendosi di servizi UUCP (Unix to Unix copy) che erano appena stati aggiunti in una nuova versione del sistema operativo Unix. Steve Bellovin, a quei tempi studente presso la University of North Carolina, scrisse un software che gestiva lo scambio dei messaggi e che fu installato nei computer delle due università. Il servizio prese il nome "News" e le sedi che lo fornivano divennero note come Usenet (reti di utenti Unix).

Negli anni successivi questi ed altri membri della comunità Unix, tra cui Steve Daniel, Mark Harton, Matt Glickman e Rick Adams, scrissero nuove versioni del software ‘News’ per la lettura, l’affissione e la distribuzione di messaggi News attraverso la rete Usenet in continua espansione.

Nella metà degli anni Ottanta, il servizio Usenet si era diffuso nei sistemi Unix di migliaia di università e organizzazioni operanti nel settore della fabbricazione e dell’uso dei computer. Vennero adottate convenzioni per coordinare il collegamento delle sedi Usenet, l’avviamento di nuovi gruppi News e le regole sociali.

Alla fine degli anni Ottanta, la rete Usenet si era già affermata come risorsa principale per discussioni e sviluppi tecnici all’interno di Unix, di TCP/IP e delle comunità Internet, oltre che come comunità pienamente autonoma.

Nei primi anni Novanta Usenet è disponibile in tutti i continenti, compresa l’Antartide.

La suddivisione nei vari Newsgroup delle migliaia di articoli affissi ogni giorno in Usenet contribuisce ad identificare quali messaggi vale la pena di leggere. Tuttavia anche questo può non essere adeguato: un gruppo di notizie può arrivare facilmente a decine e anche centinaia di affissioni quotidiane.

Un metodo per ovviare a questo inconveniente è il "concatenamento" dei messaggi, ovvero interconnettendo gli articoli secondo l’ordine delle risposte. Ogni catena di discussioni è un albero di articoli, in cui tutti gli articoli di risposta (figli) si diramano dai rispettivi articoli di origine (genitori).

L’argomento di un articolo è definito come il contenuto del relativo campo "Subject".

L’RFC (Request for Comments) 1036 (Standard for Interchange of USENET Messages) reperibile all’indirizzo Internet http://www.ietf.org/ è un documento che contiene tutti i riferimenti per il formato standard dei messaggi Usenet e per alcuni standard di trasmissione delle "News".

La regola è che tutti i messaggi Usenet devono essere formattati come messaggi di posta Internet in accordo con l’RFC 822.

Lo standard Usenet è però più restrittivo rispetto lo standard Internet. Si hanno infatti alcune necessità in più e l’impossibilità di usare alcune caratteristiche di Internet.

In generale, comunque, è possibile scrivere un messaggio Usenet con un tool per comporre messaggi di posta Internet.

I messaggi Usenet sono composti da una intestazione, costituita da una serie di righe di testo (header lines) seguita dal "corpo" del messaggio (body).

L’intestazione è separata dal corpo da una riga vuota (null line).

Ciascuna riga dell’intestazione è formata da:

• una parola chiave o nome del campo (field-name) scritta in caratteri stampabili ASCII che hanno valore tra il 33 ed il 126, eccetto il carattere ":"

• il carattere ":"

• uno spazio

• altre informazioni addizionali.

• From: contenente l’indirizzo di posta Internet della persona che ha spedito il messaggio. Esso può contenere il nome completo della persona fra parentesi dopo l’indirizzo di posta. L’RFC 822 infatti specifica che tutto il testo fra parentesi è interpretato come un commento. In questo caso, il nome completo non è considerato come un commento ma come una parte opzionale della riga d’intestazione.

Il campo From può anche contenere il nome tra parentesi angolari, inoltre il nome dell’utente dovrebbe essere riportato tutto in minuscolo in quanto "case sensitive" (sensibile alle lettere minuscole/maiuscole).

Tutti validi sono i seguenti esempi:

- From: alessandro@libero.it

- From: alessandro@libero.it (Alessandro Rossi)

- From: Alessandro Rossi <alessandro@libero.it>

mentre l’indirizzo Alessandro@libero.it è differente, ad esempio da alessandro@libero.it.

Il nome completo può contenere tutti i caratteri stampabili ASCII eccetto i seguenti:

")", "(", "<", ">", ",", ":", "@", "!", "/", "=", ";".

• Date: contenente la data in cui il messaggio è stato originariamente spedito, l’ora, i minuti i secondi della sua spedizione ed un offset (compensazione) di +/- ore e minuti.

• Newsgroup: nel quale è riportato il nome del Newsgroup o dei Newsgoups di appartenenza del messaggio. Diversi nomi sono separati da una virgola.

• Subject: ovvero l’oggetto del messaggio. Se il messaggio è stato spedito in risposta ad un altro messaggio il Subject inizierà con quattro caratteri: "Re: ". In questo caso la riga d’intestazione "References: " è richiesta.

• Message-ID: contenente un identificatore del messaggio. Posto tra parentesi angolari deve avere questo formato: <numero identificativo@numero completo del dominio o dell’host attraverso cui il messaggio è entrato nel Network>

• Path: indica il percorso preso dal messaggio per arrivare nel sistema. I segni di punteggiatura (tranne il punto) separano i vari percorsi oppure i commenti.

• Organization: contenente l’organizzazione alla quale il sottoscrittore (o la sua macchina) del messaggio appartiene;

• References: contenente un numero di riferimento, ovvero il "Message-ID" del messaggio del quale il presente ne è una risposta.

• Reply-to: contenente l’indirizzo presso il quale devono essere indirizzati i messaggi di risposta. Per questo campo ritroviamo la stessa sintassi vista per il campo From:

• Sender: contenente il riferimento della persona o ente responsabile dell’accesso nella rete.

• Follow-up: contenente i Newsgroups o il Newsgroup presso cui una copia del messaggio è stata spedita.

• Expires: contenente la data in cui il messaggio scade e può essere cancellato. Se non presente si assume come data di scadenza quella impostata di default.

• Content: se presente indica che il messaggio è un messaggio di controllo, non rivolto all’utente, derivante dal meccanismo del Newsgroup. Se non presente, il campo Subject: può essere usato per gli stessi scopi: se i primi quattro caratteri del Subject sono "cmsg" significa che il messaggio è di controllo.

• Distribution: in aggiunta al campo Newsgroup: altera la distribuzione dei messaggi. Potrebbe essere ad esempio usato per limitare la distribuzione dei messaggi ad utenti di alcune zone. Diversi nomi sono separati da una virgola.

• Summary: contenente un breve sommario del messaggio.

• Approved: è presente per i messaggi indirizzati ai Newsgroup moderati. Potrebbe essere aggiunto dal moderatore e contiene il suo indirizzo di E-mail.

• Lines: contiene il numero di righe del corpo del messaggio.

• Xref: contiene il nome dell’host (senza dominio) ed il nome del Newsgroup (separati da uno spazio vuoto) insieme ad altre informazioni circa il numero progressivo del presente messaggio ed il numero totale dei messaggi presenti nel Newsgroup stesso (questi ultimi separati dal carattere ";").

Mentre l’RFC 822 specifica i dettagli circa l’intestazione dei messaggi, l’RFC 1521 definisce il formato del "corpo" del messaggio.

Lo standard della posta elettronica così come descritto nell’RFC 821 e 822, limita il contenuto dei messaggi a linee di testo ASCII a 7 bit non più lunghe di 1000 caratteri, consentendo l’uso dei caratteri stampabili fino al valore ASCII 128.

Tale limitazione non permetterebbe l’adozione di un particolare insieme (set) di caratteri diverso da quello ASCII a 7 bit, né l’invio di dati in formato binario (non testuale), come immagini e audio.

Per ovviare a questo inconveniente i programmi di invio e ricezione delle "News" o delle "Mail" ("Local mail user Agent", ovvero programmi, con i quali gli utenti spediscono e ricevono messaggi) implementano un sistema di conversione (codifica) standard di tutti i dati non testuali in caratteri stampabili ASCII a 7 bit.

A ciò si unisce l’estensione del servizio SMTP "Simple Mail Transfer Protocol" (protocollo di trasmissione delle mail) - così come riportato nell’RFC 1426 - che consente il trasporto di messaggi MIME a 8 bit.

L’estensione SMTP lascia, però, la possibilità di limitare la lunghezza delle linee di testo le quali possono continuare ad essere non più lunghe di 1000 caratteri.

L’RFC 1521 introduce nuovi campi d’intestazione che definiscono il formato del corpo del messaggio e consentono una compatibilità tra tutti i programmi di posta elettronica.

Eventuali campi o valori dei campi stessi, al di fuori dello standard decretato dall’RFC 1521, devono essere indicati facendoli precedere dai caratteri "X-".

I campi standard sono i seguenti:

• Mime-Version: che riporta la versione dello standard MIME adottato per il corpo del messaggio. Il campo ha la seguente struttura:

Version: = "Mime-Version": "1digit (intero)"."1digit (intero)" .

I commenti possono essere inseriti tra parentesi dopo il numero di versione MIME, in accordo con l’RFC 822.

In assenza del campo Mime-Version il corpo del messaggio viene interpretato come testo in caratteri US-ASCII.

• Content-Type: che descrive il tipo di dati contenuti nel corpo del messaggio di modo che il programma di posta (Local mail user Agent) possa rappresentare in modo appropriato il messaggio stesso.

Il Content-Type può riportare 7 valori, ciascuno con alcune varianti. Tali valori possono essere scritti sia in caratteri maiuscoli che minuscoli.

Se il Content-Type non è specificato si assume che il corpo del messaggio è rappresentato da informazioni testuali in caratteri US-ASCII.

I valori sono i seguenti:

text	Informazioni testuali	/plain nota	Testo non formattato per cui non è richiesto software speciale per tradurre il corpo del messaggio
		/richtext	Testo formattato secondo le specifiche riportate nell’RFC 1341 e compatibile con il linguaggio SGML. È richiesto software speciale per tradurre il corpo del messaggio. Tale software può essere un SGML editor/viewer .
		/enriched	Testo formattato compatibile con le specifiche riportate nell’RFC 1563. La formattazione enriched è un raffinamento di quella richtext specificata sopra.
		/html	Testo formattato compatibile con le specifiche riportate nell’RFC 1866. È richiesto software speciale per tradurre il corpo del messaggio.
multipart nota	Nel corpo del messaggio si possono trovare diversi tipi di dati - testuali e non - combinati assieme.	/mixed	Ciascuna parte (ordinata) del corpo del messaggio è indipendente e deve essere interpretata secondo un preciso ordine. Ordine dato dai boundary (vedere nota a piè di pagina).
		/alternative	Sintatticamente identica al valore /mixed, indica che le parti (ordinate) in cui è diviso il corpo del messaggio sono "alternative" perché trattasi uno stesso tipo d’informazione in formati intercambiabili. In tal caso si può scegliere, tra i diversi tipi della stessa informazione, quella migliore per le caratteristiche del sistema in uso. L’ultima parte è quella più fedele rispetto all’originale. [Vedere Appendice A per un esempio].
		/digest	Ciascuna parte (ordinata) in cui è diviso il corpo del messaggio è a sua volta un messaggio formattato secondo lo standard decretato dall’RFC 822. Il valore del Content-Type è automaticamente portato al valore message/rfc822.[Vedere Appendice A per un esempio].
		/parallel	Non ha importanza l’ordine delle parti in cui è diviso il corpo del messaggio, così come avveniva per i valori precedenti: esse vengono rappresentate simultaneamente nel sistema.
message	Indica la incapsulazione di un messaggio: il corpo di un messaggio è esso stesso un messaggio che segue lo standard dell’RFC 822 o parte di esso.	/rfc822	Il messaggio incapsulato segue lo standard decretato dall’RFC 822. Non sono richiesti i campi "From", "Subject" e "To" per il messaggio incapsulato.
		/partial nota	È usato quando il messaggio incapsulato è molto grande. In questo caso il programma di posta incapsula il messaggio spezzandolo in diverse mail che verranno riassemblate dal programma che le riceverà.
		/external-body nota	Il corpo del messaggio non è incluso, bensì esterno, ovvero disponibile altrove sotto forma di file.
application	Le informazioni sono di tipo binario: sono necessari dei programmi esterni per la interpretazione.	/octet-stream nota	Dati binari non interpretabili: è consigliabile scrivere le informazioni su di un file.
		/postscript	Indica la presenza di un programma postcript.
image	Il corpo del messaggio contiene una immagine	/gif /jpeg /…	Sono i vari formati che si possono trovare. La lista non è esaustiva.
audio	Il corpo del messaggio contiene dell’audio	/basic	Ad indicare un audio codificato ad 8 bit mono PCM.
video	Il corpo contiene delle immagini in sequenza con audio	/mpeg	I dati sono codificati secondo lo standard mpeg

• Content-Transfer-Encoding: indica il tipo di trasformazione che i dati hanno subito per il loro trasporto. All’inizio del paragrafo si è specificato che i programmi, con i quali gli utenti spediscono e ricevono messaggi implementano un sistema di conversione (codifica) standard di tutti i dati non testuali in caratteri stampabili ASCII a 7 bit. E a ciò, si è visto, si unisce l’estensione del servizio SMTP "Simple Mail Transfer Protocol" (protocollo di trasmissione delle mail) che consente il trasporto di messaggi MIME a 8 bit.

7bit:	significa che i dati sono tutti rappresentati in linee lunghe non più di mille caratteri US-ASCII.
8bit:	significa che i dati sono rappresentati in linee lunghe mille caratteri i quali possono essere anche non-ASCII;
binary:	significa che i dati sono rappresentati in linee più lunghe di mille caratteri i quali possono essere anche non-ASCII
base64:	significa che è stato adottato un algoritmo di codifica per i dati. L’algoritmo è spiegato nell’RFC 1521 a pag.21. I dati codificati sono il 33% più lunghi dei dati non codificati.
quoted-printable	significa che è stata apportata una codifica per cui si sono adottati i soli caratteri stampabili ASCII. La codifica investe gli spazi vuoti e le interruzioni di linea. Ciò assicura che i dati stessi non vengano cambiati durante il loro trasporto. Le regole di questa codifica sono indicate a pag.18 dell’RFC 1521. Si riporta un piccolo esempio esplicativo. Il carattere "=" (ASCII 61) è rappresentato come "=3D" (corrispondente al suo valore esadecimale).

• Nota: uno dei metodi di codifica dei dati (ora poco usato, perché soppiantato dallo standard MIME) è lo UUENCODE. Lo UUENCODE è un metodo di compressione UNIX che converte un file binario in caratteri ASCII. Tale conversione è effettuata dal Local mail user Agent che provvederà ad inserire il file codificato sotto forma di caratteri ASCII nel corpo del messaggio. Il file codificato inizierà con la scritta "begin 644" più il nome del file e terminerà con la scritta "end".

• Content-Description: (opzionale) In cui viene riportata una breve descrizione testuale del corpo del messaggio sottostante.

• Content-ID: (opzionale) Sintatticamente identico al "Message-ID" specificato nell’RFC 822, serve ad identificare il corpo del messaggio. Tale identificatore è utile laddove si vuole creare un riferimento ad un altro corpo.

L’RFC 2183 specifica un nuovo campo (opzionale) d’intestazione per i messaggi MIME: il Content-disposition. Di seguito si riportano i valori per questo campo ed i loro parametri. I parametri sono separati tra loro dal carattere ";".

Attachment	La parte del corpo sottostante è posta in allegato, ovvero è separata dal resto del corpo e la sua visione non è immediata, ma soggetta ad alcune azioni proposte dal Local mail user Agent.	filename=	Nome del file suggerito.
		creation-date=	Data di creazione del file.
Inline	La parte del corpo sottostante può essere visionata insieme al resto del corpo del messaggio. Tale opzione risulta utile quando bisogna includere in un messaggio del testo. Informazioni non testuali verranno interpretate separatamente dal Local mail user Agent.	modification-date=	Data in cui il file è stato modificato
		read date=	Data in cui il file è stato letto l’ultima volta.
		size parameter=	Lunghezza approssimativa del file.

Note

• Alcuni Local mail user Agent hanno come opzione quella di inserire un file direttamente nel corpo del messaggio come se fosse del testo. In tal caso viene effettuato un algoritmo di codifica a livello locale che traduce le informazioni binarie in testo. Ciò risulta utile, appunto, per l’accorpamento di file di testo.

Il processo è irreversibile.

• L’RFC 1740 decreta che in genere i documenti di testo Apple Macintosh possono essere spediti con tutti i criteri specificati dallo standard MIME. I File binari Apple Macintosh vengono codificati secondo i formati AppleSingle o AppleDouble. Ciò viene indicato nell’intestazione del messaggio MacMIME secondo le specifiche indicate nell’RFC 1740.

• L’RFC 2387 introduce un nuovo valore per il campo "Content-type: ". Il multipart/related. Esso indica un meccanismo per aggregare le parti in cui il corpo del messaggio è diviso. È usato nelle applicazioni MIME-PEM (vedere più sotto) e MIME-Macintosh.

• I suoi parametri separati dal carattere ";" sono:

type="dichiarazione" (obbligatorio) Permette al Local mail user Agent di determinare il valore del Content-type della parte del corpo sottostante senza riferirsi alla sua intestazione.

start="informazioni" (opzionale) Contiene il Content-ID della parte del corpo che deve essere processata per prima.

start-info="informazioni" (opzionale) Contiene delle stringhe che costituiscono dei parametri (command line parameters) necessari per processare le parti del corpo aggregate. Un esempio è un file eseguibile che necessita di alcuni parametri prima della sua esecuzione.

• Esistono alcune applicazioni che servono per assicurare la privacy della posta inviata. Le MIME-PEM ed il formato PGP dei messaggi, nascono con questo intento: sono infatti dei sistemi di criptazione ed autenticazione delle mail.

Le MIME-PEM seguono un approccio di criptazione sia simmetrico che asimmetrico, mentre il formato PGP si basa su di un sistema di criptazione asimmetrico.

Un messaggio criptato MIME-PEM lo si riconosce perché il corpo è incapsulato tra le due stringhe

"-----BEGIN PRIVACY-ENHANCED MESSAGE-----" e

"-----END PRIVACY-ENHANCED MESSAGE-----". Esso, perciò avrà la seguente struttura:

Pre-Encapsulation Boundary (Pre-EB) Ovvero il boundary (numero di confine) indicati anche nell’intestazione del messaggio

-----BEGIN PRIVACY-ENHANCED MESSAGE-----

Righe d’intestazione in formato testo contenenti informazioni circa la criptazione e la chiave di criptazione

Una riga vuota di separazione

Testo del messaggio criptato

Post-Encapsulation Boundary (Post-EB)

-----END PRIVACY-ENHANCED MESSAGE-----

• Un messaggio criptato PGP è più complesso. L’RFC 2015 specifica la struttura di un messaggio criptato PGP. In particolare il campo d’intestazione Content-Type: si arricchisce di due nuovi valori con relativi parametri. I parametri sono separati tra loro dal carattere ";".

Essi sono:

multipart /encrypted nota	Indica che il messaggio è stato criptato	protocol= "application/pgp-encrypted"	Protocollo usato per la criptazione
multipart /signed	Indica un messaggio firmato	protocol= "application/pgp-signature"	Protocollo usato per la firma
application /pgp-keys nota	Usato solo per la distribuzione della chiave pubblica.

Bisogna notare che esiste anche un metodo combinato in cui in una unica operazione il messaggio viene firmato e criptato. In questo caso si incapsula un messaggio nell’altro [si rimanda all’appendice A per un esempio].

Comunque tutte queste operazioni sono trasparenti all’utente perché affidate interamente al Local mail user Agent.

Quello che l’utente può incontrare è un testo che inizia con la scritta "-----BEGIN PGP MESSAGE-----" oppure "-----BEGIN PGP SIGNED MESSAGE-----" in cui può incontrare un insieme di caratteri incomprensibili racchiusi tra le scritte "-----BEGIN PGP SIGNATURE-----" e "-----END PGP SIGNATURE-----" oppure ancora una volta "-----BEGIN PGP MESSAGE-----" e "-----END PGP MESSAGE-----" che rappresentano la firma PGP del messaggio.

Nel paragrafo 1.3 è stato specificato che i messaggi Usenet devono essere formattati come messaggi di posta elettronica conformemente con quanto specificato con l’RFC 822.

In generale, quindi, è possibile scrivere un messaggio Usenet con un tool per comporre messaggi di posta Internet, detto anche Local mail user Agent (programma demandato alla gestione della posta che lavora nella macchina locale, ovvero nel Pc dell’utente).

Esistono però dei programmi sviluppati appositamente per gestire i messaggi Usenet. Essi vengono denominati Newsreader (programmi di lettura di notizie).

Tali programmi nascondono all’utente il modo in cui i gruppi di notizie ed i messaggi Usenet sono effettivamente memorizzati, facilitando la selezione, la lettura e la risposta ai messaggi. Essi sono in grado infatti di leggere e interpretare l’intestazione dei messaggi così da poter rappresentare le informazioni in maniera corretta.

Sono disponibili molti programmi di lettura di notizie per vari tipi di computer per sfruttare le varie interfacce utente di tipo grafico e le altre caratteristiche specifiche del computer. Molti di questi programmi sono disponibili gratuitamente, altri vengono commercializzati. Il canale di diffusione principale è Internet.

I Newsreader hanno le seguenti caratteristiche comuni:

• Registrazioni delle catene dei messaggi. I programmi di lettura delle notizie di Usenet prevedono il concatenamento, ovvero possono esaminare ordinare, selezionare e presentare all’interno di un gruppo articoli suddivisi in catene di argomenti. Questo facilita il reperimento degli articoli desiderati, consentendo di saltare quelli che non interessano.

• File di esclusione. Si tratta di file (anche detti filtri) creati e gestiti dal programma di lettura delle notizie, per indicare un elenco di persone e di argomenti a proposito dei quali l’utente non vuole leggere affissioni. Alcuni programmi di lettura di notizie consentono anche si specificare elementi quali un periodo di tempo durante il quale un comando di esclusione deve rimanere attivo.

• Formattazione dei messaggi di risposta. Nel creare commenti ad un messaggio precedente, sovente può essere utile inserire parte di tale messaggio (qouting), contrassegnandolo in qualche modo per indicare che sono parole altrui e specificando la fonte. Questa funzione consente di inserire il messaggio desiderato, solitamente rientrato e con un carattere quale ">" oppure "|" sul margine sinistro di ciascuna riga, anteponendo una riga al messaggio stesso per indicare l’autore e la data d’affissione.

___________________________________________

NOTE

BBS

Le BBS, a differenza della posta elettronica, consentono di organizzare le informazioni come risorse comuni condivise, in directory che non appartengono al singolo utente. I messaggi arrivano in aree di proprietà del software della bacheca elettronica: molti utenti possono leggere contemporaneamente la stessa copia , come se si trattasse di un giornale comune o di un avviso affisso ad un muro, mediante programmi software progettati per organizzare e leggere i numerosi messaggi. Invece di inviare un messaggio ad una persona, lo si invia, o "affigge", in un gruppo della BBS.

INTERNET

Nel settore delle reti, il termine tecnico per designare il collegamento di reti è internetworking, mentre per indicare una rete di reti viene impiegato il termine internetwork o internet. La nuova internet work, incentrata su ARPAnet fu soprannominata Internet, con la "I" maiuscola.

TCP/IP

TCP/IP è l’acronimo di (Trasmission Control Protocol/Internetworking Protocol).

ARPA ( Advanced Research Projects Agency), negli anni sessanta, attuò una serie di progetti basati sulla creazione di hardware e software per realizzare una piccola rete sperimentale basata sulla commutazione di pacchetto.

Dal progetto ARPAnet e dal concetto di internetworking (ovvero del collegamento di singole reti in un’entità più grande) si sviluppò un nuovo protocollo di comunicazione che permise l’interconnessione di reti a commutazione di pacchetto eterogenee: il protocollo TCP/IP (Trasmission Control Protocol/Internetworking Protocol).

La commutazione di pacchetto è un metodo di condivisione della linea telefonica tra computer, per cui ogni flusso di dati viene suddiviso in pacchetti. Ogni pacchetto è formato da una porzione di dati e da una sezione denominata intestazione contenente informazioni quali l’indirizzo del mittente e del destinatario, il numero di ID del pacchetto per consentire il riassemblaggio delle porzioni di dati nell’ordine esatto, l’ora della creazione del pacchetto e le informazioni per verificare che il contenuto del pacchetto sia stato trasmesso correttamente.

Il processo di trasmissione di un pacchetto prende il nome di commutazione. I pacchetti vengono commutati attraverso la rete (definita come un insieme di linee e nodi, dove le linee sono i percorsi nei quali scorrono i dati, mentre i nodi sono i punti in cui le linee si intersecano e le risorse, ovvero i dati, vengono trasferiti ad altre linee). Nella rete i pacchetti sono trasferiti da un commutatore di pacchetto (nodo) di una linea al successivo che esamina l’intestazione per decidere a quale linea commutare (o inoltrare) il pacchetto. Con la commutazione di pacchetto molti flussi di dati possono essere inseriti e mescolati su di una linea comune per essere in seguito riordinati nella loro forma originaria all’altra estremità. Grazie alle informazioni contenute in ciascun pacchetto, i pacchetti provenienti da una sorgente possono anche essere trasmessi attraverso percorsi (route) diversi e arrivare tutti a destinazione.

NEWSGROUP

Un gruppo di notizie o Newsgroup può essere diviso in sottogruppi in una sorta di gerarchia. L’assegnazione dei nomi nei Newsgroup di Usenet segue determinate convenzioni: i nomi dei gruppi e dei sottogruppi sono separati da un punto (.). Il nome della parte sinistra indica la gerarchia di massimo livello. Per esempio it.discussioni.auto indica il sottogruppo auto nel gruppo discussioni della gerarchia it (italiano).

RFC

I documenti RFC (Request for Comments) sono le serie ufficiali di documenti che definiscono gli standard e gli altri aspetti di Internet, identificati sovente con un numero di RFC (per esempio: RFC 1822) oltre che con un titolo. Scritte da sviluppatori di spicco di Internet, le Request for Comments vanno dalle specifiche dei protocolli alle proposte, alle analisi, alle specifiche, ai resoconti generali, fino ad argomenti più leggeri come saggi umoristici occasionali o argomenti culturali quali poesie.

RFC 822

L’RFC 822 è un documento che contiene i riferimenti per il formato standard dei messaggi di testo "ARPA Internet".

ASCII

ASCII è l’acronimo di American Standard Code for Information Interchange, ovvero un sistema di codifica che permette una corrispondenza biunivoca tra i numeri binari ed un insieme di caratteri (alfanumerici e di servizio). Ciò che ne deriva è una tabella su cui viene riportato il numero binario con il corrispondente carattere di riferimento. Nelle tabelle ASCII si usa indicare il valore numerico in formato decimale o esadecimale. La codifica ASCII può essere a 7 bit oppure a 8 bit. Nel primo caso comprende 2⁷=128 caratteri dei quali, quelli fino al valore decimale 31, sono caratteri di controllo non stampabili. Nel secondo caso comprende 2⁸=256 caratteri ovvero i caratteri di controllo, quelli stampabili più gli estesi.

Oltre a quella ASCII esistono altre tabelle codici nate per soddisfare esigenze diverse come quella di gestire un sistema in una lingua diversa dall’inglese.

NEWSGROUP MODERATI

I Newsgroup moderati sono Newsgroup in cui tutti i messaggi sono sottoposti al vaglio di una persona definita il moderatore del gruppo. Il moderatore dovrà decidere della pertinenza di ciascun messaggio all’argomento del Newsgroup.

RFC 1521

L’RFC 1521 decreta lo standard MIME (Multipurpose Internet Mail Extensions).

RFC 1426

L’RFC 1426 decreta l’estensione ad 8 bit del servizio MIME.

CHARSET

Un parametro aggiuntivo, indicato insieme al valore /plain e separato da questo dal carattere ";" è charset, ovvero il set di caratteri adottato per comporre il mesaggio. Un set di caratteri è sostanzialmente una tabella in cui, per ogni carattere è riportato l’equivalente codice binario o esadecimale. La composizione e interpretazione del testo del messaggio avviene ad opera del Local mail user Agent che deve avere a disposizione, nel sistema, la tabella codice. Alcune tabelle codice sono le seguenti:

US-ASCII (ASCII); ISO-88591 (Latina: Europa occidentale); ISO-88592 (Latina: Europa centrale/est). Per una lista esaustiva riferirsi all’RFC 1521 pag. 28.

RFC 1341

L’RFC 1341 decreta lo standard MIME. È stato sostituito dall’RFC 1521. Ma la parte che riguarda il testo richtext è ancora valida.

SGML

SGML è l’acronimo di Standard Generalized Mark-up Language. Un documento in linguaggio SGML contiene due tipi d’informazione: la struttura ed il contenuto. La struttura è determinata da particolari istruzioni sempre in formato testo (Murk-up tags) racchiuse tra parentesi angolari . Il contenuto è rappresentato dal testo racchiuso tra i Murk-up tags. Per struttura si intendono le parti logiche di un documento (Capitoli, sezioni, paragrafi, ecc.) [http://www.techapps.co.uk/iihb_sgml.html]

EDITOR/VIEWER SGML

Sono programmi per comporre o semplicemente visualizzare documenti scritti in SGML. Nell’RFC 1341 (sostituito dall’RFC 1521) (Appendice D) viene proposto un semplice programma in 44 linee per tradurre un testo in "richtext" in "plain text".

RFC 1563

L’RFC 1563 (The text/enriched MIME Content-type) specifica la sintassi del testo formattato "enriched".

RFC 1866

L’RFC 1866 definisce la sintassi dell’HTML (Hypertext Markup Language, simile all’SGML di cui sopra) nonché il valore "/html" del campo "Content-Type:"

BOUNDARY

Il corpo del messaggio in questo caso è costituito da diverse parti ciascuna delimitata da precisi confini (boundary) espressi sotto forma di caratteri alfanumerici identificativi indicati anche nell’intestazione del messaggio nel campo Content-Type. La voce boundary="caratteri alfanumerici", infatti, segue con il carattere ";" la dicitura multipart . Ciascuna parte del corpo del messaggio - incapsulata tra il valore boundary specificato nell’intestazione e preceduto dai caratteri "--" (codice ASCII decimale 45) - contiene a sua volta una intestazione ed un corpo separati da una riga vuota, in maniera simile a quella specificata nell’RFC 822 e nell’RFC 1521. Il valore del boundary preceduto e terminato dai caratteri "--" indica la fine dell’ultima parte in cui è diviso il corpo del messaggio. Il testo contenuto tra i boundary può terminare con una linea vuota (in tal caso trattasi di testo esplicito in formato ASCII. Ciò viene indicato anche nell’intestazione del boundary stesso) oppure no (in questo caso trattasi di testo implicito in formato ASCII e non è necessario indicarlo nell’intestazione del boundary). [Vedere Appendice A per un esempio]

MESSAGE/PARTIAL

Tre parametri sono richiesti nel campo Content-Type (i parametri sono indicati successivamente al valore message/partial e separati da questo e tra loro dal carattere ";"). Il parametro "id" è un identificatore unico usato per riassemblare le parti del messaggio. Il parametro "number" è un numero intero che indica la sequenza delle parti del messaggio da assemblare (la numerazione inizia da 1 e non da 0). Il parametro "total" che indica il numero totale delle parti in cui è stato scomposto il messaggio. [Vedere Appendice A per un esempio]

MESSAGE/EXTERNAL-BODY

Quando il valore del campo "Content-Type: " è "message/external-body" troviamo dei valori aggiuntivi per alcuni campi atti a descrivere determinate caratteristiche del file esterno che rappresenta il corpo del messaggio. Tali valori, separati tra loro dal carattere ";" , sono i seguenti:

Nota: alla fine dei valori spiegati appena sopra, trova posto, separata da due linee vuote, l’intestazione del corpo incapsulato nel file. Nel senso che il corpo disponibile nel file ha un’intestazione che viene riportata nel messaggio d’origine. [Vedere Appendice A per un esempio]

OCTET-STREAM

Il valore octet-stream può avere i seguenti parametri indicati in successione e separati dal carattere ";":

type: tipo o categoria del dato.

padding: numero di bit di "riempimento" usati laddove i bit totali dai dati inclusi nel corpo non sono multipli di un byte.

name: parametro introdotto già dall’RFC 1341 suggerisce il nome del file quando appunto i dati vengono salvati in un file.

RFC 1740

L’RFC 1740 (MIME Encapsulation of Macintosh files – MacMIME) decreta lo standard per l’incapsulazione dei file Apple Macintosh.

RFC 2387

L’RFC 2387 (The MIME Multipart/Related Content-type) decreta le specifiche per un nuovo valore del campo "Content-Type: " .

PEM

PEM sta per privacy-enhanced mail. I dettagli del servizio PEM sono contenuti nell’RFC 1421, 1422, 1423, 1424.

PGP

PGP sta per Pretty Good Privacy. I dettagli del formato PGP sono contenuti nell’RFC 1991, 2015 e 1847.

SIMMETRICO

Con il sistema a chiave simmetrica, un messaggio è crittato e decrittato usando la stessa chiave ; questa deve essere conosciuta sia dal mittente che dal ricevente. La chiave passa dall'uno all'altro, attraverso una transazione separata, ma il sistema è vulnerabile perchè essa può venir rubata nel momento in cui attraversa la rete.

ASIMMETRICO

PGP utilizza una tecnica di criptazione basata su chiavi pubbliche asimmetriche, che prevede la presenza di due chiavi: una pubblica, che l'autore può mettere a disposizione di chiunque inviandola a un apposito server Web e una privata, conservata solo dall'utente e protetta da un codice di accesso personale. Per trasmettere un messaggio in forma protetta è anzitutto necessario che il mittente scarichi dal server Web la chiave pubblica del destinatario e cripti con questa il documento; il destinatario potrà a questo punto decriptare la comunicazione ricevuta tramite la propria chiave privata, utilizzando il codice di accesso personale. Chiaramente è virtualmente impossibile risalire dalla chiave pubblica a quella privata, poiché gli algoritmi di criptazione utilizzati hanno raggiunto livelli di sicurezza paragonabili a quelli impiegati in campo militare, impedendo qualsiasi tentativo di decifrazione operato tramite sistemi di analisi matematica.

Per firmare elettronicamente un messaggio PGP utilizza invece un metodo inverso a quello impiegato per la criptazione e cioè adopera la chiave privata (ed il relativo codice di accesso) per apporre la firma e quella pubblica per verificare la conformità del messaggio con l'impronta generata durante la sigla.

MESSAGGIO CRIPTATO PGP

Un messaggio criptato è formato da due parti: la prima costituita da una informazione di controllo indicante la versione dell’ application/pgp-encrypted, la seconda contenente i dati criptati avente "application/octet-stream" come valore del Content-Type nell’intestazione. Ogni parte è ovviamente racchiusa tra i boundary. [Vedere l’appendice A per un esempio]

MESSAGGIO FIRMATO PGP

Un messaggio firmato è costituito da due parti: la prima contenente i dati in formato MIME, la seconda contenente la firma con " application/pgp-signature" come valore del campo Content-Type. [Vedere l’appendice A per un esempio]

QUOTING

Dall’inglese to quote: citare