Prohlášení. Prohlašuji, že jsem diplomovou práci vypracoval samostatně a výhradně s použitím citovaných pramenů. V Plzni dne 22. května 2002...

Poděkování Na tomto místě je mou milou povinností poděkovat panu Ing. Jiřímu Ledvinovi, CSc. za to, že vypsal krásné téma diplomové práce, kterému jsem neodolal. Dále bych rád poděkoval jednomu z autorů JavaMail API, který ochotně odpovídal na mé zvídavé dotazy v průběhu realizace web mail aplikace, jeho jméno je Bill Shannon. Také bych neměl zapomenout poděkovat spolužákům, kteří mi pomáhali protloukat se studiem: Zdeňkovi Mukenšnáblovi, za spolupráci v průběhu studia, a Ladislavu Vaizovi za množství linuxových rad do života. Můj další dík si zaslouží i kamarád Jan Piškot Třeška, který mi ochotně zapůjčil svůj počítač 386DX-40MHz, abych mohl doma o víkendech alespoň psát texty k této práci paralelně se svým bratrem. V neposlední řadě musím také poděkovat bratrovi a rodičům, kteří mě podporovali nejen při této práci, ale i po celou dobu mého studia.

Prohlášení Prohlašuji, že jsem diplomovou práci vypracoval samostatně a výhradně s použitím citovaných pramenů. V Plzni dne 22. května 2002........................... Jiří Patera

Abstrakt Jak už samotný název napovídá, zabývá se tato diplomová práce přístupem k elektronické poště prostřednictvím WWW rozhraní. První část je spíše teoretická. Zabývá se vytvořením a odesláním elektronické zprávy pomocí SMTP protokolu a přenosem zprávy mezi jednotlivými MTA. Samozřejmě obsahuje také stručný popis protokolů POP3 a IMAP4, které slouží pro příjem elektronických zpráv ze vzdáleného poštovního serveru. Druhá část práce je zaměřena na konkrétní realizaci jednoduché web mail aplikace pomocí objektově orientovaného programovacího jazyka Java a jeho technologie JavaServlet. Pro komunikaci s poštovními servery prostřednictvím protokolů SMTP, POP3 a IMAP4 se v servletu používá JavaMail API. Klíčová slova: elektronická pošta, e-mail, HTML formulář multipart/form-data, IMAP4, JavaMail, JavaServlet, MIME, MTA, MUA, POP3, servlet, SMTP, web mail, WWW server Tomcat. Abstract As the topic itself suggests, this diploma thesis deals with access to electronic mail via WWW interface. The first part of this thesis is more often theoretical than not. It concerns with creating and sending an electronic message using the SMTP protocol and transferring the message through particular MTAs. Obviously, it also includes a short description of POP3 and IMAP4 protocols which purpose is to receive electronic messages from a remote mail server. The second part is aimed at a concrete realization of a simple web mail application using the object-oriented Java programming language and its JavaServlet technology. The JavaMail API supports SMTP, POP3 and IMAP4 protocols and thus is used for communication between the servlet and mail servers. Keywords: electronic mail, e-mail, HTML form multipart/form-data, IMAP4, JavaMail, JavaServlet, MIME, MTA, MUA, POP3, SMTP, Tomcat webserver, webmail.

i Obsah 1 Úvod 1 1.1 Čím se zabývá tato práce............................ 1 1.2 Jazykový koutek (čeština vs. angličtina)................... 2 1.3 Typografické a syntaktické konvence..................... 3 2 Elektronická pošta 4 2.1 Elektronická adresa............................... 4 2.2 Poštovní programy MUA a MTA....................... 5 2.2.1 Jak funguje MUA............................ 6 2.2.2 Jak funguje MTA............................ 6 2.3 Poštovní klient a server............................. 7 3 Popis protokolů 8 3.1 SMTP protokol................................. 8 3.1.1 SMTP obálka.............................. 9 3.1.2 Přenos SMTP obálky.......................... 9 3.1.3 Fáze SMTP dialogu........................... 10 3.1.4 ESMTP protokol............................ 10 3.2 POP3 protokol................................. 10 3.2.1 Komunikace klient/server....................... 11 3.2.2 Základní operace............................ 11 3.3 IMAP4 protokol................................. 12 3.3.1 Komunikace klient/server....................... 12 3.3.2 Základní operace............................ 13 3.4 HTTP protokol................................. 14 3.4.1 Metody GET a POST......................... 14 3.5 Bezpečnost protokolů aplikační úrovně.................... 15 4 Internetové textové zprávy 16 4.1 Formát elektronické zprávy........................... 16 4.1.1 Hlavička elektronické zprávy...................... 16 4.1.2 Tělo elektronické zprávy........................ 18 4.1.3 Formát elektronické adresy....................... 18

Obsah ii 5 Popis rozšíření MIME 19 5.1 Hlavní rozšíření pro elektronické zprávy.................... 19 5.2 Základní princip MIME............................ 19 5.3 Nové položky hlavičky elektronické zprávy.................. 20 5.4 Položka hlavičky Content-Transfer-Encoding............... 20 5.4.1 Kódování quoted-printable..................... 21 5.4.2 Kódování base64............................ 21 5.5 Hodnoty položky hlavičky Content-Type................... 21 5.5.1 Jednoduché typy............................ 22 5.5.2 Složené typy............................... 22 5.6 Obsah položek hlavičky elektronické zprávy.................. 23 6 Architektury existujících systémů 24 6.1 EMU Webmail................................. 24 6.2 Endymion MailMan............................... 25 6.3 KrystalBox Webmail.............................. 26 7 Návrh vlastního web mail systému 29 7.1 Navrhnutá architektura web mail systému.................. 29 7.2 Komunikace mezi WWW prohlížečem a WWW serverem.......... 30 7.3 Komunikace mezi WWW serverem a SMTP serverem............ 30 7.4 Komunikace mezi WWW serverem a POP3 nebo IMAP4 serverem..... 31 7.4.1 Komunikace s POP3 serverem..................... 31 7.4.2 Komunikace s IMAP4 serverem.................... 31 7.5 Ověřování uživatele............................... 31 7.6 Správa elektronických zpráv.......................... 32 8 Něco málo o HTML 33 8.1 Proč právě HTML............................... 33 8.2 HTML formuláře................................ 34 8.2.1 Formulář typu application/x-www-form-urlencoded....... 34 8.2.2 Formulář typu multipart/form-data................. 35 9 JavaServlet API 36 9.1 Proč právě JavaServlet............................. 36 9.2 HTTP servlet.................................. 37 9.2.1 Jak funguje HTTP servlet....................... 37 10 JavaMail API 39 10.1 JavaBeans Activation Framework (JAF)................... 39 10.2 Základní třídy JavaMail API.......................... 40 10.3 Práce s elektronickými zprávami........................ 40 10.3.1 Čtení elektronických zpráv z poštovního serveru........... 42

