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.
:: textTento typ je určený pre posielanie textových informácií. Text je kódovaný v niektorej z podporovaných znakových sád; znakovú sadu určuje parameter charset. Jednotlivé znakové sady sú uverejnené na: http://www.iana.org/assignments/character-sets. Primárny podtyp je plain a označuje neformátovaný text.
:: applicationBinárne dáta pochádzajúce z rôznych aplikačných programov (databáz, textových procesorov, tabuľkových kalkulátorov, kompresných programov a pod.). Primárnym typom je neutrálny octet-stream, ďalšou možnosťou je napríklad postscript.
:: imageDáta reprezentujúce (statický) obrázok. RFC 1521 definuje dva základné podtypy - gif a jpeg. Ďalšie typy sú uverejnené na: http://www.isi.edu/in-notes/iana/assignments/media-types/media-types.
:: audioTelo správy obsahuje zvuk. Primárnym podtypom je basic (mono so vzorkovacím kmitočtom 8 kHz).
:: videoObsahom tela správy je video, primárny podtyp je mpeg.
:: modelModelom sa rozumie reprezentácia troch a viac dimenzionálnych systémov, v ktorých je možné zaviesť pravouhlú súradnicovú sústavu. Model sa skladá z jedného alebo viacerých objektov, medzi ktorými je definovaný vzťah typu master/slave. Objekt sa skladá z elementov, ktoré majú medzi sebou definované vzťahy. Model môže zahŕňať faktory ako je sila, rýchlosť, zrýchlenie, hybnosť, čas atď. Primárnym podtypom je iges, ďalšou možnosťou je napr.: vrml. Popisom tohoto typ sa podrobnejšie zaoberá dokument RFC 2077.
:: messageTento typ umožňuje odoslať e-mailovú správu ako telo inej správy (rfc822), dlhú správu odoslať ako niekoľko kratších (partial) alebo namiesto tela správy odoslať informácie, že správa sa nachádza na danom serveri (external-body).
Definované podtypy sú::: multipart
- Message/rfc822 špecifikuje, že telo obsahuje vnorenú správu, ktorá má syntax podľa RFC 822. Často je potrebné poslať e-mailovú správu ako telo inej správy. Práve pre tento účel je definovaný typ message. Na rozdiel od RFC 822 nie je potrebné, aby každé telo správy typu message/rfc822 obsahovalo hlavičkové polia From, To a Subject.
- Message/Partial je definovaný preto, aby bolo možné posielať dlhé správy ako niekoľko kratších a príjemcov software ich mohol automaticky zobraziť ako jednu správu.
- Message/External-Body špecifikuje informácie o správe, ktorá je uložená na určitom serveri. Parameter acces-type obsahuje typ servera (protokolu). Najčastejšie typy serverov sú: ftp, anon-ftp (anonymný FTP server), mail-server a local-file (súbor na lokálnom počítači). Ďalšie typy je možné nájsť na adrese: ftp://ftp.isi.edu/in-notes/iana/assignments/access-types. Parameter name - určuje meno súboru, parameter site - meno počítača, parameter directory - adresár, v ktorom sa nachádza daný súbor a parameter expiration - špecifikuje čas, dokedy bude súbor aktuálny.
Telo správy tohto typu obsahuje niekoľko rôznych častí. Každá časť tela správy začína reťazcom, ktorý je definovaný v parametre boundary (v hlavičkovom poli Content-Type). Potom nasledujú hlavičkové polia tejto časti, prázdny riadok a vlastné telo správy. Posledná časť je zakončená koncovým reťazcom (napríklad: ------------D32C428032D08B1A1736CED2).
Reťazec definovaný v parametre boundary je špeciálna množina znakov, ktorá sa nesmie vyskytnúť vo vnútri žiadnej časti správy. Maximálna dĺžka tohto reťazca je 70 znakov.
Jednotlivé čiastkové správy nie sú interpretované podľa RFC 822. Môžu, ale nemusia obsahovať hlavičkové polia (prázdny riadok za záhlavím však musí byť uvedený vždy). Pokiaľ nie sú hlavičkové polia u čiastkových správ uvedené, uplatňujú sa implicitné hlavičkové polia zo záhlavia celej správy.
Definované podtypy sú:Subtypy Multipart/Signed a Multipart/Encrypted predstavujú cestu k použitiu tzv. bezpečného e-mailu a sú definovné v dokumente RFC 1847. V súčasnosti existujú štyri nezávislé štandardy pre bezpečný e-mail:
- Multipart/Mixed je primárnym podtypom. Je určený pre správy, ktoré obsahujú nezávislé časti, ktoré je potrebné zviazať v danom konkrétnom poradí. Klasickým prípadom podtypu Multipart/Mixed je správa elektronickej pošty obsahujúca jednu alebo viacej príloh.
- Multipart/Alternative - správa tohto typu obsahuje niekoľko častí, pričom všetky časti obsahujú rovnaké informácie, ale majú odlišný formát. Tá istá správa môže byť raz napísaná v US-ASCII, potom v ISO-8859-2 a nakoniec napríklad nahovorená, t.j. audio. Príjemcov software musí rozpoznať, ktoré formy je schopný zobraziť a vybrať z nich tú najlepšiu. Software vytvárajúci takúto správu musí usporiadať jednotlivé časti podľa vzrastajúcej kvality.
- Multipart/Digest umožňuje, aby jedna alebo viacej správ boli tvorené postupnosťou správ. V praxi sa môžeme stretnúť s prípadom, že správa je tvorená pomocou multipart/mixed dvomi čiastkovými správami. Prvá čiastková správa tvorí obsah a druhá pomocou multipart/digest sa skladá z jednotlivých kapitol.
- Multipart/Parallel pri tomto podtype nezáleží na poradí častí správy. Poštový software všetky tieto časti prezentuje užívateľovi súčasne.
- Multipart/Signed špecifikuje správu, ktorá sa skladá z dvoch častí:
- zo správy,
- z elektronického podpisu tejto správy.
- Multipart/Encrypted špecifikuje šifrovanú správu, ktorá sa skladá z dvoch častí:
- z informácií o použitom spôsobe šifrovania,
- zo šifrovanej správy.
- PGP (RFC 1991),
- PEM (RFC 1421 až 1424),
- MOSS (RFC 1848),
- S/MIME (Secure/MIME).
Č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:base64
- Ľ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 '='.
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 |
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 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.
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] | |
[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] |
(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.