Článek

Poděkování
Na tomto místě je mou milou povinností poděkovat panu Ing. Jiřímu Ledvinovi, CSc. za to,
že vypsal krásné téma diplomové práce, kterému jsem neodolal.
Dále bych rád poděkoval jednomu z autorů JavaMail API, který ochotně odpovídal
na mé zvídavé dotazy v průběhu realizace web mail aplikace, jeho jméno je Bill Shannon.
Také bych neměl zapomenout poděkovat spolužákům, kteří mi pomáhali protloukat se
studiem: Zdeňkovi Mukenšnáblovi, za spolupráci v průběhu studia, a Ladislavu Vaizovi
za množství „linuxovýchÿ rad do života.
Můj další dík si zaslouží i kamarád Jan „Piškotÿ Třeška, který mi ochotně zapůjčil
svůj počítač 386DX-40MHz, abych mohl doma o víkendech alespoň psát texty k této práci
paralelně se svým bratrem.
V neposlední řadě musím také poděkovat bratrovi a rodičům, kteří mě podporovali
nejen při této práci, ale i po celou dobu mého studia.
Prohlášení
Prohlašuji, že jsem diplomovou práci vypracoval samostatně a výhradně s použitím
citovaných pramenů.
V Plzni dne 22. května 2002
...........................
Jiří Patera
Abstrakt
Jak už samotný název napovídá, zabývá se tato diplomová práce přístupem k elektronické
poště prostřednictvím WWW rozhraní.
První část je spíše teoretická. Zabývá se vytvořením a odesláním elektronické zprávy
pomocí SMTP protokolu a přenosem zprávy mezi jednotlivými MTA. Samozřejmě obsahuje
také stručný popis protokolů POP3 a IMAP4, které slouží pro příjem elektronických zpráv
ze vzdáleného poštovního serveru.
Druhá část práce je zaměřena na konkrétní realizaci jednoduché web mail aplikace pomocí objektově orientovaného programovacího jazyka Java a jeho technologie JavaServlet.
Pro komunikaci s poštovními servery prostřednictvím protokolů SMTP, POP3 a IMAP4
se v servletu používá JavaMail API.
Klíčová slova: elektronická pošta, e-mail, HTML formulář multipart/form-data, IMAP4,
JavaMail, JavaServlet, MIME, MTA, MUA, POP3, servlet, SMTP, web mail, WWW server
Tomcat.
Abstract
As the topic itself suggests, this diploma thesis deals with access to electronic mail via
WWW interface.
The first part of this thesis is more often theoretical than not. It concerns with creating
and sending an electronic message using the SMTP protocol and transferring the message
through particular MTAs. Obviously, it also includes a short description of POP3 and
IMAP4 protocols which purpose is to receive electronic messages from a remote mail server.
The second part is aimed at a concrete realization of a simple web mail application
using the object-oriented Java programming language and its JavaServlet technology. The
JavaMail API supports SMTP, POP3 and IMAP4 protocols and thus is used for communication between the servlet and mail servers.
Keywords: electronic mail, e-mail, HTML form multipart/form-data, IMAP4,
JavaMail, JavaServlet, MIME, MTA, MUA, POP3, SMTP, Tomcat webserver, webmail.
i
Obsah
1 Úvod
1.1 Čím se zabývá tato práce . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Jazykový koutek (čeština vs. angličtina) . . . . . . . . . . . . . . . . . . .
1.3 Typografické a syntaktické konvence . . . . . . . . . . . . . . . . . . . . .
1
1
2
3
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 . .
.
.
.
.
.
4
4
5
6
6
7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
8
9
9
10
10
10
11
11
12
12
13
14
14
15
.
.
.
.
16
16
16
18
18
. . . .
MTA
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Popis protokolů
3.1 SMTP protokol . . . . . . . . . . . . .
3.1.1 SMTP obálka . . . . . . . . . .
3.1.2 Přenos SMTP obálky . . . . . .
3.1.3 Fáze SMTP dialogu . . . . . . .
3.1.4 ESMTP protokol . . . . . . . .
3.2 POP3 protokol . . . . . . . . . . . . .
3.2.1 Komunikace klient/server . . .
3.2.2 Základní operace . . . . . . . .
3.3 IMAP4 protokol . . . . . . . . . . . . .
3.3.1 Komunikace klient/server . . .
3.3.2 Základní operace . . . . . . . .
3.4 HTTP protokol . . . . . . . . . . . . .
3.4.1 Metody GET a POST . . . . .
3.5 Bezpečnost protokolů aplikační úrovně
4 Internetové textové zprávy
4.1 Formát elektronické zprávy . . . . .
4.1.1 Hlavička elektronické zprávy
4.1.2 Tělo elektronické zprávy . .
4.1.3 Formát elektronické adresy .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Obsah
ii
5 Popis rozšíření MIME
5.1 Hlavní rozšíření pro elektronické zprávy . . . . .
5.2 Základní princip MIME . . . . . . . . . . . . .
5.3 Nové položky hlavičky elektronické zprávy . . .
5.4 Položka hlavičky Content-Transfer-Encoding
5.4.1 Kódování quoted-printable . . . . . .
5.4.2 Kódování base64 . . . . . . . . . . . . .
5.5 Hodnoty položky hlavičky Content-Type . . . .
5.5.1 Jednoduché typy . . . . . . . . . . . . .
5.5.2 Složené typy . . . . . . . . . . . . . . . .
5.6 Obsah položek hlavičky elektronické zprávy . . .
6 Architektury existujících
6.1 EMU Webmail . . . .
6.2 Endymion MailMan . .
6.3 KrystalBox Webmail .
.
.
.
.
.
.
.
.
.
.
19
19
19
20
20
21
21
21
22
22
23
systémů
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
24
25
26
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7 Návrh vlastního web mail systému
7.1 Navrhnutá architektura web mail systému . . . . . . . . . . . . .
7.2 Komunikace mezi WWW prohlížečem a WWW serverem . . . . .
7.3 Komunikace mezi WWW serverem a SMTP serverem . . . . . . .
7.4 Komunikace mezi WWW serverem a POP3 nebo IMAP4 serverem
7.4.1 Komunikace s POP3 serverem . . . . . . . . . . . . . . . .
7.4.2 Komunikace s IMAP4 serverem . . . . . . . . . . . . . . .
7.5 Ověřování uživatele . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6 Správa elektronických zpráv . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
29
30
30
31
31
31
31
32
.
.
.
.
33
33
34
34
35
9 JavaServlet API
9.1 Proč právě JavaServlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2 HTTP servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.1 Jak funguje HTTP servlet . . . . . . . . . . . . . . . . . . . . . . .
36
36
37
37
10 JavaMail API
10.1 JavaBeans Activation Framework (JAF) . . . . . . . .
10.2 Základní třídy JavaMail API . . . . . . . . . . . . . . .
10.3 Práce s elektronickými zprávami . . . . . . . . . . . . .
10.3.1 Čtení elektronických zpráv z poštovního serveru
39
39
40
40
42
8 Něco málo o HTML
8.1 Proč právě HTML .
8.2 HTML formuláře . .
8.2.1 Formulář typu
8.2.2 Formulář typu
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
application/x-www-form-urlencoded
multipart/form-data . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Obsah
iii
10.3.2 Odesílání elektronických zpráv . . . . . . . . . . . . . . . . . . . . .
11 Web mail ze strany uživatele
11.1 Přihlašování k POP3 nebo IMAP4 účtu . . . . . . . . .
11.2 Vytváření a odesílání elektronických zpráv . . . . . . .
11.3 Pohled na věc z POP3 účtu . . . . . . . . . . . . . . .
11.4 Pohled na věc z IMAP4 účtu . . . . . . . . . . . . . . .
11.5 Práce s poštovními složkami a elektronickými zprávami
43
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
44
44
44
45
45
46
12 Web mail ze strany programátora
12.1 Web mail servlet . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2 Využití HTTP relace . . . . . . . . . . . . . . . . . . . . . . . . .
12.3 Rozbor elektronických zpráv . . . . . . . . . . . . . . . . . . . . .
12.4 Přílohy elektronických zpráv . . . . . . . . . . . . . . . . . . . . .
12.4.1 Adresování příloh elektronické zprávy . . . . . . . . . . . .
12.4.2 Přeprava přílohy z WWW serveru do WWW prohlížeče . .
12.4.3 Přenos souborů z WWW prohlížeče na WWW server . . .
12.5 Ukládání WWW stránek do vyrovnávací paměti WWW prohlížeče
12.6 Záludná čeština a web mail . . . . . . . . . . . . . . . . . . . . .
12.6.1 Čeština v HTTP odpovědích servletu . . . . . . . . . . . .
12.6.2 Čeština na WWW stránkách a v elektronických zprávách .
12.6.3 Čeština v HTTP požadavcích od WWW prohlížeče . . . .
12.6.4 Čeština v názvu poštovních složek na IMAP4 serveru . . .
12.7 Dynamické generování WWW stránek . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
48
48
49
50
50
51
52
52
54
55
55
56
56
57
57
13 Web mail ze strany administrátora
13.1 Volba WWW serveru . . . . . . . .
13.2 WWW server Tomcat . . . . . . .
13.2.1 Spouštění servletů . . . . .
13.2.2 Aktivace SSL (HTTPS) . .
13.3 Webový archiv (WAR file) . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
59
59
60
60
60
60
14 Závěr
14.1 Rekapitulace dosažených výsledků . . .
14.2 Řešené problémy při realizaci . . . . .
14.3 Známé nedostatky realizované aplikace
14.4 Testování web mail aplikace . . . . . .
14.5 Celkové zhodnocení . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
62
62
63
63
64
64
.
.
.
.
.
Literatura
64
A Zdrojový kód třídy PartAddress
68
B Zdrojový kód třídy MailUserData
71
Obsah
iv
C Zdrojový kód metody parseMultipartFormData()
ze třídy JavaMailServlet
75
D Výpis souboru WEB-INF/web.xml
79
E Konfigurační soubor WWW serveru Tomcat
80
F Několik uložených obrazovek
(různé WWW prohlížeče)
82
v
Seznam obrázků
6.1
6.2
6.3
6.4
Architektura
Architektura
Architektura
Architektura
EMU Webmail systému . . . . . . . . . . . . . . .
Endymion MailMan systému (Standard Edition) .
Endymion MailMan systému (Professional Edition)
KrystalBox Webmail systému . . . . . . . . . . . .
7.1
Architektura realizovaného web mail systému
.
.
.
.
.
.
.
.
25
26
27
27
. . . . . . . . . . . . . . . .
30
10.1 Základní rozhraní a třídy JavaMail API . . . . . . . . . . . . . . . . . . . .
10.2 Objektově orientovaný pohled na elektronickou zprávu . . . . . . . . . . .
10.3 Objektově orientovaný pohled na přílohy elektronické zprávy . . . . . . . .
41
41
42
12.1 Naznačení funkce web mail servletu . . . . . . . . . . . . . . . . . . . . . .
49
13.1 Struktura WAR archivu . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
F.1
F.2
F.3
F.4
F.5
F.6
F.7
82
83
83
84
84
85
85
Přihlašovací obrazovka – Internet Explorer 6.0 (Windows 2000) .
Vytváření elektronické zprávy – Netscape Navigator 6.2 (Windows
Vytváření elektronické zprávy – Links 0.93 (RedHat Linux) . . . .
Poštovní složky a elektronické zprávy – IE 6.0 (Windows XP) . .
Elektronická zpráva a její příloha – IE 6.0 (Windows XP) . . . . .
Elektronická zpráva – Netscape Navigator 6.2 (Windows 2000) . .
Elektronická zpráva – Lynx 2.8.4 (Debian Linux) . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . .
2000)
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
vi
Seznam tabulek
4.1
5.1
5.2
5.3
5.4
Položky hlavičky elektronické zprávy a jim příslušející typy elektronických
adres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
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ě:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML>
<HEAD>
<TITLE>Hello world!</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
</HEAD>
<BODY>
Hello world!
</BODY>
</HTML>
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ě:
<FORM ACTION="jméno_programu" METHOD="metoda" ENCTYPE="typ">
<!-- zde lze definovat vstupní prvky formuláře -- tlačítka, atd. -->
</FORM>
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ě:
<FORM ACTION="jmservlet" METHOD="post" ENCTYPE="multipart/form-data">
...
<INPUT TYPE="file" NAME="fileName" SIZE="30">
<INPUT TYPE="submit" NAME="mAddAttachment" VALUE="Add attachment">
...
</FORM>
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
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Cache-Control", "no-store");
response.setHeader("Cache-Control", "must-revalidate");
response.setHeader("Cache-Control", "pre-check=0");
response.setHeader("Cache-Control", "post-check=0");
response.setHeader("Pragma", "no-cache");
response.setDateHeader("Expires", 0);
response.setHeader("Last-Modified",
(new Date()).toString());
12.6. Záludná čeština a web mail
55
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.
12.7. Dynamické generování WWW stránek
57
private String strCharsetEncode(String strInSrcCharset,
String srcCharset, String dstCharset)
throws UnsupportedEncodingException {
return new String( strInSrcCharset.getBytes(srcCharset), dstCharset );
}
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("
<hr>\n" +
"
<b>Date Sent:</b> " + 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 (<code>pAddress</code>).
*/
public PartAddress(String pAddress) {
this.pAddress = pAddress;
}
/**
* This method decreases part’s deepness (depth). So if the part has a part address
* of <code>25.9.3.11.3</code> then after calling this method part address variable
* <code>pAddress</code> is going to have a value of <code>25.9.3.11</code>.
*/
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
* <code>pAddress</code> stored in this class).
*
* @return the msg number which is got from the <code>pAddress</code> 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 <code>pAddress</code>.
*
* @return the string variable <code>pAddress</code>
*/
public String getPartAddr() {
return pAddress;
}
/**
* This method calculates part’s deepness (depth). So if the part has a part address
* of <code>25.9.3.11.2.8.1</code> then after calling this method the caller will
* receive the value <code>7</code> (so msg’s deepness equals to <code>1</code>).
*
* @return the deepness (depth) of the part which has address <code>pAddress</code>
*/
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 <code>78.3.1.6</code> then after calling this method part address variable
* <code>pAddress</code> is going to have a value of <code>78.3.1.7</code>.
*/
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 <code>25.9.3.11</code> then after calling this method part address variable
* <code>pAddress</code> is going to have a value of <code>25.9.3.11.1</code>.
*/
public void incPartDeepness() {
pAddress = pAddress.concat(".1");
}
/**
* This method increases part’s deepness (depth). So if the part has a part address
* of <code>25.9.3.11</code> then after calling this method with a parameter
* <code>8</code> part address variable <code>pAddress</code> is going to have
* a value of <code>25.9.3.3.11.8</code>.
*
* @param
tempStr
the value to add to <code>pAddress</code> variable
*
instead of value "<code>.1</code>"
*/
public void incPartDeepness(String tempStr) {
pAddress = pAddress.concat("." + tempStr);
}
/**
* This is a setter method for a string variable <code>pAddress</code>.
*
* @param
pAddress
the string (part address) to be stored in the variable
*
<code>pAddress</code>
*/
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).
*/
import java.io.*;
// import of standard Java packages
import javax.mail.*;
import javax.mail.internet.*;
// import of JavaMail 1.2 API
import javax.activation.*;
// import of JavaActivationFramework 1.0.1 API
/**
* <code>MailUserData</code> 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 <code>MailUserData</code> 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:
* <code>protocol://username:[email protected]</code>, 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 <code>Store</code> class object from a mail
* session object.
*/
Session
session;
/**
* The <code>Store</code> you can imagine as some kind of a database. It is
* most often used to get <code>[ROOT]</code> 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;
/**
* <code>Message</code> 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 <code>MailUserData</code> object. If no msg is being processed,
* the <code>Message</code> object is <code>null</code>.
*/
Message
message;
/**
* This string variable contains user’s <code>From:</code> 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 <code>From:</code> address only one time.
*/
String
fromAddr;
/**
* This constructor overrides default constructor. An object of
* <code>MailUserData</code> class can be created only with given complete URL.
* When URL is <code>null</code> it means that this <code>MailUserData</code>
* 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 <code>URLName</code>
*
variable
*/
public MailUserData(URLName url) {
this.url = url;
}
/**
* This is a getter method for variable <code>folder</code> (mail folder).
*
* @return the requested variable -- <code>folder</code>
*/
public Folder getFolder() {
return folder;
}
73
/**
* This is a getter method for variable <code>fromAddr</code> (RFC822
* <code>From:</code> address).
*
* @return the requested string variable -- <code>fromAddr</code>
*/
public String getFromAddr() {
return fromAddr;
}
/**
* This is a getter method for variable <code>message</code> (e-mail message).
*
* @return the requested variable -- <code>message</code>
*/
public Message getMessage() {
return message;
}
/**
* This method returns <code>Multipart</code> class object which is got
* from a MUD variable <code>message</code>.
*
* @return the <code>Multipart</code> class object or <code>null</code>
*
if no msg is stored in <code>MailuserData</code> 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 <code>url.getProtocol()</code>.
*
* @return the protocol from <code>URLName</code> variable stored in string
*/
public String getProtocol() {
if (url != null)
return url.getProtocol();
else
return null;
}
/**
* This is a getter method for variable <code>session</code> (mail session).
*
* @return the requested variable -- <code>session</code>
*/
public Session getSession() {
return session;
}
/**
* This is a getter method for variable <code>store</code> (mail store).
*
* @return the requested variable -- <code>store</code>
*/
74
public Store getStore() {
return store;
}
/**
* This is a getter method for variable <code>URLName</code>
*
* @return the requested variable -- <code>URLname</code>
*/
public URLName getURLName() {
return url;
}
/**
* This is a setter method for variable <code>folder</code> (mail folder).
*
* @param
folder
the mail folder to be saved in <code>MailUserData</code> object
*/
public void setFolder(Folder folder) {
this.folder = folder;
}
/**
* This is a setter method for string variable <code>fromAddr</code>
* (RFC822 <code>From:</code> address).
*
* @param
fromAddr
the string which contains an e-mail msg’s RFC822
*
<code>From:</code> address to be stored in
*
<code>MailUserData</code> object
*/
public void setFromAddr(String fromAddr) {
this.fromAddr = fromAddr;
}
/**
* This is a setter method for variable <code>message</code> (e-mail message).
*
* @param
message
the e-mail message to be stored in <code>MailUserData</code> object
*/
public void setMessage(Message message) {
this.message = message;
}
/**
* This is a setter method for variable <code>session</code> (mail session).
*
* @param
session
the mail session to be stored in <code>MailUserData</code> object
*/
public void setSession(Session session) {
this.session = session;
}
/**
* This is a setter method for variable <code>store</code> (mail store).
*
* @param
store
the mail store to be saved in <code>MailUserData</code> 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
* <code>multipart/form-data</code> (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:
* <ul>
*
<li> save a copy to a folder (submit button "mSaveCopyTo")
*
<li> add an attachment (submit button "mAddAttachment")
*
<li> reset whole composed msg (submit button "mReset")
*
<li> send a message (submit button "mSend")
* </ul>
* 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 <code>SequenceInputStream</code> 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 <code>MailUserData</code> object to it as an attribute
* @param request
for additional informations (f.e. HTTP request’s URI)
* @param servletPrint
<code>PrintWriter</code> 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;
77
if ( (beginIndex > (-1 + 7)) && (endIndex > beginIndex) )
pName = dispHeader.substring(beginIndex, endIndex);
//
//
//
//
if
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: "<input type=file>")
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].
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" "web-app.dtd">
<web-app>
<display-name>JavaMail-Servlet</display-name>
<servlet>
<servlet-name>JavaMailServlet</servlet-name>
<servlet-class>JavaMailServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>JavaMailServlet</servlet-name>
<url-pattern>jmservlet</url-pattern>
</servlet-mapping>
</web-app>
80
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).
81
<!-- Example Server Configuration File -->
<!-- Note that component elements are nested corresponding to their
parent-child relationships with each other -->
<!-- A "Server" is a singleton element that represents the entire JVM,
which may contain one or more "Service" instances. The Server
listens for a shutdown command on the indicated port.
Note: A "Server" is not itself a "Container", so you may not
define subcomponents such as "Valves" or "Loggers" at this level.
-->
<Server port="8005" shutdown="SHUTDOWN" debug="0">
<Service name="Tomcat-Standalone">
<!-- Define a non-SSL HTTP/1.1 Connector on port 8080 -->
<!-- *1* GP has changed HTTP port="8080" to port="80" and
HTTPS redirectPort="8443" to redirectPort="443" -->
<Connector className="org.apache.catalina.connector.http.HttpConnector"
port="80" minProcessors="5" maxProcessors="75"
enableLookups="true" redirectPort="443"
acceptCount="10" debug="0" connectionTimeout="60000"/>
<!-- Note : To disable connection timeouts, set connectionTimeout value to -1 -->
<!-- Define an SSL HTTP/1.1 Connector on port 8443 -->
<!-- *2* GP has uncommented this connector to enable SSL HTTP/1.1 -->
<!-- *2* GP has changed port="8443" to port="443" -->
<Connector className="org.apache.catalina.connector.http.HttpConnector"
port="443" minProcessors="5" maxProcessors="75"
enableLookups="true"
acceptCount="10" debug="0" scheme="https" secure="true">
<Factory className="org.apache.catalina.net.SSLServerSocketFactory"
clientAuth="false" protocol="TLS"/>
</Connector>
<!-- Define the top level container in our container hierarchy -->
<Engine name="Standalone" defaultHost="localhost" debug="0">
<!-- Define the default virtual host -->
<Host name="localhost" debug="0" appBase="webapps" unpackWARs="true">
<!-- Define properties for each web application. This is only needed
if you want to set non-default properties, or have web application
document roots in places other than the virtual host’s appBase
directory. -->
<!-- *3* GP has added this line to enable servlet reloading -->
<DefaultContext reloadable="true"/>
</Host>
</Engine>
</Service>
</Server>
82
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)
83
Obrázek F.2: Vytváření elektronické zprávy – Netscape Navigator 6.2 (Windows 2000)
Obrázek F.3: Vytváření elektronické zprávy – Links 0.93 (RedHat Linux)
84
Obrázek F.4: Poštovní složky a elektronické zprávy – IE 6.0 (Windows XP)
Obrázek F.5: Elektronická zpráva a její příloha – IE 6.0 (Windows XP)
85
Obrázek F.6: Elektronická zpráva – Netscape Navigator 6.2 (Windows 2000)
Obrázek F.7: Elektronická zpráva – Lynx 2.8.4 (Debian Linux)
Poznámky
Evidenční list
Souhlasím s tím, aby moje diplomová práce byla půjčována k prezenčnímu studiu
v Univerzitní knihovně ZČU v Plzni.
V Plzni dne 22. května 2002
...........................
Jiří Patera
Uživatel stvrzuje svým čitelným podpisem, že tuto diplomovou práci použil ke studijním
účelům a prohlašuje, že ji uvede mezi použitými prameny.
Jméno
Fakulta/katedra
Datum
Podpis
c Jiří Patera
2002