Cos’è Usenet

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

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

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.

I messaggi in Usenet

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.

Ciascuna riga termina con il carattere di controllo di ritorno carrello (carriage-return) o di avanzamento riga (line-feed).

Alcune righe di intestazione sono obbligatorie, altre opzionali.

Le righe obbligatorie sono:

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.

Le righe opzionali sono:

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 “;”).

Il formato dei messaggi USENET

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

Il campo Content-Transfer-Encoding indica quale “mappa” di conversione è stata adottata per convertire i dati originari per renderli “adatti” al loro trasporto.

I valori per il campo Content-Transfer-Encoding sono i seguenti:

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’RFC1521.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.
Attachment		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	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	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.

I Newsreader

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.

________________