Elektronická pošta v prostředí TCP/IP sítí
V minulých třech dílech seriálu jsme se věnovali uživatelskému pohledu na elektronickou poštu - na její celkovou filosofii a funkční možnosti. Přitom jsme k celé problematice přistupovali obecně, a snažili se ukázat to, co je pro všechny systémy elektronické pošty společné. Nyní se již zaměříme na jednu konkrétní oblast a na způsob, jakým je elektronická pošta řešena právě v ní: na prostředí počítačových sítí na bázi TCP/IP.
Nejprve si ale znovu připomeňme základní představu o způsobu implementace elektronické pošty, kterou jsme si zavedli již v 81. dílu: že jednotlivé zprávy si mezi sebou vyměňují tzv. přenosové složky (MTA, Message Transfer Agent), které jsou pro běžného uživatele neviditelné. Ten naopak komunikuje s tzv. uživatelskými složkami (UA, User Agent), jejichž prostřednictvím čte došlé zprávy, sestavuje nové a zadává je k odeslání. Jak jsme si již také uvedli v 81. dílu, tyto dvě složky mohou, ale nemusí být provozovány na témže počítači.
Odlišnosti v konvencích a přenosových mechanismech
V minulých dílech jsme si také řekli, že existují různé systémy elektronické pošty, které v obecném případě používají různé konvence a různé přenosové mechanismy pro přenos jednotlivých zpráv. Tyto konvence a mechanismy přitom nemusí být slučitelné s obdobnými konvencemi a mechanismy, které používají jiné systémy elektronické pošty. Přesto je ale možné, aby si i různé systémy dokázaly vzájemně předávat poštu - jsou-li vhodně propojeny pomocí tzv. poštovních bran (mail gateways), které zajišťují potřebné konverze. Přitom je ale možné i to, aby v rámci jednoho a téhož systému elektronické pošty spolu úspěšně a přímo komunikovaly (v roli přenosových složek) i velmi různorodé počítače, lišící se například systémovou platformou a operačním systémem apod. Co je tedy vlastně určujícím pro možnost přímé komunikace mezi dvěma přenosovými složkami MTA, a kdy takováto komunikace dvou složek vyžaduje zprostředkovací funkce poštovní brány?
Odpověď je následující: nezáleží na způsobu implementace složek MTA (a tím ani na prostředí, ve kterém jsou provozovány). Záleží naopak na následujících skutečnostech:
- na způsobu, jakým složky MTA vzájemně komunikují, resp.
jakým si předávají jednotlivé zprávy. Tento způsob je
definován příslušným protokolem, označovaným obecně
jako protokol přenosu zpráv (mail transfer protocol).
- na způsobu, jakým složky MTA interpretují obsah jednotlivých zpráv - zejména jejich hlaviček (viz minule), které mj. definují odesilatele i koncového příjemce zprávy (zatímco interpretace vlastního obsahu zpráv je vesměs ponechávána na příjemci). Závaznou interpretaci zpráv (jejich hlaviček) pak určuje standard, který přesně definuje formát jednotlivých zpráv, především pak syntaxi a sémantiku jednotlivých položek hlaviček.
Tím, co je charakteristické pro systémy elektronické pošty, používané v sítích na bázi protokolů TCP/IP, je používání jednotného protokolu pro přenos zpráv (protokolu SMTP), a jednotného formátu zpráv (definovaného doporučením RFC 822).
SMTP - protokol přenosu zpráv
Protokol SMTP (od: Simple Mail Transfer Protocol) je novější verzí staršího protokolu MTP (Mail Transfer Protocol), který se ukázal jako zbytečně komplikovaný, a byl výrazně zjednodušen (odsud přívlastek "Simple" v názvu SMTP). Definuje pouze způsob, jakým si jednotlivé složky MTA zprávy vyměňují, ale nikoli již to, jakým způsobem s nimi dále nakládají - například jakým způsobem jsou přijaté zprávy předávány uživatelům (příjemcům) apod. Dále protokol SMTP nedefinuje způsob a místo uchovávání jednotlivých zpráv (v poštovních schránkách uživatelů, případně ve frontách zpráv k odeslání apod.), ani to, kdy a jak často se má pokoušet zprávy odesílat. Obvykle je tento protokol implementován jako proces, který je explicitně volán jinými procesy, implementujícími složku MTA.
Podrobnějším popisem tohoto protokolu se budeme zabývat v samostatném dílu tohoto seriálu.
RFC 822 - standard pro formát jednotlivých zpráv
Jednotný formát zpráv elektronické pošty je definován v doporučení RFC (Request For Comment) číslo 822, s názvem: Standard for the Format of ARPA Internet Text Messages.
Tento standard rozlišuje dvě základní části zprávy - hlavičku (header) a tělo (body), a přesně definuje syntaxi i sémantiku hlavičky, resp. jejích jednotlivých částí, obsahující údaje relevantní pro doručování zpráv: mj. odesilatele a příjemce zprávy, její předmět (subject), datum a čas odeslání apod. V to pak spadá mj. i způsob konstrukce a zápisu adres, používaných pro potřeby elektronické pošty.
Pokud jde o tělo zprávy, zde standard předpokládá pouze to, že jde o text z ASCII znaků.
Standard, daný doporučením RFC 822, je značně rozšířený, a používá se i v sítích, které nepoužívají protokoly TCP/IP (zejména pak protokol SMTP pro vlastní přenos zpráv). Také většina alternativních standardů, které nejsou zcela slučitelné s RFC 822, mu jsou alespoň dosti podobné. Díky tomu je pak výrazně usnadněna výměna zpráv mezi těmito systémy, resp. konstrukce potřebných přestupních článků (poštovních bran).
Také standardem RFC 822 se budeme ještě podrobněji zabývat.
MIME - snaha odstranit omezení
Protokol SMTP i standard RFC 822 vznikly přibližně před dvanácti lety, jako výsledek určitého historického vývoje (úspěchu či neúspěchu předchozích protokolů), a také jako důsledek tehdejších potřeb - ty byly, pokud šlo o elektronickou poštu, zaměřeny hlavně na přenos jednoduchých ASCII textů. Tomu pak také byly oba standardy uzpůsobeny: RFC 822 hovoří jen o tom, že tělo zprávy je tvořeno ASCII textem, a protokol SMTP říká, že jednotlivé ASCII znaky mají být sedmibitové, a pokud jsou přenášeny takovou přenosovou cestou, které přenáší jednotlivé znaky jako osmibitové, pak zmíněných sedm bitů má být zarovnáno doprava, a nejvyšší bit má být nastaven na nulu.
Díky tomu se ovšem prostřednictvím pošty na bázi SMTP a RFC 822 nedá přenášet nic jiného, než jednoduché ASCII texty: například žádné binární soubory, žádné formátované texty (které by obsahovaly speciální formátovací znaky) či texty v národních abecedách, které vyžadují kódování jednotlivých znaků v osmi bitech. Jisté řešení se sice našlo - zakódovat binární data (např. pomocí tzv. UUENCODE-ování) do znakové podoby (tj. tak, aby výsledkem byly jen samé tisknutelné ASCII znaky, zobrazitelné v sedmi bitech). To je ale skutečně jen nouzové řešení, navíc spojené s mnoha dalšími problémy.
Časem proto vznikl velký tlak na dodefinování standardů pro elektronickou poštu v rámci protokolů TCP/IP tak, aby zvládaly i přenos jiných druhů dat, než jen ASCII textů. Tímto rozšířením se stal standard MIME (MultiPurpose Internet Mail Extensions), definovaný doporučením RFC 1341 (z roku 1992).
Tento standard je v jistém smyslu ortogonální k doporučení RFC 822, protože sám nemění strukturu hlavičky (kterou určuje RFC 822), ale definuje formát těla zprávy tak, aby toto mohlo být dále děleno na části (doposud nebylo tělo zprávy nijak dále strukturováno), a aby každá takováto část mohla nezávisle na ostatních obsahovat i jiné druhy dat, než jen jednoduché ASCII texty: například formátované texty, texty v nejrůznějších národních abecedách, digitální zvukové záznamy, grafické soubory a všechny ostatní druhy binárních souborů. Také tímto standardem se budeme podrobněji zabývat.
POP - možnost příjmu pošty na dálku
Jednou z charakteristických vlastností protokolu SMTP je doručování jednotlivých zpráv přímo koncovým příjemcům (přesněji počítačům, na kterých se nachází poštovní schránky příjemců), a nikoli jejich postupný přenos přes různé mezilehlé uzly: před přenosem každé jednotlivé zprávy odesílající strana vždy nejprve naváže přímé spojení s přijímající stranou, a teprve pak zprávu přenese.
 |