Elektronická pošta

Jaromír Hamala, xhamala@fi.muni.cz

Obsah

Elektronická pošta

Elektronická pošta je jedna z nejstarších aplikací na Internetu. Její historie sahá ještě do původního Arpanetu. Litarutara uvádí, že již roku 1976 posílá královna Alžbeta II. elektronický dopis oznamující připojení části armády do Arpanetu. I v dnešní době patří email mezi základní služby a je jedním z hlavních důvodů raketového rozvoje Internetu. Původně byla pošta navržena jako jednoduchá služba, která nedělala nic jiného než kopírovala zprávu z počítače odesílatele na počítač příjemce, kde ji připojila k již existujícímu souboru(schránce). Tento základní princip přetrval i do dnešní doby, leč bylo třeba definovat řadu rozšíření pro vetší variabilitu. Původní pošta(definovaná dokumentem RFC 822) počítala např. s přenosem čistého textu, tedy takových znaků, které lze zakódovat do 7bitů. To je samozřejmě v dnešní době naprosto nedostatečné. Tento problem řeší standard MIME.

O přepravu emailu od odesílatele k adresátu se stará řetezec programu, které si můžeme rozdělit do následujících kategorií:

• MUA(Mail user agent) -- program ve kterém (nejčastějí) uživatel vytváří vlastní zprávu Mezi nejznámější patří mutt, elm, pine....
• MTA(Mail transport agent) -- program zajištující doručení zprávy k příjemci. Též nazýván mail server. Tradiční zástupce je sendmail, mezi "alternativní" patří qmail, exim, postfix...
• MSP(Message Submission Program) -- program starající se o odeslání zprávy. Obvykle integrován do MTA
• MDA(Mail Delivery Agent) -- program pro doručováni. Obvykle přebírá zprávy od lokálního MTA, třídí je do schránek, přeposílá, atd..Typický zástupce je Procmail

SMTP

Protokol SMTP (Simple Mail Transfer Protocol) je protokol pro předávání zpráv mezi počítači. Vychází ze staršího MTP, který se ukázal jako zbytečně komplikovaný. SMTP je definován v rfc2821. Komunikace standardně probíhá na TCP portu 25 jako komunikace typu klient - server. Jako klient vystupuje MUA(MSP), který předává zprávu prvnímu MTA, nebo MTA, který předává zprávu dále. Klient naváže spojení na příslušný port a zadává SMTP příkazy. Server na ně odpovídá a sestavuje obálku zprávy podle které je zpráva dále posílána.

Základní model doručování zprávy

Neomi chce sdělit Isacovi své poslední studyjní uspěchy. Spustí tedy svůj oblíbeny MUA, v jejím případě mutt. Jediné co Noemi musi/měla_by zadat je adresa Isaca, předmět zprávy a pochopitelně zprávu samotnou. MUA doplní všechny ostatní vyžadované hlavičky a zprávu předá dál svému oblíbenému MTA. Tím pro něj starost o doručení končí. MTA, například exim, doplní hlavičku o nejaké další údaje a take vytvoří obálku kterou se řídí další směřovaní pošty. Pomocí MX záznamu v DNS si MTA zjistí stroj odpovědný za příjem pošty pro danou doménu a pokusí se mu zprávu předat. Pokud uspěje, tak končí starosti i pro něj. V opačném případě vyhledá v DNS stroj s vyšším preferenčním číslem pro danou domenu a opět se mu pokusí zprávu předat. Spojení nemusí být vždy příjmé, ale zprávu si může vzájemně předávat více MTA. Z popsaného systému je zřejmé, že otázka doručovaní je v podstatě problém nalezení cesty v grafu. Aby se zabránilo vzniku cyklů, existuje pravidlo, dle kterého MTA předává zprávu jen MTA s preferenčním číslem nižším, než má on sám. V případě kdy pro cílovou doménu neexistuje MX záznam, MTA se zjistí IP adresu této a pokusí se email doručit příjmo na tento stroj. Není to ale rozhodně preferovaný postup. Na cílovém stroji se zpráva předá MDA(napr. Procmail), který se postará o zařazení do správne složky, odkud si ji Isac vybere svým oblíbeným MUA, kterým je elm. Popř. by si ji mohl stahnout na svůj laptop pomocí jednoho z protokolů pop3/imap.

                   +-----------+          +--------+
+-------+  pise    |odesilajici|  vola    |zdrojovy|
| Neomi |--------->|   MUA     |--------->|  MTA   |::::>::::
+-------+          |(mutt)     |          |(exim)  |       ::   na odesilajicim
                   +-----------+          +--------+       ::   pocitaci
                                                           ::
.......................................................................
                             SMTP                          ::
 ::::::::::::::::::::::::::::<:::::::::::::::::::::::::::::::
 ::
 ::   +---------+          +-----+                +-------+
 ::   | cilovy  |  vola    |     |  doruci do     |Isacova|
 ::::>|   MTA   |--------->| MDA |===============>|chranka|  na prijimajicim
      |(qmail)  |          |     |                |(elm)  |  pocitaci
      +---------+          +-----+                +-------+
z obrázku je zřetelná nezávislost emailu na konkrétní implementaci jednotlivých nástrojů

Problém nevyžádané pošty

• Reklamní zprávy
• Hoaxy
• Retezové dopisy
• Další.....

"Pred nekolika tydny si sedla jedna osoba v kine na neco 
pichajiciho na sedadle. Když vstala, aby zjistila, co to bylo, 
nasla jehlu zapichnutou do sedadla, na ktere byl pripevnen 
vzkaz: "Prave si byl nakazen HIV". Kontrolni stredisko chorob 
zaznamenalo v posledni dobe mnoho podobných pripadu v mnohych 
dalsich mestech i v PRAZE !!! Informujte sve zname o moznem riziku,
 zabranite tak sireni této choroby."

V porovnání s hoaxy, by se mohli zdát klasické řetězové dopisy neškodné. Nejčastějí motivuji adresáta k dalšímu rozeslání varovaním, že pokud tak neučíní, nebude mít štestí apod. Dostatečně zkušený/poučený uživatel tyto maily ignoruje, ale pokud musite 2x denně stahovat podobný dopis, obsahující 500kB "vtipnou" prezentaci v powerpointu, tak to mnoho radosti neuděla. Zvláště pokud jste na počítané lince.