Elektronická pošta v TCP/IP časť štvrtá


MIME (Multipurpose Internet Mail Extensions)

Elektronickou poštou okrem bežných textových správ môžeme posielať aj ľubovoľné binárne súbory. Systémové riešenie, pomocou ktorého sa toto dosiahlo sa nazýva MIME (Multipurpose Internet Mail Extensions) a je definované v normách RFC 1521 a RFC 1522.

Hlavičkové pole MIME-Version
Toto je jediné pole MIME, ktoré nezačína reťazcom "Content-". Položka špecifikuje verziu MIME. Dôvodom zavedenia tohoto kľúčového slova je zabezpečenie kompatibility, t.j. podľa prítomnosti tejto položky v správe klient rozpozná, že ide o správu rozšírenú podľa MIME a verziu MIME, podľa ktorého bola správa rozšírená. V súčasnosti sa používa MIME verzia 1.0. V budúcnosti môžu prísť ďalšie verzie MIME, s inými typmi hlavičkových polí. Správa zostavená podľa RFC 2045 až RFC 2049 musí toto hlavičkové pole obsahovať vždy. Toto pole musí byť uvedené pred ostatnými hlavičkovými poliami MIME.

Hlavičkové pole Content-Type
Pole popisuje typ dát obsiahnutých v tele správy tak, aby klient, ktorý túto správu obdrží, mohol zvoliť vhodný spôsob prezentácie obsahu správy. Hlavičkové pole špecifikuje charakter obsahu správy pomocou typu a podtypu, prípadne pomocou doplnkových informácií. Doplnkové informácie sú uvedené za bodkočiarkou ako parametre v tvare parameter=hodnota. Parametrov môže byť za sebou uvedených aj viacej, ale vždy musia byť oddelené bodkočiarkou. Na poradí týchto parametrov nezáleží. Content-Type: typ/podtyp; parameter1=hodnota; parameter2=hodnota ... Typ kľúčové slovo, ktoré určuje o aký typ dát ide a podtyp je bližšia špecifikácia obsahu správy. Napríklad hlavičkové pole Content-Type: image/jpeg informuje príjemcu správy o tom, že obsahom správy je obrázok vo formáte jpeg. RFC 2045 až RFC 2049 obsahuje niekoľko základných typov. Ďalšie typy môžu byť podľa RFC 2048 registrované odoslaním príslušného dokumentu na adresu: ietf-types@iana.org.

Typy sa rozdeľujú na dve skupiny:

Hlavičkové pole Content-Transfer-Encoding

Často sa stáva, že elektronickou poštou posielame aj binárne súbory (napr. súbory s koncovkou *.zip, *.jpeg, *.gif a pod.). Tieto súbory nie je obvykle možné poslať priamo. Z toho dôvodu musí byť použitý algoritmus, ktorý zakóduje binárne dáta do krátkych riadkov 7-bitového ASCII kódu. RFC 1521 obsahuje tieto algoritmy kódovania:

7-bit
Ide o implicitnú metódu kódovania, ktorá sa predpokladá, pokiaľ nie je hlavičkové pole Content-Transfer-Encoding uvedené. Dáta takto spracované nie sú vôbec kódované, sú iba rozdelené do krátkych riadkov, ktoré obsahujú len znaky us-ascii, t.j. znaky zo základného rozsahu 32 až 126.

8-bit
Dáta transformované týmto algoritmom nie sú opäť kódované, sú iba rozdelené do krátkych riadkov. Môžu sa tu vyskytnúť aj znaky mimo základný rozsah 32 až 126.

binary
Okrem možného výskytu znakov mimo rozsahu 32 až 126 nie je zaručená ani dĺžka riadkov. Tento algoritmus nepredstavuje žiadne kódovanie.

quoted-printable
Tento typ kódovania je vhodný pre dáta, ktoré z väčšej časti obsahujú ASCII znaky zo základného rozsahu (32 až 126), no len malý počet z nich treba kódovať. Výsledkom kódovania je teda ASCII text, ktorý je aj bez dekódovania relatívne čitateľný. Kódovaný môže byť aj text, ktorý obsahuje len ASCII znaky. Robí sa to z dôvodu zabezpečenia integrity dát (napr. ak dáta prechádzajú cez bránu (gateway), ktorá vykonáva náhradu znakov alebo zarovnávanie riadkov).
Pravidlá kódovania:
  • Ľubovolný znak (okrem znaku konca riadku) je nahradený znakom '=', za ktorým nasleduje hexadecimálna hodnota znaku.

  • Znaky s desiatkovou hodnotou od 33 do 60 a od 62 do 126 vrátane sú nahradené ASCII znakmi (od '!' do '<' a od '>' do '~').

  • Znaky s hodnotou 9 a 32 sú nahradené znakmi TAB a SPACE. Tieto znaky sa nesmú vyskytnúť na konci riadku.

  • Koniec riadku je vyjadrený znakom CRLF.

  • Zakódovaný riadok môže mať maximálne 76 znakov. Pokiaľ je riadok dlhší, vloží sa na jeho koniec znak '='.
