Posta elettronica - Content Transfer Encoding
- Segnalazioni: È richiesto un livello medio di preparazione
- Hosting Fattispazio!: a cura di infocom.uniroma1
Pagina 9 di 13
Content-Transfer-Encoding
A meno che non sia disponible l'estensione ESMTP di tipo 8BITMIME, le email devono contenere solamente caratteri US-ASCII, con il bit più significativo di ogni byte posto a zero. Questo contrasta con l'uso di set di caratteri esteso, come gli alfabeti ISO-8859-x, e con l'invio di allegati contenenti dati binari qualsiasi. Per questo, lo standard MIME prevede l'uso della intestazione Content-Transfer-Encoding, come ad esempio
| Content-Transfer-Encoding: 7bit |
che stabilisce un metodo di codifica del body tale da convertire il suo vero contenuto, qualsiasi, in una diversa rappresentazione, tale che nel flusso di byte risultante il bit più significativo sia posto a zero. Il lato trasmittente, una volta noto il formato accettabile dal server SMTP, converte al volo l'email, ed aggiunge questo header, per indicare la trasformazione effettuata. Il lato ricevente, noto il Transfer-Encodingutilizzato, provvede quindi ad invertirne la rappresentazione, in modo da ristabilire il flusso binario originario. La RFC 2045 definisce i valori che possono essere assunti dalla intestazione Content-Transfer-Encoding:, che sono:
adatti all'SMTP normale:
-
7bit - è il valore di default, assunto vero se Content-Transfer-Encoding non è presente, e prevede la trasmissone di fino a 998 byte per linea, con codici di carattere nell'intervallo 1..127, ed in cui la sequenza CR e LF (codici 13 e 10) indica la fine di una linea;
-
quoted-printable- trasforma i caratteri ad 8 bit ed i caratteri non stampabili eventualmente presenti, nella sequenza di 3 caratteri =HH, in cui le due cifre esadecimali HH (0-9 o A-F) corrispondono al codice binario (in base al charset utilizzato) del carattere trasformato. Il risultato è ancora direttamente leggibile per la sua parte stampabile, ed anche se uno UA non supporta la trasformazione inversa, la codifica dei caratteri trasformati può essere visualizzata senza danno. Ad esempio:
- il carattere US-ASCII form feed (decimale 12) viene rappresentato come =0C
- il carattere é dell'alfabeto ISO-8859-1 (decimale 233, corrispondente ad una e con accento acuto), si rappresenta con la sequenza =E9
- la parola cioè (in ISO-8859-1) è rappresentata come cio=E8
- base64- trasforma tutti i byte presenti, raggruppando i byte a tre a tre (per un totale di 24 bit), e rappresentandoli con 4 caratteri stampabili, ognuno dei quali rappresenta una codifica di 6 dei 24 bit complessivi, come in questo esempio in cui si mostrano i passaggi necessari a rappresentare la sequenza esadecimale 0x010203 nella sua rappresentazione base64 AQID:
| 1 2 3 00000001 00000010 00000011 / \ / \ / \ 000000 01 0000 0010 00 000011 |----| |------| |-----| |----| 000000 010000 001000 000011 0 16 8 3 A Q I D |
| NUM ASCII NUM ASCII NUM ASCII NUM ASCII 0 A 16 Q 32 g 48 w 1 B 17 R 33 h 49 x 2 C 18 S 34 i 50 y 3 D 19 T 35 j 51 z 4 E 20 U 36 k 52 0 5 F 21 V 37 l 53 1 6 G 22 W 38 m 54 2 7 H 23 X 39 n 55 3 8 I 24 Y 40 o 56 4 9 J 25 Z 41 p 57 5 10 K 26 a 42 q 58 6 11 L 27 b 43 r 59 7 12 M 28 c 44 s 60 8 13 N 29 d 45 t 61 9 14 O 30 e 46 u 62 + 15 P 31 f 47 v 63 / |
Nel caso in cui il testo di partenza non abbia un numero complessivo di byte multiplo di 3, si aggiungono a destra tanti zeri, quanti ne servono per completare l'ultimo gruppo di 6 bit in entrata. Quindi, se il numero di simboli BASE64 ottenuti non è un multiplo di quattro, si aggiungono alla codifica fino a tre simboli di uguale (=), in numero pari al numero di simboli mancanti, in modo da segnalarlo al ricevitore.
Ad esempio, mostriamo la codifica della parola cioé, quando inizialmente rappresentata in ISO-8859-1. In tal caso, la parola si esprime mediante la sequenza esadecimale 0x63 0x69 0x6F 0xE8 (eseguireman ascii e man iso_8859_1 per verificarlo), che in binario diviene 01100011 01101001 01101111 11101000, e che si suddivide in gruppi di 6 bit come 011000 110110 100101 101111 111010 000000, in cui gli ultimi 4 bit sono stati aggiunti, e posti a zero. Riscrivendo l'ultima sequenza in decimale, otteniamo 24 54 37 47 58 00, che in accordo alla tabella precedente, fornisce una rappresentazione BASE64 pari a Y2lv6A==, dove i due simboli = finali sostituiscono i due gruppi di 6 bit mancanti nella penultima sequenza.
Esistono alcuni siti che calcolano la trasformazione on-line, come quelli qui indicati; inoltre su Linux è disponibile il comando base64.Adatto ad un server ESMTP che supporta l'estensione 8BITMIME:
- 8bit - fino a 998 bytes per linea, con la sequenza CR e LF (codici decimali 13 e 10) che appare solo alla fine di una linea;
Adatto ad un server ESMTP che supporta l'estensione BINARYMIME (RFC 3030):
- binary - qualunque sequenza di bytes.
Encoded Word
Le intestazioni MIME Content-Type e Content-Transfer-Encoding stabiliscono alfabeto e codifica del body della email, ma per usare un alfabeto diverso da US-ASCII nel valore di una intestazione, come ad esempio nel Subject, si ricorre ad un diverso espediente, noto come Encoded Word (RFC 2047), che definisce una sintassi tale da indicare, in un sol colpo
- il charset originario,
- il transfer-encoding usato,
- il risultato della trasformazione.
=?charset?encoding?encoded text?= |
- charset può essere qualunque, purché registrato presso IANA e tipicamente, sarà lo stesso charset del body
- encoding può essere sia "
Q", ossia quoted-printable, oppure "B", ossia base64 - encoded text è il risultato della trasformazione.
| Subject: =?utf-8?Q?=C2=A1Hola, se=C3=B1or!?= |
Multipart Content Type
Un messaggio MIME multiparte è il formato tipico in cui sono realizzate le email che contengono allegati, o contenuti di tipo diverso dal text/plain. In questo caso, il body del messaggio è suddiviso mediante una stringa speciale detta confine (boundary), definita nella intestazione Content-type:, e che non deve comparire in nessuna delle parti: per questo motivo, il confine tipicamente assume l'aspetto di una sequenza di simboli casuali. Il confine è inserito oltre che tra le diverse parti, allo scopo di demarcare la loro separazione, anche all'inizio ed alla fine del corpo del messaggio, come segue:
| Content-type: multipart/mixed; boundary="frontier" MIME-version: 1.0 This is a multi-part message in MIME format. --frontier Content-type: text/plain This is the body of the message. --frontier Content-type: application/octet-stream Content-transfer-encoding: base64 PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== --frontier-- |
Multipart Subtypes
Il Content-type multipart può essere di diversi sottotipi, che specificano la natura delle parti, e le loro relazioni reciproche. I sottotipi più comuni sono:
- Mixed - usato per inviare files allegati, con Content-Type differenti dal testo del messaggio. Se il tipo di una sottoparte è ad esempio una immagine, molti client email saranno in grado di mostrarla direttamente, altrimenti proporranno di eseguire una applicazione specifica. Definito nella RFC 2046, sezione 5.1.3
- Alternative - Il sottotipo multipart/alternative indica che ogni parte è una versione alternativa dello stesso contenuto, ognuna in un formato diverso, come indicato dall'header Content-Typecorrispondente. I formati sono ordinati in base al grado di aderenza all'originale, con il meno aderente per primo, ed il più aderente per ultimo. In tal modo, il client può scegliere la migliore rappresentazione che è in grado di visualizzare, come l'ultima parte che è in grado di interpretare. Per questo, il formato text/plain viene posto per primo, in quanto il meno aderente possibile, consentendo ai client non in grado di interpretare i messaggi multiparte, di visualizzare comunque qualcosa di leggibile. Definito nella RFC 2046, Sezione 5.1.4
- Related - Questo sottotipo è usato per indicare che le parti del messaggio non devono essere considerate individualmente, ma piuttosto come parti di uno stesso aggregato. Il messaggio consiste di una parteradice (la prima), che referenzia in-linea le altre parti, per mezzo dell'header Content-ID presente nelle diverse parti. Un uso tipico del sottotipo Related, è quello che permette di inviare per email una pagina web, completa di tutte le immagini che contiene. Definito nella RFC 2387
- Report - E' il sottotipo usato da un server SMTP per comunicare (via email) eventi di errore, e indica la presenza di dati formattati in modo che possano essere letti da parte di un mail server; tipicamente, il messaggio è suddiviso in una parte di tipo text/plain, ed una di tipo message/delivery-status. Definito nella RFC 3462
- Digest - Multipart/digest è un modo semplice per allegare ad una email, un diverso messaggio email. Il content-type di default per ogni parte è message/rfc822. Definito nella RFC 2046, sezione 5.1.5
- Signed - Questo sottotipo è usato per allegare una firma digitale al messaggio, che una volta firmato, contiene due parti, un body ed una signature. Tutto il body, inclusi gli header MIME, è usato per creare la parte con la firma, prodotta in uno di diversi modi possibili, come indicato dall'header Content-Type presente nella parte con la firma, che ad es. può riportare application/pgp-signature, oapplication/x-pkcs7-signature. Definito in RFC 1847, sezione 2.1
- Encrypted - In questo caso, il messaggio è composto di due parti, dove la prima contiene le informazioni di controllo necessarie per decrittare la seconda, di tipo application/octet-stream. Definito in RFC 1847, Section 2.2
- Form Data - Come implica il nome, questo sottotipo è usato per esprimere valori immessi mediante un modulo di inserimento dati (form), tipicamente compilato mediante una pagina web. Definito in RFC 2388
Content-Disposition
Illustriamo l'uso di questa intestazione nell'ambito dei commenti al seguente capture, in cui le risposte delserver SMTP sono visualizzate in corsivo, e che corrisponde all'invio di una email contenente in allegato una immagine jpeg, codificata con il metodo base64.| 220 smtp-out2.libero.it ESMTP Service (7.3.120) ready EHLO [192.168.120.40] 250-smtp-out2.libero.it 250-DSN 250-8BITMIME 250-PIPELINING 250-HELP 250 SIZE 30000000 MAIL FROM:<>; SIZE=11599 250 MAIL FROM:<>; OK RCPT TO:<>; 250 RCPT TO:<>; OK DATA 354 Start mail input; end with <CRLF>.<CRLF> Message-ID: <>; Date: Mon, 05 Mar 2007 20:30:12 +0100 From: alef <>; User-Agent: Mozilla Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: Subject: prova invio con allegato Content-Type: multipart/mixed; boundary="------------060708020103050401060503" This is a multi-part message in MIME format. --------------060708020103050401060503 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit vediamo come parte l'allegato --------------060708020103050401060503 Content-Type: image/jpeg; name="logoalef.jpg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="logoalef.jpg" /9j/4AAQSkZJRgABAQEASABIAAD/4QAWRXhpZgAATU0AKgAAAAgAAAAAAAD//gAXQ3JlYXRl ZCB3aXRoIFRoZSBHSU1Q/9sAQwADAgIDAgIDAwMDBAMDBAUIBQUEBAUKBwcGCAwKDAwLCgsL DQ4SEA0OEQ4LCxAWEBETFBUVFQwPFxgWFBgSFBUU/9sAQwEDBAQFBAUJBQUJFA0LDRQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU/8AAEQgAZAGk AwEhAAIRAQMRAf/EABwAAQADAQEBAQEAAAAAAAAAAAABCAkHBgUEA//EAFUQAAAEBAMEBwIH CQsMAwAAAAABAgMEBhRhBQcRCBITFwkhMVFWldIVcRkiQYGUtNQWIzJVZGWRssQYM0JEYpKh oqOz0yVDRlJTV2Nyc4KTpabB5P/EABwBAQACAgMBAAAAAAAAAAAAAAABBQQGAgMHCP/EADsR AAEDAwECCwYFBAMBAAAAAAABAhEDBBIFIZEUFUFRUlRhcZKx0QYTMTIzwSIjYoHwcqGy8RYk . ..... molte linee omesse . DaSHCT3AMlHCSHCTqIkSo4Se4TwkhIlRwk9wjhJCRKjhJDhJ7gkSo4SQ4adOwSMlHCT3Bwkh IlRwkhw06dgCVHCT3Bwk9XUEiVBNJ7gNtPcAlRw09wnhJ7hEiVINtJBwk9wkSo4ST+QDbSAl Rwkhwk9wgSo4SQ4aQJlQbaSLsAmk9wSRKjhJ17A4aevqEkyo4adOwOEnXsAjJRwk9wcJIiRk o4SQ4adOwJEqfsgiJLR6d4DivxMV3zH/2Q== --------------060708020103050401060503-- . 250 <45D997EE01267F19> Mail accepted QUIT 221 smtp-out2.libero.it QUIT |
- —