VyÜlo v t²denφku: COMPUTERWORLD
╚φslo:21/94
RoΦnφk:1994
Rubrika/kategorie: Co je Φφm ... v poΦφtaΦov²ch sφtφch
Dφl:83
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:

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ßzek 83.1.
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://archiv.czech.net/copyleft.htm