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č:

  1. Textový editor pro text.
  2. Grafický editor pro obrázek.
  3. 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:

3.1               Hlavičky MIME

MIME zavádí hlavičky:

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:

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í:

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:

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í

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:

 

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í:

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:

 

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:

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.

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.:

 

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.:

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:

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>
To: drdak@ica.cz
Subject: Zprava obsahujici me 2 nazory
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="gc0p4J:2408t"

Toto je preambule, která je ignorována. Je to proto místo vhodné k vložení informací pro klienty, kteří
nepodporují MIME.
--gc0p4J:2408t

Prvni nazor
Vsimnete si, ze tato cast neobsahuje zadne hlavicky, tj. jako by byla pouzita hlavicka:
Content-Type: text/plain; charset=us-ascii
presto obsahuje prazdny radek oddelujici zahlavi od tela.
 
--gc0p4J:2408t
Content-type: text/plain; charset=iso-8859-2

 

Druhy názor (tentokrát s háčky a čárkami)
 

--gc0p4J:2408t--
Toto je zaver, je také ignorovan.

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.
 

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ě.

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—

Subtyp Multipart/Encrypted specifikuje zprávu v elektronické obálce (šifrovanou zprávu). Skládá se opět ze dvou částí:

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.:

RFC 2046 uvádí následující příklad. Příjemce obdržel 2 maily:

From: Bill@host.com 
To: joe@otherhost.com 
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST) 
Subject: Audio mail (part 1 of 2) 
Message-ID: <id1@host.com> 
MIME-Version: 1.0 
Content-type: message/partial; id="ABC@host.com"; number=1; total=2

Message-ID: <anotherid@foo.com> 
Subject: Audio mail MIME-Version: 1.0 
Content-type: audio/basic 
Content-transfer-encoding: base64

... Prvni cast audio mailu ...

From: Bill@host.com 
To: joe@otherhost.com 
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST) 
Subject: Audio mail (part 2 of 2) 
MIME-Version: 1.0 
Message-ID: <id2@host.com> 
Content-type: message/partial; id="ABC@host.com"; number=2; total=2

... 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 
To: joe@otherhost.com 
Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST) 
Subject: Audio mail 
Message-ID: <anotherid@foo.com> 
MIME-Version: 1.0 
Content-type: audio/basic 
Content-transfer-encoding: base64

... prvni cast audiomailu ... 
... druha cast audiomailu ...


Jelikož se jedná o Content-Type: audio/basic, tak zpráva není zobrazena jako textový soubor, ale přehrána jako audio.

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.