base64
Tento algoritmus (obr. 1) je pravdepodobne najvhodnejším pre kódovanie binárnych súborov. Kódované dáta sú iba o tretinu dlhšie než dáta pôvodné. Kódovací algoritmus je jednoduchý. Používa tabuľku base64, ktorá obsahuje 64 znakov a znak "=". Znak "=" sa používa pre špeciálne účely. Na začiatku kódovania sa binárne dáta rozdelia na skupiny po troch bajtoch a 24 bitov každej trojice sa prerozdelí na štyri bloky po 6 bitov. Každých 6 bitov je potom nahradených zodpovedajúcim znakom z tabuľky base64 (tab. 1). Takto zakódovaný binárny súbor sa musí usporiadať do riadkov, ktorých maximálna dĺžka je 76 znakov. Pokiaľ nie je dĺžka pôvodného súboru deliteľná tromi, zostane nám na konci kódovania menej než 24 bitov, teda 8 alebo 16. V prvom prípade sa počet bitov doplní sprava nulami na 12, teda dva bloky, ktoré sa zakódujú pomocou dvoch znakov. Za týmito znakmi sa ešte vloží dvakrát znak "=". V druhom prípade sa počet bitov doplní sprava nulami na 18, z toho dostaneme tri znaky, ktoré sa ešte doplnia znakom "=". Dĺžka výsledného kódovaného binárneho súboru je vždy deliteľná štyrmi.



Obr. 1: Princíp kódovania binárnych súborov algoritmom base64


radix-64
Ide o rozšírenie kódovania base64 o kontrolný súčet. Data v správe sú kódované algoritmom base64, za nimi však nasleduje nový riadok (CRLF), znak "=" a 24 bitov dlhý kontrolný súčet z pôvodných, nekódovaných dát. Tento súčet je vypočítaný algoritmom CRC-24 a je zakódovaný do formátu base64. Zdrojový kód algoritmu CRC-24 ako i popis kódovania radix-64 nájdete v dokumente RFC 2440.

Príklad:
  -----BEGIN PGP MESSAGE-----
  Version: OpenPrivacy 0.99

  yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS
  vBSFjNSiVHsuAA==
  =njUN
  -----END PGP MESSAGE-----
V prípade, že váš softvér nepodporuje kódovanie radix-64, stačí ak odstránite posledný riadok kódovanej správy a na dekódovanie použijete softvér, ktorý podporuje algoritmus base64.

x- anything
Štandard RFC 1521 [13] umožňuje použiť aj ďalšie typy kódovania. Ich označenie v hlavičkovom poli Content-Transfer-Encoding musí začínať prefixom x-. Tieto nové typy kódovania môžu byť použité pre experimenty. Ak byť majú používané v praxi, musia byť podľa RFC 2048 registrované odoslaním príslušného dokumentu na adresu: ietf-types@iana.org. Registrované algoritmy sú uverejnené na adrese: http://www.iana.org/assignments/transfer-encodings.
Value Encoding Value Encoding Value Encoding Value Encoding Value Encoding Value Encoding
0 A 12 M 24 Y 36 k 48 w 60 8
1 B 13 N 25 Z 37 l 49 x 61 9
2 C 14 O 26 a 38 m 50 y 62 +
3 D 15 P 27 b 39 n 51 z 63 /
4 E 16 Q 28 c 40 o 52 0 (pad) =
5 F 17 R 29 d 41 p 53 1
6 G 18 S 30 e 42 q 54 2
7 H 19 T 31 f 43 r 55 3
8 I 20 U 32 g 44 s 56 4
9 J 21 V 33 h 45 t 57 5
10 K 22 W 34 i 46 u 58 6
11 L 23 X 35 j 47 v 59 7

Tab. 1: Abeceda base64


Hlavičkové pole Content-ID

Hodnota tohto poľa môže byť použitá pre jednoznačnú identifikáciu správy. Hlavičkové pole je voliteľné; jeho použitie je ale povinné v implementácii, ktorá generuje dáta typu message/external-body.


Hlavičkové pole Content-Description

Hlavičkové pole obsahuje informácie o prenášanej správe. Príkladom môže byť názov obrázku, ktorý sa nachádza v tele správy.


Ďalšie hlavičkové polia

Aj keď RFC 2045 až RFC 2049 neuvádzajú žiadne ďalšie hlavičkové polia Content-, stačí odoslať napríklad programom Netscape mail a zistíte, že v praxi sa používajú napr. hlavičkové polia Content-Length a Content-Disposition. Prvé pole udáva veľkosť tela správy v bajtoch, druhé pole obsahuje obvykle názov súboru, napr.: Content-Disposition: inline; filename="dixie.mid".

Type Subtype Reference
text plain [RFC 1521, Borenstein]
  richtext [RFC 1521, Borenstein]
  enriched [RFC 1896]
  tab–separated–values [Paul Lindner]
  html [RFC 1866]
  sgml [RFC 1874]
