MIME - Multipurpose Internet Mail Extension

Proč MIME vzniklo?

Formát textových zpráv přenášených v Internetu byl definován dvojicí RFC821/RFC822. Brzy se však ukázalo, že tento standard nevyhovuje požadavkům uživatelů. Lépe řečeno požadavky uživalelů překračují možnosti nabízené těmito normami. Mail se 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ů. Nepříjemná byla i skutečnost, že nebylo možné poslat text s diakritikou v našem případě text skutečně český a ne pouze cesky.

Z tohoto pohledu měla původní norma pro formát mailových zpráv dvě zásadní omezení:

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 na Unixu je dvojice programů uuencode/uudecode.

Rozšíření MIME

Řešením vzniklé situace je RFC1521 označované jako MIME (Multipurpose Internet Mail Extension). Zavedení MIME se snaží řešit omezení původního standardu. MIME je standardem, který doplňuje RFC822 a zajišťuje zpětnou kompatibilitu. Je navrženo tak, aby dopisy mohly být posílány stávajícím poštovním systémem.

Tento nový standard řeší dvě otázky:

  1. Jak vytvořit ze složitého dopisu obsahujícího např. binární data zprávu vyhovující RFC822 a tedy přepravatitelnou používanými přenosovými protokoly. Tj. zavádí standard pro kódování.
  2. Jak rozlišit jednotlivé druhy zpráv, tj. zavádí klasifikaci přenášených informací. Klasifikace přenášených infromací 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. Příkladem služby, která takto MIME využívá je WWW tj. protokol http. MIME zavádí další hlavičkové řádky do mailové zprávy, které specifikují typ posílaných dat a způsob jejich kódování.

    MIME zavádí další 4 hlavičky:

    Hlavička Mime-Version

    Důvodem zavedení této hlavičky je zajištění kompatibility. Tj. podle přítomnosti této hlavičky v mailu klient rozpozná, že jde o zprávu sestavenou podle RFC1521. Zpráva sestavená podle RFC1521 musí tuto hlavičku vždy obsahovat. Hlavička obsahuje verzi MIME rozšíření (pro RFC1521 jde o verzi 1.0). Tedy konkrétní tvar hlavičky vypadá takto:

    Mime-Version: 1.0

    Hlavička musí být uvedena na začátku zprávy.

    Všechny hlavičky mailu mohou obsahovat komentář, tj. hlavičky:

    Mime-Version: 1.0
    Mime-Version: 1.0 (Generated by GBD-killer 3.7)

    jsou totožné.

    Charakter dat - hlavička Content-Type

    Hlavička popisuje data obsažená v těle zprávy tak, aby klient, který tuto zprávu obdrží mohl zvolit vhodný způsob prezentace obsahu zprávy.

    Hlavička specifikuje charakter obsahu zprávy pomocí typu a podtypu a případně pomocí doplňkových informací. Doplňkové informace jsou uvedeny jako parametry ve tvaru parametr=hodnota. Parametrů může být uvedeno i více 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 nebo např obecný binární soubor.

    Podtyp pak specifikuje konkrétní formát obrázku, textu a pod.

    Např. hlavička

    Content-Type: image/xyz

    informuje klienta o tom, že obsahem zprávy je obrázek, aniž by klient musel znát konkrétní formát obrázku xyz.

    RFC1521 definuje 7 základních typů:

    Další typy je možné definovat rozšířením standardu. Lze použít experimentální tyty, ty je však potřeba odlišit od standardních typů prefixem x- před jménem typu např. x-world/x-wrml.

    Obecný tvar hlavičky:

    Content-Type: typ/podtyp parametr1=hodnota;parametr2=hodnota.

    Jména typů, podtypů a parametry jsou case-insenzitive, tj. nezávislé na tom, zda je píšeme velkými nebo malými písmeny.

    Kódování obsahu - hlavička Content-Transfer-Encoding

    Většina shora uvedených typů dat, které chceme posílat mailem jsou 8 bitová nebo binární data. Tato data není možné poslat přímo. Proto je potřeba definovat mechanismus převodu - kódování skutečných dat do 7-bitového tvaru s krátkými řádky. Použitý typ kódování je uveden v této hlavičce.

    Pro různá data je nevýhodné definovat univerzální typ kódování. Proto se definuje několik typů kódování.

    7bit znamená, že jde o 7 bitovou zprávu vhodnou pro mail, žádné kódování ve skutečnosti tedy neproběhne. Jde o implicitní metodu kódování, která se předpokládá, pokud není toto pole v hlavičce uvedeno.

    Hodnoty 8bit, 7bit a binary vlastně nepředstavují žádné kódování, žádné kódování dat se ve skutečnosti neprovádí. Tyto hodnoty jsou potencionálně užitečné jako indikace typu dat v objektu.

    Hlavička 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.

    Musíme připomenou, že e-mail je znakově orientovaný, tj. mechanismus kódování se uplatní na osmice bitů nikoli na jednotlivé bity. Proto musí být posloupnost bitů před kódováním nejprve rozdělena na osmice - byty.

    Kódovací mechanismus kóduje všechna data do ASCII znaků. Výsledkem kódování je tedy ASCII řetězec.

    Hlavičky:

    Content-Type: text/plain; charset=ISO-8859-1
    Content-Transfer-Encoding: base64

    pak interpretujeme jako: tělo zprávy je řetězec ascii znaků vzniklých kódování base64. Původní data byla ve znakové sadě ISO-8859-1 a musí být do této sady opět převedena.

    Experimentální kódování musí být odlišeno od standardu prefixem x-. Je ho možné použít pro experimenty nebo v případě že klien i server jsou na tomto kódování dohodnuti.

    Standardní kódovací mechanismy

    1. Quoted-printable

    Toto kódování je určeno pro data, která z větší části obsahují tisknutelné ascii znaky. Výsledkem kódování je ascii text, který je i bez dekódování z velké části pro člověka čitelný.

    Kódován může být i text , který obsahuje pouze ascii znaky a to např. z důvodu zajištění integrity dat, pokud data prochází přes gateway, která provádí náhradu znaků a/nebo zarovnání řádky.

    Pravidla kódování

    1. Libovolná osmice bitů (kromě znaků konce řádky) je nahrazena znakem "=" následovaných hexadimální hodnotou osmice bitů.
    2. Osmice s hexadecimální hodnotou od 33 do 60 a od 62 do 126 včetně jsou nahrazeny acsii znaky ( od ! do < a od > do ~).
    3. Osmice s hodnotou 9 a 32 jsou nahrazeny TAB a SPACE znaky. Nesmí být na konci řádku.
    4. Konec řádky je vyjádřen CRLF.
    5. 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 = na konec řádky.

    2. Base64

    Je určeno pro obecná binární 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á 65 US-ascii znaků, u nichž 6 bitů představuje tisknutelný znak. Znak "=" (ž65) se používá ke speciálnímu účelu. Na začátku kódování se kódovaný text rozdělí na sekvence 24 bitů a ty následně 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í znakem z tabulky znaků abecedy base64.

    Tabulka abecedy base64:

       Value Encoding  Value Encoding  Value Encoding  Value Encoding
           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         (pad) =
          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 max 76 znaků dlouhých.

    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.

    Zbyde-li na konci textu po rozdělení méně než 24 bitů, doplní se nulové bity zprava. Přidáním na konec je indikováno znakem "=".

    Dodatečné hlavičky

    Content-ID

    V klientech vyšší úrovně může být požadováno vytvořit odkaz z jedné zprávy do druhé. Tělo zprávy je možné proto označit identifikátorem v hlavičče Content-ID. Hodnota hlavičky může být použita pro jednoznačnou identifikaci MIME těla. Hlavička je volitelná, její použití je ale povinné v implementaci, která generuje data typu message/external-body.

    Content-Description

    Hlavička obsahuje popisující informace k tělu, např. název obrázku, který jako tělo je posílán.

    Příklad:
    Content-Description: "obrazek Prazskeho hradu".

    Popis musí být v us-ascii.

    Předdefinované hodnoty Content-Type

    RFC1521 definuje 7 základních typů a mechanismus jejich rozšiřování. 7 základních typů bylo navrženo tak, aby pokud možno nebylo nutné přidávat další. Nicméně nové typy je možno definovat rozšířením standardu, jejich vznik se však spíše neočekává. Předpokládá se vznik nových podtypů.

    Text

    Tento typ je určen pro posílání textových informací. Jde o implicitní hodnotu. U typu je možné použít parametr CHARSET, který indikuje použitou znakovou sadu. Primární subtyp je plain, který označuje neformátovaný text. Podtypy se používají pro obohacené texty, texty s vylepšeným vzhledem. Příkladem je např. podtyp html, kdy text obsahuje příkazy jazyka HTML. Vlastností těchto textů je, že jsou čitelné i bez použití speciálního softwaru. To je odlišuje od nečitelných dat jako je obrázek nebo např. text v nečitelné formě.

    V souladu s definovanými typy a podtypy tedy zpráva podle RFC822 může být uvozena hlavičkou:

    Content-Type: text/plain; charset=us-ascii

    Tento tvar hlavičky je implicitní. RFC1521 definuje pouze podtyp text/plain.

    Parametr CHARSET

    Parametr CHARSET indikuje použitou znakovou sadu. Implicitní hodnota je US-ascii. Není case-senzitive.

    RFC1521 definuje charset pro účely MIME jako jednoznačné mapování řetězce bytů na znaky, které již nepotřebuje žádné dodatečné informace.

    RFC1521 uvádí seznam předdefinovaných znakových sad. Další znakové sady mohou být registrovány prostřednictvím IANA.

    Pokud znaková sada obsahuje 8-bitové znaky, pak při přenosu mailem - protokolem SMTP je použita hlavička Content-Transfer-Encoding a odpovídající kódování.

    Multipart

    Tělo zprávy tohoto typu obsahuje několik různých částí. Každá část těla začíná úvodním oddělovačem, pak následují hlavičky této části, prázdný řádek a vlastní část. Poslední část je ukončena koncovým oddělovačem.

    Jednotlivé části nejsou interpretovány podle RFC822. Mohou ale také nemusí obsahovat hlavičky. Pokud nejsou hlavičky u části uvedeny, uplatní se implicitní hlavičky.

    Pro tento typ jsou použitelné pouze tři metody kódování: 7bit, 8bit, binary.

    Oddělovač je speciální sekvence znaků, která se nesmí vyskytnou nikde uvnitř částí. Oddělovač se definuje v parametru hlavičky.

    Parametr má tvar boundary=řetězec. Oddělovač je pak řádka, která začína dvěma pomlčkami "--", pak následuje řetězec z parametru. Maximální délka oddělovače je 70 znaků.

    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í, každá část má strukturu podle RFC822, 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šte dvěma pomlčkami.

    Příklad mailu o dvou částech: 

          From: Nathaniel Borenstein 
      To:  Ned Freed 
      Subject: Sample message
      MIME-Version: 1.0
      Content-type: multipart/mixed; boundary="simple boundary"

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

      Toto je implicitně plain ascii text.
      Text nekončí konecem řádky.
      --simple boundary
      Content-type: text/plain; charset=us-ascii

      Toto je explicitně plain ascii text.
      Text je ukončen koncem řádky.

      --simple boundary--
      Toto je závěr, je také ignorován.
    Podtypy:

    Message

    Často je třeba poslat mailovou zprávu jako tělo jiné mailové zprávy. Pro tento účel je definován typ message. Povolené je pouze kódování 7bit, 8bit a binary.

    Definované podtypy:

    Application

    Tento typ je určen pro data, která nepatří do žádné jiné kategorie. Jde o informace, které je potřeba zpracovat nějakou aplikací, aby byly čitelné pro uživatele. Jsou definovány dva 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 nedozví.

    Podtypy:

    Image

    Obsahem těla je obrázek. K jeho prezentaci je potřeba odpovídající prohlížeč. Subtypy jsou definovány pro nejznámější používané formáty jpeg a gif.

    Audio

    Tělo zprávy obsahuje zvuk, definovaný podtyp je basic.

    Video

    Obsahem těla zprávy je video, primární typ je mpeg.