Základní principy elektronické pošty

Každý si dokáže představit, jak funguje nejoblíbenější služba internetu, WWW. Mnohem menší počet uživatelů internetu ví, co se děje s dopisem zaslaným elektronickou poštou. A právě těm je určen tento příspěvek.

Základní normou, podle které funguje elektronická pošta, je RFC 821 z roku 1982 a RFC 822 z téhož roku. RFC 821 definuje přenosový protokol SMTP (Simple Mail Transfer Protocol neboli přibližně česky jednoduchý protokol pro přenos pošty). V RFC 822 (Standard for the Format of ARPA Internet Text Messages) je zakotveno formátování textu, který je elektronickou poštou následně přenášen. Celá věc se následně v roce 1992 zkomplikovala vydáním RFC 1341 a RFC 1342, které umožňují, zavedením normy zvané MIME, zasílání binárních dat a textových zpráv obsahujících znaky národních abeced.

Pro další pokračování předpokládejme, že Pepa, který má konto na "Seznamu", tedy jeho adresa je pepa@seznam.cz, píše kamarádovi Frantovi, který má schránku třeba na email.cz a adresu tedy má franta@email.cz. Pepa tedy napíše tuto zprávu:

Ahoj Franto,
pisu Ti abys na me nezapomel.

Do patřičného pole ve svém poštovním programu vyplní adresu příjemce a klikne na ikonu odeslat. V této chvíli se teprve začíná rozbíhat doručovací proces. Zpráva je nejdříve podle RFC 822 přeformátována do požadované podoby, je tedy opatřena tzv. hlavičkami, adresou odesílatele a příjemce, datem a časem vytvoření. Hlavičky se od těla zprávy oddělují jedním prázdným řádkem a v našem případě budou vypadat třeba takto:

From: pepa@seznam.cz
To: franta@email.cz
Date: Tue, 05 Jan 1999 23:07:18 +0100
Subject: Pozdrav Frantovi

Toto jsou minimálně vyžadované hlavičky, obvykle je vhodné doplnit ještě další, třeba Organization: jako název zaměstnavatele, nebo Message-ID, což je unikátní identifikátor generovaný nějakým algoritmem pro náhodná čísla, jménem stroje a podobně. Celá zpráva bude potom vypadat takto:

From: pepa@seznam.cz
To: franta@email.cz
Date: Tue, 05 Jan 1999 23:07:18 +0100
Subject: Pozdrav Frantovi
Message-Id: 1215C47795@aaa.seznam.cz


Ahoj Franto,
pisu Ti abys na me nezapomel.

Tady končí práce RFC 822 a zpráva je odeslána protokolem podle RFC 821. Tím se tentokrát nebudu blíže zabývat. Základní princip je, že zpráva je obalena další obálkou, ve které je uveden odesílatel a příjemce, nic dalšího. Údaje v této obálce nemusí nijak korespondovat s údaji v hlavičce. Praktická ukázka jsou např. konference, které běžně při přeposílání zachovávají v poli TO: jméno a adresu konference a konkrétní adresy účastníků vyplní listserver právě jen v obálce. Zrovna tak spamovací automaty používají tento princip a uživatelé jsou potom překvapeni, že dostávají zprávy adresované třeba na friends@all.com.

Zpráva je z klientského počítače většinou nejdříve poslána na server jeho providera. Určení cesty, kterou se bude zpráva internetem pohybovat, aby nakonec skončila ve Frantově schránce, totiž není triviální a většinou jej zajišťují speciální programy jako sendmail na Unixu nebo Exchange server pod Windows NT. Server u providera vyhodnotí z transportní obálky, na který stroj se má pošta poslat. To nemusí být nutně stroj, na kterém má Franta svou poštovní schránku. Pošta se směruje podle zvláštních záznamů v DNS databázi, kterým se říká MX records. Ty zajistí jednak možnost dočasného uložení pošty na záložním serveru při výpadku serveru hlavního a také třeba to, že hlavní server nemusí být z bezpečnostních důvodů vůbec přímo dostupný. MX záznamů může být několik a jsou jim přiřazovány priority, podle kterých je pošta postupně doručována až do úspěšného doručení. Obvykle je první pokus o doručení proveden okamžitě po přijetí zprávy od klienta ke zpracování. Pokud selže vyčerpáním všech možností, je zpráva uložena do fronty a čeká na příští průchod frontou. Jak často je fronta zpracovávána, záleží na konfiguraci toho kterého stroje. Obvykle to bývá 15-60 minut, ne více než 4 hodiny. Některé servery generují po nastavených dobách, které zpráva ve frontě stráví, upozornění, že ještě nebyla doručena. Takové upozornění ale není povinné, a tak nemusí být dle úvahy správce serveru třeba vůbec generováno.

Každý server, přes který zpráva prochází, je povinen na její začátek umístit hlavičku Received:. Pokud využijeme funkce zobrazení zdrojového textu zprávy, můžeme si přečíst, kudy k nám zpráva přišla a kde se všude toulala. Tím, že hlavičky jsou přidávány na začátek, musí být čteny od poslední, nejvnitřnější. V současné době není toto pravidlo vždy dodrženo, protože u privátních sítí je žádoucí skrýt jejich vnitřní fyzickou strukturu a do velkého internetu odesílat minimum údajů.

Když zpráva doputuje k cíli, tedy stroji, kde Franta má fyzicky umístěnu svou poštovní schránku, je do ní uložena. Dříve, kdy uživatelé pracovali na stroji, na kterém se jejich schránka nacházela, byla vypisována i upozorňující zpráva, že přišel dopis od toho či onoho. Dnes je tento komfort dostupný jen těm, kteří pracují pod Unixem či Novellem a jsou k internetu připojeni pevnou linkou. Ostatní si poštu stahují na svůj počítač až při připojení k internetu. O příchodu pošty mohou být informováni jedině SMS zprávou zaslanou na mobilní telefon, nebo ti šťastnější přes D kanál ISDN spojení (není mi známo, že druhá varianta by byla v České republice již někde realizována.)

Stahování pošty probíhá obvykle protokolem POP3. Značnou nevýhodou tohoto protokolu je, že vybírá zprávy ze schránky, ve které jsou uloženy, již bez transportní obálky, tedy bez znalosti konkrétního adresáta. To je problém hlavně tehdy, pokud schránku sdílí více uživatelů a ti dostávají zprávy s univerzální TO: hlavičkou (třeba z konferencí). Schopní provideři to řeší přidáním další hlavičky X-envelope-to: do doručované zprávy. Kromě POP3 existují i jiné, dokonalejší metody, ale s těmi se téměř nesetkáte. Po stažení zprávy na svůj počítač si ji Franta konečně může přečíst.

Příště se pokusím nastínit, proč si Franta poštu třeba také nepřečte, protože pro něj nebude čitelná. Třeba nebude česky.

Dan Ohnesorg (dan@feld.cvut.cz) - 26.2.1999

Zaujal Vás tento článek? Chcete nám k němu něco sdělit? Neváhejte a sdělte nám svůj názor 

S O U V I S E J Í C Í   O D K A Z Y . . .

	Velký test českých emailových služeb - 15.1.1999
	Skutečné e-mailové viry - 20.10.1998
	DIAGNÓZA - Chatus internetus mailus - 10.9.1998
	Diagnóza � Chatus internetus mailus II - 15.9.1998
	Vyzkoušeli jsme VOCmail  - 23.7.1998