Ji°φ Peterka: Co je Φφm ... v poΦφtaΦov²ch sφtφch (85):

SMTP

Nejprve se ale vra¥me k p°edstav∞, kterou jsme si zavedli ji₧ v minulΘm dφlu, a kterß nßm bude velmi u₧iteΦnß i dnes. Jde o p°edstavu zprßvy, napsanΘ na listu papφru a vlo₧enΘ do obßlky - to, jak konkrΘtn∞ mß b²t zprßva na listu papφru napsßna, definuje doporuΦenφ RFC822 (kter²m jsme se zab²vali minule). To, jak mß vypadat obßlka, co mß b²t na nφ napsßno a jak²m zp∙sobem se mß p°enßÜet, je definovßno protokolem SMTP, kter²m se budeme zab²vat dnes.

Na sv∞t∞ nenφ jen SMTP

Hned na ·vod je dobrΘ si zd∙raznit, ₧e protokol SMTP (Simple Mail Transfer Protocol) je ve svΘ podstat∞ p°enosov² prost°edek, resp. mechanismus, koncipovan² s ohledem na pot°eby p°enosu zprßv. Nenφ ovÜem zdaleka jedin²m takov²mto p°enosov²m prost°edkem, resp. mechanismem. Je pouze tφm, kter² je nejrozÜφ°en∞jÜφ v jednom druhu sφtφ (sφtφ na bßzi TCP/IP), ale ani zde nemß zcela v²luΦnΘ postavenφ. Jeho p°edch∙dcem, kter² vznikl jeÜt∞ mimo rßmec sφ¥ovΘho modelu TCP/IP, ale dodnes se i v n∞m stßle jeÜt∞ pou₧φvß pro p°enos elektronickΘ poÜty, je protokol UUCP (Unix to Unix Copy Protocol).

Mo₧nosti, kterΘ protokol SMTP nabφzφ, p°itom nejsou omezeny jen na p°enos a doruΦovßnφ zprßv do poÜtovnφch schrßnek u₧ivatel∙, tak jak jsme a₧ dosud p°i naÜich ·vahßch o elektronickΘ poÜt∞ p°edpoklßdali. Jeliko₧ vznikl ji₧ p°ed urΦit²m Φasem - poprvΘ byl publikovßn ve form∞ doporuΦenφ RFC788 v listopadu roku 1981, a v srpnu 1982 byl "novelizovßn" doporuΦenφm RFC822 - pamatuje protokol SMTP i na existenci u₧ivatel∙, pracujφcφch na terminßlech hostitelsk²ch poΦφtaΦ∙: t∞m, kte°φ jsou momentßln∞ p°ihlßÜeni na n∞kterΘm z terminßl∙ hostitelskΘho poΦφtaΦe, je p°ipraven p°φsluÜnou zprßvu takΘ okam₧it∞ zobrazit (bu∩ mφsto jejφho ulo₧enφ do u₧ivatelovi schrßnky, nebo obojφ). Tato mo₧nost, na kterou protokol SMTP pamatuje, mß vÜak dnes ji₧ spφÜe historick² v²znam, a v praxi se nepou₧φvß.

SMTP obßlka

Na pomyslnΘ obßlce, do kterΘ je pro pot°eby p°enosu vklßdßna vlastnφ zprßva (sestavenß dle doporuΦenφ RFC822), musφ v₧dy "nadepsßny" alespo≥ dva zßkladnφ ·daje - adresa u₧ivatele, na jeho₧ popud byla obßlka se zprßvou sestavena (tzv. originator), a ·daj o tom, komu je zasφlßna (tzv. recipient). Je p°itom mo₧nΘ i to, aby jedna a tatß₧ zprßva m∞la vφce p°φjemc∙, resp. byla p°enßÜena jen jednou, ale v mφst∞ svΘho p°φjmu byla doruΦena vφce p°φjemc∙m. DalÜφ informace, jako nap°φklad p°edm∞t zprßvy Φi datum a Φas jejφho odeslßnφ, jsou ji₧ pouze souΦßstφ zprßvy samotnΘ.

