Copyright © 1997 RNDr. Libor Dostálek a Ing. Alena Kabelová

MIME - Multipurpose Internet Mail Extension


Proč MIME vzniklo?

Formát textových zpráv přenášených v Internetu byl definován dvojicí norem RFC821/RFC822. Tato norma specifikuje formát textových zpráv pro elektronickou poštu.

Brzy se však ukázalo, že tento standard nevyhovuje požadavkům uživatelů, protože se mail ukázal jako vhodný prostředek pro posílání nejen holých textových zpráv, ale i pro posílání obrázků, zvuků, formátovaného textu, obecně binárních souborů, virtuální reality atp. V poslední době pak přibyl požadavek na posílání bezpečných zpráv, tj. šifrovaných i elektronicky podepsaných.

Princip vyměny zpráv se rychle rozšířil i za hranice elektronické pošty. Zprávy podobného formátu používá nejenom elektronická pošta, ale i news a protokol HTTP.

Lépe řečeno požadavky uživalelů rychle překročily možnosti nabízené normami RFC821/RFC822. Začaly se objevovat normy rozšiřující původní standard. Tato rozšíření se označují MIME.

Z historického hlediska původní norma umožňovala posílat zprávy psané ASCII-znaky, kde délka řádku byla omezena na 1000 znaků. Nepříjemná tedy byla skutečnost, že nebylo možné poslat text s diakritikou v našem případě text skutečně český a ne pouze cesky.

Posílání binárních souborů pomocí mailu se řešilo náhradní cestou. Soubory musely být před posláním předpřipraveny (šifrovány do sedmibitového tvaru) pomocí nějakého kódovacího programu. Kódovací program převedl binární soubor do tvaru, který vyhovoval RFC822. Příkladem takového kódovacího programu v Unixu je dvojice programů uuencode/uudecode.

Ještě před tím, než si popíšeme jednotlivé možnosti rozšíření zpráv, tak si zopakujeme jaký má zpráva v jednotlivých protokolech formát. Nejprve se zastavíme u elektronické pošty, ze které vše vzniklo.

Elektronická pošta

Elektronická pošta je v Internetu základní aplikací. Slouží pro výměnu zpráv mezi uživateli Internetu. V praxi se však často setkáváme s případem, kdy si elektronickou poštou předávají data aplikace běžící na různých počítačích.

Většinou vždy, kdy úloha má dávkový charakter, je možné použít elektronickou poštu. Pro ty, kteří chtějí namítnout, že to není bezpečné, tak předběhneme a předem jim odpovíme, že pomocí rozšíření (např. S/MIME) je možné posílat zprávy i šifrované a elektronicky podepsané.

Zpráva elektronické pošty se skládá ze dvou částí:

Následující rámec schématicky znázorňuje zprávu elektronické pošty:
 
Received: .................................
Received: .................................
Date: ...................................
From: ........................................
Subject: ............................
To: .........................................
Message-Id: ............................

Text zprávy

Zajímavá je hlavička Received:. Tuto hlavičku připisuje na počátek mailu každá mailova gateway (mailový server), kterou zpráva prochází. Takže čteme-li hlavičky Received: od spodu nahoru, tak zjistíme celou trasu, přes které mailové servery zpráva šla.

RFC822 zavádí hlavičky:
 
Hlavička Význam
Received: Viz výše
From: Odesilatel (autor)
Sender: Vyřizuje (sekretářka)
Date: Datum odeslání
(Den, datum, čas a časová zóna)
Reply-To: Odpověď zasílejte na
To: Adresát
Cc: Na vědomí
Bcc: Na vědomí (tajná kopie - tato hlavička 
se před odesláním zruší)
Message-Id: Identifikace zprávy
In-Reply-To: Odpověď na
Keywords: Klíčová slova charakterizující obsah
References: Další odkazy
Subject: Věc 
(krátká charakteristika obsahu zprávy)
Comments: Komentář
Encrypted: Šifrováno (zastaralé)
X- Uživatelsky definovaná hlavička
(uživatelem se rozumí autor software) 

Např. X-Mailer se často používá 
pro specifikaci programu, kterým
odesilatel odesílá zprávu

Resent- Při automatickém předávání (forward)
zprávy se před původní hlavičky vloží řetězec Resent- 

Např.Resent-From nebo Resent-Cc apod.

Všechny hlavičky mohou (v hodnotách nikoliv uprostřed klíčových slov) obsahovat komentář v kulatých závorkách. V komentáři se však nesmějí vyskytovat některé znaky - blíže viz RFC822.

