1 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 j...
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.
2 Elektronická pošta 2.1 Elektronická adresa . . . . 2.2 Poštovní programy MUA a 2.2.1 Jak funguje MUA . 2.2.2 Jak funguje MTA . 2.3 Poštovní klient a server . .
Jména MIME položek hlavičky a jejich popisy . . . . . . . . Typy kódování dat těla zprávy a jejich popisy . . . . . . . . Jednoduché MIME typy, jejich nejčastější podtypy a popisy Složené MIME typy, jejich podtypy a popisy . . . . . . . . .
20 20 22 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ž[email protected]é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 [email protected]. 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
2.3
7
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
3.1.1
9
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 řádek1 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
3.1.3
10
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. 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]. 6
3.4. HTTP protokol
3.4
14
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 (HyperText 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ě
3.5
15
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 odesila1
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
Typ elektronické adresy
From: Adresa autora zprávy (tj. osoby/účtu, ze kterého zpráva přišla) Sender: Adresa odesilatele zprávy (např. když odesilatel není autor zprávy) Reply-To: Adresa pro odpověď na tuto zprávu (např. pokud odpovědi zpracovává jiná osoba než odesilatel nebo autor) To: Adresa příjemce zprávy (komu je zpráva primárně určena) CC: Adresa příjemce kopie zprávy – Carbon Copy (komu je zpráva zaslána pouze informativně) BCC: 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.
4.1. Formát elektronické zprávy
4.1.2
18
Tělo elektronické zprávy
Tělo elektronické zprávy je tvořeno řádkami ASCII znaků (ACSII textem), které jsou ukončeny dvojicí znaků CR a LF. Délka každé řádky nesmí překročit 998 znaků (1000 znaků dohromady se znaky CR a LF). Žádná další struktura těla elektronické zprávy není definována. Omezení délky řádky souvisí s přepravovacími schopnostmi protokolu SMTP – viz [3.1.3/10].
4.1.3
Formát elektronické adresy
Doporučení [RFC822] také stanovuje přesný formát elektronických adres, které mohou být použity při odesílání elektronických zpráv do Internetu. O tom, co je to lokální a směrová část adresy jsme již hovořili. Zde pouze poznamenejme, že každá elektronická adresa může navíc obsahovat i tzv. osobní jméno (personal name), které ji doprovází na cestě Internetem. Následující čtyři adresy jsou totožné a každá elektronická zpráva na ně zaslaná dojde stejnému uživateli. Ještě poznamenejme, že veškeré údaje spojené s hlavičkou elektronické zprávy (tedy i celé jméno a příjmení) musí být podle [RFC822] napsány pouze pomocí v sedmibitového ASCII textu (tedy bez diakritiky). Tento nedostatek odstraňuje rozšíření nazývané MIME – viz kap. [5/19]. Následující výpis ukazuje, jak mohou vypadat elektronické adresy v hlavičkách elektronických zpráv. [email protected][email protected] (Jiri Patera) Jirka Patera <[email protected]> "Patera, Jiri" <[email protected]>
19
Kapitola 5 Popis rozšíření MIME Samotné doporučení [RFC822] pochází z roku 1982. S postupem času mnohonásobně vzrostl nejen Internet jako takový, ale také počet jeho uživatelů z nejrůznějších koutů naší planety. Jednoduchý a dlouho uznávaný model přestal stačit a začala se navrhovat a uplatňovat jeho rozšíření.
5.1
Hlavní rozšíření pro elektronické zprávy
Jako nejvíce omezující faktory doporučení [RFC822] se ukázaly tyto: 1. Tělo elektronické zprávy i položky její hlavičky musí být pouze v prostém ASCII textu, a proto není umožňěn přenos národních abeced (např. češtiny). 2. Tělo elektronické zprávy musí být prostý ASCII text, proto není možné přenášet žádné soubory (např. obrázky nebo programy). 3. Rovněž není možné přenášet více elektronických zpráv najednou (např. je zapouzdřit do jedné velké elektronické zprávy). A právě zmíněná tři omezení odstraňuje standard MIME (Multipurpose Internet Mail Extensions), který výrazně změnil využívání elektronické pošty v Internetu. Detailní popis všech jeho vymožeností je uveden celkem v pěti dokumentech [RFC2045], [RFC2046], [RFC2047], RFC-2048 a RFC-2049.1
5.2
Základní princip MIME
Základní princip MIME je poměrně jednoduchý: osmibitová data jsou překódována do sedmibitových ASCII znaků, které již mohou být přenášeny protokolem SMTP (viz [3.1/8] nebo dokument [RFC821]) podobně jako původní elektronické zprávy ve formátu popsaném v doporučení [RFC822] – viz kap. [4/16]. 1
Doporučení RFC-2048 se týká možností a pravidel, podle kterých je možné MIME dále rozšiřovat. Příklady různých elektronických zpráv využívajících MIME jsou shromážděny v RFC-2049.
5.3. Nové položky hlavičky elektronické zprávy
5.3
20
Nové položky hlavičky elektronické zprávy
MIME znatelně rozšiřuje položky hlavičky elektronické zprávy definované v [RFC822]. Tabulka [5.1/20] shrnuje základní vlastnosti nových položek hlavičky. Hlavička
Popis
Říká, že daná zpráva odpovídá standardu MIME. Popisuje obsah těla zprávy. Tato položka by měla identifikovat obsah dostatečně přesně, aby se MUA mohl správně rozhodnout, jak zpracuje tělo zprávy (např. text/plain nebo img/jpeg). Content-ID: Slouží jako odkaz na výskyt zprávy (podobně jako položka hlavičky Message-Id: – viz kap. [4/16]). Content-Description: Popisuje slovně tělo zprávy (tato hlavička je nepovinná). Content-Transfer-Enconding: Říká, jakým způsobem je tělo zprávy zakódované. MIME-Version: Content-Type:
Tabulka 5.1: Jména MIME položek hlavičky a jejich popisy
5.4
Položka hlavičky Content-Transfer-Encoding
První tři kódování uvedená v tab. [5.2/20] vyjadřují identitu (není pro ně potřeba žádné kódování a dekódování pomocí speciálních algoritmů), zatímco následující dvě kódování uvedená v tab. [5.2/20] slouží pro již zmiňovanou transformaci osmibitových dat na sedmibitová a provádí se pomocí speciálních (veřejně dostupných) algoritmů. Kódování
Data těla zprávy
Tělo zprávy tvoří řádky sedmibitového ASCII textu. Tato hodnota je implicitně použita, pokud hlavička neobsahuje položku Content-Transfer-Encoding:. 8bit Stejně jako 7bit, ale v těle zprávy mohou být obsaženy i znaky s ASCII hodnotou vyšší než 127. binary Tělo je libovolná sekvence bajtů. base64 Tělo je kódováno pomocí base64. quoted-printable Tělo zprávy je kódováno jako quoted-printable. 7bit
Tabulka 5.2: Typy kódování dat těla zprávy a jejich popisy
5.5. Hodnoty položky hlavičky Content-Type
21
Pozor při přenosu elektronické zprávy s kódováním 8bit Internetem, protože není zaručeno, že všechny přenosové cesty umí přenášet osmibitová data.
5.4.1
Kódování quoted-printable
Toto kódování je určeno pro texty, které obsahují převážně ASCII znaky z dolní poloviny ASCII tabulky. Zakódovaný text je částečně čitelný i pomocí MUA, který nepodporuje rozšíření MIME. Text těla elektronické zprávy je kódovaný zhruba následovně: 1. Téměř libovolný bajt (byte) může být zakódován jako znak = následovaný dvěmi hexadecimálními číslicemi (0-9, A-F). 2. ASCII znaky s hodnotami 33–60 a 62–126, stejně jako znaky pro konec řádky (CR a LF), se kódovat nemusí. 3. Bílé znaky s hodnotami 9 a 32 mohou být reprezentovány jako tabulátor a mezera, pokud nejsou na konci řádky. 4. Kódování transformuje vstup na řádky, které jsou vždy kratší než 76 znaků. Každá delší řádka textu musí být zalomena. Zalomení se indikuje znakem = na konci řádky. Příklad: Výsledkem zakódování jednoduchého textu „Často píšete česky?ÿ pomocí kódování quoted-printable je řetězec „=C8asto p=ED=B9ete =E8esky=3Fÿ.
5.4.2
Kódování base64
BASE64 je kódování určené hlavně pro obecná binární data. Princip je podobný jako u kódovacího programu uuencode. Libovolná binární data jsou rozdělena na skupiny po třech bajtech (3 × 8 = 24 bitů). Každá taková trojice bajtů je dále rozdělena na čtyři části po šesti bitech a každá z těchto šestibitových částí reprezentuje číslo v rozmezí 0–63, kterému je přiřazen jeden ze znaků (a-z, A-Z, 0-9, +, /). Libovolnou trojici bajtů jsme tedy převedli na čtveřici ASCII znaků, které už mohou být součástí elektronické textové zprávy odpovídající doporučení [RFC822]. Maximální délka řádky je opět stanovena na 76 znaků. Speciálně se ošetřuje konec kódovaného řetězce znaků, pokud není jeho délka dělitelná třemi. K tomu se používá znak =, blíže viz [RFC2045]. Příklad: Výsledkem zakódování jednoduchého textu „Často píšete česky?ÿ pomocí kódování base64 je řetězec „yGFzdG8gcO25ZXRlIOhlc2t5Pw==ÿ.
5.5
Hodnoty položky hlavičky Content-Type
Typ obsahu (content type) těla elektronické zprávy se uvozuje položkou Content-Type:. Jedná se o položku MIME hlavičky, která se skládá ze dvou částí. První část (hlavní typ)
5.5. Hodnoty položky hlavičky Content-Type
22
určuje obecně o jaká data se jedná (text, obrázek, zvuk) a druhá část (podtyp) potom určuje formát dat (pro obrázek např. jpeg, png, gif). V dokumentu [RFC2046] je definováno pět jednoduchých typů a dva složené typy. Kromě těchto typů existuje i několik dalších, dodatečně definovaných typů (např. multipart/related pro různá data, která spolu nějak souvisí – kompletní WWW stránka obsahující text i obrázky, podrobnosti lze nalézt v dokumentu RFC-2387).
5.5.1
Jednoduché typy
Pro jednoduché MIME typy platí, že v těle elektronické zprávy jsou přímo uložena data daného typu zakódovaná pro přenos příslušným způsobem (kódováním quoted-printable nebo base64). Pět jednoduchých typů, které jsou definovány v [RFC2046] popisuje stručně tab. [5.3/22].
Typ
Popis
Je určen pro prostý text. Nepovinný parametr charset umožňuje zadat znakovou sadu těla zprávy (např. pro češtinu by obsahoval hodnotu ISO-8859-2). Nejpoužívanější podtypy jsou text/plain (prostý text) nebo text/html (přenášená zpráva vytvořená v jazyce HTML). image Reprezentuje obrázky (např. image/jpeg). audio Reprezentuje audio data (např. audio/basic). video Reprezentuje video data (např. video/mpeg). application Reprezentuje data nespadající do žádné z předchozích kategorií, speciálně různé binární formáty souborů (např. application/postscript nebo application/octet-stream – obecně neurčený formát). text
Tabulka 5.3: Jednoduché MIME typy, jejich nejčastější podtypy a popisy
5.5.2
Složené typy
Protože bylo MIME navrhnuto pro přenos libovolně strukturovaných dat, existují tzv. složené typy. Tyto typy umožňují do jednoho těla elektronické zprávy umístit několik jiných elektronických zpráv, a to i rekurzivně v několika úrovních. Jednotlivé vložené elektronické zprávy (popř. soubory) se oddělují speciálním řetězcem (tzv. boundary string ), který se nesmí vyskytovat v textu žádné z nich. Tento řetězec je uveden jako parametr boundary= v položce hlavičky Content-Type:. Dva složené MIME typy a jejich podtypy jsou podrobně definovány v [RFC2046], jejich stručný přehled uvádí tab. [5.4/23].
5.6. Obsah položek hlavičky elektronické zprávy
Typ/podtyp
23
Popis MIME typu
Slouží jako obálka pro několik vkládaných příloh. Musí být vždy kódován jako 7bit, 8bit nebo binary. multipart/mixed Obaluje jednu nebo více příloh (popř. zpráv). Typ těchto zpráv je určen v jejich hlavičkách. multipart/alternative Podobně jako mixed, ale jednotlivé zprávy mají stejný obsah, liší se pouze formou (např. obrázek v různých formátech). multipart/digest Obaluje několik zpráv (typu message/rfc822). multipart/parallel Říká, že obsah jednotlivých zpráv by měl být zobrazen současně (např. podtypy audio a video). message Vztahuje se vždy k tělu jedné zprávy. message/rfc822 Obsahuje vloženou zprávu ve formátu popsaném v [RFC822] nebo jeho rozšíření (může tedy obsahovat např. opět MIME zprávu). message/partial Umožňuje rozdělit velmi dlouhou zprávu na několik kratších, které budou přeneseny a po příjmu opět sestaveny. Tento podtyp nesmí být kódován jinak než 7bit. message/external-body Říká, že tělo není součástí zprávy, ale je umístěno někde externě (např. na FTP serveru). Parametry podtypu pak určují přesné umístění a způsob přístupu k tělu zprávy multipart
Tabulka 5.4: Složené MIME typy, jejich podtypy a popisy
5.6
Obsah položek hlavičky elektronické zprávy
Podobně jako v těle elektronické zprávy sestavené podle doporučení [RFC822], je i v její hlavičce velkým omezením používání pouze sedmibitových ASCII znaků, zejména pro neanglicky mluvící (a také píšící) země. To vedlo k úpravě formátu položek hlavičky popsaných v [RFC822]. V obsahu položky může být místo ASCII znaků speciální zakódovaná sekvence ve tvaru: „=?znaková sada?kódování?vlastní text?=ÿ. V této sekvenci je znaková sada názvem použité národní tabulky znaků (např. pro češtinu to může být hodnota ISO-8859-2), hodnota kódování je buď písmeno Q pro kódování quoted-printable (viz [5.4.1/21]), nebo písmeno B pro kódováníbase64 (viz [5.4.2/21]). Pak už následuje vlastní text, což je text v daném národním kódování.
24
Kapitola 6 Architektury existujících systémů V dnešní době existuje na Internetu celá řada programů pro čtení a psaní elektronických zpráv. Uživatelé si mohou vybrat právě ten program, který jim nejlépe vyhovuje. Programy jsou vytvářeny pro různé operační systémy a pro textová i grafická prostředí. Zvláštním druhem těchto aplikací pro čtení a psaní elektronické pošty je právě web mail. Jedná se o aplikaci, která je určitým způsobem spojena s WWW serverem. Uživatelé k ní mají přístup pomocí WWW prohlížeče, který se postupně stává nedílnou součástí většiny operačních systémů. Kromě známých grafických WWW prohlížečů (např. IE, Netscape) existují i tzv. textové WWW prohlížeče (např. lynx, links). A zde je vidět velká výhoda web mail aplikací. Pokud totiž využívají pro interakci s uživatelem právě WWW rozhraní, jsou dostupné téměř ze všech operačních systémů (ať už v grafickém nebo textovém módu), a to pro uživatele z celého světa. V následujícím textu se budeme zabývat architekturami existujících web mail systémů. Přestože je na Internetu dostupné velké množství web mail aplikací, není snadné nalézt podrobné popisy jejich architektur. Proto jsou popisy architektur nalezených web mail systémů spíše ilustrativní než vyčerpávající.
6.1
EMU Webmail
EMU Webmail je WWW aplikace, která vystupuje jako brána mezi WWW serverem, na kterém je spuštěna, a existujícími poštovními servery pro skladování a přepravu elektronických zpráv. Protože je EMU Webmail vytvořen podle existujících standardů a doporučení týkajících se práce s elektronickou poštou, dokáže spolupracovat prakticky se všemi implementacemi SMTP, POP3 a IMAP4 serverů. Uživatelé se k EMU Webmail aplikaci připojují pomocí WWW prohlížeče. Aplikace pak komunikuje s poštovními servery pomocí protokolů SMTP, POP3 nebo IMAP4. Je schopna jak odesílat, tak i přijímat elektronické zprávy. S jednotlivými uživateli pak EMU Webmail komunikuje pomocí dynamicky generovaných WWW stránek, které zpracovává WWW prohlížeč uživatele.
6.2. Endymion MailMan
25
Obrázek 6.1: Architektura EMU Webmail systému EMU Webmail může pracovat přímo na WWW serveru nebo na vlastním stroji vytvořeném speciálně pro práci s elektronickou poštou. V případě velkého uživatelského zatížení serveru je možné nainstalovat EMU Webmail na více než jeden server a tím distribuovat zátěž. Přitom je nutné ukládat uživatelská data tak, aby k nim měly přístup všechny EMU Webmail aplikace, tzn. na nějaký sdílený síťový disk. Jak je vidět na obr. [6.1/25], mohou WWW prohlížeče při přístupu k WWW serveru využívat zabezpečení pomocí SSL (HTTPS). Celá EMU Webmail aplikace je tvořena množinou CGI skriptů (Common Gateway Interface) pracujících na WWW serveru. Podrobnosti k EMU Webmail aplikaci lze získat na http://www.emumail.com.
6.2
Endymion MailMan
Endymion MailMan je web mail aplikace určená pro instalaci na WWW server. Komunikace mezi uživateli a WWW serverem je vedena pomocí WWW prohlížeče a HTTP protokolu (popř. zabezpečného prostřednictvím SSL). Požadavky od uživatelů jsou pomocí WWW prohlížeče a HTTP protokolu přenášeny na WWW server, kde jsou následně zpracovány pomocí CGI skriptů. CGI skripty jsou vytvořeny v jazyce PERL. Endymion MailMan umí odesílat elektronické zprávy pomocí protokolu SMTP a číst je pouze z POP3 serverů prostřednictvím POP3 protokolu. CGI scripty na základě výsledků získaných od POP3 serveru vytvoří HTTP odpověď (dynamickou WWW stránku), kterou odešlou k WWW prohlížeči. Aplikace Endimion MailMan je dostupná na http://www.endymion.com a je vyvíjena ve dvou verzích. Standard Edition: Tato verze zasílá elektronické zprávy WWW prohlížeči přímo z poštovních schránek na POP3 serveru (viz obr. [6.2/26]). Neukládá si tedy jejich kopie
6.3. KrystalBox Webmail
26
Obrázek 6.2: Architektura Endymion MailMan systému (Standard Edition) na WWW serveru, a proto jsou její služby omezeny možnostmi POP3 protokolu, kterých není mnoho. Professional Edition: Je verze, která načte elektronické zprávy z POP3 serveru a uloží je do souborového systému na WWW serveru (viz obr. [6.3/27]). To je výhodné hlavně proto, že elektronické zprávy jsou pak dostupné i bez spojení s POP3 serverem (tedy rychleji). Navíc tato verze poskytuje více služeb než jednoduchý POP3 protokol. Je např. možné vytvářet na WWW serveru složky s elektronickými zprávami a také zprávám přiřazovat různé příznaky. Elektronické zprávy získané z POP3 serveru se pak tváří jako by byly dostupné pomocí IMAP4 protokolu.
6.3
KrystalBox Webmail
KrystalBox Webmail je další z řady aplikací pro čtení a psaní elektronických zpráv. Stejně tak jako u dříve popsaných aplikací komunikuje s uživatelem prostřednictvím WWW prohlížeče a WWW serveru. Liší se však tím, že poskytuje nejen přenos elektronických zpráv pomocí běžně používaných protokolů (SMTP, POP3 a IMAP4), ale také poskytuje podporu protokolu NNTP. Protokol NNTP (Network News Transfer Protocol) slouží pro distribuci síťových novin v rámci diskusních skupin. Další zvláštností KrystalBox Webmail aplikace je využívání LDAP serveru pro udržování evidence uživatelů. Protokol LDAP (Lightweight Directory Access Protocol), pomocí něhož lze s LDAP serverem komunikovat, je určen pro evidenci uživatelů a jejich kontaktních informací (např. elektronická adresa, WWW adresa). Tento protokol je založen
6.3. KrystalBox Webmail
Obrázek 6.3: Architektura Endymion MailMan systému (Professional Edition)
Obrázek 6.4: Architektura KrystalBox Webmail systému
27
6.3. KrystalBox Webmail
28
na doporučení X.500, které se do praxe příliš neprosadilo (bylo příliš rozsáhlé a složité) a je podrobně popsán v RFC-2251. Architektura KrystalBox Webmail aplikace je znázorněna na obr. [6.4/27]. Další zajímavosti týkající se KrystalBox Webmail aplikace lze získat na http://www.krystalbox.com.
29
Kapitola 7 Návrh vlastního web mail systému Při navrhování architektury vlastního web mail systému pro čtení a psaní elektronických zpráv pomocí WWW rozhraní bylo vycházeno z existujících architektur, které jsou popsány v kap. [6/24].
7.1
Navrhnutá architektura web mail systému
Navrhnutá architektura web mail systému vychází z architektury EMU Webmail systému, který je stručně popsán v [6.1/24]. Liší se především způsobem konkrétní realizace, která je popsána v kapitolách [9/36], [10/39] a [12/48]. Na jedné straně tedy stojí uživatel, který si chce pomocí svého WWW prohlížeče přečíst jemu určenou elektronickou poštu, popř. napsat a odeslat nějaké elektronické zprávy. Celý systém se tedy skládá z WWW prohlížeče, který je obsluhován uživatelem. Dále pak z WWW serveru, na kterém je spuštěn program zajišťující odesílání a příjem elektronických zpráv a veškerou komunikaci s uživatelem. Pro odesílání elektronických zpráv je v systému zapotřebí SMTP server. Nedílnou součástí systému je samozřejmě také POP3 nebo IMAP4 server, který obsahuje poštovní schránky s elektronickou poštou (tu čte program běžící na WWW serveru a posílá ji, po převodu do HTML, prostřednictvím HTTP protokolu WWW prohlížeči, který je spuštěn na straně uživatele). Navrhnutá architektura takového web mail systému je znázorněna na obr. [7.1/30]. Veškerá komunikace mezi WWW prohlížečem, SMTP, POP3, IMAP4 a WWW serverem probíhá skrze navázané transportní (TCP) spojení. Transportní spojení lze navázat mezi libovolnými dvěma počítači v Internetu, které spolu komunikují prostřednictvím protokolového zásobníku TCP/IP. Vzdálenost mezi jednotlivými servery navzájem a klientem (uživatelem) je tedy teoreticky neomezená. Tato vzdálenost může být jak nulová (uživatel má spuštěn WWW prohlížeč na počítači, který je SMTP, POP3, IMAP4 a WWW serverem zároveň), tak blíže neurčená (např. uživatel se z USA pomocí WWW prohlížeče připojí na WWW server v ČR, odkud se pomocí zde spuštěného programu podívá do své schránky s elektronickou poštou, kterou vlastní na volně dostupném IMAP4 serveru v Austrálii).
7.2. Komunikace mezi WWW prohlížečem a WWW serverem
30
Obrázek 7.1: Architektura realizovaného web mail systému
7.2
Komunikace mezi WWW prohlížečem a WWW serverem
Komunikace mezi WWW prohlížečem a WWW serverem může probíhat jak po otevřeném, tak po šifrovaném TCP spojení. Komunikace po otevřeném TCP spojení probíhá pomocí HTTP protokolu a může být relativně snadno odposlouchávána (nebezpečné zejména pro citlivé informace). Šifrovaná komunikace probíhá prostřednictvím SSL (někdy se tato komunikace označuje jako HTTPS). Data se na jedné straně zašifrují a na druhé pak dešifrují, což může komunikaci zpomalovat. Proto je moudré nechat na uživateli, který způsob zvolí. Po tomto spojení se přenáší data z WWW serveru k WWW prohlížeči a naopak. Data přenášená z WWW serveru směrem k WWW prohlížeči tvoří převážně WWW stránky (data textového charakteru), ale také obsahy příloh elektronických zpráv (mohou mít binární charakter – obrázky, zvuky, atd.). Od WWW prohlížeče k WWW serveru se přenáší rovněž data textového charakteru – hodnoty jednotlivých polí formulářů (přeáší se HTTP metodou POST) a parametry předávané pomocí dynamicky generovaných hypertextových odkazů (přenášené HTTP metodou GET). WWW prohlížeč může samozřejmě na WWW server přenášet také data binárního charakteru a těmi mohou být soubory, které slouží jako přílohy pro vytvářenou elektronickou zprávu určenou k odeslání.
7.3
Komunikace mezi WWW serverem a SMTP serverem
Když uživatel potřebuje odeslat elektronickou zprávu, nejprve ji vytvoří ve spolupráci s programem spuštěným na WWW serveru. Tento program pak zajišťuje to, že hlavička
7.4. Komunikace mezi WWW serverem a POP3 nebo IMAP4 serverem
31
i tělo elektronické zprávy budou odpovídat doporučení [RFC822] a standardu MIME. Tím je zaručeno, že při odesílání této zprávy nenastanou žádné potíže. Elektronickou zprávu (i s případnými přílohami) odesílá program spuštěný na WWW serveru prostřednictvím SMTP serveru, se kterým komunikuje pomocí SMTP protokolu. Jelikož je tato komunikace určitým způsobem nezávislá na komunikaci mezi WWW serverem a POP3 nebo IMAP4 serverem, je možné odeslat elektronickou zprávu přes SMTP server a přitom nebýt přihlášen k POP3 nebo IMAP4 serveru. Více dat je přenášeno směrem k SMTP serveru (řídicí příkazy a hlavička s tělem elektronické zprávy), který nazpět zasílá pouze potvrzovací zprávy.
7.4
Komunikace mezi WWW serverem a POP3 nebo IMAP4 serverem
Program spuštěný na WWW serveru může zprostředkovat uživateli komunikaci pouze s jedním poštovním serverem (tzv. poštovní relaci) v průběhu jedné HTTP relace. S vybraným poštovním serverem dokáže program komunikovat pomocí příslušného protokolu (nejčastěji POP3 anebo IMAP4 protokol).
7.4.1
Komunikace s POP3 serverem
POP3 protokol je navržen tak, aby byl co možná nejjednodušší a slouží pouze pro čtení elektronických zpráv. Data odesílaná z WWW serveru směrem k POP3 serveru jsou v podstatě pouze řídicí příkazy (USER, PASS, RETR, QUIT, atd.). V opačném směru jsou přenášeny odpovědi na řídicí příkazy a požadovaná data (hlavičky a těla elektronických zpráv včetně případných – příslušně zakódovaných – příloh).
7.4.2
Komunikace s IMAP4 serverem
Při komunikaci s IMAP4 serverem je situace o trochu komplikovanější, protože IMAP4 protokol je mnohem složitější než protokol POP3. IMAP4 server je schopen přijímat od WWW serveru nejen znatelně větší množství řídicích příkazů, ale také data případné elektronické zprávy, kterou má uživatel např. připravenu k odeslání a chce si uložit její kopii do libovolné složky na tomto IMAP4 serveru.
7.5
Ověřování uživatele
Je samozřejmé, že k poštovní schránce s elektronickou poštou na příslušném POP3 nebo IMAP4 serveru by měl mít přístup pouze její pravý majitel. Ověření pravosti majitele schránky se provádí pomocí uživatelského jména (popř. přímo jména poštovní schránky) a nějakého sdíleného tajemství, kterým bývá nejčastěji heslo (zná ho pouze majitel schránky a příslušný poštovní server).
7.6. Správa elektronických zpráv
32
Vlastní POP3 nebo IMAP4 server si můžeme snadno představit jako počítač, na kterém má několik uživatelů své konto (přidělený určitý diskový prostor). Tento počítač je připojen do Internetu, takže k němu může přistupovat v podtatě každý. Pouze jeho administrátor však určuje, kteří uživatelé mají na tomto počítači svá uživatelská konta a jaká jsou jejich uživatelská jména, popř. prvotní hesla. Onen POP3 nebo IMAP4 server je pak pouze nějaký program, který je spuštěn na tomto počítači, očekává na příslušném TCP portu příchozí transportní spojení a pomocí služeb systému daného počítače ověřuje, zda předané uživatelské jméno a heslo patří k nějaké poštovní schránce (nějakému diskovému prostoru) s elektronickými zprávami. Podle výsledku ověřování je pak buď umožněn, nebo neumožněn uživateli přístup k dané elektronické poštovní schránce.
7.6
Správa elektronických zpráv
Když se elektronická zpráva po svém putování Internetem dostane až do cílového MTA (nejčastěji nějaký SMTP nebo ESMTP server), spustí MTA program MDA, který zajišťuje ukládání příchozích elektronických zpráv do poštovních schránek příslušných uživatelů. Elektronickou poštovní schránkou bývá většinou nějaký soubor na sdíleném disku (ve sdíleném adresáři, do kterého má přístup pouze administrátor, MDA a samotný uživatel). Pro uživatele je přístup k němu podmíněn znalostí uživatelského jména a hesla. O správu (vytvoření, editování a případné zrušení) tohoto souboru se už stará samotná implementace POP3 nebo IMAP4 serveru, která tak činí na základě řídicích příkazů přicházejících od nějaké ověřené osoby nebo programu.
33
Kapitola 8 Něco málo o HTML Základním prvkem pro tvorbu WWW stránek je už velmi dlouho jazyk HTML (HyperText Markup Language), který WWW prohlížeči vysvětluje, co a jak má zobrazit. Jako každý jiný programovací jazyk má i HTML své příkazy tzv. tag y (tags). Tyto příkazy určují, co a kde se na výsledné WWW stránce objeví (obrázky, text, odkazy, atd.). Každá WWW stránka má ve skutečnosti dvě podoby. První podobou je ta, kterou vidíme díky WWW prohlížeči a druhou podobou je zdrojový kód WWW stránky zapsaný v jazyce HTML. Tento zdrojový kód zpracovává WWW prohlížeč a předkládá ho uživateli. Minimální WWW stránka (HTML soubor), kterou by měly prohlížeče umět bez potíží zobrazit, může vypadat např. následovně: <TITLE>Hello world! <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> Hello world!
8.1
Proč právě HTML
Je známo, že existuje celá řada způsobů, jak vytvářet WWW stránky. Důležité při jejich tvorbě je myslet také na to, jaké prostředky budou potřebné pro jejich bezproblémové a správné zobrazování prostřednictvím WWW prohlížeče. Kdyby padlo rozhodnutí využít pro komunikaci s uživatelem např. Flash, musel by pak uživatel mít ve svém WWW prohlížeči zabudovánu podporu pro zobrazování Flash aplikací. To samé samozřejmě platí i pro jazyk Java a jeho technologii Applet,1 pro jejíž 1
Applet je v podstatě program napsaný v jazyce Java. Spouští se na straně WWW prohlížeče s omezenými přístupovými právy ke zdrojům daného počítače.
8.2. HTML formuláře
34
podporu si uživatel musí opatřit JVM (Java Virtual Machine) příslušné verze, jinak WWW prohlížeč applet nedokáže spustit. Navíc uživatelé chtějí k Internetu i k elektronické poště přistupovat z různých prostředí (např. Windows nebo Unix) pomocí nejrůznějších WWW prohlížečů (např. Internet Explorer, Netscape Navigator, Mozilla, Opera nebo textový Links), a proto je většinou komplikované veškerou potřebnou podporu do těchto WWW prohlížečů zabudovat. Proto padlo rozhodnutí použít samotné HTML, které stálo u zrodu WWW, a tudíž ho umí interpretovat snad všechny dostupné a používané WWW prohlížeče. HTML je jednoduché a lze ho dobře dynamicky generovat. Komunikace WWW prohlížeče s WWW serverem je minimalizována, není potřeba přenášet žádné podpůrné programové balíky a jiná data.
8.2
HTML formuláře
Formulář se na WWW stránce jeví uživateli podobně jako dialogové okno, může obsahovat většinu běžně používaných prvků – textová pole, tlačítka, přepínače, popisky, apod. Definice HTML formuláře v HTML může vypadat např. následovně:
Hodnota jméno programu určuje, kterým programem (skriptem) bude po odeslání (tzv. submit tlačítkem) HTML formulář zpracován a hodnota metoda pak říká, jestli se data získaná z HTML formuláře mají danému programu předat pomocí HTTP metody GET nebo POST. Hodnota typ pak WWW prohlížeči říká, jak má data pro přenos na WWW server zakódovat. Podle použitého kódování lze HTML formuláře rozdělit na tři typy, dva z nich si nyní popíšeme.2
8.2.1
Formulář typu application/x-www-form-urlencoded
Tento typ HTML formuláře je implicitní (není-li u HTML elementu FORM uveden atribut ENCTYPE) a v praxi se nejvíce používá. Jak již jeho název napovídá, ještě před odesláním dat z HTML formuláře na WWW server zakóduje WWW prohlížeč jeho data. Používá při tom tzv. URL kódování, které nahrazuje bílé a netisknutelné znaky sekvencí znaků %XX, kde XX je ASCII hodnota daného znaku v šestnáctkové soustavě. To znamená, že tento typ HTML formuláře používá kódování podobné MIME kódování quoted-printable, a proto není vhodný pro přenos velkého množství dat textového charakteru a už vůbec ne pro přenos dat binárního charakteru (libovolný soubor). 2
Třetí typ je text/plain, jehož výsledky lze pomocí ACTION="mailto:elektronická adresa" odeslat na libovolnou elektronickou adresu.
8.2. HTML formuláře
8.2.2
35
Formulář typu multipart/form-data
Pokud chceme mezi WWW prohlížečem a WWW serverem pomocí HTML formuláře přenášet data binárního charakteru, musíme explicitně u HTML elementu FORM uvést atribut ENCTYPE s hodnotou multipart/form-data. Tento typ HTML formuláře pak přenášená data zakóduje pomocí standardu MIME tak, že je možné je bezchybně přenést na WWW server a tam po dekódování příslušně zpracovat.
36
Kapitola 9 JavaServlet API Servlet (servlet) je označení pro program, který se spouští na straně WWW serveru a je napsán v jazyce Java. Často bývá označován jako protiklad tzv. appletu (applet), což je program spouštěný pomocí WWW prohlížeče a JVM (Java Virtual Machine) na straně klienta. Říká se, že servlet je pro WWW server tím, čím je applet pro WWW prohlížeč. Servlety komunikují s WWW serverem pomocí standardizovaného rozhranní Servlet API (v současné době je toto rozhranní popsáno v dokumentu Servlet Specification verze 2.3, který je dostupný na [Sun02]). WWW server jím předává servletu (programu) požadavky od WWW prohlížeče a jako odpověďi na ně posílá odezvu nejčastěji ve formě WWW stránky (HTML dokumentu). Velkým přínosem servletů je nezávislost na platformě (k běhu servletu na WWW serveru postačuje podpora Javy a Servlet API).
9.1
Proč právě JavaServlet
Pro obsluhu HTTP požadavků a generování příslušných HTTP odpovědí (dynamických WWW stránek) je tedy důležité mít na WWW serveru „něcoÿ, co bude zpracovávat příchozí HTTP požadavky a generovat odchozí HTTP odpovědi. Toto „něcoÿ může být buď skript, anebo jiný speciální program. Skripty (popř. speciální programy) lze vytvořit několika způsoby, a to pomocí CGI, FastCGI, PHP, ASP, JSP anebo servletu. CGI skripty jsou programy, které jsou uloženy na WWW serveru ve speciálním adresáři (nejčastěji cgi-bin). Když WWW prohlížeč požaduje na WWW serveru URL spojené s nějakým CGI skriptem, posílá tím WWW serveru požadavek na soubor obsahující vlastní skript. Jakmile WWW server zjistí, že se jedná o soubor CGI skriptu, nevrací přímo jeho obsah, ale spustí ho. Právě tímto spouštěním vytváří WWW server nový proces pro každý požadavek od WWW prohlížeče, což je časově i paměťově náročné. Tento problém částečně řeší tzv. FastCGI. Obecně mohou být CGI skripty vytvořeny v libovolném programovacím jazyce (např. C, PERL), přesto jsou interpretovány relativně pomalu (dlouho trvá, než se spustí) a v dnešní době již spíše na ústupu. Novější technologie PHP (Professional Home Pages), ASP (Active Server Pages) a JSP (Java Server Pages) mají společné to, že se jejich příkazy (popř. celé podprogramy) začleňují
9.2. HTTP servlet
37
přímo do HTML kódu WWW stránky. Příkazy těchto „skriptovacíchÿ jazyků se vykonají na WWW serveru ještě před odesláním WWW stránky ke klientu (WWW prohlížeči). Technologie ASP je produktem firmy Microsoft a bohužel je vázána pouze na WWW servery poskytované Microsoftem (využívá technologii ActiveX ). PHP je skriptovací jazyk speciálně vyvinutý pro tvorbu dynamických WWW stránek, podporuje více platforem a má zabudovánu velmi rozsáhlou podporu databází. Technologie JSP se ve většině vlastností shoduje s jazykem PHP, ale navíc vychází z jazyka Java a úzce s ním souvisí, tudíž může využívat téměř všech jeho vlastností a dostupných funkcí. Existuje také technologie JavaServlet, která se určitým způsobem vztahuje k technologii JSP. Tam, kde je velké množství statického HTML a není potřeba mnoho dynamického generování pomocí jazyka Java, se doporučuje používat technologii JSP. Naproti tomu tam, kde je nutné většinu výkonného kódu, který bude dynamicky generovat potřebný HTML kód, napsat v jazyce Java, je doporučováno používat technologii JavaServlet. Praktická část této diplomové práce je realizována právě pomocí technologie JavaServlet, která je podle statistik rychlostně srovnatelná se skriptovacím jazykem PHP. Navíc je bezpečná, protože servlety se spouští na WWW serveru pomocí JVM. Právě JVM se stará o to, aby nebyl servletem nijak ohrožen chod WWW serveru. Jazyk Java a jeho využití v souvislosti s WWW je moderní a zajímavá věc, která má pravděpodobně budoucnost teprve před sebou.
9.2
HTTP servlet
Applety umožňují běh Java aplikací na straně WWW prohlížeče. Podobně zase servlety umožňují běh Java aplikací na straně WWW serveru, a tím je umožňují využít i pro tvorbu WWW aplikací. Java dovoluje vytvářet servlety dvou typů. Prvním typem je tzv. generic servlet, který je nezávislý nejen na platformě, na které může být spuštěn, ale také na protokolu, kterým bude komunikovat s klientem. Záleží tedy přímo na programátorovi, jak daný servlet bude implementovat. Jednou již hotovou implementací servletu je právě HTTP servlet. Je to servlet, který je vytvořen tak, aby programátorovi usnadnil využívání protokolu HTTP pro komunikaci mezi servletem (spuštěným na WWW serveru) a klientem (např. WWW prohlížečem). Poznamenejme, že i servlety jsou spouštěny pomocí JVM a s WWW serverem komunikují prostřednictvím tzv. Servlet API (aktuální verze je 2.3), které není součástí standardní distribuce jazyka Java J2SE 1.4.0 (Java 2 Standard Edition), a proto musí být instalováno dodatečně.1
9.2.1
Jak funguje HTTP servlet
To, kdy bude servlet spouštěn, záleží na konfiguraci WWW serveru. Je možné servlet spouštět buď automaticky hned po startu WWW serveru, nebo až při příchodu prvního HTTP požadavku (HTTP request). HTTP servlet tedy po svém spuštění čeká na WWW 1
Ale už je součástí rozšířené distribuce jazyka Java J2EE (Java 2 Enterprise Edition).
9.2. HTTP servlet
38
serveru na příchozí HTTP požadavky. Tyto požadavky mohou vznikat pomocí různých HTTP metod (např. GET, POST nebo PUT). Servlet se v jazyce Java vytváří děděním od třídy javax.servlet.http.HttpServlet. Jedná se tedy o třídu, která zdědila od své rodičovské třídy nějaké metody. Tyto metody slouží pro obsluhu k servletu přicházejících HTTP požadavků a jsou nazývány podobně jako HTTP medody, díky kterým vznikly. Proto metoda doGet() slouží pro obsluhu GET požadavků a metoda doPost() pak pro obsluhu POST požadavků. Každá z těchto metod má možnost číst příchozí HTTP požadavek, ale i v něm přenášené parametry (parameters) a jejich hodnoty (values). Na daný HTTP požadavek pak může servlet vytvořit HTTP odpověď (HTTP response), a tu následně odeslat. Pro HTTP servlet bude odpovědí nejčastěji dynamicky vygenerovaná WWW stránka. Deklarace zmíněných metod a jejich formálních parametrů vypadá následovně: • doGet(HttpServletRequest, HttpServletResponse), • doPost(HttpServletRequest, HttpServletResponse). Jak jsme si již řekli, lze pomocí HTTP metod GET a POST přenášet na WWW server různé parametry. Servlet spolupracuje s WWW serverem pomocí tzv. servlet container u. Právě servlet container se stará o předávání HTTP požadavků příslušnému servletu. Servlet čte různé typy příchozích HTTP požadavků pomocí odpovídajících metod. Jsou-li v požadavku přenášeny nějaké parametry, jejichž hodnoty chce servlet načíst, musí být známa jejich jména. Načte je jednoduše voláním metody getParameter() z objektu třídy HttpServletRequest, na níž získal od servlet container u referenci (vstupní parametr metody doGet() nebo doPost()). Servlet pak na základě HTTP požadavku dynamicky vygeneruje HTTP odpověď. Ta se pak odesílá zpět ke klientovi pomocí Java proudu (stream). Výstupní proud servletu je vytvořen buď pro data binárního charakteru (např. obrázek, soubor), nebo pro data textového charakteru (např. text, WWW stránka). Pro binární data se proud získá voláním metody getOutputStream() z reference na objekt třídy HttpServletResponse a pro textově orientovaná data metodou getWriter(). Servlety tedy umožňují zpracovávat HTTP požadavky, které mohou obsahovat různé parametry. A právě zde se skrývá obrovský nedostatek technologie JavaServlet. Hodnoty těchto parametrů lze v servletu získat pomocí zmíněné metody getParameter() pouze v případě, že byly zaslány z HTML formuláře, který kóduje přenášená data pomocí URL kódování (tj. HTML formulář typu application/x-www-form-urlencoded)! Pokud tedy potřebujeme v servletu zpracovávat HTTP požadavky zaslané prostřednictvím HTML formuláře typu multipart/form-data, musíme si s tím nějak poradit bez používání metod ze Servlet API (viz [12.4.3/52]).
39
Kapitola 10 JavaMail API Je hezké mít naprogramovaný servlet, ale také je potřeba mít nainstalováno příslušné rozhraní (Servlet API), pomocí kterého bude servlet komunikovat s WWW serverem. Stejně tak pro komunikaci servletu (nebo jakékoliv jiné Java aplikace) s různými poštovními servery (SMTP, POP3 nebo IMAP4) je potřeba mít nainstalováno rozhraní, které tuto komunikaci programátorovi nějakým způsobem usnadní. Tímto rozhraním je pro jazyk Java právě JavaMail API (aktuální verze je 1.2), které kromě TCP komunikace se SMTP, POP3 nebo IMAP4 serverem, umožňuje také práci s vlastními elektronickými zprávami (rozbor hlavičky a těla elektronické zprávy). JavaMail umožňuje pracovat pouze s elektronickými zprávami, které odpovídají doporučení [RFC822] a standardu MIME. Existují samozřejmě i API (Application Program Interface) pro práci s elektronickou poštou, které poskytuje tzv. třetí strana (third party ). Ale u těchto balíků (packages) není zaručena taková dostupnost (zdarma), propojitelnost s J2SE (popř. J2EE) a další vývoj jako u standardního volitelně instalovatelného balíku JavaMail API.
10.1
JavaBeans Activation Framework (JAF)
Pro práci s daty těla elektronické zprávy se JavaMail spoléhá na tzv. JAF (JavaBeans Activation Framework API – aktuální verze je 1.0.1). Pomocí JAF zjišťuje JavaMail hlavní a vedlejší MIME typ dat přenášených v těle zkoumané elektronické zprávy. Dále JavaMail využívá JAF pro zjištění dostupných příkazů, které lze využít při práci s daty těla zprávy. Při vytváření nové elektronické zprávy kóduje JavaMail pomocí JAF data podle doporučení MIME. Obsah těla elektronické zprávy je zapouzdřen do tzv. DataHandler objektu, což je vlastně instance stejnojmenné třídy definované v JAF API – viz obr. [10.2/41]. Při práci s JavaMail API je JAF do jisté míry před programátorem skryto, ale přesto je důležité se zde o jeho existenci alespoň zmínit. Použití JAF se totiž nevyhneme zejména při vytváření nové elektronické zprávy, ale také při testování a ladění programu hraje znalost JAF určitou roli.
10.2. Základní třídy JavaMail API
10.2
40
Základní třídy JavaMail API
Protože Java je objektově orientovaný programovací jazyk, je práce s ní založena (kromě jiného) na využívání rozhraní, tříd, metod a proměnných (atributů). JavaMail API se skládá ze dvou vrstev. První vrstvou je tzv. abstraktní vrstva (abstract layer ) obsahující definice rozhraní, abstraktních tříd a abstraktních metod, které pokrývají obecné požadavky kladené libovolným protokolem na elektronickou poštu a její přenos. Další vrstvou je pak konkrétní implementace nejpoužívanějších metod přístupu do elektronických poštovních schránek (jako je např. POP3 nebo IMAP4 protokol). Do této vrstvy spadá také implementace metod a tříd sloužících pro rozbor hlaviček a těl elektronických zpráv podle doporučení [RFC822] a standardu MIME. Abstraktní třída Message vychází z rozhraní Part a definuje množinu proměnných (atributů) a metod, které s elektronickými zprávami pracují. Tyto proměnné v podstatě tvoří hlavičku elektronické zprávy a jednotlivé metody umožňují tuto hlavičku číst popř. upravovat. Dále tato třída obsahuje MIME typ elektronické zprávy a referenci na obsah jejího těla. Z abstraktní třídy Message je odvozena třída MimeMessage, která je vlastně konkrétní implementací pro všechny elektronické zprávy odpovídající doporučení [RFC822] a standardu MIME. Tato třída obsahuje konkrétní metody pro práci s hlavičkou a tělem MIME zprávy. Navíc obsahuje příznaky dané zprávy (uložené v objektu třídy Flags). Objekt třídy MimeMessage lze nejen zapsat do výstupního proudu, ale také ho lze z nějakého vstupního proudu vytvořit. Hierarchie často používaných tříd a rozhraní obsažených v JavaMail API je znázorněna na obr. [10.1/41]. Další významnou třídou je třída Session, která uchovává konfiguraci, ověřovací informace a další data používaná při přístupu k POP3 nebo IMAP4 serveru. Je důležité neplést si pojmy HTTP relace (HTTP session, která je spojena s komunikací WWW prohlížeče a WWW serveru) a poštovní relace (mail session, která je spojena s komunikací servletu s POP3 nebo IMAP4 serverem).
10.3
Práce s elektronickými zprávami
Nyní se pokusíme nastínit, jak jsou elektronické zprávy (z pohledu JavaMail API) ukládany na POP3 nebo IMAP4 serverech, jak se elektronické zprávy přijímají pomocí protokolu POP3 nebo IMAP4, a na závěr ještě jak lze nově vytvořenou elektronickou zprávu odeslat pomocí SMTP protokolu na SMTP server. Elektronické zprávy jsou z pohledu JavaMail API dostupné na POP3 nebo IMAP4 serverech metodami tříd Store a Folder. Jak na POP3, tak na IMAP4 serveru se zprávy ukládají do poštovních složek (folders).1 Klient získává elektronické zprávy (objekty třídy MimeMessage) čtením z poštovních složek pomocí metody getMessage() volané z objektu třídy Folder. O samotnou komunikaci, využívající POP3 nebo IMAP4 protokol, se stará JavaMail a z pohledu programátora je tato komunikace transparentní. 1
I když na POP3 serveru je to pouze jediná poštovní složka nazývaná INBOX – viz [11.3/45].
10.3. Práce s elektronickými zprávami
Obrázek 10.1: Základní rozhraní a třídy JavaMail API
Obrázek 10.2: Objektově orientovaný pohled na elektronickou zprávu
41
10.3. Práce s elektronickými zprávami
42
Obrázek 10.3: Objektově orientovaný pohled na přílohy elektronické zprávy Objekt třídy MimeMessage obsahuje hlavičku elektronické zprávy a referenci na její tělo (viz obr. [10.2/41]). Klient z hlavičky nejprve zjistí MIME typ těla zprávy a podle toho se pak zachová. Buď přímo přistoupí k tělu zprávy (nejčastěji je-li to soubor nebo nějaký prostý text), nebo zahájí další rozbor zprávy pomocí třídy MimeMultipart, jejíž metody dokážou přistupovat k jednotlivým vloženým přílohám. K těmto přílohám se přistupuje jako k objektům třídy MimeBodyPart (viz obr. [10.3/42]).
10.3.1
Čtení elektronických zpráv z poštovního serveru
Třída Store definuje jakousi databázi, která obsahuje hierarchii poštovních složek a elektronických zpráv v nich uložených. Tato třída také stanovuje protokol, pomocí kterého se budou zpřístupňovat poštovní složky na vzdáleném poštovním serveru (POP3 nebo IMAP4), a z nich pak číst elektronické zprávy. Klient získá objekt třídy Store voláním metody getStore() z objektu třídy Session. Parametrem tohoto volání je kompletní URL serveru, ke kterému se chce klient připojit (protokol, adresa, uživatelské jméno a heslo). Vlastní připojení (vytvoření TCP spojení) k poštovnímu serveru se pak provádí voláním metody connect() z objektu třídy Store. Po připojení k POP3 nebo IMAP4 serveru je zapotřebí získat tzv. kořenovou poštovní složku (bývá označována jako default folder nebo root folder ) daného poštovního serveru, což se provádí voláním metody getDefaultFolder() z objektu třídy Store. Spojení se serverem lze ukončit voláním metody close() – opět z objektu třídy Store. Získanou referencí na kořenovou poštovní složku je objekt třídy Folder. Ten tedy reprezentuje složku obsahující elektronické zprávy a popř. další poštovní složky. Poštovní složky mohou tvořit hierarchickou strukturu, a proto tato třída definuje metodu getType(), po-
10.3. Práce s elektronickými zprávami
43
mocí které lze zjistit, zda daná složka může obsahovat elektronické zprávy, další poštovní složky anebo obojí. Pomocí objektu třídy Folder lze přistupovat ke všem složkám a zprávám na daném serveru. Dále lze vytvářet nové, přejmenovávat existující a rušit nepoužívané poštovní složky (metody create(), rename() a remove() z objektu třídy Folder). Pomocí metody getMessage() může klient získat objekt třídy MimeMessage a s ním dále pomocí metod této třídy pracovat (provádět rozbor hlavičky a těla elektronické zprávy, na kterou objekt MimeMessage odkazuje).
10.3.2
Odesílání elektronických zpráv
Odeslání elektronické zprávy se provádí prostřednictvím SMTP protokolu a SMTP serveru, ke kterému se není potřeba nijak přihlašovat. JavaMail sám automaticky představí SMTP serveru počítač, ze kterého chce klient elektronickou zprávu odeslat (příkazem HELO ze SMTP protokolu – viz [3.1.3/10]), a pak už záleží jenom na SMTP serveru, jestli zprávu přijme nebo odmítne. Adresu SMTP serveru je nutné zapsat do tzv. systémových vlastností (system properties) ještě před získáním objektu třídy Session, který reprezentuje poštovní relaci. Zapsání SMTP serveru do systémových vlastností se ve web mail servletu provádí pomocí následujících několika řádek kódu. Properties props = System.getProperties(); props.put("mail.smtp.host", "adresa_SMTP_serveru"); Session mailSession = Session.getInstance(props, null);
Po nastavení SMTP serveru a vytvoření poštovní relace musí klient nějakou elektronickou zprávu sestavit (může ji mít už předem připravenou – např. při přeposílání). Elektronickou zprávu vytváří jako objekt třídy MimeMessage. Hlavičku a tělo zprávy vytvoří klient pomocí odpovídajících metod z této třídy. Pokud je elektronická zpráva vytvořena a připravena k odeslání, lze ji odeslat voláním statické metody send() ze třídy Transport.
44
Kapitola 11 Web mail ze strany uživatele V této kapitole se podíváme na vytvořenou web mail aplikaci z uživatelského hlediska. Teprve potom, když už budeme znát všechny věci, které s elektronickou poštou dokáže provádět, podíváme se podrobněji na jeho realizaci z programátorského hlediska (v kap. [12/48]) a nakonec se zmíníme také o tom, jak web mail aplikaci umístit a spustit na WWW serveru (viz kap. [13/59]). Obecně je veškerá koncová činnost prováděná s elektronickou poštou (čtení, vytváření, rušení) řízena uživatelem. Web mail aplikace je z uživatelského hlediska tvořena několika WWW stránkami, mezi kterými se uživatel pohybuje. Stav své vzdálené poštovní schránky kontroluje (popř. mění) pomocí HTML formulářů a hypertextových odkazů, které mu zobrazuje jeho WWW prohlížeč. Většinu funkcí WWW prohlížeče lze ovládat pouze myší (mouse), ale pro psaní adres WWW stránek a textů do textových polí HTML formulářů je nezbytná také klávesnice (keyboard).
11.1
Přihlašování k POP3 nebo IMAP4 účtu
POP3 nebo IMAP4 účet je vlastně elektronická poštovní schránka, která je určena pro nějakého uživatele a je vytvořena na POP3 nebo IMAP4 serveru. Uživatel se k ní tudíž musí přihlásit (prokázat, že je jejím majitelem) pomocí uživatelského jména a hesla. Při přihlašování je tedy povinné vybrat protokol pro komunikaci s poštovním serverem, jehož jméno (popř. IP adresu) je také nutno zadat. Dále je potřeba zadat jméno (popř. IP adresu) SMTP serveru pro případné odesílání elektronických zpráv. Nakonec je po uživateli požadováno jeho uživatelské jméno a heslo, pod kterým má na zadaném POP3 nebo IMAP4 serveru zřízenu poštovní schránku.
11.2
Vytváření a odesílání elektronických zpráv
Pro vytvoření a odeslání elektronické zprávy není obecně nutné se k SMTP serveru přihlašovat (jménem a heslem), a proto je možné zprávu vytvořit jak bez přihlášení, tak i po při-
11.3. Pohled na věc z POP3 účtu
45
hlášení. Na dynamicky generovanou WWW stránku, která umožňuje vytvořit a odeslat elektronickou zprávu se uživatel dostane stisknutím tlačítka Compose a message. Uživateli se zobrazí WWW stránka obsahující políčka pro jednotlivé položky hlavičky elektronické zprávy. Z těchto políček je nutné správně vyplnit alespoň tři (adresa SMTP serveru, adresa odesilatele From: a adresa příjemce To:). Elektronická zpráva může obsahovat také tzv. přílohy (soubory, které budou začleněny do vytvářené elektronicé zprávy). Takové soubory je nutné zadávat postupně za sebou. Počítač uživatele má dostupné různé disky s adresáři a soubory. Z těchto dostupných souborů lze libovolný vybrat stiskem tlačítka Browse (popř. Procházet). Toto tlačítko vyvolává systémový dialog pro výběr souboru, a proto je jeho nápis určen systémem a nelze ho ze strany web mail servletu nijak ovlivnit. Pro začlenění vybraného souboru do vytvářené elektronické zprávy je pak ještě nutné stisknout tlačítko s nápisem Add attachment. Celou elektronickou zprávu lze pak odeslat pomocí tlačítka Send message, popř. ji lze vymazat tlačítkem Reset message.
11.3
Pohled na věc z POP3 účtu
Pokud se uživatel pomocí jména a hesla přihlásí k POP3 serveru, musí počítat s tím, že množina dostupných funkcí pro práci s jeho elektronickou poštou, kterou má na serveru ve své poštovní schránce uloženu, bude omezená. POP3 server udržuje pro každého uživatele pouze jednu složku nazývanou INBOX . Tuto složku nelze smazat ani přejmenovat a obsahuje pouze elektronické zprávy (žádné další vnořené poštovní složky). Poznamenejme, že při práci s web mail aplikací a POP3 serverem dochází k nenávratnému odstraňování elektronických zpráv hned po příslušné volbě (tlačítko Delete).
11.4
Pohled na věc z IMAP4 účtu
Při použití IMAP4 protokolu pro komunikaci s IMAP4 serverem může uživatel využívat více služeb pro práci se svojí elektronickou poštou. Protokol IMAP4 se od protokolu POP3 liší zejména tím, že podporuje využívání hierarchické struktury poštovních složek a elektronických zpráv, což uživateli určitým způsobem usnadňuje a zpříjemňuje práci. Navíc ke každé uložené elektronické zprávě přidává IMAP4 server tzv. příznaky (flags), podle kterých může uživatel poznat, zda byla zpráva označena ke smazání, přečtena anebo jestli je v právě otevřené složce nová. Příznak elektronické zprávy je zobrazován pomocí malých a jednoduchých obrázků. Práce s web mail aplikací a elektronickou poštou pomocí IMAP4 protokolu v sobě zahrnuje veškeré služby, které web mail aplikace poskytuje při komunikaci s poštovním serverem prostřednictvím protokolu POP3. Poznamenejme, že při práci s web mail aplikací a IMAP4 serverem dochází po stisku tlačítka Delete pouze k označení elektronické zprávy jako smazané (toto označení lze zrušit výběrem a stiskem tlačítka Undelete). Elektronické zprávy z právě prohlížené poštovní složky lze samozřejmě také trvale odstranit (tlačítko Expunge deleted).
11.5. Práce s poštovními složkami a elektronickými zprávami
11.5
46
Práce s poštovními složkami a elektronickými zprávami
Hned po přihlášení uživatele k POP3 nebo IMAP4 serveru je automaticky načtena příslušná kořenová poštovní složka (označovaná jako [ROOT]). Na POP3 serveru obsahuje kořenová složka pouze složku INBOX , zatímco na IMAP4 serveru může obsahovat daleko více složek. Zobrazení dostupných funkcí web mail aplikace (tlačítka HTML formulářů, položky rolovacích menu) je závislé na komunikačním protokolu a poštovním serveru. Pro protokol POP3 nebude určitá množina tlačítek vůbec zobrazena. Dále budeme popisovat tlačítka pro práci s IMAP4 serverem (pro práci s POP3 serverem je tlačítek daleko méně a jejich funkce jsou v podstatě totožné s příslušnými tlačítky zobrazenými při komunikaci s IMAP4 serverem). Vstoupit do libovolné z vypsaných poštovních složek (otevřít složku – open folder ) je možné dvěma způsoby. Buď výběrem z rolovacího menu a následným stiskem tlačítka s nápisem Go to selected folder, nebo pomocí hypertextového odkazu, kterým je jméno poštovní složky. Pokud se chce uživatel vrátit o složku výše, může tak učinit výběrem položky [PARENT] z rolovacího menu.1 Poštovní složky lze také vytvářet (pomocí tlačítka Create folder). Nově vytvářená složka bude obsahovat buď pouze elektronické zprávy (je zaškrtnuto pouze políčko uvozené textem Holds M:), nebo pouze další poštovní složky (je zaškrtnuto pouze políčko Holds F:). Některé implementace IMAP4 serverů umožňují vytvářet i poštovní složky, které mohou obsahovat jak elektronické zprávy, tak další složky. Pro vytvoření takové poštovní složky je nutné zaškrtnout obě zaškrtávací políčka (Holds M: i Holds F:). Jméno nově vytvářené poštovní složky se zadává do textového pole, jehož implicitní hodnota je folderName. Pro přejmenování jedné libovolné poštovní složky (kromě INBOX u) je nutné nejprve tuto složku vybrat (pomocí zaškrtávacího políčka), zvolit v textovém poli její nový název, a pak stisknout tlačítko Rename folder. Název nově vytvářené nebo přejmenovávané poštovní složky může obsahovat mezery a české akcentované znaky. Po stisku tlačítka s nápisem Delete selected folders budou nenávratně odstraněny všechny vybrané poštovní složky, které obsahují pouze elektronické zprávy nebo jsou prázdné. Poštovní složky, které obsahují další vnořené složky, lze samozřejmě také odstranit. Provádí se to pomocí zaškrtávacího políčka uvozeného textem Recursive:. Ve vybrané poštovní složce může uživatel pomocí zaškrtávacích políček (checkboxes) označit množinu elektronických zpráv (pokud daná složka nějaké zprávy obsahuje) a ty pak dále zpracovávat. Zprávy lze označovat buď po jedné, anebo výběrem (všechny, žádné, smazané, přečtené, nepřečtené) pomocí příslušného rolovacího menu a tlačítka Select. Vybraným elektronickým zprávám lze měnit některé příznaky. Pro označení vybraných zpráv ke smazání stačí stisknout tlačítko Delete a pro zrušení tohoto označení (opět pouze u vybraných zpráv) pak tlačítko Undelete. Pro nastavení/zrušení příznaku, že je zpráva přečtena slouží tlačítko Mark as a příslušné rolovací menu. Dále lze pomocí tlačítka Forward 1
Tato poštovní složka bývá někdy označována jako rodičovská složka (parent folder ) nebo také jako složka nadřazená.
11.5. Práce s poštovními složkami a elektronickými zprávami
47
vybrané zprávy přeposlat (forward) jako jednu velkou elektronickou zprávu s MIME typem multipart/digest.2 Oproti práci na POP3 účtu může při práci na IMAP4 účtu uživatel využívat možnost kopírování nebo přesunu elektronické zprávy (popř. skupiny elektronických zpráv) do jiné složky a to tak, že vybere v dostupném rolovacím menu příslušnou poštovní složku a pak stiskne buď tlačítko Copy, nebo Move. Přesun elektronických zpráv mezi složkami není destruktivní operace (zprávy nejsou trvale smazány, jsou pouze označeny ke smazání). Položky v rolovacím menu pro kopírování (popř. přesun) se mohou lišit od položek rolovacího menu sloužícího pro pohyb uživatele mezi jednotlivými poštovními složkami na daném poštovním serveru. Důvodem je to, že mohou existovat složky, které nemohou obsahovat elektronické zprávy.3 Také může uživatel samozřejmě elektronické zprávy (a jejich případné přílohy) číst, a to pomocí hypertextového odkazu, který je vytvořen z názvu každé načtené elektronické zprávy. Při čtení zprávy ji může uživatel přeposlat někomu jinému (tlačítko Forward), odpovědět autorovi (tlačítko Reply) nebo všem, kterým je zpráva adresována (tlačítko Reply to all). Uživatel může nahlédnout i přímo do hlavičky prohlížené elektronické zprávy (tlačítko Show all headers), přejít na další (tlačítko Next) nebo předešlou (tlačítko Previous) elektronickou zprávu v aktuální složce. Pro návrat k výpisu seznamu všech elektronických zpráv v aktuální poštovní složce stačí použít tlačítko Go to actual folder. Při čtení elektronické zprávy s libovolnými přílohami jsou tyto přílohy zobrazovány (hned po dostupném popisu, typu nebo názvu souboru) jako hypertextové odkazy.4 Prostřednictvím těchto odkazů lze přílohy přímo zobrazit pomocí WWW prohlížeče (pokud daný typ přílohy zobrazit dokáže) nebo uložit do příslušného souboru na lokální disk (v případě, že WWW prohlížeč nedokáže zobrazit danou přílohu, automaticky nabídne její uložení do souboru).
2 Typ multipart/digest slouží pro vložení několika elektronických zpráv do těla jedné velké elektronické zprávy – viz [5.5.2/22]. 3 Do takových složek samozřejmě nelze přidávat elektronické zprávy pomocí kopírování ani přesouvání, a proto nejsou v příslušném rolovacím menu vůbec zobrazovány. 4 Výjimku tvoří pouze přílohy MIME typů text/plain a message/rfc822, které jsou zobrazovány přímo.
48
Kapitola 12 Web mail ze strany programátora V této kapitole se zaměříme na vlastní realizaci web mail aplikace pro čtení elektronické pošty pomocí WWW prohlížeče. Jak již bylo řečeno, je web mail aplikace vytvořena za pomoci programovacího jazyka Java, technologie JavaServlet a jazyka HTML. Z návrhu web mail systému (viz kap. [7/29]) by mělo být zřejmé, jak celý systém při pohledu zvenčí funguje, a proto se zaměříme zejména na realizaci výkonného servletu, který se stará o řadu podstatných věcí.
12.1
Web mail servlet
Obecná funkce servletu již byla vysvětlena (viz kap. [9/36]). Samotný web mail servlet je v podstatě jedna velká třída nazvaná JavaMailServlet. Tato třída implementuje rozhraní (implements interface) SingleThreadModel. To znamená, že WWW server vytvoří a spustí nové vlákno pro každého klienta, který požaduje nějaké jeho služby (tj. vytvoří pro každého uživatele kopii servletu, kterou spustí – pro lepší představu viz obr. [12.1/49], kde jsou znázorněni tři uživatelé, z nichž každý pracuje na jiném poštovním serveru). Web mail aplikace využívá pro přenos dat a parametrů mezi WWW prohlížečem a web mail servletem pouze HTTP metody GET a POST, kterým odpovídají Java metody doGet() a doPost(). Tyto dvě metody jsou jediné, které volá přímo servlet container .1 Metoda doGet() je volána, pokud uživatel použije nějaký dynamicky vygenerovaný hypertextový odkaz (tj. požaduje vstup do nějaké poštovní složky, čtení určité elektronické zprávy nebo prohlédnutí její přílohy). Metoda doPost() je volána pokaždé, když uživatel stiskne tlačítko z libovolného HTML formuláře. Tyto dvě metody pak na základě vyhodnocení příchozího HTTP požadavku vyvolají příslušné metody pro jeho správné zpracování a vygenerování příslušné HTTP odpovědi pro uživatele (nejčastěji ve formě WWW stránky). Jména jednotlivých metod a proměnných (pokud nejsou pomocné) ve zdrojovém kódu web mail servletu jsou sestavena podle určitého schematu. První písmeno jména metody 1 Jedná se v podstatě o určitou obdobu metody main(), kterou po startu běžné Java aplikace automaticky volá JVM – servlet jako takový totiž nemá žádnou metodu main().
12.2. Využití HTTP relace
49
Obrázek 12.1: Naznačení funkce web mail servletu nebo proměnné říká, zda metoda hraje roli při práci s poštovními složkami (folder ), elektronickými zprávami (message), částí elektronické zprávy – přílohou (part) nebo souvisí s ověřováním uživatele (user ).
12.2
Využití HTTP relace
Protože je HTTP protokol zkonstruován jako bezestavový, je při tvorbě efektivních WWW aplikací nutné používat nějaký externí mechanismus, který umožní seskupovat požadavky od jednotlivých klientů. To znamená, že pokud chce uživatel využít nějakou službu web mail servletu (odeslání elektronické zprávy nebo přihlášení k POP3 či IMAP4 serveru), vytvoří se pro něho tzv. HTTP relace (HTTP session). Tato relace je tedy vytvořena mezi instancí web mail servletu a konkrétním uživatelem. HTTP relace lze vytvářet několika způsoby. Nejčastěji se využívají tzv. cookies („koláčkyÿ), což je určitý záznam na straně klienta, který pak klientův WWW prohlížeč automaticky zasílá se všemi požadavky na WWW server. Při HTTPS komunikaci lze HTTP relaci také udržovat pomocí SSL, které má pro tuto činnost v sobě zabudovaný určitý mechanismus. Naneštěstí nemusí všichni klienti cookies ani HTTPS podporovat, a proto existuje u servletů ještě jeden způsob. Tím způsobem je tzv. přepisování URL (URL rewriting ). Jeho princip spočívá v tom, že každý HTTP požadavek od WWW prohlížeče je směřován na určité URL na WWW serveru. Do tohoto URL se zakóduje i speciální identifikátor dané HTTP relace a servlet container na WWW serveru ho pak využívá pro seskupování jednotlivých požadavků do různých HTTP relací. Web mail servlet pro vytváření a udržování HTTP relací využívá cookies. Každá HTTP relace v sobě může uchovávat data, která se k ní nějak vztahují. U web mail servletu je těmito daty objekt třídy MailUserData (zdrojový kód viz příl. [B/71]).
12.3. Rozbor elektronických zpráv
50
Objekt této třídy v sobě obsahuje důležitá data, která úzce souvisí s jednotlivými uživateli, a tudíž i HTTP relacemi. Tato data obsahují: kompletní URL pro přístup k elektronické poště, aktuální poštovní relaci, jméno aktuální poštovní složky s elektronickými zprávami a případně i pro odeslání vytvářenou elektronickou zprávu. Tato data se do HTTP relace vkládají voláním metody setAttribute() z objektu třídy HttpSession, číst je lze pomocí metody getAttribute(). Kompletní URL pro přístup k elektronické poště může vypadat např. následovně. imap://jméno:[email protected]éna Při příchodu každého HTTP požadavku na web mail servlet se metodou getSession() z objektu třídy HttpServletRequest zjišťuje, je-li tento požadavek součástí nějaké HTTP relace. Když tomu tak není, je pro něj vytvořena HTTP relace nová. Dále servlet zkusí z této HTTP relace získat objekt třídy MailUserData (atribut této relace). Podle přítomnosti tohoto objektu (a v něm uloženého URL) v HTTP relaci lze usoudit, zda je uživatel, který požadavek zaslal, úspěšně přihlášen k POP3 nebo IMAP4 serveru.
12.3
Rozbor elektronických zpráv
Jak už víme, lze do jedné elektronické zprávy vložit nejen několik souborů, ale také několik dalších elektronických zpráv. To vše se provádí pomocí standardu MIME, který podrobně popisuje právě tuto rekurentní datovou strukturu elektronických zpráv a jejich příloh – viz kap. [5/19]. Protože MIME je rekurentní datová struktura, je nejlepší (pokud je to možné) její rozbor provádět pomocí rekurzivní funkce. Pro web mail servlet provádí rozbor elektronické zprávy jeho metoda displayPart(). Úkolem této metody je rekurentní rozbor požadované zprávy a dynamické vygenerování příslušné HTTP odpovědi pro WWW prohlížeč (zobrazení veškerých textů obsažených v dané elektronické zprávě a hypertextových odkazů na všechny její přílohy).
12.4
Přílohy elektronických zpráv
Pod pojmem příloha elektronické zprávy budeme nejčastěji rozumět libovolný binární soubor (ať už obsahuje obrázek, databázi nebo jiná binární data), ale také elektronickou zprávu jejíž struktura odpovídá doporučení [RFC822]. Přílohou může také být pouhý text v různých formátech a národních kódováních. V dalším textu se budeme zabývat problémy, které jsou spojeny s adresováním příloh elektronické zprávy, s přepravou vybrané přílohy z WWW serveru až k uživateli a na závěr také s přenosem souborů (příloh) od uživatele pomocí WWW prohlížeče na WWW server.
12.4. Přílohy elektronických zpráv
12.4.1
51
Adresování příloh elektronické zprávy
Podle doporučení [RFC822] a standardu MIME může každá elektronická zpráva obsahovat MIME položku hlavičky Message-Id: a každá její příloha obdobně může obsahovat MIME položku Content-Id:. Problém je v tom, že pouze může, ale nemusí. Proto se na hodnoty těchto MIME položek nemůžeme spoléhat při jednoznačném adresování elektronických zpráv a jejich příloh. Představme si nyní situaci, kdy uživatel otevře nějakou elektronickou zprávu, která obsahuje různé přílohy. Web mail aplikace mu pro každou přílohu dynamicky vygeneruje hypertextový odkaz a pokud se uživatel rozhodne si přílohu prohlédnout (popř. uložit), může tak učinit právě pomocí tohoto odkazu. Vygenerovaný odkaz by tedy měl obsahovat nějaký parametr, ze kterého v případě potřeby bude možné přesně určit, kterou přílohu má web mail servlet směrem k WWW prohlížeči odeslat. A právě pro tento účel jednoznačného adresování příloh elektronických zpráv byla vytvořena třída PartAddress obsahující několik metod, které přistupují k proměnné typu String – zdrojový kód viz příl. [A/68]. Adresa libovolné části elektronické zprávy začíná vždy pořadovým číslem této zprávy v poštovní složce, ze které pochází (podle specifikace IMAP4 protokolu je toto číslo vždy větší nebo rovno jedné).2 N message/rfc822 (multipart/mixed) N.1 text/plain N.2 multipart/digest N.2.1 message/rfc822 (multipart/mixed) N.2.1.1 text/plain N.2.1.2 application/ms-word N.2.1.3 img/jpg N.2.2 message/rfc822 (text/plain) N.2.3 message/rfc822 (multipart/alternative) N.2.3.1 text/plain N.2.3.2 text/html N.2.3.3 application/x-rar-compressed N.2.4 message/rfc822 (multipart/related) N.2.4.1 text/plain N.2.4.2 img/gif N.3 video/mpeg N.4 application/octet-stream
Předešlý výpis obsahuje v levém sloupci adresu přílohy (hodnota proměnné typu String v objektu třídy PartAddress). Znak N v této adrese zastupuje číslo elektronické zprávy v aktuální složce (popř. číslo 0, jedná-li se o právě vytvářenou zprávu). V pravém sloupci jsou pak rozepsány MIME typy jednotlivých příloh.3 2
Výjimku tvoří pouze nově vytvářená elektronická zpráva, které je vždy přiřazeno číslo nula. Jedná se v podstatě o hodnotu položky Content-Type: z hlavičky příslušné elektronické zprávy nebo její přílohy. 3
12.4. Přílohy elektronických zpráv
12.4.2
52
Přeprava přílohy z WWW serveru do WWW prohlížeče
Uživatel vidí přílohu elektronické zprávy pouze jako vygenerovaný hypertextový odkaz na WWW stránce. O tom co se děje, když využije tento odkaz ke získání dané přílohy, si nyní něco povíme. WWW stránku s hypertextovými odkazy příloh elektronické zprávy dynamicky vygeneroval web mail servlet, a proto každý z těchto odkazů obsahuje parametr pAddress. Hodnotou tohoto parametru je řetězec obsahující číslo zprávy v aktuální složce a adresu přílohy (proměnná typu String ze třídy PartAddress), která danému odkazu odpovídá. Použití tohoto hypertextového odkazu způsobí zaslání HTTP požadavku na web mail servlet. Tento požadavek bude servlet zpracovávat pomocí metody doGet(). Podle jedinečné adresy přílohy (kterou web mail servlet získal jako hodnotu parametru pAddress z příchozího HTTP požadavku) vybere servlet z dané elektronické zprávy požadovanou přílohu.4 Nejprve musí servlet získat skutečnou délku přílohy, kterou bude zasílat zpět k WWW prohlížeči uživatele. Pokud totiž nenastaví správnou délku HTTP odpovědi, získá WWW prohlížeč buď neúplnou přílohu, nebo bude čekat na data přílohy, která nikdy nezíská. Metody dostupné v JavaMail API dokážou vrátit pouze velikost zakódované přílohy (ať je kódována pomocí quoted-printable nebo base64). Vlastní binární data dekódované přílohy se z elektronické zprávy získávají pomocí Java proudu. O správné dekódování těchto dat se ještě před jejich zpřístupněním pomocí proudu postará JavaMail ve spolupráci s JAF. Skutečná délka přílohy je tedy shodná s délkou dekódovaného proudu, kterou již spočítat lze (např. pomocí čtení jednotlivých bajtů proudu v cyklu). Dále je nutné pomocí příslušných MIME položek HTTP hlavičky odpovědi oznámit WWW prohlížeči, že mu budou zaslána binární data souboru, jejich správnou délku, MIME typ a případně název přenášeného souboru.5 Content-Type: typ/podtyp Content-Disposition: inline; filename="jméno_souboru" Content-Length: délka_souboru
Po odeslání HTTP odpovědi je už záležitostí WWW prohlížeče, jak s daty přílohy konkrétně naloží. Buď je dokáže přímo zobrazit (např. obrázky, texty, některé dokumenty), nebo nabídne uživateli jejich uložení do souboru na nějaký dostupný disk. Podrobnosti k MIME položce Content-Disposition: HTTP hlavičky odpovědi lze nalézt v [RFC2183].
12.4.3
Přenos souborů z WWW prohlížeče na WWW server
K tomuto přenosu slouží HTML formulář typu multipart/form-data společně se speciálním vstupním HTML elementem INPUT typu file a odesílacím tlačítkem (HTML element 4 Adresa přílohy elektronické zprávy není globálně jedinečná pro celý poštovní server, ale je jedinečná pro aktuální poštovní složku. 5 Název souboru předávaný pomocí parametru filename MIME položky Content-Disposition: není povinný, ale je vhodné ho předávat, protože při ukládání souboru na disk nabídne automaticky systémový dialog WWW prohlížeče právě toto jméno.
12.4. Přílohy elektronických zpráv
53
INPUT typu submit). Velice zjednodušený HTML formulář, pomocí kterého se přepravují soubory (přílohy) z WWW prohlížeče na WWW server vypadá zhruba následovně:
Uživatel si po stisku tlačítka Browse (popř. Prohlížet) vybere pomocí systémového dialogu soubor na disku a stiskem tlačítka Add attachment ho odešle zapouzdřený do HTTP požadavku typu multipart/form-data na WWW server. Tam na něj čeká web mail servlet, který ho má za úkol zpracovat (zakódovat a přidat do vytvářené elektronické zprávy). Potíž je v tom, že současná technologie JavaServlet neumožňuje téměř nijak HTTP požadavky typu multipart/form-data přímo zpracovávat (natož získat z nich případný vložený soubor).6 Jediné co lze, je rozpoznat tento typ HTTP požadavku a získat všechna data, která obsahuje, jako Java proud bajtů. Na programátorovi servletu pak je, jak z daného proudu bajtů získá všechny požadované hodnoty anebo data případného souboru. Je zřejmé, že vytvořit od počátku podprogram, který bude analyzovat vstupní proud MIME dat, není nic snadného. Skoro hned asi každého napdane, že když tento typ HTML formuláře kóduje data pomocí MIME, že by se k jejich získání dal využít vhodný konstruktor ze třídy MimeMessage, který dokáže z proudu bajtů vytvořit elektronickou zprávu. To je sice pravda, ale data odesílaná HTML formulářem nedokáže tento konstruktor zpracovat, protože mají k elektronické zprávě zřejmě ještě trochu daleko. Po zdlouhavém bádání se ale přece jen nalezl způsob, jak lze upravit vstupní proud dat z HTML formuláře tak, aby ho zmíněný konstruktor dokázal analyzovat. Tím speciálním způsobem je sekvenční spojení dvou proudů pomocí objektu třídy SequenceInputStream. Konkrétní realizaci naznačuje následující výpis ze zdrojového kódu web mail servletu. Properties props = System.getProperties(); Session mailSession = Session.getInstance(props, null); String newHeader = "Content-Type: " + request.getContentType() + "\n\n"; InputStream mInputStream = new SequenceInputStream( new ByteArrayInputStream(newHeader.getBytes()), request.getInputStream() ); MimeMessage mimeMsg = new MimeMessage(mailSession, mInputStream);
Docílili jsme tedy toho, že máme data z HTML formuláře uložena jako elektronickou zprávu v objektu třídy MimeMessage. Tato zpráva je MIME typu multipart/form-data, 6
Rozbor požadavků tohoto typu nemá implementován údajně ani technologie ASP. Zde tedy vyhrává skriptovací jazyk PHP, kterému získání souboru z HTTP požadavku typu multipart/form-data údajně nečiní žádné potíže.
12.5. Ukládání WWW stránek do vyrovnávací paměti WWW prohlížeče
54
takže ještě před přístupem k hodnotám jednotlivých HTML entit (např. tlačítka, textová pole) a binárním datům případného souboru je nutné tělo této elektronické zprávy konvertovat na objekt třídy Multipart. Položky tohoto objektu jsou objekty (instance) třídy MimeBodyPart a skrývají už přímo hodnoty a data, která potřebujeme z HTTP požadavku získat – viz obr. [10.2/41] a obr. [10.3/42]. Ještě poznamenejme, že se získanými daty souboru je spojen absolutní název souboru na vzdáleném počítači (tj. i se všemi adresáři a jejich oddělovačemi, které je potřeba odstranit). Maximální délka přílohy, kterou je web mail servlet ochoten přijmout je dána konstantou MAX ATTACHMENT SIZE definovanou ve třídě JavaMailServlet.
12.5
Ukládání WWW stránek do vyrovnávací paměti WWW prohlížeče
Aby veškerá práce WWW prohlížečů byla efektivní, snaží se většina z nich nějakým způsobem snižovat počty přístupů do Internetu. Nejčastějším způsobem bývá právě ukládání přijatých (uživatelem navštívených) WWW stránek do nějaké vyrovnávací paměti WWW prohlížeče (např. do souboru na lokálním pevném disku). WWW prohlížeč tedy uchovává po určitou dobu lokální kopie přijatých WWW stránek. Pokud uživatel vyžaduje po WWW prohlížeči, aby mu ukázal nějakou WWW stránku z Internetu, podívá se prohlížeč nejprve do své vyrovnávací paměti (cache) a pokud zde nenalezne kopii požadované WWW stránky, načte ji z Internetu. Ale pokud kopii WWW nalezne, předloží ji uživateli. Problémem tedy je, že předkládaná kopie nemusí být aktuální. U statických stránek to v podstatě nevadí, ale u dynamicky generovaných ano. Pro web mail aplikaci to totiž znamená, že ve vyrovnávací paměti WWW prohlížeče se i po odhlášení uživatele budou nacházet jeho soukromé věci a kdokoliv má k danému počítači přístup si je může prohlédnout. Také to znamená, že když uživatel trvale odstraní ze své poštovní schránky nějaké elektronické zprávy (popř. poštovní složky) a stiskne ve WWW prohlížeči tlačítko Zpět (popř. Back), načte se mu neaktuální WWW stránka z vyrovnávací paměti WWW prohlížeče. Hodnoty parametrů HTTP požadavků následně zasílaných na WWW server jsou pak neplatné a matoucí. Tyto nepříjemnosti lze odstranit tím, že web mail servlet bude do HTTP hlavičky každé HTTP odpovědi přidávat následující MIME položky (v levém sloupci je uvedena MIME položka a její hodnota, v pravé pak realizace zápisu MIME položek do HTTP odpovědi). Cache-Control: no-cache Cache-Control: no-store Cache-Control: must-revalidate Cache-Control: post-check=0 Cache-Control: pre-check=0 Pragma: no-cache Expires: 0 Last-Modified: aktuální_datum
Tyto MIME položky oznamují WWW prohlížeči, že nesmí ukládat data následující WWW stránky do své vyrovnávací paměti. Položky Cache-Control: jsou uvedeny pro komunikaci pomocí protokolu HTTP/1.1, zatímco Pragma: je pro protokol HTTP/1.0. Kdyby WWW prohlížeč nerozuměl výše uvedeným položkám, jsou zde ještě položky Expires: a Last-Modified:, které oznamují WWW prohlížeči, že platnost dané WWW stránky končí hned po jejím přijetí a zobrazení. Nyní by žádný WWW prohlížeč neměl servletem dynamicky generované WWW stránky ukládat do své vyrovnávací paměti. Každopádně jsme tím poněkud znepříjemnili „pohybuschopnostÿ uživatele, který je nyní do jisté míry omezen na pohyb mezi elektronickými zprávami a poštovními složkami výhradně za pomoci tlačítek, rolovacích menu a hypertextových odkazů, které jsou součástí dynamicky vygenerované WWW stránky (nikoliv za pomoci tlačítek WWW prohlížeče Zpět a Vpřed (resp. tlačítek Back a Forward).
12.6
Záludná čeština a web mail
S počítačovým světem je úzce spojen i anglický jazyk, který je využíván nejenom ve velké části nejrůznějších programů, ale také je pomocí něho na WWW uloženo největší množství informací. Přestože se v poslední době rozšiřuje i český Internet, jsou zdrojový kód a uživatelské rozhraní web mail aplikace vytvořeny v anglickém jazyce. Ale to v žádném případě neznamená, že web mail aplikace si s českými znaky vůbec neporadí. Existuje mnoho různých kódování češtiny. Ve světě operačního systému Windows převládá kódování Cp1250, zatímco ve světě Linuxu pak kódování ISO-8859-2. Pokud není uvedeno jinak, bývá v elektronické poště i WWW stránkách implicitně předpokládáno kódování US-ASCII. Toto implicitní nastavení lze samozřejmě měnit. Právě kódování ISO-8859-2 automaticky generuje web mail servlet do hlaviček a těl vytvářených textových elektronických zpráv, ale i do HTTP hlaviček každé ze servletem dynamicky vygenerovaných WWW stránek. Je to v podstatě implicitní kódování web mail aplikace a lze ho změnit pouze ve zdrojovém kódu web mail servletu (konstanta CHARSET definovaná ve třídě servletu JavaMailServlet). Jedná se o kódování standardizované mezinárodní organizací ISO (International Organization for Standardization) a podporované snad všemi WWW prohlížeči, které umí zobrazovat české znaky.
12.6.1
Čeština v HTTP odpovědích servletu
Jak už víme, servlety generují dynamické WWW stránky pomocí Java proudů. Referenci na takový proud získá servlet voláním metody getWriter() pro textově orientovaná data nebo voláním metody getOutputStream() pro binárně orientovaná data (obě tyto metody jsou definované ve třídě HttpServletResponse). Implicitní kódování znaků u takového proudu je shodné s kódováním, které je nastaveno na WWW serveru, na kterém je servlet spuštěn a samozřejmě ho lze změnit.
12.6. Záludná čeština a web mail
56
Změna kódování HTTP odpovědi servletu se provádí nastavením příslušné položky MIME hlavičky v HTTP odpovědi. Tuto MIME položku je ale nutné v HTTP odpovědi nastavit ještě před tím, než si vyžádáme referenci na daný výstupní proud. Poznamenejme, že proud pro binární data na nastavení této položky hlavičky nebere žádný ohled, a proto hraje důležitou roli pouze pro textový proud. Následující výpis programu ukazuje jak web mail servlet nastavuje kódování češtiny pro většinu HTTP odpověďí. response.setContentType("text/html; charset=" + CHARSET); PrintWriter servletPrint = new PrintWriter( new BufferedWriter(response.getWriter()) );
Přičemž response je reference na objekt třídy HttpServletResponse, kterou předává servlet container přímo do příslušné metody doGet() (popř. doPost()) jako vstupní parametr.
12.6.2
Čeština na WWW stránkách a v elektronických zprávách
Samozřejmě i WWW stránky a elektronické zprávy mohou obsahovat české texty a opět je nutné to někde explicitně naznačit. U elektronických zpráv se naznačení provádí pomocí MIME položky Content-Type a jejího parametru charset. Content-Type: text/plain; charset=iso-8859-2
U česky psaných WWW stránek se tato situace řeší podobným způsobem v HTML hlavičce dané WWW stránky. <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-2">
12.6.3
Čeština v HTTP požadavcích od WWW prohlížeče
Web mail servlet dostává od WWW prohlížeče různé HTTP požadavky a podle parametrů, které tyto požadavky nesou se rozhoduje, jakou HTTP odpověď dynamicky vygeneruje. Požadavky přicházející na web mail servlet mohou samozřejmě také obsahovat české znaky (např. parametry zasílané z textových polí HTML formulářů). Implicitní kódování těchto hodnot stanovuje WWW prohlížeč. V našich zeměpisných šířkách je toto kódování nejčastěji ISO-8859-1. Ale ne všude tomu tak musí být, a proto je možné ho ve zdrojovém kódu servletu změnit (konstanta FORM CHARSET definovaná ve třídě JavaMailServlet). Jedná se tedy o nastavení kódování příchozích HTTP požadavků, které může web mail servlet potřebovat změnit na jiné národní kódování (např. z kódování ISO-8859-1 na ISO-8859-2). Změna kódování znaků řetězce v jazyce Java se provádí pomocí jednoho z konstruktorů třídy String. Následující metoda provádí ve web mail servletu změnu kódování řetězců přijatých v HTTP požadavku z HTML formuláře.
Převod příslušných řetězců HTTP požadavku ze vstupního kódování ISO-8859-1 do kódování ISO-8859-2 pomocí metody strCharsetEncode() se provádí jak pro HTTP požadavky zaslané na servlet HTTP metodou PUT, tak i pro požadavky zaslané metodou GET.
12.6.4
Čeština v názvu poštovních složek na IMAP4 serveru
Protože IMAP4 protokol je mnohem propracovanější než protokol POP3, umožňuje poštovním klientům vytvářet libovolně pojmenované poštovní složky. Názvy těchto složek mohou být samozřejmě v různých jazycích, tedy také např. v češtině. Název poštovní složky je nutné IMAP4 serveru předat zakódovaný pomocí upraveného base64 kódování. JavaMail API umožňuje práci s takto pojmenovanými složkami, a proto byla implementována jejich podpora do vytvořené web mail aplikace. Pouze je opět nutné převést WWW prohlížečem zaslané jméno poštovní složky z kódování ISO-8859-1 na kódování ISO-8859-2 pomocí zmíněné metody strCharsetEncode().
12.7
Dynamické generování WWW stránek
Web mail servlet přijímá a zpracovává HTTP požadavky od WWW prohlížeče. Každý požadavek vyhodnotí a dynamicky pro něj vygeneruje příslušnou HTTP odpověď. Tato HTTP odpověď může mít buď textový charakter, nebo binární. HTTP odpovědi textového charakteru se vytváří pomocí metod print() a println() objektu třídy PrintWriter. Obvykle se jedná o HTML text (WWW stránku). Následující výpis naznačuje, jak ve zdrojovém kódu web mail servletu vypadá dynamické generování WWW stránky. response.setContentType("text/html; charset=" + CHARSET); PrintWriter servletPrint = new PrintWriter(new BufferedWriter(response.getWriter())); servletPrint.println(" \n" + " Date Sent: " + msg.getSentDate().toString());
HTTP odpovědi binárního charakteru (např. soubory, obrázky) se vytváří sekvenčním zápisem jednotlivých bajtů do binárního proudu HTTP odpovědi. response.setHeader("Content-Disposition", "inline; filename=\"" + part.getFileName() + "\";"); response.setContentType(part.getContentType()); response.setContentLength(partFileSize);
12.7. Dynamické generování WWW stránek
58
int i; BufferedInputStream pBuffInputStream = new BufferedInputStream( part.getInputStream() ); ServletOutputStream servletOutput = response.getOutputStream(); while ( (i = pBuffInputStream.read()) != -1 ) servletOutput.write(i); pBuffInputStream.close();
K WWW prohlížeči jsou data odeslána až po vyvolání metody flush(), která je součástí obou použitých tříd (PrintWriter i ServletOutputStream).
59
Kapitola 13 Web mail ze strany administrátora V předešlých dvou kapitolách jsme se zabývali uživatelským a programátorským pohledem na web mail aplikaci. Nyní, když máme představu co všechno web mail umí a jak je to pomocí technologie JavaServlet zajištěno, vyvstává otázka, jak a kde daný servlet zprovoznit. A právě o tom by měla být tato kapitola.
13.1
Volba WWW serveru
Na světě se v dnešní době používá celá řada WWW serverů. Mezi dva nejpoužívanější se řadí volně dostupný WWW server Apache a komerční produkt firmy Microsoft – WWW server IIS. WWW server Apache je volně dostupný pro různé platformy, zatímco IIS je vyvíjen pouze pro platformu Microsoftu – Windows. Možná právě to, kvalita a rychlost staví WWW server Apache na první místo v používání. WWW server Apache neumí sám o sobě spouštět servlety. Proto byl vyvinut JServ, což je speciální modul, který umí nastartovat servlet pomocí JVM a předávat vybrané HTTP požadavky z Apache do JVM daného servletu. Jserv modul umí pracovat pouze se Servlet API 2.0 (v současné době je dostupné Servlet API 2.3). Tento modul je vhodný pokud je většina WWW stránek statických, ale spíše se vyplatí používat spojení WWW serveru Apache se serverem Tomcat. Tomcat je společný projekt nadace Apache a Sun Microsystems. Díky tomu umí spolupracovat se servlety podle nejnovější specifikace Servlet API. Dříve byl Tomcat servlet container , který se k WWW serveru Apache pouze připojoval. V současné době si můžeme vybrat jestli chceme spouštět Tomcat samostatně (jako plnohodnotný WWW server) nebo pouze jako servlet container napojený na WWW server Apache (popř. na WWW server IIS). Se statickými stránkami pracuje samozřejmě lépe WWW server Apache, ale pro servlety je nejvhodnější WWW server Tomcat, proto je využíván i pro chod web mail aplikace.
13.2. WWW server Tomcat
13.2
WWW server Tomcat
13.2.1
Spouštění servletů
60
O spouštění servletů se stará WWW server. Je čistě na něm, zda bude servlety spouštět hned po svém startu nebo až při příchodu prvního HTTP požadavku. Nepříjemné však je, že při tvorbě a ladění servletu se musí pro ukončení spuštěného a následné spuštění upraveného servletu restartovat celý WWW server, což je zdlouhavá operace. Existuje však způsob, jak WWW serveru Tomcat říci, že má sám automaticky ukončit spuštěný servlet a spustit jeho upravenou verzi. To, je-li dostupná novější verze servletu, pozná Tomcat podle datumu a času servletu (soubor s koncovkou .class na WWW serveru – viz [13.3/60]). Toto automatické nahrávání servletů lze u WWW serveru Tomcat povolit v jeho konfiguračním souboru – viz příl. [E/80].
13.2.2
Aktivace SSL (HTTPS)
Pro bezpečnou komunikaci mezi WWW prohlížečem a WWW serverem je Tomcat v podstatě připraven. Jednoduchým zásahem do konfiguračního souboru lze aktivovat na stanoveném TCP portu šifrování dat pomocí SSL – viz příl. [E/80]. Konfigurační soubor je na WWW serveru Tomcat uložen v adresáři TOMCAT HOME/conf a jmenuje se server.xml. Důležité však je nezapomenout vytvořit úložiště certifikátů (keystore) a vygenerovat kořenový certifikát (root certificate), kterým se bude Tomcat WWW prohlížečům představovat. Toto úložiště a kořenový certifikát lze vytvořit pomocí programu keytool ze standardní distribuce Javy (J2SE, popř. i J2EE). JAVA HOME/bin/keytool -genkey -alias jméno -keyalg RSA Tento program bude vyžadovat zadání několika údajů, které je potřeba vyplnit. Aby při navazování komunikace WWW serveru s WWW prohlížečem probíhalo vše tak jak má, je nutné jako CN (Comunity Name) a OU (Organizational Unit) zadat doménové jméno (popř. IP adresu) WWW serveru.
13.3
Webový archiv (WAR file)
Pro začátečníka je spuštění servletu na WWW serveru poměrně náročnou operací. Tuto činnost mu může usnadnit to, že autor servletu ho dodá ve speciálním zkomprimovaném souboru (archivu), který bývá označován jako WAR archiv (Web ARchive file). Tento archiv pak stačí umístit do adresáře, kde WWW server Tomcat uchovává z Internetu přístupné WWW stránky a soubory (TOMCAT HOME/webapps). Potom je nutné WWW server restartovat a on už sám zajistí správné umístění servletu (do adresáře, jehož jméno je shodné se jménem WAR archivu – bez koncovky) a případné spuštění servletu. Vlastní WAR archiv má speciální strukturu, která je znázorněna na obr. [13.1/61].
13.3. Webový archiv (WAR file)
61
Obrázek 13.1: Struktura WAR archivu V souboru s popisem vztahu servletu k WWW serveru (deployment descriptor ) se nachází informace o mapování třídy servletu na URL příchozího HTTP požadavku – viz příl. [D/79]. WAR archiv obsahuje speciální adresářovou strukturu jak ukazuje obr. [13.1/61]. Jinak se v podstatě jedná o běžný JAR archiv (Java ARchiver ). Pokud máme na WWW serveru umístěn nějaký servlet a jeho popisovač v uvedené adresářové struktuře, můžeme ho snadno zkomprimovat do WAR archivu. Pouze vstoupíme do kořenového adresáře (adresář [ROOT] na obr. [13.1/61]) a spustíme archivační program jar, který je dodáván jako součást standardní distribuce Javy (J2SE, popř. i J2EE). JAVA HOME/bin/jar -cf nějaké jméno.war ./
62
Kapitola 14 Závěr Téma „Web mailÿ úzce souvisí s elektronickou poštou, která je snad nejpoužívanější službou Internetu. Vlastní realizace jakékoliv WWW aplikace není jednoduchou záležitostí a zahrnuje řešení nejrůznějších problémů. V současné době je pro většinu tvůrců WWW aplikací hlavním nástrojem populární skriptovací jazyk PHP. V poslední době však nezanedbatelně vzrůstá také popularita nových technologií jazyka Java (JSP, JavaServlet), jimž někteří prorokové věští velkou budoucnost. Potřebné prográmátorské detaily těchto technologií nejsou ještě příliš rozšířeny, ale přesto byl pro realizaci web mail aplikace zvolen programovací jazyk Java a technologie JavaServlet.
14.1
Rekapitulace dosažených výsledků
Kapitola [6/24] týkající se návrhu web mail systému pojednává o několika již hotových web mail aplikacích. Na těchto aplikacích spolupracovalo mnohdy i několik programátorských skupin a jejich dokonalost je spojena s jejich používáním v praxi a následným odstraňováním chyb a rozšiřováním služeb. Vytvořená web mail aplikace tedy oproti těmto systémům o mnoho zaostává. Poskytuje však veškeré základní funkce potřebné pro manipulaci s elektronickou poštou pomocí WWW prohlížeče a protokolů SMTP, POP3 a IMAP4. Navíc je možné pomocí web mail aplikace přeposlat více elektronických zpráv vložených do jedné velké zprávy s MIME typem multipart/digest. Tato funkce byla implementována, protože běžné web mail aplikace neumožňují přeposlat více elektronických zpráv najednou. Další vlastností, kterou se vytvořená web mail aplikace odlišuje od některých poštovních klientů, je možnost vytvářet, přejmenovávat a rušit česky pojmenované poštovní složky.
14.2. Řešené problémy při realizaci
14.2
63
Řešené problémy při realizaci
Při realizaci web mail aplikace se vyskytlo několik problémů, které bylo potřeba vyřešit. Jejich řešení nebylo jednoduché, ale nakonec se přeci jen podařilo. První překážkou bylo navrhnutí a odladění rekurentní metody displayPart(), která má v podstatě tu nejdůležitější a zároveň nejsložitější funkci v celé web mail aplikaci. Jejím úkolem totiž je rozbor elektronické zprávy a jejích příloh (včetně případného rozboru dalších rekurentně vnořených elektronických zpráv a jejich příloh). Druhou překážkou bylo vytvoření a odladění jednoznačného adresování příloh elektronických zpráv (přílohy mohou být libovolně hluboko v rekurentní datové struktuře, kterou popisuje MIME). Třetí překážkou se přesně podle očekávání stala čeština, která komplikuje práci nejen tvůrcům WWW aplikací, ale obecně všem programátorům.1 Právě proto byla věnována čestině celá podkapitola. Čtvrtou a poslední překážkou (zřejmě nejvíce komplikovanou) bylo vytvoření a odladění metody pro rozbor příchozích HTTP požadavků zasílaných HTTP metodou POST pomocí HTML formuláře typu multipart/form-data.
14.3
Známé nedostatky realizované aplikace
Řešení zmíněných problémů bylo časově náročné a jejich odladění zabralo také mnoho času. Proto nezbyl dostatek času na implementaci dalších rozšiřujících funkcí, které by celou web mail aplikaci určitým způsobem zdokonalily. Uvedené nedostatky v žádném případě nijak neovlivňují standardní chod web mail aplikace. Mezi rozšiřující funkce, které nejsou ve web mail aplikaci implementovány, patří např. vyhledávání elektronických zpráv v poštovních složkách podle různých klíčových slov. Toto vyhledávání podporuje jak protokol IMAP4, tak JavaMail API. Také není implementováno řazení elektronických zpráv a poštovních složek např. podle abecedy nebo podle odesilatele (sestupně, popř. vzestupně). Tyto rozšiřující funkce pravděpodobně budou implementovány v budoucí verzi web mail aplikace. Některé SMTP, POP3 nebo IMAP4 servery mohou podporovat pomocí SSL zabezpečenou komunikaci s klientem (v našem případě web mail servletem). A právě to je další nedostatek web mail aplikace, která podporuje zabezpečenou SSL komunikaci pouze mezi WWW prohlížečem a WWW serverem. Plně zabezpečené čtení a odesílání elektronické pošty je tedy možné pouze v případě, že web mail servlet je spuštěn na WWW serveru, který je zároveň také IMAP4 serverem (popř. ještě POP3 serverem). Obecně se v jazyce Java šifrování TCP spojení pomocí SSL provádí již při vytváření tzv. soketu (socket), pomocí něhož se pak komunikuje. Při využití JavaMail API však programátor nevytváří žádný soket, ten za něho vytváří JavaMail a programátor nemá možnost ovlivnit jeho vytváření. Navázání bezpečného TCP spojení se provádí pomocí balíku 1 Komplikace bývají způsobeny jak množstvím různých kódování českých znaků, tak i jejich psaním na různých platformách.
14.4. Testování web mail aplikace
64
javax.net.ssl (nyní je součástí distribuce J2SE verze 1.4, dříve byl externí a označován jako JSSE – Java Secure Socket Extension), ale nepodařilo se zjistit, je-li možné jeho možnosti spojit přímo s JavaMail API. V současné době se plánuje vývoj nové verze JavaMail API verze 1.3 (aktuální stabilní verze je 1.2), která bude možná obsahovat přímou podporu využití SSL při navazování spojení s poštovním serverem.
14.4
Testování web mail aplikace
V průběhu realizace byla web mail aplikace testována na nejrůznějších datech (elektronických zprávách). Při testování bylo zjištěno, že zdaleka ne všechny existující poštovní aplikace dodržují při vytváření elektronických zpráv doporučení [RFC822] a standard MIME. Takové zprávy pak při rozboru působí poštovním klientům nemalé starosti. Testování komunikace s různými poštovními servery bylo úspěšné. Odesílání elektronických zpráv prostřednictvím protokolu SMTP bylo odzkoušeno na SMTP serverech: smtp.zcu.cz a smtp.seznam.cz. Čtení elektronických zpráv pomocí protokolu POP3 bylo testováno na POP3 serverech: pop.zcu.cz, pop3.seznam.cz a pop3.post.cz. Schopnosti protokolu IMAP4 byly prověřeny na IMAP4 serverech imap.zcu.cz a adela.fel.zcu.cz. Komunikace web mail aplikace s různými WWW prohlížeči byla také odzkoušena. Testování probíhalo pomocí WWW prohlížečů: Internet Explorer 6.0, Netscape Navigator 6.2, Mozila 0.9.5, Links 0.93 a Lynx 2.8.4 – viz příl. [F/82]. Web mail aplikace byla zatím pečlivě odzkoušena pouze na WWW serveru Tomcat, ale nemělo by činit velké potíže ji zprovoznit na jakémkoliv jiném WWW serveru s nainstalovanou podporou technologie JavaServlet.
14.5
Celkové zhodnocení
Cílem diplomové práce bylo seznámit se s existujícími web mail systémy a jejich architekturou, navrhnout a realizovat vlastní systém založený na vhodném HTTP serveru. Tyto cíle se podařilo splnit. Před započetím realizace práce podobného charakteru je dobré pořádně zvážit a promyslet si, který skriptovací jazyk nebo serverovou technologii k realizaci využít. Jako příklad uveďme velice propracovaný skriptovací jazyk PHP (je určen výhradně pro tvorbu dynamických WWW stránek) a naproti němu jazyk Java a technologii JavaServlet. Řešení web mail aplikace pomocí jazyka Java bylo poměrně náročné, možná by bylo snažší a rychlejší vytvořit aplikaci pomocí jazyka PHP. Web mail aplikace je vytvořena pomocí jazyka Java a technologie JavaServlet, při realizaci byl kladen důraz na přenositelnost aplikace pod různé platformy (přenositelnost je jedna z nejdůležitějších předností jazyka Java). Také byl důraz kladen na funkčnost aplikace s různými WWW prohlížeči a WWW servery.
65
Literatura [Her00]
Herout, P. : Učebnice jazyka Java, Nakladatelství KOPP, České Budějovice, 2000.
[Her01]
Herout, P. : Java – grafické uživatelské prostředí a čeština, Nakladatelství KOPP, České Budějovice, 2001.
[HTML]
W3C : HTML 4.01 Specification, W3C Recommendation, http://www.w3.org/TR/html401, 1999.
[Kol96]
Kolář, P. : Sendmail, http://www.euke.sk/~paulik/sendmail, 1996.
[Kun01]
Kunderová, L. – Liška, I. : Datová komunikace a informační zdroje, http://www.mendelu.cz/user/lidak/site3/, Ústav informatiky PEF MZLU v Brně, 2001.
[Pet02]
Peterka, J. : Články, přednášky a tutoriály, http://earchiv.isdn.cz, 2002.
[RFC821]
Postel, J. : Simple Mail Transfer Protocol, RFC 821, http://www.ietf.org/rfc.html, 1982.
[RFC822]
Crocker, D. : Standard for the Format of ARPA Internet Text Messages, RFC 822, http://www.ietf.org/rfc.html, 1982.
[RFC1149] Waitzman, D. : A Standard for the Transmission of IP Datagrams on Avian Carriers, RFC 1149, http://www.ietf.org/rfc.html, 1990. [RFC1939] Myers, J. – Rose, M. : Post Office Protocol – Version 3, RFC 1939, http://www.ietf.org/rfc.html, 1996. [RFC2045] Borenstein, N. – Freed, N. : MIME Part One: Format of Internet Message Bodies, RFC 2045, http://www.ietf.org/rfc.html, 1996.
Literatura
66
[RFC2046] Borenstein, N. – Freed, N. : MIME Part Two: Media Types, RFC 2046, http://www.ietf.org/rfc.html, 1996. [RFC2047] Borenstein, N. – Freed, N. : MIME Part Three: Message Header Extensions for Non-ASCII text, RFC 2047, http://www.ietf.org/rfc.html, 1996. [RFC2060] Crispin, M. : Internet Message Access Protocol - Version 4rev1, RFC 2060, http://www.ietf.org/rfc.html, 1996. [RFC2183] Troost, R. – Dorner, S. – Moore, K. : Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field, RFC 2183, http://www.ietf.org/rfc.html, 1997. [Sun02]
Sun Microsystems, Inc. : http://java.sun.com, The Source For JavaTM Technology, 2002.
[Tom02]
Apache Software Foundation: http://jakarta.apache.org/tomcat/, Part of the Jakarta Project, 2002.
[Wu00]
Wu, A. W. : Performance Comparison of Alternative Solutions For Web-to-Database Applications, Master degree thesis, http://rain.vislab.olemiss.edu/~ww1/homepage 2000.
67
Přílohy
68
Příloha A Zdrojový kód třídy PartAddress Tato příloha obsahuje zdrojový kód třídy PartAddress, která je ve web mail aplikaci používána v souvislosti s jednoznačným adresováním příloh elektronických zpráv. Stručný popis problému lze nalézt v [12.4.1/51], veškeré další realizační detaily pak v této příloze. /* * @(#)MailUserData.java 1.0 MAY-18-2002 * * Copyright 2002 George Patera software (GPsoft) * * This software is part of the "Web mail" diploma thesis * made at the Faculty of Applied Sciences at the University * of West Bohemia (Department of Informatics and Computer * Sciences -- specialization Distributed Systems). * * ZCU-FAV5-IVT-DS (summer term 2002 -- by Jiri Patera) * * This class is used to create unique addressing scheme for bodyparts * of MIME multipart msgs. MIME is recursive structure and RFC822 headers * "Message-Id:" and "Content-Id:" only SHOULD be in all e-mail msgs. */
import java.io.*; import java.util.*;
// import of standard Java packages
/** * This class is used to create unique addressing scheme for bodyparts * of MIME multipart msgs. MIME is recursive structure and RFC822 headers * "Message-Id:" and "Content-Id:" only SHOULD be in all e-mail msgs. * The purpose of this class is to unique address any part in structured * MIME multipart msg. The part address is unique only due to actual folder. * It is composed from msg number, dot and dotted decimal numbers which tells * the WebMail servlet which hyer-link belongs to which msg and its part. */ class PartAddress { /** * This is the part’s address string. It contains corresponding msg’s number * and a way to its specific bodypart. It is composed of dotted decimal numbers. */ private String pAddress;
69
/** * This constructor overrides default constructor. It stores the initial * value to part address variable (pAddress). */ public PartAddress(String pAddress) { this.pAddress = pAddress; } /** * This method decreases part’s deepness (depth). So if the part has a part address * of 25.9.3.11.3 then after calling this method part address variable * pAddress is going to have a value of 25.9.3.11. */ public void decPartDeepness() { if (getPartDeepness() > 1) pAddress = pAddress.substring(0, pAddress.lastIndexOf(".")); } /** * This method reads a msg number from a part address (from a variable * pAddress stored in this class). * * @return the msg number which is got from the pAddress variable */ public int getMessageNumber() { if (getPartDeepness() > 1) return Integer.valueOf(pAddress.substring(0, pAddress.indexOf("."))).intValue(); else return Integer.valueOf(getPartAddr()).intValue(); } /** * This is a getter method for a string variable pAddress. * * @return the string variable pAddress */ public String getPartAddr() { return pAddress; } /** * This method calculates part’s deepness (depth). So if the part has a part address * of 25.9.3.11.2.8.1 then after calling this method the caller will * receive the value 7 (so msg’s deepness equals to 1). * * @return the deepness (depth) of the part which has address pAddress */ public int getPartDeepness() { StringTokenizer strTokens = new StringTokenizer(this.pAddress, "."); return strTokens.countTokens(); } /** * This method increases part’s address. So if the part has a part address * of 78.3.1.6 then after calling this method part address variable * pAddress is going to have a value of 78.3.1.7. */ public void incPartAddr() { if (pAddress.lastIndexOf(".") != -1) { String tempStr = pAddress.substring(pAddress.lastIndexOf(".") + 1); decPartDeepness(); incPartDeepness( String.valueOf(Integer.valueOf(tempStr).intValue() + 1) ); } }
70
/** * This method increases part’s deepness (depth). So if the part has a part address * of 25.9.3.11 then after calling this method part address variable * pAddress is going to have a value of 25.9.3.11.1. */ public void incPartDeepness() { pAddress = pAddress.concat(".1"); } /** * This method increases part’s deepness (depth). So if the part has a part address * of 25.9.3.11 then after calling this method with a parameter * 8 part address variable pAddress is going to have * a value of 25.9.3.3.11.8. * * @param tempStr the value to add to pAddress variable * instead of value ".1" */ public void incPartDeepness(String tempStr) { pAddress = pAddress.concat("." + tempStr); } /** * This is a setter method for a string variable pAddress. * * @param pAddress the string (part address) to be stored in the variable * pAddress */ public void setPartAddr(String pAddress) { this.pAddress = pAddress; } }
// end "class PartAddress {"
71
Příloha B Zdrojový kód třídy MailUserData Vztah objektu třídy MailUserData k HTTP relaci je stručně popsán v [12.2/49]. Objekt této třídy bývá ve zdrojovém kódu web mail servletu (třída JavaMailServlet) často používán pro získání různých informací o uživateli a stavu HTTP relace, která se k němu vztahuje. Tato příloha obsahuje úplný zdrojový kód třídy MailUserData. /* * @(#)MailUserData.java 1.0 MAY-18-2002 * * Copyright 2002 George Patera software (GPsoft) * * This software is part of the "Web mail" diploma thesis * made at the Faculty of Applied Sciences at the University * of West Bohemia (Department of Informatics and Computer * Sciences -- specialization Distributed Systems). * * ZCU-FAV5-IVT-DS (summer term 2002 -- by Jiri Patera) * * This class is used to store user’s session data. It contains many useful * informations about the user. It is an attribute of HTTP session. * Every mail session HAS TO have a MailUserData attribute (MUD attribute). */
/** * MailUserData class (MUD) is a class used to store user’s * session data. It contains many useful informations about the user. * It is an attribute of HTTP session. Every mail session HAS TO have * a MailUserData attribute (MUD attribute) set. * * @author George (Jiri) Patera * @version 1.0, MAY-18-2002 */ public class MailUserData {
72
/** * The complete URL of mail server the user want to connect to. This complete * URL contains all needed informations for establishing a connection and * a mail session with a mail server. It may looks something like this: * protocol://username:[email protected], where * protocol can be IMAP4 or POP3. */ URLName url; /** * this is a mail session established with a mail server (IMAP4 or POP3 server). * Webmail servlet can get a Store class object from a mail * session object. */ Session session; /** * The Store you can imagine as some kind of a database. It is * most often used to get [ROOT] folder from a mail server * (this folder is sometimes called default folder). */ Store store; /** * This variable is going to hold actually processed folder (actual folder). */ Folder folder; /** * Message class object contains a message which is being composed. * This msg’s number is always zero and is not stored in any folder, it’s * only stored in MailUserData object. If no msg is being processed, * the Message object is null. */ Message message; /** * This string variable contains user’s From: address which * is related to one HTTP (mail) session. It is here to make entering * an e-mail msg more easy for users which are logged in. So they can enter * the From: address only one time. */ String fromAddr; /** * This constructor overrides default constructor. An object of * MailUserData class can be created only with given complete URL. * When URL is null it means that this MailUserData * object is created for a HTTP session of the user who is not logged in. * * @param url complete URL name which will be written to a URLName * variable */ public MailUserData(URLName url) { this.url = url; } /** * This is a getter method for variable folder (mail folder). * * @return the requested variable -- folder */ public Folder getFolder() { return folder; }
73
/** * This is a getter method for variable fromAddr (RFC822 * From: address). * * @return the requested string variable -- fromAddr */ public String getFromAddr() { return fromAddr; } /** * This is a getter method for variable message (e-mail message). * * @return the requested variable -- message */ public Message getMessage() { return message; } /** * This method returns Multipart class object which is got * from a MUD variable message. * * @return the Multipart class object or null * if no msg is stored in MailuserData object * @exception MessagingException if some error during processing the msg occurs * @exception IOException if an I/O error occurs */ public Multipart getMultipart() throws MessagingException, IOException { Multipart multipart = null; if ( (message != null) && (message.isMimeType("multipart/*")) ) multipart = (Multipart)message.getContent(); return multipart; } /** * This method returns a protocol which is used to connect to a mail server. * The protocol is got from a complete URL by method url.getProtocol(). * * @return the protocol from URLName variable stored in string */ public String getProtocol() { if (url != null) return url.getProtocol(); else return null; } /** * This is a getter method for variable session (mail session). * * @return the requested variable -- session */ public Session getSession() { return session; }
/** * This is a getter method for variable store (mail store). * * @return the requested variable -- store */
74
public Store getStore() { return store; } /** * This is a getter method for variable URLName * * @return the requested variable -- URLname */ public URLName getURLName() { return url; } /** * This is a setter method for variable folder (mail folder). * * @param folder the mail folder to be saved in MailUserData object */ public void setFolder(Folder folder) { this.folder = folder; } /** * This is a setter method for string variable fromAddr * (RFC822 From: address). * * @param fromAddr the string which contains an e-mail msg’s RFC822 * From: address to be stored in * MailUserData object */ public void setFromAddr(String fromAddr) { this.fromAddr = fromAddr; } /** * This is a setter method for variable message (e-mail message). * * @param message the e-mail message to be stored in MailUserData object */ public void setMessage(Message message) { this.message = message; } /** * This is a setter method for variable session (mail session). * * @param session the mail session to be stored in MailUserData object */ public void setSession(Session session) { this.session = session; } /** * This is a setter method for variable store (mail store). * * @param store the mail store to be saved in MailUserData object */ public void setStore(Store store) { this.store = store; } }
// end "public class MailUserData {"
75
Příloha C Zdrojový kód metody parseMultipartFormData() ze třídy JavaMailServlet V souvislosti s využíváním technologie JavaServlet se můžeme dočíst (např. v [9.2.1/37] nebo na [Sun02]), že tato technologie přímo podporuje pouze HTTP požadavky zasílané pomocí HTML formuláře typu application/x-www-form-urlencoded – viz [8.2.1/34]. Tyto HTML formuláře však nejsou vytvořeny pro přepravu binárních souborů z WWW prohlížeče na WWW server. Přeprava souborů se obvykle řeší pomocí HTML formulářů typu multipart/form-data – viz [8.2.2/35], jejichž podpora není v současné době součástí technologie JavaServlet. Tato příloha obsahuje zdrojový kód metody parseMultipartFormData(), která je součástí web mail servletu. Zmíněná metoda řeší nedostatek technologie JavaServlet prostřednictvím JavaMail API – viz [12.4.3/52]. /** * The method which is able to parse incomming HTTP requests from HTML form of the type * multipart/form-data (incomming HTTP requests can contain a file). * HTML from of this type is only one in WebMail servlet and is situated in * "Compose message" HTML form. This method also handles HTTP requests: *
*
save a copy to a folder (submit button "mSaveCopyTo") *
add an attachment (submit button "mAddAttachment") *
* This method is the one I am really proud of. It takes a lot of time to find * out how to realize it using standard (java.*) and optional (javax.*) Java * packages. It uses SequenceInputStream class and JavaMail. * * @param mud is object containing user’s informations (URL, store, mailSession, * actual folder, composing message) * @param httpSession if the user is not logged in we need to know the HTTP session for adding * newly created MailUserData object to it as an attribute * @param request for additional informations (f.e. HTTP request’s URI) * @param servletPrint PrintWriter to output data of textual character to * @exception IOException if an I/O error occurs */
76
private void parseMultipartFormData(MailUserData mud, HttpSession httpSession, HttpServletRequest request, PrintWriter servletPrint) throws Exception { String smtphost = null; String from = null, to = null, cc = null, bcc = null; String subject = null, text = null; String fDstSel = null, mSaveCopyTo = null; String mAddAttachment = null, mSend = null, mReset = null; MimeBodyPart mimeAttachment = null; Session mailSession = null; if (!request.getContentType().toLowerCase().startsWith("multipart/form-data")) { return; // if there is no "multipart/form-data" HTTP request } if ( (mailSession = mud.getSession()) == null ) { // to create a message from an InputStream we need a temporary "mailSession" Properties props = System.getProperties(); mailSession = Session.getInstance(props, null); } Message mimeMsg = null; String pName = null; String fileName = null; // variables for extraction of only filename ("filename.ext", no "/home/user/filename.ext") int beginIndex = -1, endIndex = -1; // now the key operation -- the JavaMail constructor can’t create a msg object // right from HTTP request’s stream, there is a need to add one MIME header field // to this request before processing it by JavaMail; the "formPutHeader" // value HAVE TO be written as below (don’t chage it or nothing will work properly) String formPutHeader = "Content-Type: " + request.getContentType() + "\n\n"; InputStream mInputStream = new SequenceInputStream(new ByteArrayInputStream(formPutHeader.getBytes()), request.getInputStream()); // OKay, now create the msg object from updated HTTP request’s InputStream // and start with analyzing it by the common way mimeMsg = new MimeMessage(mailSession, mInputStream); Object mimeMsgContent = mimeMsg.getContent(); // the created msg MUST be of the MIME type "multipart/mixed" if (mimeMsgContent instanceof MimeMultipart) { MimeMultipart mimeMultipart = (MimeMultipart)mimeMsgContent; // each bodypart of multipart is one HTML object (text area, button, // file dialog data, etc.), so we have to extract required values // from the multipart for (int i = 0; i < mimeMultipart.getCount(); i++) { BodyPart bodyPart = mimeMultipart.getBodyPart(i); if (bodyPart instanceof MimeBodyPart) { // get the MIME bodypart’s Content-Disposition header field; this // field contains informations if this MIME bodypart is a file or not MimeBodyPart mimeBodyPart = (MimeBodyPart)bodyPart; String dispHeader = mimeBodyPart.getHeader("Content-Disposition")[0]; // now start finding of the parameter "name" of the Content-Disposition // header field -- it corresponds to appropriate HTML "name" attribute // which names all elements of HTML form beginIndex = dispHeader.indexOf(" name=\"") + 7; // (" name=\"").length() == 7 endIndex = dispHeader.indexOf("\"", beginIndex); pName = null;
here we’re going to find out if this MIME bodypart is a file and has a filename or not; remember the filename given by system’s file open dialog (HTML: "") contains absolute path to a file (f.e. "c:\data\filename.ext" or "/home/usr/data/filename.ext") and we need only the "filename.ext" ( (beginIndex = dispHeader.lastIndexOf("\\") + 1) <= (-1 + 1) ) if( (beginIndex = dispHeader.lastIndexOf("/") + 1) <= (-1 + 1) ) if ( (beginIndex = dispHeader.indexOf(" filename=\"") + 11) <= (-1 + 11) ) beginIndex = -1; endIndex = dispHeader.indexOf("\"", beginIndex); fileName = null; if ( (beginIndex > (-1 + 1)) && (endIndex > beginIndex) ) fileName = dispHeader.substring(beginIndex, endIndex); // here we have the "name" and optional "filename" values so we can // reach right the bodypart’s data (values of HTML elements) if (pName.matches("smtphost")) smtphost = (String)mimeBodyPart.getContent(); else if (pName.matches("from")) from = (String)mimeBodyPart.getContent(); else if (pName.matches("to")) to = (String)mimeBodyPart.getContent(); else if (pName.matches("cc")) cc = (String)mimeBodyPart.getContent(); else if (pName.matches("bcc")) bcc = (String)mimeBodyPart.getContent(); else if (pName.matches("subject")) subject = (String)mimeBodyPart.getContent(); else if (pName.matches("text")) text = (String)mimeBodyPart.getContent(); else if (pName.matches("fDstSel")) fDstSel = (String)mimeBodyPart.getContent(); else if (pName.matches("mSaveCopyTo")) mSaveCopyTo = (String)mimeBodyPart.getContent(); else if (pName.matches("mAddAttachment")) mAddAttachment = (String)mimeBodyPart.getContent(); else if (pName.matches("mSend")) mSend = (String)mimeBodyPart.getContent(); else if (pName.matches("mReset")) mReset = (String)mimeBodyPart.getContent(); else if (pName.matches("fileName")) // getting the file data from a HTTP request and putting it in appropriate MimeBodyPart // object is a special operation; to create an attachment of type different from "text/plain" // we have to use a DataHandler object (JavaActivationFramework) to encapsulate the part’s; // data to befor putting them in MimeBodyPart object; last we need to setup the "filename.ext" // filename in addition: it seems that WWW browser’s do not encode the data // using "base64" or "quoted-printable" but using "8bit" and] // that causes the problem which solves use of Datahandler object if (fileName != null) { MimePartDataSource mpds = new MimePartDataSource(mimeBodyPart); mimeAttachment = new MimeBodyPart(); mimeAttachment.setDataHandler(new DataHandler(mpds)); mimeAttachment.setFileName(fileName); } } else { // end "if (bodyPart instanceof MimeBodyPart) {" printErrorCompose(null, null, "Error: Your browser has sent invalid \"Multipart/Form-Data\"! (NOT MimeBodyPart)", request, servletPrint); } }
// end "for (int i = 0; i < mimeMultipart.getCount(); i++)"
78
} else { // end "if (mimeMsgContent instanceof MimeMultipart) {" printError(null, "Error: Your browser has sent invalid \"Multipart/Form-Data\"! (NOT MimeMultipart)", servletPrint); } // next code handles user’s hits of a few submit buttons from "Compose" HTML form if (request.getContentLength() > MAX_ATTACHMENT_SIZE) { // don’t add an attachment into MUD if it is too large but add textual data mud.setMessage( mCreate(mud, smtphost, from, to, cc, bcc, subject, text, null, request, servletPrint) ); printErrorCompose(null, "Error: You have exceed MAX attachment size of " + MAX_ATTACHMENT_SIZE/1024 + "kB...", "Please don’t try to send too large file attachments...", request, servletPrint); } else if (mSaveCopyTo != null) { mud.setMessage( mCreate(mud, smtphost, from, to, cc, bcc, subject, text, mimeAttachment, request, servletPrint) ); mSaveCopyTo(mud, fDstSel); mCompose(mud, httpSession, true, request, servletPrint); } else if (mAddAttachment != null) { mud.setMessage( mCreate(mud, smtphost, from, to, cc, bcc, subject, text, mimeAttachment, request, servletPrint) ); mCompose(mud, httpSession, true, request, servletPrint); } else if (mSend != null) { mud.setMessage( mCreate(mud, smtphost, from, to, cc, bcc, subject, text, mimeAttachment, request, servletPrint) ); mSend(mud, httpSession, request, servletPrint); } else if (mReset != null) { mud.setMessage(null); if (mud.getURLName() == null) mud.setFromAddr(null); mCompose(mud, httpSession, false, request, servletPrint); } }
79
Příloha D Výpis souboru WEB-INF/web.xml V této příloze je výpis XML souboru, který bývá označován jako deployment descriptor a je povinnou součástí WAR archivu. Struktura WAR archivu a vztah deployment descriptor u k servletům a WWW serveru Tomcat jsou stručně popsány v [13.3/60].
Příloha E Konfigurační soubor WWW serveru Tomcat Po instalaci WWW serveru Tomcat je potřeba provést několik konfiguračních kroků, aby Tomcat fungoval tak, jak většina uživatelů bude předpokládat. WWW server Tomcat má svůj konfigurační soubor uložen v adresáři TOMCAT HOME/conf pod jménem server.xml. Konfigurační kroky mají za úkol následující tři věci: 1. Změnit komunikační TCP port pro protokol HTTP (viz [3.4/14]) z původní nestandardní hodnoty 8080 na novou standardní hodnotu 80 a nastavit přesměrování komunikačního TCP portu pro bezpečnou komunikaci prostřednictvím SSL na hodnotu 443 (z původní hodnoty 8443). 2. Povolit podporu bezpečné komunikace pomocí SSL na TCP portu 443 (pro stručný popis SSL viz [3.5/15] a [13.2.2/60]). 3. Povolit automatické nahrávání změněných servletů (viz [13.2.1/60]). Ve výpisu z konfiguračního XML souboru jsou výše zmíněné změny označeny příslušnými čísly *1*, *2* a *3* (v komentářích). Výpis uvedený na následující straně obsahuje pouze část celého konfiguračního souboru WWW serveru Tomcat (tu část, ve které byly provedeny zmíněné úpravy).
Příloha F Několik uložených obrazovek (různé WWW prohlížeče) Protože při realizaci web mail aplikace byl kladen důraz na její funkčnost s různými WWW prohlížeči, je v této příloze zobrazeno několik z nich uložených obrazovek (screen-shots).
Obrázek F.1: Přihlašovací obrazovka – Internet Explorer 6.0 (Windows 2000)
