Figura 315.3. Procedimento necessario a produrre un allegato.
|
|
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico] [volume] [parte]
Il messaggio di posta elettronica tradizionale è composto utilizzando soltanto la codifica ASCII a 7 bit e ha un aspetto simile all'esempio seguente:
|
Per garantire che un messaggio di posta elettronica viaggi attraverso qualsiasi servente SMTP, è necessario che si rimanga nell'ambito dei soli 7 bit, oltre al fatto di avere un limite alla lunghezza delle righe.
La necessità di scrivere in lingue differenti dall'inglese e di poter trasmettere informazioni diverse dal solito testo puro e semplice, ha fatto nascere lo standard multimediale MIME (Multipurpose internet mail extentions).
Con le estensioni multimediali MIME è possibile definire come deve essere interpretato il contenuto di un messaggio di posta elettronica, che così può essere codificato in modo particolare, per trasportare anche informazioni diverse dal solo testo ASCII puro, rispettando i limiti tradizionali dei sistemi di trasporto dei messaggi.
|
Negli esempi che si mostrano in questo capitolo, viene omessa la riga di intestazione iniziale del tipo seguente, che è essenziale per completare il messaggio, ma che qui non serve per comprendere quanto spiegato e rischia solo di creare confusione con il campo From::
|
L'invio di un file allegato a un messaggio di posta elettronica richiede un modo per inserire e circoscrivere questo file, oltre alla sua trasformazione in modo tale che possa essere gestito come un file di testo normale. In pratica, è come allegare un file a un file di testo, dal quale deve poter essere estrapolato correttamente in un momento successivo.
|
Figura 315.3. Procedimento necessario a produrre un allegato.
|
Dal momento che in un messaggio di posta elettronica alcuni caratteri, che in condizioni normali appartengono già all'ASCII standard a 7 bit, hanno un significato speciale (senza contare l'importanza di alcune parole chiave, quando collocate a partire dalla prima colonna), sono da escludere anche questi nelle trasformazioni necessarie a creare gli allegati.
La figura 315.3 mostra in modo semplificato il problema che si tenta di descrivere: un file viene prima trasformato, in base a un certo algoritmo, in un file di testo puro, che possa essere trasmesso attraverso il sistema della posta elettronica; questa trasformazione genera necessariamente un file più grande di quello di partenza; quindi, per diventare un allegato, occorre un modo per circoscriverlo, aggiungendo anche le informazioni necessarie a riprodurre il file originale (che nell'esempio della figura sono state omesse per semplicità).
Uuencode (1) è il sistema storico per la conversione di file di qualunque tipo in un allegato in forma di file ASCII, che si utilizza senza gestire le estensioni MIME. Si compone di due eseguibili: uuencode per la codifica e uudecode per la decodifica.
Il programma uuencode si comporta in maniera differente a seconda che riceva il file da codificare dallo standard input, oppure che questo gli sia indicato come argomento della riga di comando:
uuencode [-m] file_da_codificare nome_da_usare |
cat file_da_codificare | uuencode [-m] nome_da_usare |
In entrambi i casi, il risultato della codifica viene emesso attraverso lo standard output, con la differenza che nel primo caso il file da codificare viene indicato come primo argomento, mentre nel secondo viene fornito attraverso lo standard input. L'ultimo argomento è sempre obbligatorio e rappresenta il nome che si vuole attribuire a questo file, ovvero il nome che viene usato nel momento dell'estrazione.
L'unica opzione disponibile, -m, consente di richiedere espressamente l'utilizzo della codifica Base64.
Disponendo del file già visto nella figura 315.3, ovvero il testo
|
supponendo che si tratti del file prova.xxx, si potrebbe codificare con uuencode nel modo seguente:
$ uuencode prova.xxx prova.xxx > allegato.txt[Invio]
Si può osservare che il nome prova.xxx appare due volte nella riga di comando: la prima volta indica il file da leggere per la codifica; la seconda indica il nome da indicare nell'allegato, in modo che al momento della decodifica si riottenga lo stesso file. Il file allegato.txt che si ottiene ha l'aspetto seguente:
|
In alternativa, usando la codifica Base64,
$ uuencode -m prova.xxx prova.xxx > allegato.txt[Invio]
si ottiene invece:
|
Evidentemente il principio è lo stesso, cambiando il modo di delimitare il file e di indicare le sue caratteristiche.
|
Il numero che appare dopo la parola chiave begin, o dopo begin-base64, rappresenta i permessi da attribuire al file, indicato subito dopo, in ottale. Nel caso dell'esempio, trattandosi di 6648, si intendono attribuire i permessi di lettura e scrittura al proprietario e al gruppo, lasciando solo i permessi di lettura agli altri utenti. |
Naturalmente, si possono creare anche situazioni più complesse, come nel caso in cui il file di origine sia prima compresso, poi codificato e quindi trasmesso attraverso la posta elettronica:
$ cat prova.xxx | gzip | uuencode prova.xxx.gz \
\| mail tizio@dinkel.brot.dg[Invio]
In questo caso, il messaggio che deve ricevere tizio@dinkel.brot.dg è, più o meno, quello seguente:
|
uudecode funziona in modo simmetrico rispetto a uuencode. In questo caso, dal momento che il nome del file da rigenerare fa già parte delle informazioni necessarie dell'allegato, è sufficiente fornire a uudecode il file di testo contenente l'allegato. Il file in questione può anche essere un messaggio di posta elettronica, completo di intestazione, come nell'ultimo esempio mostrato per la codifica.
uudecode [-o file_da_generare] file_con_allegato... |
cat file_con_allegato | uudecode [-o file_da_generare] |
In generale non si usa l'opzione -o, a meno che ci sia la necessità di generare un file con un nome differente da quanto previsto da chi ha predisposto l'allegato.
$ uudecode allegato.txt[Invio]
L'esempio soprastante è elementare, ma rappresenta l'uso normale di uudecode. In questo caso, il file allegato.txt è ciò che contiene l'allegato, dal quale viene estratto probabilmente un file, il cui nome è già stato deciso in precedenza.
Un messaggio realizzato secondo le estensioni MIME contiene informazioni aggiuntive specifiche nell'intestazione, come si vede nell'esempio seguente:
|
In generale appare il campo MIME-Version:, che dichiara l'utilizzo delle estensioni, secondo la versione indicata, anticipando così la presenza di altri campi specifici. L'elenco seguente descrive quelli essenziali.
Content-type: tipo/sottotipo[; opzione]... |
Il campo Content-type: serve a specificare il tipo e il sottotipo MIME del messaggio. Esiste un tipo MIME particolare, che serve a dichiarare la presenza di più componenti; si tratta di multipart e viene chiarito meglio nel seguito il suo significato.
Il campo Content-type:, oltre al tipo e al sottotipo MIME, consente l'indicazione aggiuntiva di informazioni opzionali, precedute da un punto e virgola (;), che chiariscono ulteriormente le caratteristiche dell'informazione contenuta. Per esempio, quando si tratta di text/plain, può essere specificato l'insieme di caratteri con l'opzione charset=insieme_di_caratteri. In mancanza di indicazioni, l'insieme di caratteri corrisponde a us-ascii, mentre nell'esempio si vede l'uso dell'insieme iso-8859-1, corrispondente a ISO 8859-1. Segue la descrizione delle opzioni più frequenti.
charset=insieme_di_caratteri |
Definisce l'insieme di caratteri nel caso si tratti di un testo. Il valore predefinito è us-ascii, mentre iso-8859-n rappresenta una codifica secondo lo standard ISO 8859-n.
name=file |
Definisce il nome del file nel caso il contenuto venga salvato.
boundary="stringa" |
Definisce la stringa di delimitazione del confine delle componenti MIME multiple.
Content-Transfer-Encoding: codifica_per_il_trasferimento |
Il campo Content-Transfer-Encoding: serve a specificare in che modo avviene la trasformazione delle informazioni stabilite nel campo Content-type:, per le esigenze legate al trasferimento del messaggio. In pratica si tratta di indicare una parola chiave che chiarisca come interpretare il contenuto del messaggio al momento della ricezione. L'esempio mostra l'uso del tipo quoted-printable (non fa differenza l'uso delle maiuscole o delle minuscole).
Content-Transfer-Encoding: 7bit |
Si tratta della codifica predefinita, ovvero della situazione in cui non è necessario apportare alcuna trasformazione, perché si utilizzano solo i primi 7 bit e le righe di testo non sono troppo lunghe.
Content-Transfer-Encoding: 8bit |
In questo caso si tratta di un testo in cui vengono usati 8 bit, senza trasformazioni, con righe non troppo lunghe. Tuttavia, si tratta di una codifica non conveniente, perché non tutti i serventi SMTP sono in grado di mantenere invariate queste informazioni.
Content-Transfer-Encoding: binary |
Le informazioni sono inserite così come sono, senza alcuna trasformazione. In generale è impossibile trasmettere messaggi di questo tipo.
Content-Transfer-Encoding: quoted-printable |
I caratteri che richiedono l'uso di 8 bit, si rappresentano nella forma =hh, dove la coppia hh rappresenta un numero esadecimale, corrispondente al codice del carattere. In pratica, la lettera «è» si rappresenta come =E8 (come si può vedere dall'esempio); inoltre, per evitare di avere righe troppo lunghe, queste vengono spezzate ponendo il simbolo = alla fine della riga; infine, il carattere «=» viene rappresentato necessariamente come =3D.
Content-Transfer-Encoding: base64 |
Si tratta di una trasformazione in cui ogni gruppo di 24 bit (3 byte) viene trasformato in quattro caratteri (4 byte), su righe non troppo lunghe. Il nome della codifica deriva dal fatto che per ogni byte si possono rappresentare solo 64 simboli, essendo necessario escludere tutto ciò che può creare problemi alla trasmissione del messaggio. Pertanto: 224 = 643.
Questo tipo di codifica rende completamente illeggibile, a livello umano, il suo contenuto. In questo senso, si presta alla trasmissione di immagini o di altri tipi di file che non sarebbero comunque leggibili in questo modo.
Il tipo MIME multipart prevede la presenza di più componenti separate, con altrettante intestazioni specifiche. In questo caso si indica comunemente il confine tra una componente e l'altra attraverso una stringa particolare (di solito creata in modo da essere univoca), dichiarata con l'opzione boundary="stringa" nel campo Content-Type:, come si può osservare nell'esempio seguente:
|
In questo caso, la stringa -1463811839-324931406-994342670=:16889 viene usata per delimitare i vari componenti del messaggio. Si può osservare che quanto contenuto tra la fine dell'intestazione del messaggio e il primo componente MIME viene ignorato dai programmi utilizzati per leggerlo. Questa zona può essere usata per annotare informazioni tecniche destinate alla lettura umana, nel caso di un accesso diretto al file.
Si noti che ogni componente MIME è preceduto dalla stringa di delimitazione, a cui si aggiungono inizialmente due trattini (--). Alla fine, dopo l'ultimo componente la stringa di delimitazione ha altri due trattini finali. Volendo schematizzare la cosa:
Date: data From: mittente To: destinatario Subject: oggetto MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="delimitatore" [commento] ... ... --delimitatore Content-Type: tipo/sottotipo[; opzione]... Content-Transfer-Encoding: codifica_per_il_trasferimento contenuto_codificato ... ... [--delimitatore Content-Type: tipo/sottotipo[; opzione]... Content-Transfer-Encoding: codifica_per_il_trasferimento contenuto_codificato ... ...]... --delimitatore-- |
Teoricamente, un elemento MIME potrebbe scomporsi in altri sottoelementi, dichiarando nuovamente un tipo multipart, ma questo modo di intervenire è sconsigliabile.
Un caso particolare di messaggi multipart è quello che consente di trasmettere il contenuto in forme alternative, come quando si affianca un messaggio in forma testuale a una copia più appariscente in formato HTML. In tal caso si aggiunge il sottotipo alternative:
Content-Type: multipart/alternative; boundary="xxxx" |
La composizione del messaggio è analoga a quanto già visto, con la differenza che il programma che consente la lettura del messaggio ricevuto, sceglie in che modo visualizzare il contenuto.
I programmi usati generalmente per scrivere e inviare la posta elettronica sono in grado normalmente di gestire gli allegati, sia per inviarli, sia per estrarli. Ogni programma aggiunge a modo suo dei campi particolari per qualche scopo, anche se non si tratta di informazioni essenziali. Seguono due esempi, uno realizzato con Pine e l'altro con Mozilla.
|
|
Purtroppo, alcune volte può capitare di ricevere messaggi in cui gli allegati sono stati inseriri in modo non standard, oppure utilizzando standard troppo recenti. In questi casi capita di non riuscire a estrarre il contenuto in alcun modo, a meno di mettere mano direttamente al messaggio, per correggere gli errori.
|
L'esempio che si vede sopra, è ovviamente abbreviato. L'intenzione di Caio era quella di inviare un'immagine a Tizio. Si tratta precisamente del file prova.jpg, ma per qualche motivo, non si riesce a estrarla.(2)
Il messaggio inizia con una breve descrizione, seguita dalla stessa cosa in HTML. Quindi appare un primo allegato, che in realtà non serve, quindi l'ultimo allegato, che è la vera immagine cercata. Per rimediare, occorre salvare il messaggio in un file separato per poi metterci mano direttamente. Il messaggio trasformato per estrarre esclusivamente l'immagine cercata, può avere l'aspetto seguente, tenendo conto che probabilmente è necessario lasciare la prima riga di intestazione contenente il campo From ..., che però qui è stata omessa:
|
Si può osservare che il messaggio non è più di tipo MIME multiplo, così non è necessario indicare i confini con la stringa dell'opzione boundary.
Volendo, dal momento che l'immagine è stata codificata con la codifica Base64, si può usare anche Uuencode senza preoccuparsi di rispettare le specifiche MIME. Il file si riduce all'estratto seguente, dove il codice della figura è delimitato come si vede:
|
Per l'estrazione basta usare il programma uudecode, come è già stato descritto in precedenza.
Mpack (3) consente di generare allegati MIME, ovvero allegati con più informazioni e per questo più facili da estrarre. Anche in questo caso si distinguono due eseguibili: mpack per la codifica e munpack per la decodifica. Il primo, tra le altre cose, è anche in grado di inviare direttamente il risultato della codifica a un recapito di posta elettronica.
mpack [-s oggetto] [-d file_introduttivo] [-m n_caratteri] [-c sottotipo_mime] \ |
mpack [-s oggetto] [-d file_introduttivo] [-m n_caratteri] [-c sottotipo_mime] \ |
mpack [-s oggetto] [-d file_introduttivo] [-m n_caratteri] [-c sottotipo_mime] \ |
I tre modelli sintattici mostrano tutte le opzioni disponibili e i tre contesti di utilizzo di mpack. Nel primo caso, il file codificato viene inviato direttamente attraverso la posta elettronica, agli indirizzi specificati; nel secondo caso si crea un file; nell'ultimo caso si invia il file codificato a uno o più gruppi di discussione di Usenet.
È importante chiarire il significato di alcune opzioni. -d permette di indicare un file, il cui contenuto viene poi usato come introduzione all'allegato che si crea. In altri termini, permette di spiegare di cosa si tratta, senza interferire con il file da codificare. -m consente di indicare la dimensione massima, espressa in caratteri, ovvero in byte, dei messaggi. Ciò permette di creare automaticamente diversi file, oppure di inviare diversi messaggi, ognuno non eccedente la dimensione richiesta.(4) Infine, l'opzione -c consente di indicare un sottotipo MIME, dei tipi application, audio, image e video. Se non si indica questa informazione, è mpack a determinarla in modo automatico. È il caso di osservare che l'oggetto viene richiesto in modo interattivo, se non si usa l'opzione -s esplicitamente.
A titolo di esempio si può vedere cosa succede se l'utente caio invia a tizio@dinkel.brot.dg il file già visto nell'introduzione del capitolo, denominato prova.xxx:
$ mpack -s "Prova di trasmissione" prova.xxx tizio@dinkel.brot.dg[Invio]
Ciò che viene ricevuto può assomigliare al messaggio seguente, dove si può notare che la stringa di delimitazione è ridotta a un solo trattino:
|
L'uso di munpack è più semplice, dal momento che nella maggior parte dei casi è sufficiente fornire il file contenente l'allegato, come argomento oppure attraverso lo standard input:
munpack [opzioni] file_con_allegato... |
cat file_con_allegato | munpack [opzioni] |
Il file che contiene l'allegato può anche essere un messaggio di posta elettronica, in cui appare ancora l'intestazione. Tuttavia, è da tenere in considerazione che viene estratto solo il primo messaggio che contiene un allegato, salvo il caso di allegati suddivisi in più messaggi.
In condizioni normali, se il file o il messaggio contenente l'allegato è preceduto da una descrizione (un commento), questa informazione viene salvata in un file con estensione .desc.
Jerry Peek, MH & nmh: Email for Users & Programmers
<http://www.ics.uci.edu/~mh/book/>
Introduction to MIME
Overview of MIME Messages
Multipart Messages
Appunti di informatica libera 2007.02 --- Copyright © 2000-2007 Daniele Giacomini -- <daniele (ad) swlibero·org>
1) GNU Sharutils GNU GPL
2) L'esempio proviene da un caso accaduto realmente, senza che sia stato possibile chiarire il motivo della composizione errata. Viene proposto questo esempio perché reale, anche se incompleto, considerato il fatto che il mittente e il destinatario sono stati sostituiti, inoltre alcune informazioni sono state eliminate dal messaggio.
3) Mpack software libero con licenza speciale
4) In realtà la dimensione indicata con questa opzione è solo un riferimento approssimato, dal momento che i messaggi di posta elettronica e di Usenet tendono a espandersi, mano a mano che si aggiungono informazioni sul loro percorso.
Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome messaggi_allegati_ed_estensioni_mime.htm
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico]