V následujícím rámci je pak uveden příklad skutečné zprávy poslané elektronickou poštou:
 
       
    Received: from mh.pvt.cz (mh.pvt.cz [194.149.105.36]) by cbu.pvtnet.cz 
               (8.8.5/8.7.3) with SMTP id PAA23028; 
               Wed, 16 Apr 1997 15:10:14 +0200 (MET DST)
    Received: from ncc.ripe.net by mh.pvt.cz with SMTP id AA08008
               (5.67b/IDA-1.5 for <registr@pvt.cz>); 
               Wed, 16 Apr 1997 15:05:09 +0200
    Received: by ncc.ripe.net 
               id AA00228 (5.65a/NCC-2.41); Wed, 16 Apr 1997 13:55:02 +0200
    Received: from mail.freedotnet.net by ncc.ripe.net with SMTP
               id AA00215 (5.65a/NCC-2.41); Wed, 16 Apr 1997 13:55:00 +0200
    Received: from jon.freedotnet.net ([208.215.186.129])
               by homer.freedotnet.com (Netscape Mail Server v2.02) with ESMTP    
               id AAA105 for <local-ir@ripe.net>;
               Wed, 16 Apr 1997 13:09:15 +0100
    Reply-To: <jon.brody@freedotnet.net>
    From: "Dr Jon Brody" <jon.brody@freedotnet.net>
    To: <local-ir@ripe.net>
    Subject: Re: Role?
    Date: Wed, 16 Apr 1997 12:58:51 +0100
    X-Mailer: Microsoft Internet Mail 4.70.1155
    
    I'm sorry if this offends, but I'm not really that interested in being
    constantly mailed (about 70 to date) about one person's problems.
    Wouldn't our time be better spent working than being party to this?
    If one has a problem with, tell them, please, not me.....
    
    

Čteme-li hlavičky Received od spodu nahoru, pak vidíme, že zpráva byla odeslána z počítače jon.freedotnet.net, pak ji zpracovával počítač homer.freedotnet.net (počítač mail.freedotnet.net je jen jiné jméno téhož počítače). Dále zpráva putovala na ncc.ripe.net, který ji předal na mh.pvt.cz a nakonec zkončila na cbu.pvtnet.cz.

Problém jak poslat elektronickou poštou zprávu obsahující jiná data než text psaný v kódu ASCII lze řešit dvojím způsobem:

  1. Předem si připravit (zakódovat) zprávu do ASCII znaků a tu posléze poslat mailem. Odesilatel se s příjemcem předem dohodnou na způsobu kódování zpráv do ASCII. Odesilatel a příjemce se tedy musí jinou cestou dohodnout na typu přenášených dat a způsobu kódování do ASCII.
  2. Druhou možností je, rozšířit repertoár hlaviček o hlavičky popisující typ přenášených dat a algoritmus, kterým byla před odesláním data kódována do ASCII. Popis těchto dodatečných hlaviček specifikuje právě norma MIME.

  3. V tomto případě může příjemcův software z hlaviček automaticky dekódovat zprávu a rozpoznat typ přenášených dat. Příjemci pak podle typu přenášených dat spustí příslušný prohlížeč:

Příklady prvního typu zpráv (odesilatel musí být s příjemcem dohodnuti na kódování a typu přenášených zpráv)

Zpráva, kterou odesilatel předem připravil šifrovacím programem pgp
pgp -esa soubor
a následně ji jako text odeslal. Program pgp vyrobí zprávu a uzavře ji do závorek
-----BEGIN PGP MESSAGE-----
a
-----END PGP MESSAGE-----
 
       
    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-----
