zpět do archivu článků |
rejstřík |
předchozí díl |
následující díl
Jiří Peterka: Co je čím ... v počítačových sítích (83):
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.
Existence poštovní brány je nevyhnutná v případě, kdy
komunikující složky používají odlišný formát zpráv.
V případě, kdy používají stejný formát přenášených zpráv,
ale liší se v používaném protokolu pro jejich přenos,
potřebují mezi sebou také vhodného prostředníka. Je pak
ovšem spíše terminologickou otázkou, zda takovýto
prostředník bude označován jako poštovní brána či nikoli.
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.
 |
Obr. 83.1.: Představa protokolů elektronické pošty
Toto řešení ovšem vychází z předpokladu, že
přijímající počítač je trvale v provozu (i když na straně
odesilatele jsou pro případ potřeby implementovány fronty
dosud neodeslaných zpráv, ve kterých tyto mohou určitou dobu
čekat). Z tohoto důvodu jsou pak v roli poštovních uzlů
využívány výhradně takové počítače, které jsou provozovány
trvale - typicky různé Unixovské servery, a nikoli pracovní
stanice, na kterých uživatelé skutečně pracují (a které
nejsou trvale v provozu). Pro většinu uživatelů však není
příliš výhodné zpracovávat si svou poštu přímo na takovémto
počítači - zejména kvůli komfortu, který nabízí příslušné
programy, realizující tzv. uživatelské složky (UA, User
Agent). Jak jsme si naznačili již v 81. dílu, je v zásadě
možné provozovat uživatelskou složku i na jiném počítači,
než který je skutečným příjemcem pošty a na kterém se
nachází poštovní schránky jednotlivých uživatelů. K tomuto
účelu ovšem bylo nutné vyvinout také potřebný přenosový
protokol, který by zprostředkovával komunikaci mezi
přenosovou složkou (v roli poštovního serveru)
a uživatelskou složkou (v roli klienta). Takovýchto
protokolů vzniklo dokonce víc, přičemž tím nejpoužívanějším
je dnes zřejmě protokol POP3 (Post Office Protocol, verze
3), sloužící pro přenos zpráv směrem k uživatelské složce
(zatímco v opačném směru je obvykle využíván protokol SMTP,
viz též obrázek 83.1). Také protokolem POP3 se v tomto
seriálu budeme zabývat podrobněji.
zpět do archivu článků | rejstřík |
předchozí díl |
následující díl
Tento článek může být volně šířen, pokud se tak děje pro studijní účely, na nevýdělečném základě a se zachováním tohoto dovětku. Podrobnosti hledejte zde, resp. na adrese
http://ksi.ms.mff.cuni.cz/~peterka/archiv/copyleft.htm