Obsah iii 10.3.2 Odesílání elektronických zpráv..................... 43 11 Web mail ze strany uživatele 44 11.1 Přihlašování k POP3 nebo IMAP4 účtu.................... 44 11.2 Vytváření a odesílání elektronických zpráv.................. 44 11.3 Pohled na věc z POP3 účtu.......................... 45 11.4 Pohled na věc z IMAP4 účtu.......................... 45 11.5 Práce s poštovními složkami a elektronickými zprávami........... 46 12 Web mail ze strany programátora 48 12.1 Web mail servlet................................ 48 12.2 Využití HTTP relace.............................. 49 12.3 Rozbor elektronických zpráv.......................... 50 12.4 Přílohy elektronických zpráv.......................... 50 12.4.1 Adresování příloh elektronické zprávy................. 51 12.4.2 Přeprava přílohy z WWW serveru do WWW prohlížeče....... 52 12.4.3 Přenos souborů z WWW prohlížeče na WWW server........ 52 12.5 Ukládání WWW stránek do vyrovnávací paměti WWW prohlížeče..... 54 12.6 Záludná čeština a web mail.......................... 55 12.6.1 Čeština v HTTP odpovědích servletu................. 55 12.6.2 Čeština na WWW stránkách a v elektronických zprávách...... 56 12.6.3 Čeština v HTTP požadavcích od WWW prohlížeče......... 56 12.6.4 Čeština v názvu poštovních složek na IMAP4 serveru........ 57 12.7 Dynamické generování WWW stránek.................... 57 13 Web mail ze strany administrátora 59 13.1 Volba WWW serveru.............................. 59 13.2 WWW server Tomcat............................. 60 13.2.1 Spouštění servletů........................... 60 13.2.2 Aktivace SSL (HTTPS)........................ 60 13.3 Webový archiv (WAR file)........................... 60 14 Závěr 62 14.1 Rekapitulace dosažených výsledků....................... 62 14.2 Řešené problémy při realizaci......................... 63 14.3 Známé nedostatky realizované aplikace.................... 63 14.4 Testování web mail aplikace.......................... 64 14.5 Celkové zhodnocení............................... 64 Literatura 64 A Zdrojový kód třídy PartAddress 68 B Zdrojový kód třídy MailUserData 71

Obsah iv C Zdrojový kód metody parsemultipartformdata() ze třídy JavaMailServlet 75 D Výpis souboru WEB-INF/web.xml 79 E Konfigurační soubor WWW serveru Tomcat 80 F Několik uložených obrazovek (různé WWW prohlížeče) 82

v Seznam obrázků 6.1 Architektura EMU Webmail systému..................... 25 6.2 Architektura Endymion MailMan systému (Standard Edition)....... 26 6.3 Architektura Endymion MailMan systému (Professional Edition)...... 27 6.4 Architektura KrystalBox Webmail systému.................. 27 7.1 Architektura realizovaného web mail systému................ 30 10.1 Základní rozhraní a třídy JavaMail API.................... 41 10.2 Objektově orientovaný pohled na elektronickou zprávu........... 41 10.3 Objektově orientovaný pohled na přílohy elektronické zprávy........ 42 12.1 Naznačení funkce web mail servletu...................... 49 13.1 Struktura WAR archivu............................ 61 F.1 Přihlašovací obrazovka Internet Explorer 6.0 (Windows 2000)...... 82 F.2 Vytváření elektronické zprávy Netscape Navigator 6.2 (Windows 2000). 83 F.3 Vytváření elektronické zprávy Links 0.93 (RedHat Linux)......... 83 F.4 Poštovní složky a elektronické zprávy IE 6.0 (Windows XP)....... 84 F.5 Elektronická zpráva a její příloha IE 6.0 (Windows XP).......... 84 F.6 Elektronická zpráva Netscape Navigator 6.2 (Windows 2000)....... 85 F.7 Elektronická zpráva Lynx 2.8.4 (Debian Linux).............. 85

vi Seznam tabulek 4.1 Položky hlavičky elektronické zprávy a jim příslušející typy elektronických adres....................................... 17 5.1 Jména MIME položek hlavičky a jejich popisy................ 20 5.2 Typy kódování dat těla zprávy a jejich popisy................ 20 5.3 Jednoduché MIME typy, jejich nejčastější podtypy a popisy........ 22 5.4 Složené MIME typy, jejich podtypy a popisy................. 23

1 Kapitola 1 Úvod Spolu s rozšiřováním počítačových sítí vyvstává potřeba komunikace mezi jednotlivými uživateli počítačů. Zatímco dříve se jednalo především o elektronické vzkazy mezi několika uživateli, kteří střídavě pracovali na jednom počítači, v dnešní době se používá elektronická pošta (electronic mail, e-mail) ke komunikaci mezi uživateli z celého světa, kteří využívají počítačů připojených do sítě Internet. Jednoduchá podoba elektronické pošty se objevila již v první verzi operačního systému UNIX. S velkým rozmachem moderních technologií se náležitě rozšířily i možnosti počítačové elektronické pošty. To, co dříve zvládaly velké systémy zabírající celé sály, dnes hravě zvládne počítačová síť. Elektronická pošta je základní službou počítačových sítí a velmi se podobá své všeobecně známé papírové kolegyni. Využití elektronické pošty tedy spočívá zejména v rychlém předávání nejrůznějších vzkazů (včetně textových, obrázkových, databázových i jiných souborů), dále v přehledném rozčleňování došlé pošty a vůbec organizaci dat, což v konečném součtu velmi šetří čas, energii i námahu jednotlivých uživatelů. Vzkazy a soubory je možno rozesílat jednomu nebo více uživatelům současně, došlou poštu lze prohlížet, editovat, kopírovat a posílat dále (přeposílat). Při používání elektronické pošty musí být každý účastník (stejně jako u pošty skutečné) nějak identifikován. Elektronickou poštu tedy zasíláme na elektronickou adresu, která jednoznačně a celosvětově určuje adresátovu elektronickou poštovní schránku. Odesilatel kromě této adresy nepotřebuje o příjemci vědět žádné další informace, o vlastní dopravu se už postarají poštovní servery. 1.1 Čím se zabývá tato práce Jak už samotný úvod naznačil, bude se tato práce zabývat právě elektronickou poštou. První část práce je převážně teoretická a obsahuje popis toho, jak elektronické zprávy vlastně vypadají. Práce pojednává o vnitřním složení jednoduchých, ale i složitějších zpráv. Jednoduchou zprávou může být např. pouze prostý ASCII text, zatímco složitou pak texty v různých formátech a znakových sadách, obrázky a různé další datové soubory. Složitější