Na tomto mφst∞ je velmi d∙le₧itΘ si uv∞domit, ₧e adresa p°φjemce (recipient-a) na SMTP obßlce v∙bec nemusφ b²t shodnß s adresßtem vlastnφ zprßvy. D∙vod∙ k tomu je hned n∞kolik - nap°φklad ten, ₧e jedna a tatß₧ zprßva m∙₧e mφt krom∞ svΘho "hlavnφho" p°φjemce (vyjßd°enΘho v hlaviΦce zprßvy v polo₧ce To:) takΘ jednoho Φi n∞kolik p°φjemc∙ b∞₧n²ch Φi slep²ch kopiφ (vyjßd°en²ch v polo₧kßch Cc:, resp. Bcc:). Kdy₧ je pak zprßva doruΦovßna t∞mto p°φjemc∙m kopiφ, je na obßlce "nadepsßna" jejich adresa, zatφmco v polo₧ce To: v rßmci vlastnφ zprßvy z∙stßvß nadßle adresa hlavnφho adresßta. Analogicky je tomu i v p°φpad∞, kdy "hlavnφch" adresßt∙ (uveden²ch v polo₧ce To: hlaviΦky zprßvy) je vφce, v p°φpad∞ zasφlßnφ jednΘ zprßvy celΘmu seznamu u₧ivatel∙ apod. Vedle toho vÜak existuje jeÜt∞ celß °ada dalÜφch d∙vod∙, kv∙li kter²m se adresy na SMTP obßlce mohou liÜit od adres, uveden²ch v hlaviΦce vlastnφ zprßvy. Tyto d∙vody souvisφ s konkrΘtnφm vyu₧itφm protokolu SMTP v prost°edφ sφt∞ Internet a s pou₧φvßnφm systΘmu domΘnov²ch jmen v tΘto soustav∞ sφtφ. Ve svΘm koneΦnΘm efektu tyto d∙vody vedou k tomu, ₧e jednotlivΘ zprßvy mohou b²t na svΘ cest∞ ke koneΦnΘmu adresßtovi (vyjßd°enΘm v polo₧ce To: hlaviΦky zprßvy) postupn∞ p°enßÜeny p°es r∙znΘ mezistupn∞ (p°es r∙znΘ recipent-y). TΘto problematice se budeme podrobn∞ji v∞novat v n∞kterΘm z dalÜφch pokraΦovßnφ serißlu.

P°enos obßlky a jejφho obsahu

Protokol SMTP p°edpoklßdß, ₧e "obßlka" i jejφ obsah budou p°enßÜeny po takovΘm transportnφm spojenφ, kterΘ se samo postarß o zajiÜt∞nφ spolehlivosti p°enosu. Obvykle je toto transportnφ spojenφ zajiÜ¥ovßno protokolem TCP (v sφtφch na bßzi TCP/IP prakticky v²luΦn∞), ale v zßsad∞ nenφ vylouΦeno ani pou₧itφ jin²ch p°enosov²ch protokol∙, zajiÜ¥ujφcφch spolehliv² p°enos. Existuje nap°φklad doporuΦenφ RFC1090, definujφcφ zp∙sob provozovßnφ SMTP nad protokoly X.25.

Protokol SMTP chßpe p°enßÜenß data jako textovß, Φlen∞nß na jednotlivΘ °ßdky (pomocφ znak∙ CR a LF), a tvo°enß pouze znaky z p∙vodnφ 128-prvkovΘ abecedy ASCII. Jin²mi slovy: SMTP p°edpoklßdß pouze p°enos znak∙, k≤dovan²ch do sedmi bit∙. Pokud se takovΘto sedmibitovΘ znaky p°enßÜφ kanßlem, kter² je uzp∙soben p°enosu osmibitov²ch znak∙ resp. byt∙ (co₧ je mj. p°φklad protokolu TCP), pak standard SMTP definuje, ₧e jeho sedmibitovΘ znaky majφ b²t vklßdßny do osmic bit∙ tak, aby byly zarovnßny doprava a zleva dopln∞ny nulov²m bitem.

Pomyslnß obßlka protokolu SMTP se sv²mi ·daji je p°itom p°enßÜena takΘ ve form∞ textu, a to na zaΦßtku p°enosu. Celß komunikace mezi p°φjemcem a odesilatelem (po navßzßnφ spojenφ na ·rovni protokolu TCP) mß formu dialogu, v rßmci kterΘho se ob∞ strany nejprve informujφ o svΘ obecnΘ p°ipravenosti p°ijφmat poÜtu, pak si p°edajφ ·daje o odesilateli a p°φjemci (resp. dalÜφ ·daje z pomyslnΘ obßlky), a potΘ pak i samotn² samotn² obsah zprßvy.

Forma SMTP dialogu

Vlastnφ dialog obou komunikujφcφch stran mß formu p°edßvßnφ p°φkaz∙, a zasφlßnφ odpov∞dφ na n∞. P°φkazy jsou tvo°eny klφΦov²mi slovy, za kter²mi obvykle nßsledujφ dalÜφ up°es≥ujφcφ parametry. Nap°φklad p°φkazem

HELO einar.dcit.cz

MAIL FROM: <pet@dcit.cz>

RCPT TO: <pav@einar.dcit.cz>

Naproti tomu odpov∞di na p°φkazy jsou zßsadn∞ ΦφselnΘ, tvo°enΘ trojmφstn²mi desφtkov²mi Φφsly (p°enßÜen²mi v textovΘm tvaru). Jejich struktura je p°itom obdobnß struktu°e Φφseln²ch odpov∞dφ, pou₧φvan²ch v protokolu FTP (kter²mi jsme se podrobn∞ji zab²vali v 72. dφlu serißlu): prvnφ z trojice Φφslic (1 a₧ 5) vyjad°uje celkovou povahu odpov∞di (nap°. 2 znamenß kladnou odpov∞∩, 5 zßpornou odpov∞∩), druhß Φφslice ji dßle up°es≥uje a koneΦn∞ t°etφ ji specifikuje jeÜt∞ blφ₧e (nap°. odpov∞∩ 220 signalizuje celkovou p°ipravenost druhΘ strany k p°enosu poÜty, odpov∞∩ 250 potvrzuje ·sp∞ÜnΘ spln∞nφ po₧adavku, zatφmco nap°φklad odpov∞∩ 550 °φkß, ₧e po₧adovanß akce nemohla b²t provedena proto, ₧e p°φsluÜn² u₧ivatel nenφ na p°ijφmajφcφ stran∞ znßm, resp. jeho poÜtovnφ schrßnka nenφ k dizpozici, odpov∞∩ 552 signalizuje nemo₧nost dokonΦenφ po₧adovanΘ akce kv∙li nedostatku pam∞ti pro doΦasnΘ ulo₧enφ apod.). Obdobn∞ jako u protokolu TCP je i zde sledovßna pot°eba r∙zn∞ "siln²ch" analyzßtor∙ - ty nejjednoduÜÜφ dokß₧φ vystaΦit jen s prvnφ Φφslicφ, zatφmco ty slo₧it∞jÜφ se orientujφ i podle dalÜφch Φφslic. P°φpadnΘ textovΘ °et∞zce, kter²mi b²vajφ ΦφselnΘ Φßsti odpov∞di dopln∞ny, pak majφ pouze povahu komentß°∙ (urΦen²ch pro p°φpadnΘ "lidskΘ" p°φjemce), a jejich tvar nenφ standardizovßn. M∙₧e se proto p°φpad od p°φpadu liÜit.

Fßze dialogu

Prvnφ fßzφ dialogu podle protokolu SMTP je samotnΘ navßzßnφ spojenφ. Ten, kdo spojenφ navazuje (za ·Φelem nßslednΘho odeslßnφ zprßvy), vystupuje v roli klienta, a kontaktuje protistranu v roli SMTP serveru, kter² bude zprßvu p°ijφmat. Klient p°itom kontaktuje sv∙j server na portu Φ. 25, kter² pat°φ mezi tzv. dob°e znßmΘ porty (well-known ports, viz 55. dφl serißlu). Je-li vÜe v po°ßdku a server je p°ipraven ₧ßdost p°ijmout, odpovφ na ni Φφselnou odpov∞dφ 220 (dopln∞nou p°φpadn²m textov²m komentß°em), viz °ßdek 1 obrßzku 85.1. Klient na to reaguje tak, ₧e se serveru p°edstavφ - pomocφ p°φkazu HELO, viz °ßdek 2 na obr. 85.1. Pokud je server ochoten p°ijφmat poÜtu od tohoto klienta, odpovφ na jeho p°edstavenφ kladn∞ (odpov∞dφ 250, viz 3. °ßdek).

DalÜφ fßzφ vzßjemnΘho dialogu mezi klientem (odesφlajφcφm) a serverem (p°ijφmajφcφm) je p°enos pomyslnΘ obßlky, spoΦφvajφcφ v p°edßnφ adresy odesilatele (p°φkazem MAIL FROM:, viz °ßdka Φ. 4) a jednΘ Φi n∞kolika adres p°φjemc∙ (pomocφ p°φkazu RCPT TO:, viz °ßdky 6 a 8).

PotΘ ji₧ nßsleduje p°enos vlastnφ zprßvy. Ten je ze strany vysφlajφcφho klienta uvozen p°φkazem DATA (viz °ßdek 10), a ze strany p°ijφmajφcφho klienta odpov∞dφ 354 (je-li server na p°φjem zprßvy p°ipraven, viz °ßdek 11). Samotnß zprßva, tvo°enß svou hlaviΦkou a t∞lem (a strukturovanß podle doporuΦenφ RFC822, viz minul² dφl) je p°enßÜena po jednotliv²ch °ßdcφch. Konec zprßvy je signalizovßn °ßdkou, obsahujφ pouze jedin² znak - teΦku (na prvnφ znakovΘ pozici). P°φpadn² v²skyt takovΘhoto °ßdku v t∞le zprßvy je °eÜen zdvojenφm uvozujφcφ teΦky.

Po ·sp∞ÜnΘm p°enosu celΘ zprßvy nßsleduje kladnΘ potvrzenφ (odpov∞dφ 250, viz °ßdka 13 obrßzku 85.1), a ukonΦenφ spojenφ ze strany klienta (p°φkazem QUIT, viz 14. °ßdek).