Následující příklad je odeslání zprávy připravené programem uuencode
$ cat soubor | uudecode soubor.uue | mail alena@pvt.net
který zprávu obalí závorkami:
begin práva soubor
a
end
 
       
    Subject: Zprava kodovana uuencode
    Date:    Sat, 19 Apr 1997 17:12:26 +0200
    From:    System PRIVILEGED Account <root@pvt.cz>
    To:      alena@pvt.net
    
    begin 644 soubor.uue
    M(" U.C$R<&T@('5P(#$W(&1A>7,L(" Y.C$X+" @,2!U<V5R+" @;&]A9"!A    
    M=F5R86=E.B P+C U+" P+C P+" P+C P"E5S97(@(" @('1T>2!F<F]M(" @
    *(" @(" @('<@"B @
    end

Zkušený příjemce sice v těchto případech na první pohled pozná o jaký typ kódování se jedná, ale obecně nelze zaručit, že příjemce bez toho, aniž by se předem dohodl s odesilatelem, pozná co má se zprávou dělat.

Příklad druhého typu zprávy (záhlaví zprávy je obohaceno o hlavičky specifikující způsob kódování a typ přenášené zprávy)

V následujícím rámu je příklad takové zprávy. Odesilatel odesílá dvě alternativy téže zprávy. Jednu pro případ, že příjemce ji bude číst běžným textovým prohlížečem (editorem) a druhou alternativu pro případ, že zpráva bude čtena prohlížečem, který podporuje jazyk HTML.

Tyto informace nesou hlavičky začínající řetězcem "Content-", které specifikuje norma MIME. Objasnění významu těchto hlaviček je cílem následujícíh kapitol.
 
                                      
    From: "Dr Jon Brody" <jon.brody@freedotnet.net>
    To: <local-ir@ripe.net>
    Subject: Re: Role?
    Date: Wed, 16 Apr 1997 12:58:51 +0100
    X-Mailer: Microsoft Internet Mail 4.70.1155
    Mime-Version: 1.0
    Content-Type: multipart/alternative; boundary="----=_NextPart"
    Content-Transfer-Encoding: 7bit
    Message-Id: <19970416120915085.AAA105@jon.freedotnet.net>
    Content-Length: 1095
    
    
    This is a multi-part message in MIME format.
    
    ------=_NextPart
    Content-Type: text/plain; charset=ISO-8859-1
    Content-Transfer-Encoding: 7bit
    
    I'm sorry if this offends, but I'm not really that interested in being   
    constantly mailed (about 70 to date) about one person's problems.
    
    Wouldn't our time be better spent working than being party to this?
    
    If one has a problem, tell them, please, not me.....
    
    ------=_NextPart
    Content-Type: text/html; charset=ISO-8859-1
    Content-Transfer-Encoding: quoted-printable
    
    
    <html><head></head><BODY bgcolor=3D"#FFFFFF"><p><font size=3D2 =
    color=3D"#000000" face=3D"Arial">I'm sorry if
    this offends, but I'm not =
    really that interested in being constantly mailed 
    about 70 to date) =
    about one person's problems.<br><br>Wouldn't our time be =
    problem, tell them, please, not me.....<br><br><br></p>
    </font></body></html>
    ------=_NextPart--

News

News používá velmi podobný tvar svých zpráv. Podle RFC1036 jsou hlavičky rozděleny na:
Hlavička Význam
From: Odesilatel (autor)
Date: Datum odeslání
(Den, datum, čas a časová zóna)
Newsgroups: Skupina do které zpráva patří
(Obdoba To: u mailu)
Subject: Věc 
(krátká charakteristika obsahu zprávy)
Message-id: Identifikace zprávy
Path: Cesta (seznam serverů), kterou zpráva
urazila od odesilatele - viz dále
Followup-To: Skupiny, do kterých má být zpráva také odeslána
(Obdoba Cc: u mailu)
Expires: Datum do kdy má být zpráva udržována na serveru.
Poté je zpráva zrušena. 
Reply-To: Mailová adresa odesilatele
Sender: Vyřizuje (sekretářka)
References: Další odkazy
Control: Řídící hlavička. Pomocí této hlavičky se řídí komunikace mezi servery.
Tato hlavička není určena pro komunikaci uživatele se serverem.
Distribution: Tato hlavička zmenšuje počet serveru, na které bude zpráva distribuována.
Zpráva bude šířena pouze na servery uvedené v této hlavičce.
Keywords: Klíčová slova.
Summary: Krátký obsah zprávy.
Approved: Zpráva schválena (povolena k šíření). Tato hlavička se používá v moderovaných konferencích.
Jako parametr se uvede mail osoby, která zprávu povolila.
Lines: Počet řádků těla zprávy.
Xref: Přesná identifikace zprávy v konferenci
(server konference:číslo)
Organization: Zaměstnavatel uživatele

Reálný příklad zprávy systému news následuje. Odeslal jsem obrázek formátu JPEG jako příspěvek do diskuzní skupiny - konference news.newusers.questions:
 
     
    Path: pvtnet.cz!not-for-mail
    From: Libor Dostálek <dostalek@pvt.cz>
    Newsgroups: news.newusers.questions
    Subject: TEST JPG
    Date: Mon, 05 May 1997 14:42:12 +0200
    Organization: PVT a.s.
    Lines: 330
    Message-ID: <336DD5A4.6D8B@pvt.cz>
    NNTP-Posting-Host: libor.pvt.net
    Xref: pvtnet.cz news.newusers.questions:590527
    Mime-Version: 1.0
    Content-Type: image/jpeg; name="sit.jpg"
    Content-Transfer-Encoding: base64
    
    /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof     
    Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh
    ...
    38mtHYTCtCirSPqrVzfTXI0V28Pjf8OrTcNj3leb+up0cKGJk0SM0HNE0WCE2GlDov4SiY3C
    kUj/2Q==

V předchozím příkladu byla velice jednoduchá hlavička Path, protože zpráva byla serverem zpracována lokálně. V následujícím příkladu je příklad cesty z reálného života. Zprávu odeslal uživatel vladboro@mff.cuni.cz z počítače ns2.aladdin.net a já jako uživatel jsem si jí získal ze serveru pvtnet.cz. Všechny počítače oddělené vykřičníkem tvoří cestu zprávy news mezi těmito dvěma news-servery.
 
Path:   pvtnet.cz!uunet!in2.uu.net!206.229.87.25!news-peer.sprintlink.net!news.sprintlink.net!Sprint!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!rill.news.pipex.net!pipex!Aladdin!aladdin.net!ns2.aladdin.net!not-for-mail
From:   Vladimir Borovicka <vladboro@mff.cuni.cz>;

Záměrně jsem poslal jako příspěvek do konference zprávu obsahující obrázek (ne text), aby jste si mohli všimnout, že i news mohou obsahovat rozšiřující hlavičky MIME (začínají řetězcem Content-).

Podobně i zprávy news je možné posílat šifrované i elektronicky podepsané (Secure news - S/NEWS).

Protokol HTTP

Obdobnou strukturu zprávy jako elektronická pošta používá i protokol HTTP. Avšak u protokolu HTTP má speciální význam první řádek záhlaví. V dotazu specifikuje metodu (GET, POST, HEAD, STATUS atp.) požadovaná data (např. jméno souboru) a verzi protokolu HTTP. Dále pak následují hlavičky, prázdný řádek a případně data zprávy.

V následujícím rámci uvádíme příklad dotazu v protokolu HTTP, který obsahuje pouze hlavičky a má prázdné tělo (prázdný řádek ukončující záhlaví však nesmí chybět - na obrázku to nelze dostatečně zdůraznit).
 
                                     
    GET prirucka.htm HTTP/1.1
    Host: info.pvt.net

Odpověď v protokolu HTTP obsahuje jako první řádek tzv. stavový řádek specifikující verzi protokolu HTTP použitého serverem (musí být stejná nebo nižší než uvedl klient) a výsledkový kód, případně textový význam výsledkového kódu.

Data zprávy jsou od záhlaví opět oddělena právě jedním prázdným řádkem. Příklad je v následujícím rámci:
 
                                     
    HTTP/1.0 200 OK
    Server: Netscape-FastTrack/2.01
    Date: Fri, 18 Apr 1997 13:49:20 GMT
    Accept-ranges: bytes
    Last-modified: Wed, 26 Mar 1997 06:39:49 GMT      
    Content-length: 1940
    Content-type: text/html
    
    <HTML>
    <HEAD>
    <TITLE>Titulek</TITLE>
    </HEAD>
    <BODY>
    <H1>Kapitola</H1>
    ...
    </BODY>
    </HTML>

Zatímco u elektronické pošty a u news jsme oddělovali hlavičky pošty (resp. news) od hlaviček MIME, tak v případě protokolu HTTP jsou hlavičky začínající řetězcem Content součástí specifikace protokolu HTTP.

Na rozdíl od elektronické pošty a news je protokol HTTP interaktivní. To umožňuje, aby se oba účastníci komunikace (klient a server) nejprve dohodli na kódování, kompresním algoritmu, jazyku atd. Takže ještě před tím než jsou data odeslána s příslušnou hlavičkou začínající řetězcem Content, tak protějšek nabízí jaké možnosti podporuje (hlavičkami začínajícími řetězcem Accept).

Přehled hlaviček HTTP/1.1:
 
Hlavička Vyznam
Accept: Seznam podporovaných typů (anglicky medium) 

Příklad:
Accept: text/plain; q=0.5, text/html
(preferovaný typ je text/html, s prioritou 0.5 je možný typ text/plain)

Accept-Charset: Seznam podporovaných znakových sad 

Příklad:
Accept-Charset: iso-8859-2, iso-8859-1; q=0.2
(preferovaná sada je iso-8859-2, možná je i iso-8859-1)

Accept-Encoding: Podporované kódování. Zpravidla se používá pro kompresi dat. 

Příklad:
Accept-Encoding: gzip, compress

Accept-Language: Podporavaný jazyk 

Accept-Language: cz, en-gb;q=0.5
(Preferovaný jazyk čeština, možná je i angličtina)

Accept-Range: Podporované množství přenášených dat
Age: Čas po který může cache použít data
Allow: Seznam podporovaných metod 

Příklad:
Allow: GET, PUT, HEAD

Authorization: Tato hlavička se používá pro autorizaci. Klient v této hlavičce uvádí informace, kterými prokazuje svou totožnost.
Cache-Control: Tato hlavička se používá pro řízení dat v cache.
Content-Base: Kořen absolutního URL. Používá-li se relativní URL, pak předsazením obsahu této
hlavičky před relativní URL vznikne absolutní URL.
Content-Encoding: Použité kódování. Zpravidla použitý kompresní algoritmus. 

Content-Encoding: gzip

Content-Language: Použitý jazyk 

Content-Language: en

Content-Length: Velikost těla zprávy v bajtech.
Content-Location: Zpráva je na uvedeném URL.
Content-MD5: Kontrolní součet přenášené zprávy vytvořený algoritmem MD5 (RFC1864)
Content-Range: Část zprávy (odeslaná serverem). 

Příklad: Prvních 1000 bajtů zprvávy dlouhé 5555 bajtů:
Content-Range: 0-999/5555

Content-Type: Typ přenášené zprávy 

Příklad:
Content-Type: model/vrml

Date: Den, datum, čas a časová zóna
ETag: Definice tagu
Expires: Čas po kterém zpráva v cache expiruje.
From: Poštovní adresa odesilatele.
Host: Specifikuje server (zejména virtuální).
If- Hlavičky začínající If umožňují vydávat podmíněné požadavky.
Last-Modified: Datum a čas poslední modifikace zprávy.
Location: Přesměrování na jiné URL
Max-Forwarders: Max. počet proxy na cestě mezi klientem a serverem
(význam má pro metodu TRACE)
Pragma: Hlavička pro uživatelsky definované potřeby.
Proxy-Authenticate:
Proxy-Autorization:
Obdoba hlaviček Authorization: a WWW-Authenticate:, které slouží k vyžádání a prokázání totožnosti klienta vůči originálnímu serveru. Hlavičky Proxy-Autorization: a Proxy-Authenticate: slouží pro vyžádání a prokázání totožnosti klienta vůči proxy serveru.
Public: Server touto hlavičkou dává na vědomí seznam jím podporovaných metod. 

Public: GET, PUT

Range: Požadavak pouze na část zprávy. 

Range: 500-999

Refer: Klient specifikuje serveru, odkud se o zprávě dozvěděl. 

Refer: http://info.pvt.net

Retry-After: V případě výpadku spojení se má opakovat pokus o opětovné navázání spojení za.
Server: Informace o software použitém jako server. 

Server: CERN/3.0

Transfer-Encoding: Kódovací algoritmus použitý pro přenos zpráv. Jelikož je HTTP osmibitový, tak tato hlavička není příliš častá.
Upgrade: Klient specifikuje jaké další protokoly podporuje 

Upgrade: SHTTP/1.3

User-Agent: Obsahuje informace o programu klienta. 

User-Agent: CERN-LineMode/2.15

Vary: Změna typu dat.
Via: Specifikuje cestu přes gatewaye a proxy. (Obdoba hlavičky Path u news). Každá proxy nebo gateway je povinna se do této hlavičky připsat.
Warning: Upozornění. Chybové hlášení je obsaženo ve stavovém řádku (první řádek zprávy). Jsou-li třeba uvést další vysvětlující informace, pak se uvedou v této hlavičce.
WWW-authenticate: V případě, že server vyžaduje autorizovaný přístup, pak v odpovědi 401 (Unauthorized) uvede hlavičku WWW-authenticate, kde uvede způsob jakým má klient prokázat svou totožnost (např. způsob basic - klient se prokazuje jménem a heslem). 

Klient v odpovědi uvede hlavičku Authorization se způsobem a příslušným řetězcem, kterým prokazuje svou totožnost (v případě basic auth. řetězec obsahuje zakódované jméno a heslo pomocí base64)

Z předchozí tabulky je zřejmé, že problematika MIME je do protokolu HTTP zcela organicky zapracována. Dále se v tomto textu nebudeme už zabývat problematikou protokolu HTTP. Naopak až budete studovat protokol HTTP, pak vám budou velmi užitečné informace uváděné v tomto textu.



Rozšíření MIME