1.2. Jazykový koutek (čeština vs. angličtina) 2 elektronické zprávy vznikají především díky existenci standardu MIME, o kterém se v této práci také zmíníme. Budeme se samozřejmě zabývat i tím, jak elektronické zprávy putují počítačovou sítí. Povíme si, kde zprávy vznikají a jak se díky protokolu SMTP dostanou až do elektronické poštovní schránky svého příjemce. Řekneme si, jak se elektronické zprávy ukládají do elektronických poštovních schránek jednotlivých uživatelů a také jak se díky protokolům POP3 a IMAP4 dostanou až ke svým adresátům (čtenářům). Téma celé práce je Web mail, což znamená, že přijde řeč především na čtení a odesílání elektronické pošty pomocí běžně dostupných Internetových prohlížečů a dynamicky generovaného WWW rozhraní. Zmíníme se tedy i o tom, jak se dynamicky vytváří WWW stránky pomocí jazyka HTML a objektově orientovaného programovacího jazyka Java (využijeme při tom jednu jeho moderní Internetovou technologii JavaServlet. Podíváme se i na problémový přenos souboru z HTML formuláře pomocí technologie JavaServlet a WWW prohlížeče na WWW server, kde chceme soubor zpracovat. Lehce prozkoumáme několik architektur existujících web mail systémů. Zaměříme se hlavně na to, jak přistupují do poštovních schránek svých uživatelů a jak předkládají ve schránkách uložené zprávy jejich čtenářům. Druhá část práce je z větší části praktická a věnuje se navržení architektury vlastního web mail systému. Jak už bylo řečeno, bude se tato část zabývat tím, jak vytvořit plně funkční web mail aplikaci na bázi technologie JavaServlet. Povíme si o programování WWW aplikace, která pro práci s elektronickou poštou využívá programové rozhraní JavaMail API a o problémech spojených se čtením i odesíláním elektronické pošty. Krátce naznačíme, jak vlastně obecně pracují servlety a co všechno je nutné udělat pro to, aby na WWW serveru fungovaly tak jak mají. Přijde řeč i na komunikaci servletu s WWW prohlížečem. Ukážeme si, jak říci WWW prohlížeči, že pokud může, má přijímaný soubor přímo zobrazit a jinak nabídnout uživateli např. jeho uložení. Internet vyrůstal zpočátku především v anglickém jazyce, a tudíž jsou mu znaky anglické abecedy nejbližší. Proto jsou s vytvářením WWW aplikací v českém jazyce spojeny určité problémy, kterými se také budeme zabývat. V závěru nahlédneme na používání, tvorbu a administraci jednoduchého web mail systému pro čtení a odesílání elektronické pošty. 1.2 Jazykový koutek (čeština vs. angličtina) Můj každodenní počítačový život se odehrává především v anglickém jazyce, možná právě proto nejsem tolik citlivý na nesprávné používání češtiny. Někdy mi připadá, jako by se lidé chtěli ukázat jako světoběžníci, a proto používají anglické výrazy i tam, kde existuje ekvivalentní český výraz. Proto pokud to bude možné, budu používat českou terminologii. Při prvním použití termínu se budu snažit uvést v závorce i jeho anglický ekvivalent, se kterým se setkáte, když budete číst literaturu v angličtině. Může se stát, že budu používat naprosto vžité a srozumitelné anglicismy (např. web mail nebo servlet). Dopředu se

1.3. Typografické a syntaktické konvence 3 omlouvám všem, kterým se mnou použitý přístup k českému jazyku nelíbí a chci je ujistit, že se ono nesprávné používání češtiny není mým úmyslem. 1.3 Typografické a syntaktické konvence Při vyznačování slov v textu se budeme držet následujících pravidel: neproporcionální písmo (jména souborů a adresářů, URL, výpisy programů, data vkládaná uživatelem, atd.), neproporcionální nepravá italika (klíčová slova související s protokoly), bezpatkové tučné (položky menu a tlačítka formulářů), bezpatkové skloněné (cizojazyčné termíny a slova většinou anglické), tučné písmo (zvýraznění důležitých slov a sousloví), italika (prvně použité termíny, které budou dále vysvětleny). Veškeré odkazy na obrázky (obr.), tabulky (tab.) a přílohy (příl.) jsou tvořeny podle stejného schematu. Pokud tedy za některou z výše uvedených zkratek naleznete např. odkaz [12.3/53], znamená to, že příslušný objekt naleznete na straně 53 v části 12.3.

4 Kapitola 2 Elektronická pošta Elektronická pošta je základní službou počítačových sítí. Její použití je jednoduché, z pohledu uživatele obecně stačí pouze zadat adresu příjemce a napsat text zprávy. Přestože se formáty adres v různých počítačových sítích mohou lišit, je díky tzv. poštovním branám (mail gateways) možné zasílat elektronické zprávy z jedné sítě do druhé. Poštovní brány fungují jako spojky mezi jednotlivými sítěmi. 2.1 Elektronická adresa Každá elektronická zpráva musí obsahovat adresu příjemce. Jestliže má být zpráva doručena na jiný počítač, skládá se tato adresa ze dvou částí: směrové a lokální. Část směrová udává, na který počítač má být elektronická zpráva doručena a lokální část pak určuje, co se má na tomto počítači se zprávou udělat (zpravidla kterému uživateli má být doručena). V síti Internet je základní formát elektronických zpráv a adres stanoven doporučením [RFC822] (zabývá se pouze textovými zprávami, které obsahují sedmibitový ASCII text viz kap. [4/16]). Rozšířením tohoto dokumentu pro zprávy obsahující národní znaky jednotlivých zemí (např. české znaky) a binární soubory je standard MIME (viz kap. [5/19]). Základní tvar elektronických adres je uživatel@host.doména. Směrová část adresy je za znakem @ (host.doména) a bývá tvořena doménovým jménem počítače. Lokální část je před znakem @ (uživatel), zpravidla určuje jméno uživatelského účtu na počítači host.doména. Stále častěji se však v poslední době používají elektronické adresy ve tvaru jméno.příjmení@doména, ve kterých je místo jména účtu použito skutečné jméno uživatele a místo jména počítače jméno domény. Přitom není nutné, aby existoval počítač se jménem doména a na něm poštovní schránka uživatele jméno.příjmení. Jak tedy potom může být elektronická zpráva správně doručena? Ukažme si to na konkrétním příkladě. Mějme zprávu určenou pro adresáta jiri.patera@worldonline.cz. Odesilatel připraví zprávu na svém počítači a odešle ji do Internetu. To znamená, že jeho klientský program předá tuto zprávu, pomocí protokolu SMTP poštovnímu serveru (tomu, který je uveden v jeho konfiguraci). Tento server se podívá na směrovou část adresy

2.2. Poštovní programy MUA a MTA 5 (worldonline.cz) a zeptá se systému doménových jmen (DNS Domain Name System), kam má být doručována elektronická pošta pro doménu worldonline.cz. Odpověď mu může poskytnout pouze jmenný server domény worldonline.cz, na který se SMTP server musí se svým dotazem obrátit (pokud nezná jeho adresu, musí se zeptat nejprve jmenného serveru nadřazené domény, tj. domény.cz). Ve jmenném serveru domény worldonline.cz by měl být uložen tzv. MX záznam (Mail exchange), který vyjadřuje požadovanou informaci v tomto případě informaci, že veškerá pošta adresovaná na doménu worldonline.cz má být doručována na počítač se jménem mail.worldonline.cz. Proto odesílající SMTP server naváže spojení se zjištěným SMTP serverem (mail.worldonline.cz) a elektronickou zprávu mu zašle. Přijímající SMTP server však stále ještě nemusí vědět, kterému konkrétnímu uživateli zpráva patří, a proto se podívá do své tabulky poštovních přezdívek (table of aliases). Tato tabulka obsahuje údaje typu: veškerá elektronická pošta adresovaná uživateli jiri.patera ve skutečnosti patří do poštovní schránky se jménem cz311423. Pokud je vše v pořádku, je elektronická zpráva uložena do příslušné poštovní schránky, v opačném případě je odesílajícímu SMTP serveru sděleno, že adresovaný uživatel nebyl nalezen. Internetové elektronické adresy jsou absolutní (adresa nezávisí na umístění odesilatele vůči příjemci). V sítích UUCP (Unix to Unix Copy Protocol) byly používány adresy ve speciálním tvaru host1!host2!host3!uživatel, které je možné interpretovat jako: zašli elektronickou zprávu přes počítače host1 a host2 uživateli uživatel na počítači host3. Směrová část této elektronické adresy je host1 a lokální pak host2!host3!user. Elektronické adresy v sítích UUCP jsou relativní, jejich směrová a lokální část se mění v závislosti na pozici elektronické zprávy v síti (závisí na umístění odesilatele vůči příjemci). Pokud nefunguje správně systém DNS, lze ve směrové části adresy uvést přímo IP adresu cílového počítače. Oproti jiným programům, kde lze místo jména počítače psát rovnou IP adresu, v elektronické adrese musí být IP adresa uzavřena do hranatých závorek (uživatel@[ipadresa]). 2.2 Poštovní programy MUA a MTA O vlastní přepravu elektronické pošty se odesilatel nemusí vůbec starat, probíhá zcela automaticky a většinou velice rychle. Není nic výjimečného, když odeslaná elektronická zpráva dojde na místo určení během několika desítek vteřin. V případě problémů však doručení může trvat i několik hodin či dnů, neboť neexistuje žádná záruka, že elektronická zpráva bude doručena do určité doby. Ke ztrátám elektronických zpráv může samozřejmě také dojít, i když spolehlivost je v poštovním systému řazena na první místo. 1 Přepravu elektronických zpráv musí zajišťovat počítače, které jsou trvale zapnuté, protože uživatel může svůj počítač vypnout okamžitě po jejich odeslání. Proto jsou programy, které s poštou pracují, rozděleny do dvou skupin: MTA (Mail Transfer Agent) a MUA (Mail 1 Podle mých zkušeností je ztráta elektronické zprávy většinou zaviněna spíše samotným uživatelem, než přepravním systémem.

2.2. Poštovní programy MUA a MTA 6 User Agent). MTA slouží k vlastní přepravě elektronických zpráv, MUA pak k jejich psaní a čtení. Díky tomuto rozdělení si uživatel může vybrat takový MUA, se kterým se mu bude dobře pracovat, nezávisle na tom, jaký MTA zvolí správce sítě nebo uzlu pro přepravu. 2.2.1 Jak funguje MUA MUA (poštovní klient) pracuje samostatně a nezávisle na MTA. Každý uživatel, který chce s elektronickou poštou pracovat, potřebuje kromě MUA ještě poštovní schránku, do které mu MTA bude vhazovat přicházející elektronické zprávy. Když si uživatel poštovního klienta spustí, prohlédne obvykle nejprve svoji poštovní schránku (může jich mít i více) a přečte si nové elektronické zprávy. Po přečtení nebude nejspíše všechny zprávy vyhazovat, ale některé si uschová k pozdějšímu použití. Místo, kam si přečtené elektronické zprávy uloží, může být shodné s místem, kam mu chodí nové zprávy, ale může být i jinde (v jiném adresáři, na jiném počítači). Dopisy není vhodné nechávat volně přístupné, a proto jsou obvykle ukládány na sdílený disk serveru, kde jsou chráněny přístupovým jménem a heslem uživatele. Když na server umístíme MTA, může být na sdílený disk ukládána i nově příchozí elektronická pošta. Tato metoda je pro poštovního klienta pravděpodobně nejjednodušší a nevyžaduje po něm kromě čtení ze sdíleného disku žádné další speciální operace. Část MUA bývá označována jako MRA (Mail Retrieval Agent). MRA zprostředkovává přístup do elektronické poštovní schránky uživatele, umístěné na vzdáleném poštovním serveru. MRA předává elektronické zprávy umístěné ve vzdálené schránce ke zpracování pomocí MUA. 2.2.2 Jak funguje MTA Pro MTA je většinou vyhrazen port číslo 25 (tzv. well-known port), kde MTA jako server očekává příchozí TCP spojení, pomocí kterých přijímá elektronické zprávy odkudkoliv z Internetu. Po přijetí zprávy je adresa příjemce podrobena rozboru, na základě kterého MTA rozhodne o dalším směrování zprávy. Pokud je elektronická zpráva určena pro lokálního uživatele, vyvolá MTA program, který tuto zprávu vloží do příslušné poštovní schránky. Pokud příjemce není lokální, je dopis převeden do fronty, kde čeká na odeslání. Frontu MTA opakovaně prochází v intervalech zadaných při svém startu a pokouší se dosud neodeslané elektronické zprávy doručit. Zpráva ve frontě zůstává po dobu definovanou v konfiguračním souboru daného MTA. Při opakovaném neúspěchu odešle MTA odesilateli nejprve varování, že elektronická zpráva stále leží ve frontě (obvykle čtyři hodiny), ale že ji není zatím potřeba posílat znovu, protože ve frontě zatím zůstává. Po uplynutí dalšího intervalu (obvykle čtyři dny) je celá elektronická zpráva vrácena odesilateli společně s chybovým hlášením. Někdy je možné se ve spojení s MTA setkat i s programem označovaným jako MDA (Mail Delivery Agent). MDA přebírá elektronické zprávy od MTA a ukládá je do poštovních schránek adresátů (mailbox) nebo je předává dalšímu MTA.

2.3. Poštovní klient a server 7 2.3 Poštovní klient a server Vztah mezi MUA a MTA je v podstatě vztahem typu klient-server. Při odesílání elektronické zprávy se MUA postará (v interakci s uživatelem) o její sestavení, ale pak ji předá k odeslání příslušnému MTA (tj. vyžádá si od MTA službu, spočívající v přenosu zprávy). Naopak v okamžiku, kdy se uživatel rozhodne podívat na došlou elektronickou poštu, obrátí se MUA na MTA se žádostí o poskytnutí obsahu příslušné poštovní schránky. Z tohoto důvodu je MUA (uživatelská složka systému elektronické pošty) často označován jako poštovní klient (mail client), zatímco MTA (přenosová složka resp. počítač, na kterém je provozována) jako poštovní server (mail server). Terminologie, kterou jsme až doposud používali, je charakteristická spíše pro systémy elektronické pošty založené na bázi standardu X.400. V prostředí TCP/IP sítí se hovoří spíše o poštovních serverech a klientech.

8 Kapitola 3 Popis protokolů Ve spojení s elektronickou poštou vzniklo několik známých protokolů pro její přepravu a čtení. K přepravě elektronické pošty mezi jednotlivými MTA slouží především protokol SMTP (Simple Mail Transfer Protocol) nebo jeho rozšířená verze ESMTP (SMTP Service Extensions). Dříve, když teprve vznikala elektronická pošta založená na bázi SMTP, se používaly hostitelské počítače a aplikace pracující v režimu host/terminál. To znamená, že poštovní server a poštovní klient běželi na stejném počítači a komunikovali spolu prostřednictvím souborů umístěných na sdíleném disku ve sdílených adresářích. Později, když začalo docházet k osamostatňování poštovních klientů a k jejich stěhování na osobní počítače jednotlivých uživatelů, bylo nutné vymyslet nový způsob jejich komunikace. Původní protokol SMTP bylo možné použít pouze pro jeden směr komunikace, a to pro odesílání (pro předání odesílané elektronické zprávy od poštovního klienta příslušnému poštovnímu serveru). Pro opačný směr komunikace (čtení elektronické zprávy poštovním klientem z poštovního serveru) bylo nutné vyvinout další, pro tuto činnost specializované, protokoly. Vzniklo jich dokonce několik, ale nejvíce se prosadily dva z nich. První, do dnešní doby hodně používaný, je POP3 (Post Office Protocol verze 3) a druhý pak IMAP4 (Internet Message Access Protocol verze 4). 3.1 SMTP protokol Protokol SMTP není jediný protokol pro přenos elektronických zpráv Internetem, je pouze nejvíce rozšířen v počítačových sítích založených na bázi TCP/IP. Jeho předchůdcem, který se stále místy používá, je protokol UUCP. Velice podrobný popis protokolu SMTP viz doporučení [RFC821]. Celou elektronickou zprávu si můžeme představit jako zprávu napsanou na listu papíru a vloženou do obálky. To jak má být zpráva na listu papíru napsána, definuje doporučení [RFC822] viz kap. [4/16], zatímco 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 právě protokolem SMTP, kterým se budeme nyní zabývat.

3.1. SMTP protokol 9 3.1.1 SMTP obálka Pro potřeby přenosu je elektronická zpráva (sestavená podle doporučení v [RFC822]) vložena do jakési pomyslné obálky. Aby tato obálka mohla cestovat mezi odesilatelem a příjemcem, musí na ní vždy být nadepsány alespoň dva základní údaje. Prvním z nich je elektronická adresa původce zprávy (originator) a druhým pak adresa příjemce zprávy (recipient). Je možné na obálku nadepsat i více než jednoho příjemce zprávy. Zpráva pak může být přenesena pouze jednou, ale v místě svého příjmu pak doručena více příjemcům. Další informace, které běžného uživatele mohou zajímat (např. čas a datum odeslání nebo přijetí zprávy, předmět zprávy), jsou součástí samotné elektronické zprávy (jsou napsány na listě papíru uvnitř obálky). Elektronická adresa příjemce nadepsaná na obálce zprávy se nemusí přesně shodovat s hlavním adresátem vlastní zprávy. Důvodem může být např. to, že jedna elektronická zpráva může mít kromě svého hlavního příjemce i několik příjemců její kopie. Když je potom taková zpráva doručována tomuto druhořadému příjemci, je na její obálce jeho elektronická adresa. Dalším důvodem může být používání SMTP protokolu v prostředí Internetu se systémem DNS. 3.1.2 Přenos SMTP obálky Protokol SMTP předpokládá, že obálka i celý její obsah budou přenášeny po takovém spojení, které samo zajistí spolehlivý přenos dat. Nejčastěji bývá toto spolehlivé spojení zajišťováno protokolem TCP (Transmission Control Protocol), ale existují i doporučení, jak provozovat SMTP nad protokolem X.25 (RFC-1090). Data přenášená protokolem SMTP jsou chápána jako textová, členěná do jednotlivých řádek 1 a tvořena pouze dolními 128 znaky ASCII abecedy. Jinými slovy SMTP předpokládá přenos pouze sedmibitových znaků. Pokud se tyto znaky přenášejí transportním kanálem, který je uzpůsoben přenosu osmibitových znaků (což TCP spojení je), pak protokol SMTP definuje, že jeho sedmibitové znaky budou zleva doplněny jedním nulovým bitem. Pro přenos jiných než ASCII znaků (texty s diakritikou, soubory) se jednoduše tyto znaky přetransformují tak, aby měly tvar sedmibitového ASCII textu. Tím je zaručeno, že se správně přenesou. Na druhé straně se potom provede inverzní transformace, která vše vrátí do původního stavu. O tom, jak tyto transformace správně provést, pojednává standard MIME (Multipurpose Internet Mail Extensions) viz kap. [5/19]. Pomyslná obálka protokolu SMTP je také přenášena ve formě textu, a to na začátku přenosu. Komunikace mezi příjemcem (server) a odesilatelem (klient) má formu dialogu. 2 V průběhu dialogu se obě strany informují o své připravenosti k přenosu, pak si předají údaje o odesilateli a příjemci následované samotným obsahem zprávy. 1 Jednotlivé řádky se v SMTP protokolu oddělují výhradně pomocí dvojice znaků CR (Carriage Return) a LF (Line Feed) 2 Když se elektronická zpráva předává mezi dvěma MTA, chová se jeden z nich také jako server (ten, který přijímá) a druhý zase jako klient (ten, který odesílá).

3.2. POP3 protokol 10 3.1.3 Fáze SMTP dialogu Vlastní SMTP dialog má celkem čtyři fáze. První fází tohoto dialogu je samotné navázání spojení. Ten, kdo spojení navazuje, vystupuje jako klient. Klient kontaktuje svůj server na TCP portu číslo 25, který patří mezi tzv. dobře známé porty (well-known ports). Je-li vše v pořádku a server je připraven žádost přijmout, kladně odpoví. Klient na to reaguje tím, že se serveru představí pomocí příkazu HELO. Pokud je server ochoten přijmout elektronickou zprávu od tohoto klienta, odpoví na jeho představení kladně. 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í elektronické adresy odesilatele (příkazem MAIL FROM:) a jedné nebo několika adres příjemců (pomocí příkazu RCPT TO:). Poté již následuje přenos vlastní elektronické zprávy. Ten je ze strany vysílajícího klienta uvozen příkazem DATA. Samotná zpráva, tvořená hlavičkou a tělem, je přenášena po jednotlivých řádkách. Maximální délka přenášené řádky je 1000 znaků. Konec elektronické zprávy je signalizován řádkou, která obsahuje pouze jediný znak tečku. Po úspěšném přenosu celé zprávy pošle server kladné potvrzení a klient ukončí TCP spojení (příkazem QUIT). 3.1.4 ESMTP protokol Hlavní síla protokolu SMTP je v jeho jednoduchosti, ale i přesto se vyskytly požadavky na jeho rozšíření, a proto vznikl protokol ESMTP (SMTP Service Extensions) definovaný v doporučení RFC-1869. ESMTP je zpětně kompatibilní rozšíření protokolu SMTP. Detekce, že daný poštovní server podporuje protokol ESMTP se provádí hned po přijetí uvítací zprávy. Klient namísto příkazu HELO vyšle příkaz EHLO a server podporující protokol ESMTP mu musí odpovědět seznamem podporovaných rozšíření. Mezi rozšíření patří např. možnost nastavit přenos osmibitových dat namísto původních sedmibitových nebo možnost definovat maximální délku přenášené elektronické zprávy a tím předejít potížím, které mohou vzniknout při vyčerpání zdrojů poštovního serveru (vyrovnávací paměť, diskový prostor, atd.). 3.2 POP3 protokol Současně s přestěhováním poštovních klientů na osobní počítače jednotlivých uživatelů došlo i k určitému rozdělení jejich elektronické poštovní schránky. Původně jedna velká schránka, určená jak pro právě došlé a dosud nepřečtené elektronické zprávy, tak i pro zprávy již přečtené, se rozdělila na dvě části. První část je ta, do které se ukládají došlé, ale dosud nevyzvednuté elektronické zprávy (tzv. vzdálená část). 3 Naproti tomu již vyzvednuté 3 Tato část nutně musela zůstat přímo na poštovním serveru, protože je potřebné, aby byla nepřetržitě dostupná (tj. i když uživatel nemá zapnutý počítač, existuje místo, kam se mu ukládají nově příchozí elektronické zprávy).

3.2. POP3 protokol 11 zprávy, které si uživatel načetl z poštovního serveru k sobě např. pomocí protokolu POP3, se hromadí u něho na počítači ve druhé (tzv. lokální) části jeho poštovní schránky. Nyní je zřejmé, že např. majitelé přenosných počítačů se mohou odkudkoliv připojit k Internetu a pomocí protokolu POP3 si načíst do svého počítače čerstvě došlé elektronické zprávy ze svého poštovního serveru. Po jejich načtení se mohou od Internetu odpojit a zpracovávat je lokálně (bez nutnosti připojení k Internetu). Odesílání elektronických zpráv z klienta není obsahem specifikace POP3 protokolu, obvykle se řeší tím, že klient navazuje TCP spojení přímo s nějakým SMTP serverem. Veškeré podrobnosti týkající se POP3 protokolu lze nalézt v [RFC1939]. 3.2.1 Komunikace klient/server Veškerá komunikace prostřednictvím protokolu POP3 odpovídá modelu klient/server. Serverem je v tomto případě počítač, který spravuje uživatelskou poštovní schránku. Klientem je pak počítač uživatele, který chce do své schránky přistoupit a načíst si z ní nové elektronické zprávy. Všechny elektronické zprávy přepravované pomocí POP3 protokolu v průběhu TCP spojení mezi klientem a serverem musí dodržovat formát textových zpráv specifikovaný v doporučení [RFC822]. Server zahajuje službu POP3 tím, že naslouchá na TCP portu číslo 110. Když chce klient jeho služeb využít, naváže s ním na daném portu TCP spojení. Jakmile klient úspěšně naváže s poštovním serverem TCP spojení, obdrží od něho uvítací zprávu, po které může se serverem zahájit dialog. Dialog je tvořen výměnou požadavků (POP3 příkazů, které zasílá klient na server) a odpovědí (hlavičky a těla elektronických zpráv, které zasílá server klientovi). Pomocí POP3 příkazů si klient může na serveru např. vyžádat zaslání počtu uložených elektronických zpráv, smazání určité zprávy, atd. Odpovědi na žádosti klienta mohou být následovány informativní větou a jsou buď kladné (uvozeny znaky +OK), nebo záporné (uvozeny znaky -ERR). Většinou jsou odpovědi pouze jednořádkové, ale některé mohou být i víceřádkové a potom musí být ukončeny znakem tečky na samostatné řádce (stejně jako tělo elektronické zprávy odesílané pomocí SMTP protokolu). 3.2.2 Základní operace POP3 server prochází v průběhu komunikace s poštovním klientem několika stavy. Když je TCP spojení úspěšně navázáno a POP3 server zaslal klientovi uvítací zprávu, přechází do tzv. autorizačního stavu (authorization state). V autorizačním stavu se musí klient autentizovat (prokázat, že vlastní poštovní schránku na daném POP3 serveru). Nejčastěji to dělá pomocí uživatelského jména (username) a hesla (password), která předá serveru pomocí příkazů USER a PASS. Stejně jako jméno, předává se i heslo v otevřené podobě, což není z hlediska bezpečnosti dobré. Proto byl protokol POP3 rozšířen o příkaz APOP, pomocí kterého lze heslo zasílat zašifrované algoritmem MD5. Tomuto příkazu rozumí pouze takové POP3 servery, které zasílají společně s uvítací zprávou i speciální časové razítko, za které se heslo přidá ještě před aplikací šifrovacího algoritmu MD5.

3.3. IMAP4 protokol 12 Pokud byl klient úspěšně ověřen, přechází POP3 server do tzv. transakčního stavu (transaction state), ve kterém může klient zasílat POP3 serveru různé POP3 příkazy. Nejznámější z nich jsou STAT (STATistic vrátí počet a velikost všech zpráv ve schránce dohromady), LIST (vypíše čísla a velikosti jednotlivých elektronických zpráv), DELE (DELEte označí jednu určenou zprávu jako smazanou) 4, RETR (RETRieve zobrazí vybranou elektronickou zprávu včetně všech jejích položek hlavičky), RSET (ReSET odznačí všechny elektronické zprávy označené jako smazané). Každá elektronická zpráva má na POP3 serveru přiřazeno unikátní číslo, které se v čase nemění (ani mezi jednotlivými poštovními relacemi). To je důležité pro jednoznačnou identifikaci zprávy, aby např. nedocházelo k jejímu několikanásobnému doručení při nekorektním ukončení poštovní relace. Jak je zřejmé, používají poštovní klienti pro přepravu elektronických zpráv ze vzdálené poštovní schránky do lokální výhradně příkaz RETR. Z transakčního stavu může server přejít už jen do stavu aktualizace (update state), a to pomocí příkazu QUIT. V tomto stavu uvolňuje POP3 server všechny zdroje, které používal v transakčním stavu. Také jsou v tomto stavu nenávratně smazány všechny elektronické zprávy označené ke smazání pomocí příkazu DELE. Poslední akcí serveru po příkazu QUIT je zrušení navázaného TCP spojení. 3.3 IMAP4 protokol Protokol POP3 (viz [3.2/10] nebo [RFC1939]) byl navržen tak, aby umožňoval pouze operace potřebné pro přepravu elektronické pošty z poštovního serveru ke klientovi a při tom byl co možná nejjednodušší. Obsahuje tedy pouze minimální množinu operací (příkazů) potřebných pro manipulaci s elektronickými zprávami na poštovním serveru. Se zvyšujícími se nároky pro vzdálenou manipulaci s elektronickými zprávami byl vyvinut mnohem rozsáhlejší protokol IMAP4 (Internet Message Access Protocol verze 4), který je detailně popsán v doporučení [RFC2060]. 3.3.1 Komunikace klient/server Server zahajuje IMAP4 službu tím, že naslouchá na TCP portu číslo 143. Když chce klient jeho služeb využít, naváže s ním na tomto portu TCP spojení. Jakmile klient úspěšně naváže s IMAP4 serverem spojení, obdrží od něho uvítací zprávu, po které může se serverem zahájit dialog. Komunikace probíhá jako sekvence příkazů klienta a odpovědí serveru (dialog). Každému příkazu klienta musí předcházet řetězec znaků nazývaný tag (např. A123 ). Tento tag slouží k identifikaci odpovědi serveru a měl by být pro každý IMAP4 příkaz v rámci jedné poštovní relace jiný. Každá odpověď serveru je uvozena zmíněným tag em, který je povinnou součástí každého příkazu klienta. Potom následuje řetězec OK, pokud byl příkaz proveden v pořádku nebo řetězec NO, pokud došlo k chybě, popř. řetězec BAD pokud je příkaz (nebo jeho argumenty) neznámý. IMAP4 server může zasílat klientovi i odpovědi, 4 Takto označenou zprávu nebude POP3 server klientovi nikde zobrazovat (ani po příkazu LIST).

3.3. IMAP4 protokol 13 které si přímo nevyžádal, např. informace o nově příchozí elektronické zprávě v poštovní schránce. 3.3.2 Základní operace V každém okamžiku se IMAP4 server nachází v jednom ze tří stavů. Pro každý stav je definována určitá množina příkazů, které v něm lze používat. Když je TCP spojení navázáno a IMAP4 server zaslal klientovi uvítací zprávu, přechází do stavu, kdy ještě uživatel neprokázal, že na serveru vlastní poštovní schránku (nonauthenticated state). Uživatel se tedy musí nějak prokázat. Nejčastěji to dělá (stejně jako u komunikace s POP3 serverem) pomocí uživatelského jména a hesla, která předá serveru pomocí příkazu LOGIN. Stejně jako jméno, předává se i heslo v otevřené podobě, což není z hlediska bezpečnosti dobré. Na to samozřejmě pamatuje i protokol IMAP4 a nabízí ověřování uživatele pomocí různých mechanismů (např. kerberos). Podle uvítací zprávy by měl klient poznat, jaké ověřovací mechanismy server podporuje a pak pomocí příkazu AUTHENTICATE může zahájit proces ověřování uživatele v zabezpečené podobě. Úspěšným ověřením uživatele přechází IMAP4 server do dalšího stavu (authenticated state). Protokol IMAP4 umožňuje uživateli vytvářet poštovní složky (mailbox, folder) obsahující jednotlivé elektronické zprávy popř. další poštovní složky. Obecně se tedy jedná o hierarchickou strukturu, 5 konkrétní možnosti seskupování složek a zpráv však záleží na dané implementaci IMAP4 serveru. 6 V tomto stavu může uživatel manipulovat se složkami (vybírat, vytvářet, rušit, přejmenovávat, atd.). Avšak to hlavní, co je od něho očekáváno je otevření libovolné dostupné složky, a to buď pouze pro čtení (příkaz EXAMINE), nebo pro čtení a zápis (příkaz SELECT). Po otevření složky server přechází do dalšího stavu (selected state). IMAP4 protokol umožňuje označovat elektronické zprávy několika příznaky (nová, přečtená, smazaná, atd.). 7 Je dobré zdůraznit, že pro permanentní smazání zprávy je nutné ji nejprve označit jako smazanou a po té následně v dané složce vyvolat příkaz EXPUNGE. Při vstupu do složky s elektronickými zprávami IMAP4 server vypíše jejich počet. Klient si pak může vyžádat libovolnou zprávu pomocí příkazu FETCH [číslo] rfc822. Tento stav slouží i ke kopírování elektronických zpráv do jiných složek anebo k vyhledávání v nich pomocí různých kritérií. Do předchozího stavu se lze navrátit příkazem CLOSE, který uzavře aktuální poštovní složku. Existuje několik příkazů, které lze použít v libovolném stavu. Nejpoužívanějším z nich je příkaz LOGOUT, který slouží k ukončení TCP spojení s IMAP4 serverem. 5 Tato struktura je často velice podobná běžnému souborovému systému. 6 Existují implementace IMAP4 serverů, které umožňují uživateli do složek ukládat jak zprávy, tak další složky. Ale také existují implementace, které nedovolí mít ve složce se zprávami další složky. 7 To POP3 protokol vůbec neumožňuje, např. po označení zprávy ke smazání se s ní nedá nijak manipulovat (lze pouze najednou obnovit všechny zprávy označené ke smazání) viz [3.2.2/11].

3.4. HTTP protokol 14 3.4 HTTP protokol Pro správné fungování služby WWW (World Wide Web) je nutné nejen to, aby byl popsán obsah jednotlivých WWW stránek (k čemuž slouží jazyk HTML). Další nutností je komunikace mezi WWW serverem, na kterém jsou jednotlivé WWW stránky ve svém HTML tvaru uloženy, a mezi WWW prohlížečem (WWW browser) spuštěném přímo u uživatele na jeho počítači. WWW server se při této komunikaci chová pasivně a pouze čeká, až ho nějaký prohlížeč požádá o určitou WWW stránku, kterou mu pak pošle. K tomu je ale nutná určitá dohoda, podle které WWW prohlížeč vznáší svůj požadavek, a podle které pak WWW server na něj reaguje. Touto dohodou je přenosový protokol HTTP (Hyper- Text Transfer Protocol), podle kterého komunikace mezi WWW serverem a prohlížečem probíhá. Pro samotný HTTP protokol je vyhrazen TCP port 80. 3.4.1 Metody GET a POST O dynamické generování WWW stránek se stará většinou nějaký program, který je spuštěn na straně WWW serveru. Tento program generuje WWW stránky na základě nějakých vstupních parametrů, které může dostávat od WWW prohlížeče dvěma metodami. Každá z těchto metod má své výhody a nevýhody. Každá WWW stránka v Internetu je jednoznačně adresovatelná pomocí své adresy tzv. URL (Uniform Resource Locator). První metodou pro přenos parametrů od WWW prohlížeče (klienta) k WWW serveru je HTTP metoda GET. Mezi její výhody patří to, že ze strany prohlížeče se dá použít u jakéhokoliv hypertextového odkazu (link). Všechna data (z formuláře nebo ze speciálně vygenerovaného odkazu) se tedy pomocí metody GET zasílají na WWW server, na kterém se daná WWW stránka nachází. Jednotlivé parametry jsou předávány ve formě jméno=hodnota. Od URL se oddělují znakem? a vzájemně od sebe jsou odděleny znakem &. Aby to nebylo tak jednoduché, jsou speciální znaky, které se vyskytují v hodnotách proměnných zakódovány. Mezera se kóduje jako znak +, interpunkční znaménka apod. se kódují jako %HH, kde HH je dvouciferná hexadecimální hodnota ASCII kódu znaku. 8 Odkaz, pomocí kterého lze programu jmservlet předat dva parametry, pak může vypadat třeba následovně: http://ds04.fav.zcu.cz/gp/jmservlet?polozka1=data1&polozka2=data2 Metoda GET není vhodná hned z několika důvodů. Například pokud požadujeme na uživateli jméno a heslo, je při přenosu sítí viditelné v URL. Další nevýhodou je, že protokol HTTP nepodporuje nekonečně dlouhé URL adresy, a proto je velikost přenášených dat omezená. V určitých případech je také na škodu zmíněné kódování speciálních znaků v URL (např. při přenosu dat binárního charakteru souborů). HTTP metoda POST odstraňuje uvedené nevýhody metody GET. Její nevýhodou je ale to, že data musí pocházet z nějakého HTML formuláře. Nelze je tedy zaslat např. pomocí výše uvedeného dynamicky vygenerovaného odkazu. 8 Nyní je zřejmé, že znak mezery lze zakódovat dvěma způsoby. Buď jako zmíněné +, nebo jako trojici znaků %20.

3.5. Bezpečnost protokolů aplikační úrovně 15 3.5 Bezpečnost protokolů aplikační úrovně Vzhledem k různým způsobům využívání služeb WWW je stále více požadováno zabezpečení přenášených informací. Bez tohoto zabezpečení by bylo velice riskantní používat WWW např. v elektronickém obchodování. V současné době se pro zabezpečení HTTP přenosů v Internetu používá SSL (Secure Socket Layer). Tato bezpečená komunikace se běžně označuje jako HTTPS (HyperText Transfer Protocol Secure). Pro bezpečnou komunikaci prostřednictvím HTTPS (HTTP over SSL) je vyhrazen TCP port 443. SSL šifruje data přenášená pomocí protokolů aplikační úrovně, řeší tedy bezpečnost sady protokolů TCP/IP a poskytuje bezpečný komunikační kanál mezi dvěma počítači v Internetu na úrovni TCP spojení. Tím SSL umožňuje bezpečnou implementaci různých protokolů aplikační úrovně (např. HTTP, FTP, TELNET). SSL šifruje přenášená data pomocí algoritmu DES nebo RSA. Podpora zabezpečení pomocí SSL musí být implementována jak na straně WWW serveru (např. Apache, Tomcat), tak i na straně klienta ve WWW prohlížeči (např. Explorer, Netscape). Stejně jako mezi WWW prohlížečem a WWW serverem jsou běžně data přenášena v otevřené podobě, jsou tak přenášena i mezi poštovním klientem a serverem (ať už jím je SMTP, ESMTP, POP3 nebo IMAP4 server). Jediné, co lze před potenciálním útočníkem běžně utajit, jsou přihlašovací údaje (uživatelské jméno a heslo). To se provádí voláním k tomu určených příkazů (pro POP3 protokol je to příkaz APOP a pro IMAP4 protokol příkaz AUTHENTICATE viz [3.2.2/11] a [3.3.2/13]). Ale právě díky SSL je možné šifrovat veškerou komunikaci mezi poštovním klientem a serverem, protože tato komunikace probíhá pomocí TCP protokolu. K tomuto šifrování však musí být přizpůsoben jak poštovní server, tak i klient.

16 Kapitola 4 Internetové textové zprávy V této kapitole budeme opět vycházet z představy, že elektronická zpráva je jako list papíru a je přenášena v obálce (envelope). Na pomyslném listu papíru je vlastní obsah zprávy tzv. tělo (body) a její hlavička (header). Tento list papíru je vytvořen uživatelským programem MUA. Když ho MUA předá přenosovému programu MTA k odeslání, vloží ho MTA do obálky a na ni nadepíše údaje potřebné pro její přenos. MTA pak také zajistí 1 přenos obálky Internetem. Při sestavování údajů, které budou na obálce, vychází MTA z údajů zapsaných v hlavičce zprávy (např. údaje o odesilateli a příjemci). Proto musí MTA rozumět formátu, podle kterého je zpráva sestavena. Tento formát Internetových textových zpráv je podrobně popsán v doporučení [RFC822]. Nápisy na obálce a její přenos se řídí protokolem SMTP viz [3.1/8]. 4.1 Formát elektronické zprávy Každá elektronická zpráva se podle [RFC822] skládá z řádek textu v ASCII kódu. Tyto řádky jsou zakončeny dvojicí znaků CR a LF. Elektronická zpráva obsahuje hlavičku a nepovinné tělo. Tělo zprávy je od hlavičky odděleno jednou prázdnou řádkou. 4.1.1 Hlavička elektronické zprávy Hlavička elektronické zprávy se skládá z položek, jejichž pořadí není přesně stanoveno. Každá položka hlavičky se skládá ze jména a obsahu (jsou od sebe odděleny dvojtečkou). Jméno položky musí být vždy na začátku řádky. Položka může být rozdělena i na několik řádek. 2 Hlavička obsahuje strukturované a nestrukturované položky. Nestrukturované nemají žádný pevný formát (např. předmět zprávy subject). Strukturované mají definován určitý formát, aby mohly být různými počítači snadno zpracovány (např. adresa odesila- 1 Zde by možná bylo vhodnější použít termín zahájí, protože na přenosu zprávy se většinou podílí více programů MTA. 2 Tyto řádky pak musí začínat nějakým bílým znakem (např. mezerou nebo tabulátorem), aby nemohlo dojít k záměně jména a obsahu položky.

4.1. Formát elektronické zprávy 17 tele nebo příjemce). Význam zajímavých položek hlavičky se pokusí vysvětlit následujících několik odstavců. Jak elektronická zpráva putuje mezi jednotlivými MTA, každý z nich do ní zaznamenává (za klíčové slovo Received:) 3 svoji adresu (buď IP adresu anebo doménové jméno), adresu zdrojového MTA (od kterého zprávu přijal), datum a čas přijetí zprávy, protokol, atd. Přijatá elektronická zpráva obsahuje často v hlavičce několik těchto položek a podle nich lze přesně určit, odkud a kudy zpráva putovala a také kde se nejvíce zdržela. Kdyby bylo nutné dohledávat určitou elektronickou zprávu v případě potíží, existuje položka hlavičky, která obsahuje jednoznačnou identifikaci zprávy v celém Internetu, jmenuje se Message-Id:. Dále samozřejmě hlavička elektronické zprávy obsahuje adresy, jejichž přehled ukazuje tab. [4.1/17]. Samotné [RFC822] myslí i na přeposílání elektronických zpráv bez úprav, a proto může všechny položky uvedené v tab. [4.1/17] (a položku Message-Id: také) předcházet řetězec Resent-. Uveďme si např. položku Resent-From:, která říká, že tato elektronická zpráva byla přeposlána odesilatelem uvedeným za položkou Resent-From:, přičemž odesilatel původní (originální) zprávy je uveden za položkou From:. Předmět elektronické zprávy se udává za položku Subject: hlavičky. Po předmětu elektronické zprávy obvykle následuje její tělo, které může být pro utajení přenášených informací zašifrováno. Aby to bylo příjemci (a jeho poštovnímu klientovi) naznačeno, existuje položka hlavičky Encrypted:, za kterou následuje název programu (případně i algoritmu), jenž tělo zprávy zašifroval. Položka From: Sender: Reply-To: To: CC: BCC: Typ elektronické adresy Adresa autora zprávy (tj. osoby/účtu, ze kterého zpráva přišla) Adresa odesilatele zprávy (např. když odesilatel není autor zprávy) Adresa pro odpověď na tuto zprávu (např. pokud odpovědi zpracovává jiná osoba než odesilatel nebo autor) Adresa příjemce zprávy (komu je zpráva primárně určena) Adresa příjemce kopie zprávy Carbon Copy (komu je zpráva zaslána pouze informativně) Adresa příjemce slepé kopie zprávy Blind Carbon Copy (příjemci To: a CC: v hlavičce zprávy nevidí adresu příjemce BCC:) Tabulka 4.1: Položky hlavičky elektronické zprávy a jim příslušející typy elektronických adres Také je možné si pro potřeby komunikace (např. mezi poštovními klienty) vytvářet tzv. uživatelské položky hlavičky. Jejich jména musí začínat řetězcem X- a je zajištěno, že takovéto položky nebudou nikdy použity v žádném případném rozšíření doporučení [RFC822]. Příkladem může být položka hlavičky X-Sender:, za kterou následuje obvykle popis programu, jenž elektronickou zprávu sestavil a odeslal do Internetu. 3 Toto klíčové slovo je vlastně název položky hlavičky.