[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [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:
Date: Tue, 17 Jul 2001 11:27:59 +0200 From: caio@dinkel.brot.dg To: tizio@dinkel.brot.dg Subject: Messaggio tradizionale Message-Id: <E15MR95-0001Wb-00@dinkel.brot.dg> Questo rappresenta un esempio di messaggio di posta elettronica tradizionale, dove si utilizzano solo i primi 7 bit. In pratica, per quanto riguarda la lingua italiana, non si possono usare le lettere accentate. |
Per garantire che un messaggio di posta elettronica viaggi in modo 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 From daniele@swlibero.org Tue Jul 17 12:28:15 2001 +0200 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 153.1. 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 153.1 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.
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 verrà 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 153.1, ovvero il testo
lkjsdhèe9 845ry#fgg fòéùìÌÀÒÈ öüä$%&£K* |
supponendo che si tratti del file prova.xxx, si potrebbe codificare con uuencode nel modo seguente:
$ uuencode prova.xxx prova.xxx > allegato.txt
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:
begin 664 prova.xxx G;&MJ<V1HZ&4Y"C@T-7)Y(V9G9PIF\NGY[,S`TL@*]OSD)"4FHTLJ ` end |
In alternativa, usando la codifica Base64,
$ uuencode -m prova.xxx prova.xxx > allegato.txt
si ottiene invece:
begin-base64 664 prova.xxx bGtqc2Ro6GU5Cjg0NXJ5I2ZnZwpm8un57MzA0sgK9vzkJCUmo0sq ==== |
Evidentemente il principio è lo stesso, cambiando il modo di delimitare il file e di indicare le sue caratteristiche.
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
In questo caso, il messaggio che riceverà tizio@dinkel.brot.dg sarà, più o meno, quello seguente:
To: tizio@dinkel.brot.dg Message-Id: <E15L3u4-00009I-00@dinkel.brot.dg> From: caio@dinkel.brot.dg Date: Fri, 13 Jul 2001 16:26:48 +0200 begin 664 prova.xxx.gz M'XL(`"<%3SL``\O)SBI.R7B1:LEE86):5*F<EI[.E?;IY<\W9PY<.L'U[<\3 /%56UQ=Y:`#NWZ88G```` ` end |
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
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:
Date: Tue, 17 Jul 2001 12:28:23 +0200 (CEST) From: caio@dinkel.brot.dg To: daniele@dinkel.brot.dg Subject: Messaggio MIME semplice Message-ID: <Pine.LNX.4.04.10107171139070.5873@dinkel.brot.dg> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Questo =E8 un messaggio un po' pi=F9 complesso, perch=E9 consente l'uso di un insieme di caratteri pi=F9 ampio. |
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 verrà 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:
Date: Thu, 5 Jul 2001 16:38:22 +0200 (CEST) From: caio@dinkel.brot.dg To: tizio@dinkel.brot.dg Subject: Foto MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463811839-324931406-994342670=:16889" Il testo che appare qui viene ignorato. ---1463811839-324931406-994342670=:16889 Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1 Content-Transfer-Encoding: 7BIT Ciao Tizio, ti allego le foto che ti ho promesso. Caio ---1463811839-324931406-994342670=:16889 Content-Type: IMAGE/JPEG; NAME="caio-1.jpg" Content-Transfer-Encoding: BASE64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/ 2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB ... ... 45/Q+9TZ+XPtn9KAFopFORk9/wDGokdmdgcYAPT2IH9aAJqKqTyurooIAJ5/ L/P5fWrAJC/THX3AP9aAKU2nwzyGRgCSMc+g/D3orC1HWby2umii8rYFUjcj E5Oc87x/KildXt/XT/NGijKytLp3Z//Z ---1463811839-324931406-994342670=:16889 Content-Type: IMAGE/JPEG; NAME="caio-2.jpg" Content-Transfer-Encoding: BASE64 /9j/4AAQSkZJRgABAQEAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsL DBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/ 2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy ... ... AgkiBwEifAQArSQpJAD/APah2keikDwgBeEj0iOUKXAFXKIZXKQ5PSJ54tdA VIH7Innrwm9nlABJ8JpKcRQQDfKAGpD5TiEPhACHISI5TttBCigAcoHtO8IA ikACvlJHj5SXAP/Z ---1463811839-324931406-994342670=:16889-- |
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, sceglierà 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.
From: caio@dinkel.brot.dg To: tizio@dinkel.brot.dg Subject: Prova di trasmissione Message-ID: <Pine.LNX.4.04.10107131839040.579@dinkel.brot.dg> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463811839-1689890199-995042379=:579" Content-ID: <Pine.LNX.4.04.10107131839530.579@dinkel.brot.dg> ---1463811839-1689890199-995042379=:579 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <Pine.LNX.4.04.10107131839531.579@dinkel.brot.dg> Esempio di trasmissione con Pine. ---1463811839-1689890199-995042379=:579 Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1; NAME="prova.xxx" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.4.04.10107131839390.579@dinkel.brot.dg> Content-Description: Content-Disposition: ATTACHMENT; FILENAME="prova.xxx" bGtqc2Ro6GU5DQo4NDVyeSNmZ2cNCmby6fnszMDSyA0K9vzkJCUmo0sq ---1463811839-1689890199-995042379=:579-- |
From: caio@dinkel.brot.dg User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2 i586; en-US; m18) Gecko/20001103 MIME-Version: 1.0 To: tizio@dinkel.brot.dg Subject: Prova di trasmissione Content-Type: multipart/mixed; boundary="------------050408090202040304080207" This is a multi-part message in MIME format. --------------050408090202040304080207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ecco un esempio di allegato con Mozilla. --------------050408090202040304080207 Content-Type: application/octet-stream; name="prova.xxx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="prova.xxx" bGtqc2Ro6GU5Cjg0NXJ5I2ZnZwpm8un57MzA0sgK9vzkJCUmo0sq --------------050408090202040304080207-- |
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.
Date: Fri, 13 Jun 2001 17:30:00 +0200 Subject: Esempio di allegato non corretto From: caio@dinkel.brot.dg To: tizio@dinkel.brot.dg Message-ID: <B761F178.202%caio@dinkel.brot.dg> Mime-version: 1.0 Content-type: multipart/mixed; boundary="MS_Mac_OE_3076649336_173889_MIME_Part" --MS_Mac_OE_3076649336_173889_MIME_Part Content-type: multipart/alternative; boundary="MS_Mac_OE_3076649336_173889_MIME_Part" --MS_Mac_OE_3076649336_173889_MIME_Part Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Ecco, ti allego il file che tanto aspettavi. --MS_Mac_OE_3076649336_173889_MIME_Part Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable <HTML> <HEAD> <TITLE>Esempio di allegato non corretto</TITLE> </HEAD> <BODY> <P ALIGN=3DCENTER> Ecco, ti allego il file che tanto aspettavi. </BODY> </HTML> --MS_Mac_OE_3076649336_173889_MIME_Part-- --MS_Mac_OE_3076649336_173889_MIME_Part Content-type: multipart/appledouble; boundary="MS_Mac_OE_3076649333_192109_MIME_Part" --MS_Mac_OE_3076649333_192109_MIME_Part Content-type: application/applefile; name="prova.jpg" Content-transfer-encoding: base64 Content-disposition: attachment AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAJAAAAPgAAACAAAAADAAAAXgAAABIAAAAC AAAAcAAAO2xKUEVHOEJJTQUA//8CAQAAAAAAAAAAAAAAAAAAAAAAAEZSQU5DT18yIHNtYWxs LmpwZwAAAQAAADrqAAA56gAAAIIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ... ... AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAA66gAAOeoAAACCU09SVAN2AIAAHACCAARJQ04j AAAAKlBJQ1QAAAA2U1RSIAAAAEJpY2w4AAAATnBub3QAAABav7n//wAAOOYM1aTQVHD//wAA ABoAAAAAv/T//wAAAAAM1afMv7n//wAANOIM1afcAAD//wAANNAM1aTY --MS_Mac_OE_3076649333_192109_MIME_Part Content-type: image/jpeg; name="prova.jpg"; x-mac-creator="3842494D"; x-mac-type="4A504547" Content-disposition: attachment Content-transfer-encoding: base64 /9j/4AAQSkZJRgABAgEBLAEsAAD/7Ro4UGhvdG9zaG9wIDMuMAA4QklNA+kKUHJpbnQgSW5m bwAAAAB4ACgAAABIAEgAAAAAAxgCQf/3//cDQAJKIAIFewPgAAAAAAFoAWgAAAAAD3gLRQFs ADILRUcYAFAAAQEBAAAAAScPAAEAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAZAAAAAAAAAAA ... ... QI08T/rKM3l/9Q/kKl+d8gj10WjbW2szHqF/2lrR6pr9PfEGJ3+n7v5bdyk9rgdwcQ6AIjSe SpO/nP7P/fgp92f69mo9fBGjnnHtyOoMy72AOxQ5mKxvg6Bde/8Al7Wtrr/cYrXpt+ltPMz8 uFK3+cPy/iif4H5JaXp9U+rr9H//2Q== --MS_Mac_OE_3076649333_192109_MIME_Part-- --MS_Mac_OE_3076649336_173889_MIME_Part-- |
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:
Date: Fri, 13 Jun 2001 17:30:00 +0200 Subject: Esempio di allegato non corretto From: caio@dinkel.brot.dg To: tizio@dinkel.brot.dg Mime-version: 1.0 Content-type: image/jpeg; name="prova.jpg"; Content-transfer-encoding: base64 /9j/4AAQSkZJRgABAgEBLAEsAAD/7Ro4UGhvdG9zaG9wIDMuMAA4QklNA+kKUHJpbnQgSW5m bwAAAAB4ACgAAABIAEgAAAAAAxgCQf/3//cDQAJKIAIFewPgAAAAAAFoAWgAAAAAD3gLRQFs ADILRUcYAFAAAQEBAAAAAScPAAEAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAZAAAAAAAAAAA ... ... QI08T/rKM3l/9Q/kKl+d8gj10WjbW2szHqF/2lrR6pr9PfEGJ3+n7v5bdyk9rgdwcQ6AIjSe SpO/nP7P/fgp92f69mo9fBGjnnHtyOoMy72AOxQ5mKxvg6Bde/8Al7Wtrr/cYrXpt+ltPMz8 uFK3+cPy/iif4H5JaXp9U+rr9H//2Q== |
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:
begin-base64 664 prova.jpg /9j/4AAQSkZJRgABAgEBLAEsAAD/7Ro4UGhvdG9zaG9wIDMuMAA4QklNA+kKUHJpbnQgSW5m bwAAAAB4ACgAAABIAEgAAAAAAxgCQf/3//cDQAJKIAIFewPgAAAAAAFoAWgAAAAAD3gLRQFs ADILRUcYAFAAAQEBAAAAAScPAAEAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAZAAAAAAAAAAA ... ... QI08T/rKM3l/9Q/kKl+d8gj10WjbW2szHqF/2lrR6pr9PfEGJ3+n7v5bdyk9rgdwcQ6AIjSe SpO/nP7P/fgp92f69mo9fBGjnnHtyOoMy72AOxQ5mKxvg6Bde/8Al7Wtrr/cYrXpt+ltPMz8 uFK3+cPy/iif4H5JaXp9U+rr9H//2Q== ==== |
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] <-'
`->file_da_codificare indirizzo_posta_elettronica...
mpack [-s oggetto] [-d file_introduttivo] [-m n_caratteri] [-c sottotipo_mime] <-'
`->-o file_da_generare file_da_codificare
mpack [-s oggetto] [-d file_introduttivo] [-m n_caratteri] [-c sottotipo_mime] <-'
`->-n indirizzo_usenet[,indirizzo_usenet]... file_da_codificare
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 verrà 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
Ciò che viene ricevuto può assomigliare al messaggio seguente, dove si può notare che la stringa di delimitazione è ridotta a un solo trattino:
Message-ID: <846.995041413@dinkel.brot.dg> Mime-Version: 1.0 To: tizio@dinkel.brot.dg Subject: Prova di trasmissione Content-Type: multipart/mixed; boundary="-" From: caio@dinkel.brot.dg Date: Fri, 13 Jul 2001 18:23:32 +0200 This is a MIME encoded message. Decode it with "munpack" or any other MIME reading software. Mpack/munpack is available via anonymous FTP in ftp.andrew.cmu.edu:pub/mpack/ --- Content-Type: application/octet-stream; name="prova.xxx" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="prova.xxx" Content-MD5: JSc+xPLb3o3I5NlBYvyVJA== bGtqc2Ro6GU5Cjg0NXJ5I2ZnZwpm8un57MzA0sgK9vzkJCUmo0sq ----- |
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
daniele @ swlibero.org1) 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.html
[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico]