SMTP

V minulém dílu tohoto seriálu jsme se zabývali základním formátem zpráv elektronické pošty, tak jak jej v rámci síťového modelu TCP/IP definuje doporučení RFC 822. Dnes se již dostaneme k představě toho, jak jsou takto sestavené zprávy přenášeny.

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

sděluje odesílající uzel na začátku vzájemného dialogu svou identitu přijímajícímu uzlu, zatímco příkaz

MAIL FROM: <pet@dcit.cz>

signalizuje, kdo je odesilatelem zprávy, příkaz

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

zase specifikuje příjemce zprávy apod. Jak jsme si ale již uvedli výše, nemusí tyto adresy z SMTP obálky nutně odpovídat adresám prvotního odesilatele a konečného příjemce, uvedeným v hlavičce zprávy.

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).

Obr. 85.1: Fáze SMTP dialogu

	odesílající (klient)	přijímající (server)
	{navázání spojení na úrovni protokolu TCP}
1		220 einar.dcit.cz SMTP service ready
2	HELO frode.dcit.cz
3		250 einar.dcit.cz hello frode.dcit.cz
4	MAIL FROM <pet@dcit.cz>
5		250 sender ok
6	RCPT TO: <pav@einar.dcit.cz>
7		250 recipient ok
8	RCPT TO: <votava@einar.dcit.cz>
9		250 recipient ok
10	DATA
11		354 Enter mail, end with "." on a line by itself
12	{ hlavička zprávy dle RFC 822}
	...............
	{tělo zprávy dle RFC822}
	.
13		250 mail accepted
14	QUIT
15		221 einar.dcit.cz closing connection
	ukončení spojení na úrovni protokolu TCP

---