multipart mixed [RFC 1521, Borenstein]
  alternative [RFC 1521, Borenstein]
  digest [RFC 1521, Borenstein]
  parallel [RFC 1521, Borenstein]
  voice–message [RFC 1911]
message rfc822 [RFC 1521, Borenstein]
  partial [RFC 1521, Borenstein]
  external–body [RFC 1521, Borenstein]
  news [RFC 1036, Henry Spencer]
application octet–stream [RFC 1521, Borenstein]
  postscript [RFC 1521, Borenstein]
  activemessage [Ehud Shapiro]
  rtf [Paul Lindner]
  applefile [MacMime, Patrick Faltstrom]
  mac–binhex40 [MacMime, Patrick Faltstrom]
  news–message–id [RFC 1036, Henry Spencer]
  news–transmission [RFC 1036, Henry Spencer]
  wordperfect5.1 [Paul Lindner]
  pdf [Paul Lindner]
  zip [Paul Lindner]
  macwriteii [Paul Lindner]
  msword [Paul Lindner]
image jpeg [RFC 1521, Borenstein]
  gif [RFC 1521, Borenstein]
  tiff [Tag Image File Format, Rose]
audio basic [RFC 1521, Borenstein]
  32kadpcm [RFC 1911]
video mpeg [RFC 1521, Borenstein]
  quicktime [Paul Lindner]

Tab. 2 Registrované MIME typy


Tabuľka obsahuje len výber registrovaných MIME (Multipurpose Internet Mail Extensions) typov. Aktuálny listing, prípadne detailnejšie informácie hľadajte na serveri: http://www.isi.edu/in-notes/iana/assignments/media-types/media-types resp. na FTP ftp://ftp.isi.edu/in-notes/iana/assignments/media-types.


Vysvetlivky

RFC (Request for Comments) - Sada článkov, v ktorých sa dokumentujú a zverejňujú štandardy Internetu, návrhy štandardov a obecne odsúhlasené myšlienky.

DNS (Domain Name System) - Systém doménových mien. Distribuovaný hierarchický informačný systém využívaný v IP sieťach, umožňujúci preklad symbolických doménových mien (napr.: www.zoznam.sk) na číselné IP adresy (napr.: 195.85.36.45).

(c) 2004 Ing. Peter Gašparovič - www.pgasparovic.com

Literatúra

[1]  Feiber, W.: Encyklopedie počítačových sítí. Praha, Computer Press, 1996.
[2]  Břehovský, P.: Praktický úvod TCP/IP. České Budějovice, KOPP, 1994 .
[3]  Mrázek, L.: První kroky INTERNETEM aneb Je to na WWW!. České Budějovice, KOPP, 1995.
[4]  Šmrha, P. – Rudolf, V.: Internetworking pomocí TCP/IP. České Budějovice, KOPP, 1995.
[5]  Hejna, L.: Lokální počítačové síte. Praha, GRADA, 1994.
[6]  Falk, B.: Průvodce světem Internetu. Praha, Computer Press, 1995.
[7]  Lhotka, L.: SERVER v INTERNETU. České Budějovice, KOPP, 1997.
[8]  Peterka, J.: Co je čím ... v počítačových sítích. COMPUTERWORLD, 1994, č. 4, 7, 9, 17, 21, 35, 44.
[9]  Sterling, B.: Short History of the Internet. The Magazine of Fantasy and Science Fiction, 1993.
[10]  Dostálek, L. - Kabelová, A.: MIME – Multipurpose Internet Mail Extension. http://info.pvt.net/mime.htm, 1997.
[11]  Postel, J. B.: Simple Mail Transfer Protokol. RFC # 821, August 1982.
[12]  Crocker, D. H.: Standard For The Format Of Arpa Internet Text Messages. RFC # 822, August 1982.
[13]  Borenstein, N. - Freed, N.: MIME (Multipurpose Internet Mail Extension) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. RFC # 1521, September 1993.
[14]  Borenstein, N. - Freed, N.: Multipurpose Internet Mail Extension (MIME) Part One: Format of Internet Message Bodies. RFC # 2045, November 1996.
[15]  Rose, M.: Post Office Protocol – Version 3. RFC # 1225, May 1991.
[16]  Rose, M. - Myers, J.: Post Office Protocol – Version 3. RFC # 1725, November 1994.
[17]  Dresslerová, B. - Veselský, J. - Gombik, G.: LINUX Dokumentační projekt. Praha, Computer Press, 1998.
[18]  Šovčík, J.: Login. PC Revue, 1995, č. 4 až 8.
[19]  Palúch, P.: Poznáte LINUX?. PC Revue, 1998, č. 2.
[20]  Rivest, R.: The MD5 Message–Digest Algorithm. RFC # 1321, Apríl 1992.
[21]  Dostálek, L. a kol.: Velký průvodce protokoly TCP-IP Bezpečnost. Praha, Computer Press, 2001.