![](../gifs/logoprint.png)
Elektronická pošta á la TCP/IP - část II.
Koncepce elektronické pošty, používané v Internetu (tzv. SMTP pošty) je ilustrativním příkladem celkového přístupu světa TCP/IP k vytváření nových aplikačních služeb: vyvíjí se postupně, od jednoduššího ale spolehlivě fungujícího řešení, cestou dalšího zdokonalování. V této části si podrobněji popíšeme podstatu a význam takovýchto rozšíření.
V první části tohoto dvoudílného miniseriálu jsme se seznámili s původní koncepcí tzv. SMTP pošty, tak jak byla vyvinuta na samém počátku - šlo o jednoduchou službu pro přenos krátkých, čistě textových zpráv (tvořených tzv. čistými ASCII znaky, které je možné znázornit v sedmi bitech). Takto koncipovaná služba například nepočítala s žádným významnějším formátováním textu zpráv, nedovolovala přikládat ke zprávám různé přílohy apod.
Proč je nutný MIME?
I přes svou jednoduchost a skromnost nabízených možností se elektronická pošta na bázi protokolu SMTP, nasazená v prostředí celosvětového Internetu, stala velmi populární a hojně používanou službou. S její oblibou však zákonitě rostly i požadavky, které uživatelé začali na tuto službu klást - když náležitě docenili její podstatu, chtěli ji začít používat jako univerzální přenosový mechanismus. V tom smyslu, že chtěli svěřit elektronické poště k přenosu a doručení v zásadě cokoli, co lze "zabalit" do podoby souboru (tedy například různé datové soubory, programy, statické obrázky, formátované texty apod.). Původní koncepce SMTP pošty však s něčím takovým nepočítala.
Problémy, které bylo nutné překonat, byly tři:
- Jak zajistit, aby jiná než čistě textová data správně "prošla" skrz přenosové kanály, které garantují pouze přenos sedmibitových ASCII znaků (viz minule)?
- Jak definovat povahu přenášených netextových dat, tak aby příjemce správně poznal co jsou tato data zač?
- Jak zakomponovat netextová data do čistě textové zprávy, tak aby příjemce vždy správně poznal, co je co, a jak má s čím naložit?
Technické řešení všech tří právě naznačených problémů není nijak těžké - možná řešení lze téměř "sypat z rukávu". Právě v tom byl ale kámen úrazu: jelikož existuje mnoho různých řešení těchto problémů, které z nich mělo být vybráno? Skutečný problém tedy byl spíše organizační: jak přimět všechny zainteresované strany, aby se sjednotily na jednom konkrétním řešení? Právě toto trvalo nejdéle, ale nakonec vyústilo v přijetí standardu jménem MIME (Multipurpose Internet Mail Extensions), který řeší všechny tři výše naznačené okruhy problémů.
Co MIME umožňuje?
V tomto článku bohužel nemáme prostor si podrobněji popsat, jak přesně MIME funguje - tj. jakým konkrétním způsobem jsou netextová data konvertována do čistě textového tvaru (do tvaru čistého ASCII textu), tak aby mohla být spolehlivě přenesena přenosovými kanály elektronické pošty, ani jak konkrétně jsou příslušné informace (o způsobu konverze, o povaze dat apod.) začleněny do výsledné zprávy. Neptejme se tedy JAK konkrétně je to uděláno, ale zastavme se spíše u toho, co všechno je díky standardu MIME možné dosáhnout. Ještě si ale zdůrazněme, že samotný standard MIME je nadstavbou nad původní koncepcí SMTP pošty - v tom smyslu, že tento "základ" nijak nemění, a pouze jej doplňuje. V praxi to znamená, že konkrétní podpora standardu MIME je záležitostí poštovních klientů, a netýká se samotných přenosových mechanismů elektronické pošty (nadále fungujících na bázi protokolu SMTP, který není standardem MIME nijak dotčen). Důvodem je skutečnost, že zpráva, vytvořená podle standardu MIME, se vůči přenosovým mechanismům elektronické pošty "tváří" přesně stejně, jako běžná zpráva, která se standardem SMTP nemá nic společného (a proto přenosové mechanismy nemusí být nijak upravovány).
Standard MIME tedy umožňuje například to, aby k textovému tělu zprávy bylo možné přiložit jednu nebo několik příloh - v zásadě cokoli, co má formu souboru. Standard MIME zde říká nejen to, jak má být obsah souboru konvertován pro potřeby přenosu, ale pamatuje mj. i na to, jak vyjádřit, co je tento soubor zač (jakého je typu). To je důležité k tomu, aby příjemce po "vybalení" přílohy věděl, jak ji dále zpracovat - například že ji má "předhodit" k dalšímu zpracování editoru MS Word, nebo jiné aplikaci. Díky tomu je pak možné, aby si uživatel-příjemce ve svém klientském poštovním programu pouze kliknul na ikonku reprezentující konkrétní přílohu zprávy, a jeho poštovní program již dokázal sám rozhodnout, kterou aplikaci má zavolat ke zpracování této přílohy (např. k jejímu zobrazení). Příslušný údaj, který standard MIME pro potřeby identifikace povahy obsahu zavádí, je tzv. MIME typ. Ten se pak používá i jinde než v rámci elektronické pošty (například při komunikaci mezi WWW serverem a jeho klientem se MIME typ používá k vyjádření toho, zda je právě přenášena WWW stránka, obrázek, čistý text apod.).
Standard MIME však pokrývá ještě jednu důležitou oblast, a tou je samotný obsah poštovní zprávy (přesněji: jejího těla). I zde dovoluje použití jiných než čistě textových dat (sedmibitových ASCII znaků). V našich zeměpisných končinách je například podstatné to, že díky standardu MIME můžeme psát své zprávy včetně háčků a čárek (a to dokonce včetně komentářových částí adres v hlavičce zprávy, a v jejím předmětu). Pozor ale na to, že k jejich korektnímu zobrazení musí mít obě strany nainstalovány takové klientské poštovní programy, které standard MIME podporují - pokud ne, zpráva jim sice korektně přijde, ale její obsah může být plný kryptických znaků, které na první pohled nedávají smysl!
Schopnost standardu MIME přenášet přímo v těle zprávy i jiné než čisté ASCII texty je dnes hojně využívána. Tuto schopnost totiž lze využít například pro obohacení formátu zprávy, a dokonce i pro přenos WWW stránek pomocí elektronické pošty (viz obrázek). Díky standardu MIME totiž může text poštovní zprávy tvořit třeba i stránka v jazyku HTML, tedy vlastně přesně to, co nabízí služba WWW a její jednotlivé servery - včetně obrázků, různých druhů písma, formátování, aktivních odkazů apod. V praxi se pak mohou díky této možnosti distribuovat elektronickou poštou například různé elektronické časopisy (tzv. e-ziny), psané v HTML formátu (viz obrázek).
![]() |
K čemu je MAPI, a co jsou mail-aware aplikace?
Dalším krokem na cestě k postupnému zdokonalování SMTP pošty byla možnost jejího provázání s jinými aplikacemi, které uživatelé používají - například s textovými editory, spreadsheety apod. Důvodem byla snaha využít přenosové schopnosti elektronické pošty i pro přenos datových objektů, se kterými tyto aplikace pracují. Například k tomu, aby uživatel textového editoru mohl odeslat právě zpracovávaný dokument elektronickou poštou jinému uživateli (například svému nadřízenému, ke schválení), a mohl tak učinit co možná nejjednodušším způsobem, přímo z prostředí aplikace se kterou pracuje, a nemusel ji opouštět a sám "ručně" zajišťovat vše potřebné. V zásadě šlo o to, aby se příslušné aplikace typu editorů, spreadsheetů apod. dokázaly samy domluvit s klientem elektronické pošty, a vše potřebné si dokázaly vyřešit samy mezi sebou.
Právě za tímto účelem vzniklo rozhraní MAPI (Messaging API), které si lze představit jako "společnou řeč" mezi ne-poštovními aplikacemi a klientem elektronické pošty. Toto rozhraní striktně vzato vůbec nesouvisí s protokoly TCP/IP (protože je implementační záležitostí, navíc vázanou na konkrétní platformu MS Windows). Pro uživatel elektronické pošty je ale důležité to, že existence MAPI umožňuje vytvářet tzv. mail-aware aplikace (doslova: aplikace uvědomující si existenci elektronické pošty), schopné samy využívat přenosových schopností elektronické pošty jako služby.
![]() |
K čemu slouží LDAP?
Dalším rozšířením elektronické pošty, které si její vývoj doslova vynutil, bylo její provázání s nejrůznějšími veřejnými adresáři a jinými formami "hromadné" evidence poštovních adres. Konkrétní uživatelé si samozřejmě mohou vést své vlastní adresáře a v nich si uchovávat adresy na osoby, se kterými si častěji dopisují. Pokud ale potřebují získat adresu někoho, koho dosud ve svém adresáři nemají, je vhodné jim dát možnost obrátit se co možná nejjednodušším způsobem na službu, specializovanou na sběr a evidenci elektronických poštovních adres. Pokusů o takovéto "hromadné" evidence bylo již více, a byly založeny na různých principech, mechanismem a konkrétních protokolech. Asi nejznámějším, ale nepříliš úspěšným pokusem bylo nasazení standardu X.500, pocházejícího z konkurenčního světa ISO/OSI. Příčinou jeho neúspěchu byla zejména jeho přílišná "mohutnost".
V prostředí Internetu se nakonec ujala "odlehčená" verze X.500, využívající protokol LDAP (od: Lightweight Directory Access Protocol). Na této bázi pak funguje většina dnešní forem evidence poštovních adres (adresářových služeb), a to i v českém Internetu - jmenovitě server Lidé (http://lide.seznam.cz) a adresář služby Atlas (http://ldap.atlas.cz). Samotný protokol LDAP je pak součástí rodiny protokolů TCP/IP, a jeho podpora je dnes zabudována do většiny poštovních klientských programů (nebo přímo do samotného operačního systému, jako v případě Windows 95). Výsledkem je pak možnost, aby uživatel vyhledával nové poštovní adresy (nebo si ověřoval správnost jemu známých adres) maximálně jednoduchým způsobem, přímo z prostředí svého poštovního klienta.
Budoucnost je v provázání, mobilitě a v hlasové poště
Obliba elektronické pošty neustále stoupá, a lidé se na jejím fungování a trvalé dostupnosti stávají doslova bytostně závislí - přístup ke své elektronické korespondenci chtějí mít doslova kdekoli a kdykoli. Proto se v poslední době stále více objevují nejrůznější brány mezi elektronickou poštou v Internetu a jinými službami, například tzv. paging systémy, či službou SMS mobilních telefonů GSM. Tyto brány pak jsou využívány například k tomu, aby uživatel dostal jejich prostřednictvím (do svého pageru, na svůj mobilní telefon) krátké oznámení o příchodu konkrétní zprávy do jeho poštovní schránky (případně i text zprávy samotné).
Jiným zajímavým trendem, který souvisí s rostoucí mobilitou uživatelů, je možnost plnohodnotného přístupu k elektronické poště z mobilních prostředků. Může toho být dosaženo například pomocí kombinace mobilního telefonu a počítače (ať již připojeného notebooku, nebo osobního organizéru zabudovaného přímo do GSM telefonu, jako např. u produktu Nokia 9000). Zde přitom nejde o žádnou změnu v samotném systému fungování elektronické pošty, ale jde pouze o nový způsob implementace poštovních klientů a jejich fyzické komunikace s příslušnými poštovními servery.
Stejně tak je tomu i v případě hlasového ovládání elektronické pošty, například v prostředí jedoucího osobního automobilu. Řidič, s rukama na volantu a očima na silnici, může stále ještě pracovat s elektronickou poštu - svůj klientský program ovládá hlasem, nechává si od něj předčítat obsah jednotlivých zpráv, nebo mu může přímo diktovat obsah nových zpráv.