1.3 RFC 822 e MIME
Inizialmente il protocollo per la rappresentazione dei documenti di posta elettronica (e-mail) era definito nel documento RFC 822, del 1982; in questo documento veniva specificato il formato per i messaggi di posta e ci si limitava a messaggi esclusivamente di tipo testo ASCII, senza alcun riferimento a messaggi di altro tipo (ad esempio, le immagini).
Nel giugno 1992 è stato presentato un nuovo documento, l’RFC 1341, in cui viene descritto lo standard MIME.
In RFC 1341 vengono presentati i meccanismi per superare le limitazioni contenute in RFC 822; viene specificato come definire il formato sia di messaggi testuali (ASCII e non) sia di messaggi multimediali (cioè contenenti video, suono, immagini, ecc.).
Una delle principali limitazioni del protocollo descritto in RFC 822 si ha nel fatto che il contenuto dei messaggi è limitato a simboli (caratteri) di 7 bit; questo impone che ogni messaggio non costituito da solo testo ASCII, debba essere convertito in questo formato prima di essere inviato in rete.
Per risolvere questo problema è stato proposto il documento RFC 1341.
RFC 822
Secondo tale specifica un messaggio di posta elettronica è una stringa di testo costituita da un header e da un body separati da una linea vuota.
L’header contiene le informazioni per il trasporto:
To: lista di destinatari
From: mittente
Cc: lista di destinatari per conoscenza
Bcc: lista nascosta di destinatari per conoscenza
Date: data di spedizione
Reply-to: indirizzo diverso dal mittente
Subject: titolo del messaggio
Keywords non previste sono comunque spedite e interpretate dagli agenti utente: es. Organization
RFC 1341 o MIME
(Multipurpose Internet Mail Extensions)
Con lo standard MIME è possibile inserire in un qualsiasi messaggio di e-mail, oltre al testo, anche files contenenti immagini, segnali audio e video; il software che gestisce la posta non si preoccupa del contenuto del messaggio, è l'utilizzatore finale a preoccuparsi della sua opportuna decodifica in base alle specifiche di tipo inserite nel messaggio stesso.
In MIME, come descritto in RFC 1341, vengono introdotti dei meccanismi che permettono di risolvere i problemi di RFC 822, senza introdurre delle incompatibilità con i documenti scritti secondo il vecchio standard. Un documento MIME contiene una testata in cui si trovano i seguenti campi:
- Content-Transfer-Encoding
- Content-Type
- Content-ID
- Content-Description
Identifica la versione dello standard MIME usato nel messaggio. Questo permette di indicare se un messaggio è conforme allo standard, in modo tale che il software che lo riceve possa distinguerlo da quei messaggi scritti secondo il vecchio standard (in cui questo campo è assente).
Content-Transfer-Encoding
Specifica un modo di codifica dei dati accessorio a quello principale, utilizzato per permettere loro di passare attraverso tutti i meccanismi di trasporto della posta elettronica, i quali potrebbero avere delle limitazioni nel set di caratteri ammessi (questa codifica aggiuntiva deve essere applicata ai dati prima della loro trasmissione). I documenti, per essere trasportati in rete, necessitano di un’ulteriore codifica e nel content-trasfer-encoding viene specificato qual è la relazione tra i dati nella loro forma originale ed il formato con cui vengono trasmessi.
La maggioranza dei documenti può così essere trasportata nella rete senza problemi, anche nel caso in cui i dati debbano attraversare una rete conforme soltanto allo standard RFC 822 e non alle sue successive versioni (come il MIME); un esempio è un sistema di posta compatibile col protocollo SMTP (Simple Mail Transfer Protocol), in cui è necessario che il documento venga opportunamente codificato in caratteri ASCII, a 7 bit, con non più di 1000 linee.
Il campo Content-Transfer-Encoding è appunto usato per specificare come possono essere manipolati i dati per essere trasportati in rete; in esso viene specificato un meccanismo, invertibile, per trasformare il documento originario e non ha alcuna influenza sul tipo di dati trasportati.
I valori di Content-Transfer-Encoding sono: 7bit, 8bit, binary, quoted-printable, base64.
Il loro significato è questo:
7bit, 8bit, binary
Questi valori stanno a significare che nessuna operazione di codifica è stata effettuata sul contenuto del messaggio e, allo stesso tempo, forniscono una indicazione sul tipo di dati contenuti nel messaggio stesso (quindi forniscono un'indicazione sul tipo di codifica che potrebbe rendersi necessaria per trasmettere il messaggio in determinati sistemi di trasmissione).
Il valore "7bit" significa che in questo caso i dati possono essere rappresentati in gruppi di sette bit, ognuno dei quali rappresenta un carattere ASCII; questo è anche il valore assunto come default se il campo non viene specificato.
Il valore "8bit" significa che possono essere presenti caratteri non appartenenti al set ASCII; cioè, suddividendo il messaggio in linee di 8 bit ciascuna e associando ad ogni linea un carattere ASCII, si possono ottenere delle sequenze di caratteri apparentemente senza significato.
Il valore "binary" indica che il contenuto del messaggio è in formato binario (un'immagine, un file audio, ecc.).
La differenza tra "8bit" e
"binary" può sembrare irrilevante ma, può assumere grande significato
in quei sistemi di trasferimento dati che non sono conformi alle restrizioni
della RFC 822.
Questo valore significa che un'operazione di codifica è già stata applicata ai dati, in modo da trasformare il messaggio in una sequenza di caratteri ASCII (se il messaggio originario era già costituito da un testo ASCII, questa codifica lo lascia sostanzialmente inalterato).
Lo scopo principale di questa codifica è di mettere i
dati in un formato che difficilmente subirà delle trasformazioni da parte dei
vari sistemi che è costretto ad attraversare, prima di giungere a destinazione.
Questo valore significa che sui dati è stata effettuata un'operazione di codifica, detta base64; con questa operazione il messaggio viene trasformato in una sequenza di caratteri appartenenti ad un sottogruppo del set di caratteri ASCII (le lettere maiuscole da "A" a "Z", quelle minuscole da "a" a "z", I numeri da"0" a "9", il carattere "+" ed il carattere "\").
In questo modo, ogni carattere codificato può essere
rappresentato con sei bit. L'operazione di codifica consiste nel suddividere la
sequenza dei bit in ingresso (il messaggio) in gruppi di 24 bit; ogni gruppo di
24 bit viene diviso in quattro gruppi di sei bit, ad ognuno dei quali si
associa il corrispondente carattere ASCII appartenente al sottogruppo
specificato.
x-token
Viene usato per specificare uno schema di codifica
esterno, non standard, scelto da chi trasmette il messaggio (token coinciderà col nome dato a questa codifica); si deve fare
attenzione al fatto che questa codifica deve essere nota anche a chi riceve il
messaggio, in modo che questo possa essere ricostruito correttamente
Content-Type
Specifica il tipo ed il sottotipo di dati contenuti nel messaggio (MIME type), in modo che il software che riceve il messaggio possa immediatamente capire come sono codificati i dati ricevuti.
Questo campo ha la forma:
dove tipo specifica la forma generale dei dati, mentre sottotipo specifica il particolare tipo di dati trasmessi. Il campo parametro è opzionale.
Text, per esempio, è un tipo usato per rappresentare informazioni in forma testuale, scritte secondo un certo linguaggio.
Un sottotipo per text è plain, che indica un testo non formattato, un altro è richtext, usato per testi con una semplice formattazione.
Un parametro usato per i messaggi text è charset, che è usato per indicare il set di caratteri utilizzato.
Ad esempio, per la posta elettronica in Internet, il campo Content-Type assume la forma:
Nel caso non sia specificato il parametro,
viene usato come default il set di caratteri US-ASCII.
Content-ID
Identifica il messaggio in modo univoco (opzionale).
Content-Description
Descrizione testuale del contenuto del messaggio (opzionale).
Tutti i tipi di dati MIME, specificati nel campo Content-Type, devono essere registrati presso la IANA (Internet Assigned Numbers Authority); i nuovi tipi di dati, non ancora ufficialmente riconosciuti dalla IANA devono essere indicati con "x-",come ad esempio multipart/x-mixed, oppure application/x-http-cgi.