3 MIME
Formát zpráv protokolu SMTP definovaný normou RFC-822 umožňoval přenášet data pouze formátu US-ASCII. Brzy se však ukázalo, že tento standard nevyhovuje mnohým požadavkům uživatelů, kteří chtějí elektronickou poštu využít i pro posílání textu jiných znakových sad, formátovaného textu, obrázků, zvuků, obecně binárních souborů atp. V poslední době pak přibyl požadavek na posílání zabezpečených zpráv, tj. šifrovaných zpráv nebo elektronicky podepsaných zpráv.
Požadavky uživatelů rychle překročily možnosti nabízené normou RFC821. Objevilo se tak rozšíření MIME (Multipurpose Internet Mail Extension) dnes specifikované normami RFC-2045 až 2049.
Problém jak poslat elektronickou poštou zprávu obsahující jiná data než text v kódu US-ASCII lze řešit i bez MIME. Znamená to zprávu před odeslání zakódovat do US-ASCII. Příjemce pak musí nejprve zprávu dekódovat a pak ji může teprve zpracovat (přečíst). Odesilatel a příjemce se musí jinou cestou dohodnout na typu kódování přenášených dat do US-ASCII. V praxi se zpravidla používá kódování Base64, Quotet Printable nebo v UNIXu kódování UUENCODE. Zkušený příjemce se podívá na zakódovaná data a na první pohled vidí jak jsou data zakódovaná a podle kódování se rozhodne použít vhodný dekódovací program na přijatá data před tím, než je bude zpracovávat (např. číst).
Tato cesta je pro běžné uživatele nepřijatelná. Uživatel si
nepřeje se nějakým kódování zabývat – přeje si, aby tyto problémy za něj
vyřešil software poštovního klienta sám. Pro běžného uživatele je tak přijatelná
druhá možnost spočívající v myšlence rozšířit repertoár hlaviček zprávy o
hlavičky popisující typ přenášených dat a algoritmus, kterým byla data před
odesláním zakódována do US-ASCII. Tím je pak možné celý proces zautomatizovat,
aniž by do něj musel uživatel zasahovat. Popis dodatečných hlaviček specifikuje
právě norma MIME.
V tomto případě může příjemcův software z hlaviček automaticky rozeznat, jak byla data kódována, a automaticky zprávu dekódovat. Navíc v hlavičce Content-Type odesilatelův software uloží typ přenášených dat, podle kterého příjemcův software automaticky rozpozná, jakým prohlížečem má data příjemci zobrazit. Příjemci pak podle typu přenášených dat spustí příslušný prohlížeč:
- Textový editor pro text.
- Grafický editor pro obrázek.
- Příslušný přehrávač pro zvuk, video či animaci.
Tyto dodatečné informace o přenášených datech nesou hlavičky začínající řetězcem "Content-", které specifikuje norma MIME. MIME je standardem, který doplňuje normu RFC-822 a zajišťuje zpětnou kompatibilitu. MIME je navrženo tak, aby mohly být posílány stávajícím poštovním systémem zprávy obsahující diakritiku, obrázky, zvuk atd.
Tento standard řeší dvě otázky:
- Jak vytvořit ze zprávy
obsahující např. binární data zprávu vyhovující normě RFC-822 a tedy přepravitelnou
používanými přenosovými protokoly.
- Jak rozlišit jednotlivé druhy zpráv, tj. zavádí klasifikaci přenášených informací. Klasifikace přenášených informací se ukázala velmi užitečnou i mimo e-mail. Moderní služby Internetu ji přebírají a používají ke stejnému účelu. MIME zavádí další hlavičkové řádky do poštovní zprávy, které specifikují typ posílaných dat a způsob jejich kódování.
3.1 Hlavičky MIME
MIME zavádí hlavičky:
- MIME-Version - přítomnost této hlavičky elektronické pošty indikuje, že je zpráva sestavena podle MIME, tj. dle RFC2045 až RFC2049.
- Content-Type - specifikuje typ a podtyp dat posílaných v těle zprávy (text, audio, video, virtuální realita).
- Content-Transfer-Encoding - specifikuje použité kódování, pomocí kterého je zpráva převedena do formátu vyhovujícího přenosovému mechanismu (do ASCII).
- Content-ID - identifikace zprávy použitelná v možném odkazu.
- Content-Description - textový popis obsahu.
- Content-řetězec - je rezervováno pro budoucí použití v MIME.
- Content-Disposition – je hlavička specifikovaná normou RFC-2183.
3.1.1 Hlavička Mime-Version
Tato hlavička je jediná hlavička MIME nezačínající řetězcem "Content-". Hlavička specifikuje verzi normy MIME. Důvodem zavedení této hlavičky je zajištění kompatibility. Tj. podle přítomnosti této hlavičky software klienta rozpozná, že jde o zprávu rozšířenou podle MIME, a dále rozezná verzi MIME, podle kterého byla zpráva rozšířena. Rozšíření MIME podle RFC2045 až RFC2049 je verze 1.0. V budoucnu však mohou přijít další verze MIME s jiným repertoárem hlaviček.
Protokol HTTP používá také hlavičky vycházející z filosofie MIME a mnohé rovněž začínají řetězcem „Content-“, ale jsou uzpůsobeny protokolu HTTP. Právě skutečnost, že záhlaví HTTP není zcela kompatibilní s MIME, je v protokolu HTTP signalizováno neexistencí hlavičky Mime-Version v záhlaví HTTP zprávy.
Zpráva sestavená podle RFC2045 až RFC2049 musí tuto hlavičku vždy obsahovat. Tedy konkrétní tvar hlavičky vypadá takto:
Mime-Version: 1.0
Hlavička musí být uvedena před ostatními hlavičkami MIME.
3.1.2 Hlavička Content-Type
Hlavička popisuje typ dat obsažených v těle zprávy tak, aby klient, který tuto zprávu obdrží, mohl zvolit vhodný způsob prezentace obsahu zprávy. Hlavička má tvar:
Content-Type: typ/podtyp; parametry
Hlavička specifikuje charakter obsahu zprávy pomocí typu a podtypu a případně pomocí doplňkových parametrů. Parametry mají tvar:
atribut=hodnota; …
Parametrů může být i více – jsou pak odděleny středníkem a na jejich pořadí nezáleží.
Typ specifikuje, o jaký typ dat se jedná, zda je v těle zprávy obsažen text, obrázek (image) nebo např. obecný binární soubor (octet stram). Podtyp pak specifikuje konkrétní formát obrázku, textu apod.
Např. hlavička
Content-Type: image/jpeg
informuje příjemce o tom, že obsahem zprávy je obrázek formátu JPEG. RFC2045 až RFC2049 definuje několik základních typů. Způsob registrace dalších typů je popsán v RFC2048.
Typy jsou dvojího druhu:
- Jednoduché typy popisující typ přenášených dat. Jedná se např. o typy:
- text
- application
- image
- audio
- video
- model
- Kompozitní typy specifikující, že zpráva se skládá z několika částí. Jedná se např. o typy:
- message
- multipart
- report
Lze použít i experimentální typy, ty je však potřeba odlišit od standardních typů prefixem x- před jménem typu. Např. pro zprávu VRML se kdysi používalo x-world/x-vrml. Dnes však VRML (po ukončení experimentů) používá model/vrml.
Jména typů, podtypů a parametry jsou nezávislé na tom, zda je píšeme velkými nebo malými písmeny.
3.1.3 Hlavička Content-Transfer-Encoding
Data, která chceme posílat elektronickou poštou, jsou často 8bitová nebo binární. Tato data není možné zpravidla poslat přímo. Proto je potřeba definovat mechanismus převodu – kódování, jakým se data převedou na data, která jsou v kódu US-ASCII, tj. jsou převedena do 7bitového tvaru. Použitý typ kódování je uveden právě v hlavičce Content-Transfer-Encoding.
Ona hlavička Content-Transfer-Encoding v podstatě nenese pouze informaci o tom, jakým algoritmem jsou přenášená data kódována, ale v případě, že kódována nejsou, tak nese informaci o datech jako takových: jsou-li sedmibitová, osmibitová či binární (7bit, 8bit či binary).
MIME definuje dva algoritmy kódování dat: Quoted-Printable a Base64. Další algoritmy mohou být registrovány rovněž podle RFC2048.
Hlavička Content-Transfer-Encoding tak nejčastější nese následující způsoby kódování:
- quoted-printable
- base64
- 7bit – data nejsou kódována, jsou v krátkých řádcích, obsahují pouze znaky US-ASCII.
- 8bit – data nejsou kódována, řádky jsou krátké, ale mohou se vyskytnout i znaky, které nejsou US-ASCII.
- binary – data nejsou kódována, tok bitů není dělený na řádky. Celkový počet přenášených bitů musí být dělitelný osmi.
- x-rozšíření - experimentální kódování (určeno pro vývojáře).
Hodnoty 8bit, 7bit a binary nepředstavují žádné kódování. Tyto hodnoty jsou užitečné jako indikace typu dat.
Hlavička Content-Transfer-Encoding se vztahuje k celému tělu zprávy. Pokud se hlavička objeví v konkrétní části zprávy, pak se vztahuje pouze na tuto část. Problém, jak kódovat ne US-ASCII informace v hlavičce, je popsán v kapitole „Znaky v hlavičce, které nejsou US-ASCII“.
Kódovací mechanismus kóduje všechna data do ASCII znaků. Výsledkem kódování je tedy US-ASCII řetězec.
Příklad
Content-Type: text/plain;
charset=ISO-8859-2
Content-Transfer-Encoding: base64
interpretujeme takto: tělo zprávy je řetězec znaků US-ASCII vzniklých kódováním base64. Původní data byla ve znakové sadě ISO-8859-2 a musí být do této sady opět převedena při zobrazování příjemci.
3.1.4 Hlavička Content-ID
Hlavička nese jednoznačnou identifikaci obsahu zprávy. Hlavička je volitelná, její použití je ale v některých případech povinné – např. v implementacích používajících data typu message/external-body.
3.1.5 Hlavička Content-Description
Hlavička obsahuje popisné informace o přenášené zprávě, např. název obrázku, který je jako tělo posílán.
Příklad:
Content-Description: "Obrazek Prazskeho hradu".
Popis musí být v US-ASCII.
3.1.6 Hlavička Content-Disposition
Hlavička Content-Disposition určuje, zda-li jsou přenášená data určena k automatickému zobrazení příjemci (inline) či nejsou určena k automatickému zobrazení příjemci (attachment), tj. příjemce je má zpracovávat ručně (např. se jedná o soubor, který má být uložen na lokální disk). Dále hlavička může obsahovat další parametry:
- filename=jméno souboru
- creation-date=datum vytvoření
- modification-date=datum poslední modifikace
- read-date=datum posledního čtení
- size=velikost přenášeného souboru
Příklad (zpráva nesoucí zvuk, který se má příjemci
přehrát):
Message-ID: <335A2639.C79@pvt.cz>
Date: Sun, 20 Apr 1997 16:20:41 +0200
From: Libor Dostalek <dostalek@pvt.cz>
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: dostalek@pvt.net
Subject: (no subject)
Content-Type: audio/wav
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="ding.wav"
UklGRkYtAABXQVZFZm10IBAAAAABAAEAIlYAACJWAAABAAgAZGF0YSItAACAgICAgICAgICA
gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA
gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC
...
3.2 Standardní kódovací mechanismy
Kódovací mechanismus převádí osmibitová data na sedmibitová (tj. data obsahující pouze znaky US-ASCII).
MIME definuje dva kódovací mechanismy: Quoted-printable a Base64. Pro úplnost se zmíníme ještě o mechanismu Radix-64, který používá PGP.
3.2.1 Quoted-printable
Toto kódování je určeno pro data, která z větší části obsahují znaky US-ASCII. Výsledkem kódování je text, který je i bez dekódování z velké části pro člověka čitelný.
Pravidla kódování
- Bajty s desítkovou hodnotou od 33 do 60 a od 62 do 126 včetně jsou nahrazeny znaky US-ASCII (od ! do < a od > do ~). Jinými slovy: znaky, které jsou US-ASCII, se nekódují, tj. ponechávají se beze změny. Rovněž konce řádků se ponechávají.
- Ostatní bajty se nahrazují znakem "=" následovaným šestnáctkovou hodnotou bajtu. Např. znak „á“ se nahradí „=E1“.
- Bajty s hodnotou 9 a 32 jsou nahrazeny znaky tabulátor a mezera. Nesmí být na konci řádku.
- Konec řádky je vyjádřen CRLF.
- Zakódovaná řádka musí mít maximálně 76 znaků. Pokud je řádka delší použije se měkký konec řádky, tj. vloží se znak „=“ a konec řádky.
Tento způsob kódování není příliš úsporný. V případě, že všechny přenášené znaky jsou ne US-ASCII, pak se přenášená data zvětší na trojnásobek.
Příklad:
Řetězec Václav Vopička bude kódován v quoted-printable jako V=E1clav Vopi=E8ka protože:
- á je šestnáctkově E1
- č je šestnáctkově E8
Tento způsob kódování by v případě, že by všechny znaky byly ne US-ASCII, prodloužil původní text na trojnásobek. Naopak kódování Base64 prodlouží text pouze právě o třetinu.
3.2.2 Base64
Kódování Base64 je určeno pro kódování obecných binárních data, která nemusí být čitelná pro člověka. Kódovaná data jsou pouze o třetinu delší než data původní.
Kódovací algoritmus je jednoduchý. Používá tabulku base64 o 64 znacích (a znak "="). Pro kódování 64 znaků je třeba 6 bitů (26=64).
Znak "=" (6510) se používá ke speciálnímu účelu pro označení výplně na konci textu.
Z hlediska kódování se na zprávu nehledí jako na proud osmic bitů (bajtů), ale jako na proud šestic bitů. Každá šestice se pak kóduje podle tabulky base64. Viz obr. 3-1.
Na začátku kódování se kódovaný text rozdělí na sekvence 24 bitů (trojice bajtů). Každá trojice bajtů se rozdělí na 4 šestice bitů. Každá šestice reprezentuje jeden znak v abecedě base64. Kóduje se zleva doprava. Každých 6 bitů je nahrazeno odpovídajícím znakem z tabulky znaků abecedy base64.
Tabulka base64:
Hodnota Kódováno Hodnota Kódováno Hodnota Kódováno Hodnota Kódováno
0 A
17 R
34
i
51 z
1
B 18 S
35
j
52 0
2 C
19
T
36 k
53 1
3
D
20
U 37
l
54 2
4 E
21
V
38
m 55 3
5
F
22
W
39 n
56 4
6
G 23 X
40
o
57 5
7 H
24 Y 41
p 58 6
8
I
25
Z 42 q
59 7
9
J 26 a
43
r
60 8
10 K
27
b
44 s
61 9
11
L
28
c 45 t
62 +
12
M 29 d
46 u
63 /
13
N
30 e 47 v
14
O 31
f 48
w (výplň 002) =
15
P 32 g
49 x
16
Q 33 h 50 y
Výstupní - zakódovaný text musí být uspořádán do řádek maximálně dlouhých 76 znaků.
Obr. 3-1 Kódování Base64
Všechny znaky pro konec řádky a jiné znaky, které nejsou obsaženy v tabulce base64, musí být dekódovacím programem ignorovány, mohou indikovat chybu přenosu.
Zbude-li na konci textu po rozdělení méně než 24 bitů, doplní se nulové bity zprava. Přidání na konec je indikováno znakem "=".
Jenže jak je to přesně s tím „=“. Problém je v tom, že´délka textu, který se kóduje, nemusí být dělitelná třemi. Rozdělí-li se text vstupující do kódování na skupiny po třech bajtech, pak poslední skupina:
· Má rovněž tři bajty. Nedochází k žádné komplikaci a žádné znaky „=“ se na konec nepřidávají.
· Má dva bajty (16 bitů), pak se prvních dvanáct bitů kóduje normálně dle tabulky Base64. Zbylé 4 bity se doplní dvěma binárními nulami na 6 bitů a výsledek se rovněž kóduje Base64. Avšak na konec se přidá jeden znak „=“ signalizující doplnění výplní dlouhou dva bity.
· Má jeden bajt (8 bitů), pak se prvních 6 bitů kóduje normálně dle tabulky Base64. Zbylé dva bity se doplní čtyřmi binárními nulami a výsledek se kóduje dle tabulky Base64. Na konec se přidají dva znaky „=“ signalizující výplň dlouhou 4 bity.
Nejlépe se princip pochopí na příkladech:
Příklad: délka vstupního
textu je dělitelná třemi
|
Vstup 8-bit: |
01101101 01001000 01111011 11100011
10101010 11110001 |
|
Vstup 6-bit: |
011011 010100 100001 111011
111000 111010 101011 110001 |
|
Desítkově: |
27 20 33 59 56 58 43
49 |
|
Base64 (výstup): |
b U h 7 4 6 r x |
Příklad: poslední skupina
má dva bajty
|
Vstup 8-bit: |
01101101 01001000 01111011 11100011
10101010 |
|
Výplň: |
00 |
|
Vstup 6-bit: |
011011 010100 100001 111011
111000 111010 101000 |
|
Desítkově: |
27 20 33 59 56 58 40
|
|
Base64 (výstup): |
b U h 7 4 6 o
= |
Příklad: poslední skupina
má jeden bajt
|
Vstup 8-bit: |
01101101 01001000 01111011 11100011 |
|
Výplň: |
0000 |
|
Vstup 6-bit: |
011011 010100 100001 111011
111000 110000 |
|
Desítkově: |
27 20 33 59 56 48 |
|
Base64 (výstup): |
b U h 7 4 w ==
|
3.2.3 Radix-64
Kódování Radix-64 je popsáno v RFC-2440, které specifikuje formát zprávy PGP. Jedná se o rozšíření kódování Base64 o kontrolní součet. Data jsou kódována Base64. Za Base64 kódovanými daty následuje nový řádek (CRLF), znak „=“ a 24 bitů dlouhý kontrolní součet z původních nekódovaných dat počítaný algoritmem CRC-24. Sám kontrolní součet je též kódován Base64. Zdrojový kód algoritmu CRC-24 je uveden v RFC-2440.
Příklad (RFC-2440):
-----BEGIN PGP MESSAGE-----
Version:
OpenPrivacy 0.99
yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS
vBSFjNSiVHsuAA==
=njUN
-----END
PGP MESSAGE-----
V případě, že Váš software nepodporuje kódování Radix-64, pak stačí vypustit poslední řádek a data dekódovat běžným software pro Base64 kódování.
3.3 Znaky v hlavičce, které nejsou ASCII
Znaky, které nejsou ASCII, by se v žádném případě neměly vyskytnout v záhlaví zprávy. Na otázku co se stane, když se tam takový znak vyskytne, není jednoznačná odpověď. Zpráva může dojít příjemci bez problému, zpráva může být nějakým serverem na cestě vrácena nebo se může ztratit.
RFC-2047 řeší otázku, jak do parametrů hlaviček dodat znaky, které nejsou ASCII. I zde se problém skládá ze dvou částí:
- Co takový znak vyjadřuje? Např. hexadecimálně znak F8 může v jedné abecedě představovat ř a v jiné azbukové š.
- Jak je kódován do ASCII. Např. base64 nebo Quoted-printable.
Syntaxe parametru hlavičky obsahujícího znaky, které nejsou ASCII, je:
=?charset?kódování?řetězec?=
kódování je buď b pro base64 nebo q pro quoted printable.
Příklad:
Chce-li si odesilatel do hlavičky From zadat své jméno s diakritikou, pak:
From: =?iso8859-2?q?V=E1clav Vopi=E8ka?= <Vaclav.Vopicka@firma.cz>
Je zpráva od Václava Vopičky, který má poštovní adresu Vaclav.Vopicka@firma.cz, ale nemá rád své jméno bez háčků a čárek, tak si jej dal alespoň do ignorované časti hlavičky From:. Václav Vopička použil znakovou zadu iso8859-2.
3.4 Jednoduché typy dat v hlavičce Content-Type
Jednoduché typy v podstatě sdělují, jaký software má příjemcův poštovní klient použít pro zobrazení zprávy adresátovi. Zda-li zprávu má zobrazit textovým editorem, grafickým editorem, přehrávačem zvuku, videa či snad dokonce zobrazit jako virtuální realitu.
3.4.1 Text
Typ text je určen pro textové zprávy.
Typ text může mít mj. následující podtypy:
- plain - viz RFC-2646 a RFC-2046,
- richtext – viz RFC-2045 a RFC-2046,
- enriched - viz RFC-1896,
- html – viz RFC-2854,
- sgml - viz RFC-1874,
- c822-headers – viz RFC-1892,
- css - viz RFC-2318,
- xml – viz RFC-2376,
- directory – viz RFC-2425,
- calendar – viz RFC-2445.
- parityfec – viz RFC-3009.
Primární podtyp je plain, který označuje neformátovaný text. Podtypy se používají pro formátované texty. Příkladem je např. podtyp html, kdy text obsahuje příkazy jazyka HTML.
U typu text je možné použít parametr charset, který indikuje použitou znakovou sadu. Pro nás jsou zajímavé zejména sady US-ASCII, ISO-8859-2 („ISO-LATIN2“), Windows-1250 a případně IBM850.
Příklad:
Content-Type: text/plain; charset=us-ascii
Tento typ je implicitní. Tj. pokud ve zprávě MIME hlavička Content-Type uvedena není, pak se má za to, že zpráva je typu text/plain a použitá znaková sada je US-ASCII.
Příklad:
Content-Type: text/html;
charset=ISO-8859-2
3.4.2 Application
Tento typ je určen pro data, která je třeba zpracovat nějakou aplikací, aby byla čitelná pro uživatele. Jsou definovány podtypy: octet-stream a PostScript. Obecně podtyp bývá jménem aplikace, pro kterou jsou data určena. Uživatel musí být nějakým způsobem informován, jak dotyčná data zpracovat, např. průvodním dopisem. Pouze z hlavičky se o jejich bližším charakteru uživatel nemusí dozvědět všechny informace.
Podtypy:
- Octet-Stream -
indikuje, že tělo obsahuje binární data. Lze uvést parametry:
Type - druh binárních dat (pro informaci uživatele)
Doporučená akce při obdržení takovéto zprávy je uložit data do souboru bez dekódování a použít aplikaci.
- PostScript - indikuje, že v těle zprávy je postscriptový dokument.
- Další podtypy jsou mj.:
- sgml – viz RFC-1874
- pgp-sinature, pgp-encrypted a pgp-keys – viz RFC-2015
- pkcs7-mime, pkcs7-signature a pkcs-10 – viz RFC-2311
- xml - viz RFC-2376
- http – viz RFC-2616
- parityfec – viz RFC-3009
- msword – text ve formátu MS Word.
Příkald:
Content-Type: application/msword
Content-Disposition: attachment; filename="soubor.doc"
3.4.3 Image
Typ image specifikuje obrázek, tj. obsahem těla zprávy je obrázek. K jeho prezentaci je třeba odpovídající prohlížeč. Podtypy jsou mj.:
- jpeg – viz RFC-2045 a RFC-2046,
- gif – RFC-2045 a RFC2046,
- tiff – viz RFC2302.
Příklad:
Content-Type: image/jpeg
Content-Disposition: inline; filename="soubor.jpg"
3.4.4 Audio
Typ audio specifikuje zvuk. K prezentaci
je třeba odpovídající přehrávač. Podtypy jsou mj.:
- basic - mono se
vzorkovacím kmitočtem 8 kHz (implicitní podtyp),
- 32kadpcm - viz RFC-2421 a
RFC2422,
- L16 – viz RFC-2586,
- telephone-event - viz
RFC-2833,
- tone - viz RFC-2833,
- mpeg - viz RFC-3003,
- parityfec – RFC-3009,
- MP4A-LATM – viz RFC-3016.
Příklad:
Content-Type: audio/wav
3.4.5
Video
Obsahem těla zprávy je video, implicitní podtyp je mpeg.
Příklad:
Content-Type: video/mpeg
3.4.6 Model
Typ model je určen pro vícedimenzionální struktury (např. pro virtuální realitu). Typem model se zabývá RFC-2077.
3.5 Kompozitní typy v Content-Type
Doposud jsme se zabývali pouze jednoduchými zprávami, tj. zprávami, které se skládaly z jedné části (viz obr. 3-2).
Obr. 3-2 Struktura standardní zprávy dle RFC-822
Nyní se budeme zabývat zprávami složenými z více jednotlivých zpráv. Každá jednotlivá zpráva se může opět skládat z dílčích zpráv nebo již může být jednoduchou zprávou.
Zpráva může ve svém těle nést:
- Několik dílčích zpráv, pak je použito hlavičky (Content-Type: multipart).
- Dlouhá zpráva může být transportována jako několik kratších (Content-Type: message).
- Jiným případem je situace, že poštovní server z nějaké příčiny nemůže poštovní zprávu předat dále směrem k adresátovi pro chybu v doručování zprávy. V takovém případě poštovní servery často tuto skutečnost signalizují adresátovi poštovní zprávou, která se skládá ze dvou částí: z části specifikující chybu a části obsahující původní zprávu (nebo alespoň počátek původní zprávy).
3.5.1 Multipart
Tělo zprávy tohoto typu obsahuje několik různých částí - několik dílčích zpráv. Každá část těla celkové zprávy začíná úvodním oddělovačem, pak následují hlavičky této části, prázdný řádek a vlastní tělo dílčí zprávy. Poslední část je ukončena koncovým oddělovačem.
Jednotlivé dílčí zprávy nejsou interpretovány podle RFC-822. Mohou, ale také nemusí obsahovat hlavičky (prázdný řádek za záhlavím však musí být vždy uveden). Pokud nejsou hlavičky u části uvedeny, uplatní se implicitní hlavičky ze záhlaví celé zprávy.
Oddělovač je speciální sekvence znaků, která se nesmí vyskytnout nikde uvnitř částí. Oddělovač se definuje v záhlaví celé zprávy v hlavičce Content-Type parametrem boundary.
Parametr má tvar boundary=řetězec. Oddělovač je pak řádka, která začíná dvěma pomlčkami "- -", pak následuje řetězec z parametru. Maximální délka oddělovače je 70 znaků.
|
|
From: Libor Dostalek <dostalek@pvt.cz> Toto je preambule, která je ignorována. Je to proto místo
vhodné k vložení informací pro klienty, kteří Prvni nazor Druhy názor (tentokrát s háčky a čárkami) --gc0p4J:2408t-- |
Obr. 3-3 Zpráva typu multipart/mixed
Příklad:
Content-Type: multipart/mixed;
boundary="gc0p4J:2408t"
Tato hlavička vyjadřuje, že je tělo zprávy složeno z několika částí, přičemž hlavičky jednotlivých částí nemusí
být uvedeny. Každá část začíná řádkou:
- - gc0p4J:2408t
Koncový oddělovač určuje, že již nenásleduje žádná část, a má tvar:
- - gc0p4J:2408t - -
tj. je na konci doplněný ještě dvěma pomlčkami.
Podtypy:
·
Multipart/Mixed - je primárním podtypem. Je
určen pro zprávy, které obsahují nezávislé části, které je potřeba svázat v
daném konkrétním pořadí. Klasickým případem podtypu multipart/mixed je zpráva elektronické pošty obsahující
jeden nebo více příloh.
- Multipart/Alternative
Zpráva tohoto typu obsahuje několik částí, přitom všechny části obsahují
shodné informace, pouze tvar je odlišný. Např. táž zpráva jednou napsaná v
US-ASCII, potom v ISO-8859-2 a nakonec třeba namluvena, tj. audio.
Nejlepší prezentace informací je uváděna jako poslední část. Příjemcův
software musí rozpoznat, které formy je schopen zobrazit, a vybrat z nich
tu nejlepší.
Příklad:
From: andel@pvt.cz
To: cert@peklo.org Subject: Pozvani MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=boundary42 Pro pripad, ze Tvuj prohlizec neumi MIME, tak Te proste zvu na vylet. --boundary42 Content-Type: text/plain; charset=us-ascii Zvu te i bez hacku a carek --boundary42 Content-Type: text/html; charset=us/ascii Pridej se <H1>k nam</H1> --boundary42 Content-Type: audio/basic Content-Transfer-Encoding: base64 UklGRkYtAABXQVZFZm10IBAAAAABAAEAIlYAACJWAAABAAgAZGF0YSItAACAgICAgICAgICA gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA
gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA
...
--boundary42--
Software vytvářející zprávu tohoto typu musí řadit části ve vzrůstající kvalitě.
- Multipart/Report. S tímto
podtypem jsme se setkali ve 2. kapitole v části o potvrzování
doručovaných poštovních zpráv.
- Multipart/Parallel.
Klientem mají být všechny části prezentovány uživateli současně. Např.
zvuk na pozadí obrázku.
Následující příklad zprávy se skládá ze tří částí. Třetí část se skládá ze dvou částí, které mají být prezentovány současně.
MIME-Version: 1.0
From:
To:
Date:
Subject: Priklad
Content-Type: multipart/mixed; boundary=unique-boundary-1
Zde je misto pro text, kterym je mozne
objasnit smysl zpravy pro ty,
kteri nejsou schopni zpravu podle MIME interpretovat.
Treti dilci zprava obsahuje obrazek, na jehoz
pozadi se ma spustit hudba.
--unique-boundary-1
První dílčí zpráva
--unique-boundary-1
Content-type: text/plain; charset=US-ASCII
Druha dilci zprava
--unique-boundary-1
Content-Type: multipart/parallel; boundary=unique-boundary-2
--unique-boundary-2
Content-Type: audio/basic
Content-Transfer-Encoding: base64
... base64-kódované mono se vzorkovacím
kmitočtem 8 KHz
--unique-boundary-2
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
... base64-kódovaný obrázek formátu JPEG
--unique-boundary-2--
--unique-boundary-1—
- Multipart/Signed a
Multipart/Encrypted jsou subtypy definované v RFC1847.
Subtyp Multipart/Signed je určen pro elektronicky podepsanou zprávu; specifikuje zprávu skládající se ze dvou částí: - Zprávy
- Elektronického podpisu této zprávy
Subtyp Multipart/Encrypted specifikuje zprávu v elektronické obálce (šifrovanou zprávu). Skládá se opět ze dvou částí:
- Z informací o použitém způsobu šifrování (např. verzi šifrovacího software).
- Z šifrované zprávy.
Není definován subtyp pro zprávy elektronicky podepsané a zároveň šifrované. Na takovýto požadavek je nutné zprávu nejprve elektronicky podepsat a výsledek pak celý šifrovat.
Příkladem může být PGP.
Pokud nepoužijete MIME, pak se veškeré informace ukládá do datové části
zprávy. Např.:
Subject: Tajna zprava
Date: Sat, 19 Apr 1997 17:16:27 +0200
From: Libor Dostalek <dostalek@pvt.cz>
To: alena@pvt.net
-----BEGIN PGP MESSAGE-----
Version: 2.6.3i
hEwDVzIQ/0AACWUBAgCjg7Plko8fm4nrCZOn7LQprCvcMelrF7qr2N5S5adUHujQ
hiUmcIMDK8zx+Cvm52lD68NZxKybexuaAESa+fMgpgAAALFXB4DlbeEWRHe6GwDz
vYMsWPbK7+UFC9ZXeHsKc+c6iPokzMG/NWHf76/OLJXV3iKIKrfRFycA77Pu1G/X
IccoMlAIfC29cqT7Y//q5TvYAwDoqpfIjoVaqz8dIjqy2G/2rf+acb4nyitLEtwL
NE0huVXKsgenm39MqQp9A5W+dWzC8OcB2uHTzdzpQgNzJJ5JYf1/L75XZ0la3jyA
t7HvXV6IPqQPIw0s0uChsEaKDPI=
-----END PGP MESSAGE-----
Takovou zprávu musíme nejprve uložit do souboru a pak na tento soubor spustit program PGP. Zejména příjemce musí rozpoznat, že jde o zprávu, kterou má zpracovat programem PGP.
RFC2015 zavádí typy:
· application/pgp-encrypted
· application/pgp-signature
· application/pgp-keys
Takže náš příklad může vypadat např. následovně:
Subject: Tajna zprava
Date: Sat, 19 Apr 1997 17:16:27 +0200
From: Libor Dostalek <dostalek@pvt.cz>
To: alena@pvt.net
Mime-Version: 1.0
Content-Type: multipart/encrypted; boundery=hranice;
protocol=application/pgp-encrypted
--hranice
Contentn-Type: application/pgp-encrypted
Version: 1.
--hranice
Content-Type: application/octet-stream
-----BEGIN PGP MESSAGE-----
Version: 2.6.3i
hEwDVzIQ/0AACWUBAgCjg7Plko8fm4nrCZOn7LQprCvcMelrF7qr2N5S5adUHujQ
hiUmcIMDK8zx+Cvm52lD68NZxKybexuaAESa+fMgpgAAALFXB4DlbeEWRHe6GwDz
vYMsWPbK7+UFC9ZXeHsKc+c6iPokzMG/NWHf76/OLJXV3iKIKrfRFycA77Pu1G/X
IccoMlAIfC29cqT7Y//q5TvYAwDoqpfIjoVaqz8dIjqy2G/2rf+acb4nyitLEtwL
NE0huVXKsgenm39MqQp9A5W+dWzC8OcB2uHTzdzpQgNzJJ5JYf1/L75XZ0la3jyA
t7HvXV6IPqQPIw0s0uChsEaKDPI=
-----END PGP MESSAGE-----
--hranice--
Za povšimnutí stojí, že první část nenese žádné kryptografické údaje - vše je v druhé části. První část nese pouze informaci o verzi PGP/MIME, tj. je umělá, aby syntaxe vyhovovala MIME.
3.5.2 Message
Tento typ umožňuje odeslat poštovní zprávu jako tělo jiné poštovní zprávy (message/rfc822), dlouhou zprávu odeslat jako několik kratších (message/partial) nebo namísto těla zprávy odeslat jen informace, že se zpráva nachází na nějakém serveru (message/external-body).
Podtypy jsou mj.:
- Message/rfc822 specifikuje, že tělo obsahuje vnořenou zprávu, která má syntaxi podle RFC-822. Na rozdíl od zprávy definované v RFC-822 není nutné, aby každé tělo zprávy typu message/rfc822 obsahovalo hlavičky From, Subject a To. Vnořená zpráva může být i MIME zpráva.
- Message/Partial je
definován proto, aby bylo možné posílat dlouhé zprávy jako několik
kratších a příjemcův software je mohl automaticky zobrazit jako jednu
(sloučenou) zprávu.
RFC 2046 uvádí následující příklad. Příjemce obdržel 2 maily:
|
From:
Bill@host.com Message-ID:
<anotherid@foo.com> ... Prvni cast audio mailu ... |
|
From:
Bill@host.com ... druha cast audiomailu ... |
Příjemcův software zjistil, že se jedná o dvě části téže zprávy o identifikaci (id) ABC@host.com. Jednotlivé části jsou číslovány pomocí parametru number. Celkový počet částí (total) je 2. Takže příjemcův software má k dispozici celou zprávu a může ji zobrazit jako:
|
From:
Bill@host.com ... prvni cast audiomailu
... |
Jelikož se jedná o Content-Type: audio/basic, tak zpráva není zobrazena jako
textový soubor, ale přehrána jako audio.
- Message/External-Body specifikuje pouze informace o zprávě, která je uložena mimo vlastní zprávu. Místo, kde jsou data zprávy uložena, je specifikováno pomocí parametrů:
- Parametr acces-type specifikuje, o jaký server (protokol) se jedná. Nejčastější typy serverů jsou ftp, anon-ftp (anonymní FTP-server), mail-server (list server) a local-file (soubor na lokálním počítači).
- name - jméno souboru
- site - jméno počítače (serveru se souborem)
- directory - adresář, ve kterém soubor leží
- expiration - čas, do kdy tam soubor bude (do kdy bude aktuální).
Příklad (RFC 2046):
From:
To:
Date:
Subject:
MIME-Version: 1.0
Message-ID: <id1@host.com>
Content-Type:
multipart/alternative; boundary=42
Content-ID:
<id001@guppylake.bellcore.com>
--42
Content-Type:
message/external-body; name="BodyFormats.ps";
site="thumper.bellcore.com"; mode="image";
access-type=ANON-FTP; directory="pub"; expiration="Fri, 14 Jun
1991 19:13:14 -0400 (EDT)"
Content-type:
application/postscript
Content-ID:
<id42@guppylake.bellcore.com>
--42
Content-Type:
message/external-body; access-type=local-file;
name="/u/nsb/writing/rfcs/RFC-MIME.ps";
site="thumper.bellcore.com"; expiration="Fri, 14 Jun 1991
19:13:14 -0400 (EDT)"
Content-type:
application/postscript
Content-ID:
<id42@guppylake.bellcore.com>
--42
Content-Type:
message/external-body; access-type=mail-server
server="listserv@bogus.bitnet"; expiration="Fri, 14 Jun 1991
19:13:14 -0400 (EDT)"
Content-type:
application/postscript
Content-ID:
<id42@guppylake.bellcore.com>
--42--
V tomto příkladu odesilatel posílá tři odkazy na stejná data. První kopie dat je na anonymním FTP-serveru, druhá na lokálním disku a třetí lze získat z archivu list serveru.
Zatímco identifikace celé zprávy je nepovinná (<id1@host.com>), tak identifikace obsahu dílčí zprávy je povinná (<id42@guppylake.bellcore.com>).
Důležité je si také uvědomit, že obsahem těla dílčí zprávy nejsou data, ale informace o této zprávě. Hlavičku Content-Type tak máme použitu celkem ve třech různých významech:
1.
Content-Type: multipart/alternative;
boundary=42
Specifikuje typ zprávy jako celku.
2.
Content-Type:
message/external-body;
Specifikuje, typ dílčí zprávy - jedná se o odkaz.
3.
Content-Type:
application/postscript
Toto v podstatě není hlavička, ale obsah zprávy, kterým se specifikuje typ dat,
na které je odkazováno.