2 Aplikační protokoly

2.1 Telnet

Telnet je jedním z nejstarších protokolů používaných v Internetu, má kořeny v síti ARPANET. První prameny jsou z roku 1969, kdy slovo Telnet vzniklo jako akronym z „Telecommunications network protocol“ . Byl standardizován v roce 1980 normou RFC-764, která byla v roce 1983 nahrazena dodnes platnou normou RFC-854.

2.1.1 Protokol Virtuální terminál (NVT)

NVT je zkratka vzniklá z network virtual terminal. NVT je podmnožinou protokolu Telnet, tj. jakoby se protokol Telnet skládal ze dvou vrstev: ze spodní vrstvy – NVT a horní vrstvy – vlastního protokolu Telnet. Protokol NVT se zabývá prezentací dat, tj. v jaký bajt se má změnit písmeno A, aby na druhém konci síťového spojení bylo interpretováno opět jako A, či jaký příkaz protokolu Telnet se má vygenerovat po stisku známého ^C pro abnormální ukončení programu spouštěného z terminálu.

Právě protokol NVT je použit v omezené míře pro prezentaci dat v mnoha dalších protokolech jako jsou FTP, POP3, SMTP, NNTP i HTTP apod. V podstatě MIME je rozšířením této filosofie.

Obr. 2-1 Síťová architektura protokolu NVT

Obr. 2-2 Protokol virtuální terminál (NVT)

2.1.2 Příkazy protokolu Telnet

Zvláštní význam má znak „IAC“ (Interpret as command) s dekadickou hodnotou 255 (šestnáctkově FF). Pokud se opravdu má přenést znak s touto hodnotou, pak musí být zdvojen. Znak IAC se interpretuje jako začátek příkazu protokolu Telnet.

Příkazy protokolu Telnet jsou tak uvozeny znakem IAC. Za znakem IAC mohou následovat příkazy uvedené v následující tabulce.

Tab. 2-1 Příkazy protokolu Telnet

Příkaz			Význam
Desítkově	Šestnáctkově	Označení	Význam
236	EC	EOF	Konec souboru (End of file)
237	ED	SUSP	Suspenduj proces – vyšli procesu signál SUSP
238	EE	ABORT	Ukonči proces signálem ABORT (Abort process)
239	EF	EOR	Konec věty (End of record)
240	F0	SE	Konec parametrů příkazu (Suboption end)
241	F1	NOP	Prázdná operace (No operation)
242	F2	DM	Značka pro označení urgentních dat v TCP segmentu (Data mark)
243	F3	BRK	Ukonči proces signálem BREAK (Break process)
244	F4	IP	Ukonči proces signálem INTERRUPT (Interrupt process)
245	F5	AO	Zahoď výstup (abort output)
246	F6	AYT	Jsi tam? (Are your there?)
247	F7	EC	Únik do příkazového řádku (Escape character)
248	F8	EL	Zruš řádek (Erase line)
249	F9	GA	„Příjem“ (Go ahead)
250	FA	SB	Počátek parametrů příkazu (Suboption end)
251	FB	WILL	Viz tab. 2-2
252	FC	WONT
253	FD	DO
254	FE	DONT
255	FF	IAC	Datový bajt o hodnotě dekadicky 255 (šestnáctkově FF)

Základním nástrojem protokolu Telnet jsou následující složené příkazy, kterými se odesilatel s příjemcem dohadují na nastavení voleb pro vzájemnou komunikaci:

· WILL, kterým odesilatel navrhuje, že by rád používal nějakou volbu.

· DO, kterým odesilatel sděluje příjemci, aby příjemce používal nějakou volbu.

· WONT, kterým odesilatel příjemci sděluje, že odesilatel nepoužije nějakou volbu.

· DONT, kterým odesilatel příjemci sděluje, aby příjemce nepoužil nějakou volbu.

Je možných šest případů vzájemné komunikace:

Tab. 2-2 Základní schéma komunikace složenými příkazy

Odesilatel

Příjemce

Popis

WILL

Odesilatel si přeje používat nějakou volbu

Příjemce potvrzuje použití volby

WILL

DONT

Odesilatel si přeje používat nějakou volbu

Příjemce zamítá použití volby odesilatelem

WILL

Odesilatel si přeje, aby příjemce použil nějakou volbu

Příjemce souhlasí

WONT

Odesilatel si přeje, aby příjemce použil nějakou volbu

Příjemce odmítá

WONT

DONT

Odesilatel si přeje nepoužívat nějakou volbu

Příjemce je povinen potvrdit nepoužití této volby

DONT

WONT

Odesilatel si přeje, aby příjemce nepoužíval nějakou volbu

Příjemce je povinen potvrdit nepoužití této volby

Mnohé volby mohou mít i parametry. Seznam některých voleb je uveden v následující tabulce (podrobný seznam naleznete např. v RFC-2400):

Tab. 2-3 Volby protokolu Telnet

Volba			Význam	RFC
Název	desítkově	šestnáctkově	Význam	RFC
ECHO	1	1	Pokud na terminálu zmáčkneme např. klávesu „A“, pak očekáváme, že se nám znak „A“ objeví na obrazovce terminálu abychom měli jistotu, že jsme příslušnou klávesu opravdu zmáčkli. Poslat znak na obrazovk může provést lokálně náš terminál nebo server protokolem TELNET. Volbou ECHO žádáme o tuto službu.	857
SUPPRESS GO AHEAD	3	3	Potlačení poloduplexního režimu	858
STATUS	5	5	Status	859
TIMING MARK	6	6	Značka. Dnes se nejčastěji používá pro komunikaci v pseudo-řádkovém režimu.	860
TERMINAL TYPE	24	18	Typ terminálu, tato volba může mít následující parametry: 1 = „Pošli“ - požadavek serveru na zaslání typu terminálu 0 = „Posílám“ – klient zasílá typ terminálu. Po volbě 0 bezprostředně následuje řetězec obsahující typ terminálu.	1091
NAWS	31	1F	Dohoda na velikosti okna terminálu (tj. klient informuje server o počtu řádků a sloupců svého okna terminálu). Tato volba může mít dva dvojbajtové parametry: počet sloupců a počet řádků.	1073
TSPEED	32	20	Rychlost připojení terminálu (sériové linky klasického terminálu). Volba může obsahovat dva parametry: rychlost vysílání a rychlost příjmu.	1079
LFLOW	33	21	Řízení toku dat (tj. zpracování ^S a ^Q – pozastavení a opětovný start výstupu terminálu) , tato volba může mít následující parametry: 0 = OFF (používá např. editor vi), 1 = ON, 2 = RESTART-ANY, 3 = RESTART-XON	1372
LINEMODE	34	22	Řádkový režim, tato volba může použít řadu parametrů.	1184
XDISPLOC	35	23	Umístění X-serveru v X-Windows. Význam parametrů je stejný jako u volby TERMINAL TYPE. Rozdílem je, že místo typu terminálu se odesílá umístění X-serveru ve formátu host:display[.obrazovka].	1096
OLD ENVIRON	36	24	Proměnné prostředí, tato volba byla inovována normou RFC-1572, viz další řádek	1408
NEW ENVIRON	39	27	Proměnné prostředí, tato volba používá řadu parametrů (viz RFC-1572). V praxi se přenáší dvě proměnné prostředí: DISPLAY a PRINTER.	1572
STARTTLS	46	2E	Telnet Start TLS
KERMIT	47	2F	Telnet Kermit
EXTOP	255	FF	Rozšířený seznam voleb	861

Příkladem použití složených příkazů je vyžádání si typu terminálu. Pokud server totiž zná typ (a tím i vlastnosti) terminálu, u kterého uživatel sedí, pak může uživateli nabídnout např. celoobrazovkový režim editoru vi apod. Jednou z možností komunikace získání typu terminálu je, že server iniciuje vyžádání typu terminálu. V prvním kroku se server klienta zeptá, zda-li je mu vůbec klient typ terminálu schopen poskytnout – komunikace DO/WILL (když klient odpovídá kladně). V dalším kroku pak server vyšle složený příkaz (a to s parametry), kterým si vyžádá řetězec obsahující konkrétní typ parametrů. Složený příkaz s parametry je vždy uzavřen mezi dvojici „závorek“ SB a SE. Příklad této komunikace obsahuje následující tabulka (inverzně je uvedena šestnáctková hodnota následovaná příkazem v textové formě):

Klient		Server	Význam
	<-	FF FD 18 <IAC DO TERMINAL-TYPE>	Kliente pošli mi typ tvého terminálu.
FF FB 18 <IAC WILL TETMINAL-TYPE>	->		Souhlasím s poskytnutím typu terminálu.
	<-	FF FA 18 01 FF FO <IAC SB TERMINAL-TYPE pošli> <IAC SE>	Zašli mi typ svého terminálu. Parametr 01 = Pošli.
FF FA 18 00 76 74 31 30 30 FF F0 <IAC SB TERMINAL-TYPE posílám> vt100 <IAC SE>	->		Klient posílá serveru typ svého terminálu, který je vt100. Parametr 00 = Zasílám typ terminálu (vt100)

Úniková sekvence a příkazový řádek programu telnet

Uživatel pracující s programem telnet pracuje v lokálním operačním systému a je díky protokolu Telnet připojen do operačního systému vzdáleného stroje. Úniková sekvence je zpravidla  znak ^] (tj. současný stisk klávesy CTRL a klávesy ]).

2.1.3 Příklad komunikace klienta z Windows NT

Náš příklad komunikace klienta protokolu Telnet z Microsoft Windows NT je se serverem s operačním systémem True64 Unix. Ve Windows NT (ani 2000) nemáme k dispozici příkaz toggle, takže nemůžeme zkoumat protokol Telnet pomocí ladícího výpisu.

To nás však neodradí. Vzpomeneme si, že ve Windows máme k dispozici MS Network Monitor. Takže spustíme Network monitor a odchytíme si jednotlivé pakety protokolu Telnet (viz obr. 2-3).

Obr. 2-3 Paket protokolu Telnet obsahuje IAC příkazy odesílané serverem

Předpokládáme, že komunikace byla navázána na úrovni protokolu TCP. Klient Microsoft i na implicitním portu nezačíná s komunikací pomocí IAC příkazů protokolu Telnet, ale počká zda-li se ze serveru vyklube server protokolu Telnet.

Tab. 2-4 obsahuje vyčerpávající výpis této komunikace. Např. aplikační data z obr. 2-3 jsou rozpitvána do pěti jednotlivých IAC příkazů. Nejprve je uveden IAC příkaz šestnáctkově a vždy následuje jeho textový ekvivalent.

Tab. 2-4 Komunikace kliet/server protokolu Telnet (klient Windows NT)

Klient		Server	Význam
	<-	FF FD 18 <IAC DO TERMINAL-TYPE > FF FD 20 <IAC DO TSPEED> FF FD 23 <IAC DO XDISPLOC> FF FD 27 <IAC DO NEW-ENVIRON> FF FD 24 <IAC DO OLD-ENVIRON>	· Kliente pošli mi typ tvého terminálu · Kliente pošli mi rychlost tvé linky · Kliente posli mi umístění tvého okna (pro X-Windows) · Pošli mi proměnné tvého prostředí (vlastně výpis příkazu SET ve Windows) · Pošli mi proměnné prostředí (tato volba je zastaralá)
FF FB 18 <IAC WILL TETMINAL-TYPE>	->		· Souhlasím s poskytnutím typu terminálu (odpověď na DO)
FF FC 20 <IAC WONT TSPEED> FF FC 23 <IAC WONT XDISPLOC> FF FC 27 <WONT NEW-ENVITON> FF FC 24 <WONT OLD-ENVIRON>	->		· Nesouhlasím s poskytnutím rychlosti své linky (uživatel nepracuje s klasickým terminálem). · Nesouhlasím s poskytnutím umístění svého okna (uživatel nepracuje v X-Windows) · Neposkytnu proměnné svého prostředí
	<-	FF FA 18 01 <IAC SB TERMINAL-TYPE pošli> FF FO <IAC SE>	· Zašli mi typ svého terminálu. Jelikož tato volba se použije s parametrem, tak je nutné volbu uložit mezi závorky SB a SE
FF FA 18 00 76 74 31 30 30 <IAC SB TERMINAL-TYPE posílám> vt100 FF F0 <IAC SE>	->		· Klient posílá serveru typ svého terminálu, který je vt100. Jelikož tato volba se použije s parametrem, tak je nutné volbu uložit mezi závorky SB a SE
	<-	FF FB 03 <IAC WILL SUPPRESS –GO-AHEAD> FF FD 01 <IAC DO ECHO> FF FD 1F <IAC DO NAWS> FF FB 05 <IAC WILL STATUS> FF FD 21 <IAC DO LFLOW>	· Server si přeje nepoužívat poloduplexní režim · Server chce, aby klient prováděl ECHO · Server chce, aby klient používal NAWS · Server si přeje STATUS · Server chce, aby klient používal RFC
FF FD 03 <IAC DO SUPPRESS-GO-AHEAD>	->		· Klient potvrzuje nepoužití poloduplexího režimu
FF FB 01 <IAC WILL ECHO> FF FC 1F <IAC WONT NAWS> FF FC 05 <IAC DONT STATUS> FF FC 21 <IAC WONT LFLOW>	->		· Klient souhlasí s tím, že bude provádět ECHO · Klient odmítá NAWS · Klient odmítá STATUS · Klient odmítá RFC
	<-	FF FE 01 <IAC DONT ECHO> FF FB 01 <IAC WILL ECHO>	· Server nechce, aby klient prováděl ECHO · Server chce sám provádět ECHO
FF FC 01 <IAC WONT ECHO>	->		· Klient nebude provádět ECHO
	<-	Login:
FF FD 01 <IAC DO ECHO>	->		· Klient souhlasí s tím, že server bude provádět ECHO
Jméno uživatele	->
	<-	Password:

2.2 FTP

Protokol FTP má obdobně jako protokol telnet také velice bohatou historii. V normách RFC se objevil v RFC-114 (dnes už ani není k dispozici) z 10. dubna 1971. Nyní je standardizován RFC-959 s úpravami v RFC-2228 a RFC-2640.

2.2.1 Architektura

Architektura protokolu FTP je znázorněna na obr. 2-5. Uživatel pracuje s uživatelským rozhraním. To bývá buď jako příkazový řádek programu ftp. Nebo jako grafická utilita či internetový prohlížeč.

Obr. 2-5 Architektura FTP

Architektura protokolu FTP je velice zvláštní. Protokol FTP používá dva kanály typu klient/server:

Příkazový kanál, kterým klient zasílá na server své požadavky např. na výpis adresáře či stažení souboru. Tento kanál používá jako prezentační protokol NVT. Server vždy očekává požadavky příkazového kanálu na portu 21/tcp.
Datový kanál, kterým se přenášejí požadovaná data (výpis adresáře či obsah souboru). U datového kanálu je právě jistá zvláštnost v tom, že se může role serveru a klienta obrátit. Proto rozeznáváme dva režimy komunikace protokolu FTP: aktivní a pasivní.

2.2.2 Aktivní režim komunikace protokolu FTP

Aktivní režim komunikace protokolu FTP je tím „klasickým režimem komunikace protokolu FTP“. Nejčastější otázkou je, jak může uživatel ovlivnit volbu režimu komunikace. Odpověď je: „těžko“, protože takovou volbu nám musí umožnit tvůrce klienta ftp. Jen málokterý klient má však takovou volbu. Takže pakliže používáme klienta z příkazového řádku, pak nejspíš budeme používat právě aktivní režim. Na druhou stranu mnohé verze internetových prohlížečů používají pasivní režim. Naopak serverům musíme přiznat, že zpravidla podporují oba režimy komunikace.

Nejprve si v krátkosti objasníme princip aktivní komunikace na obr. 2-6. Klient si přeje navázat spojení se serverem infoserv.ripe.net. Klient nejprve požádá správu volných portů na svém lokálním počítači o přidělení volného portu. Je mu přidělen nějaký port větší než 1023 (klientský port). Na tomto portu naváže TCP spojení s portem 21/tcp serveru. Vytvoří se tak příkazový kanál.

Jelikož si chceme podrobně popisovat komunikaci protokolem FTP, tak na straně klienta zadáme interní příkaz klienta ftp: debug. Tento příkaz nic nemění na komunikaci mezi klientem a serverem. Pouze nám klient bude vypisovat detailní informace o komunikaci protokolem FTP. Např. vypíše:

---> PORT 194,149,105,131,4,11
Což znamená, že klient odeslal na server (šipka --->) příkaz protokolu FTP: „PORT 194,149,105,131,4,11“.

Nyní již můžeme zadat příkaz pro podrobný výpis aktuálního adresáře na serveru: „DIR“. Pro zaslání výpisu adresáře ze serveru na klienta se zřídí datový kanál. Právě aktivní režim je charakteristický tím, že datový kanál je zřízen zvláštním způsobem:

1. Klient požádá správu volných portů svého operačního systému o přidělení volného portu. Je mu přidělen port 1035 desítkově. (Číslo portu je pak přenášeno ve dvou bajtech: tj. 1035 je 04 0B šestnáctkově. V protokolu FTP se však každý bajt uvádí desítkově, tj. 4 a 11).

2. Klient odešle příkazem PORT šest desítkových čísel obsahujících svou IP-adresu a port, tj. odešle 194,149,105,131,4,11.

3. Server naváže protokolem TCP spojení s klientem o IP-adrese a portu uvedeném v příkazu PORT. Tj. server navazuje spojení s klientem! – jakoby si server a klient vzájemně vyměnili svou roli v datovém kanálu.

Nyní může již klient odeslat příkaz LIST pro výpis adresáře. Všimněte si, že zatímco uživatel v uživatelském rozhraní zadal příkaz „DIR“, tak tento příkaz byl pro interpret příkazů konvertován do příkazu LIST protokolu FTP. Výpis adresáře na straně unixového serveru znamená spustit program /bin/ls, protože server vypisuje obsah adresáře právě tímto programem. Standardní výstup programu /bin/ls je přesměrován do datového kanálu.

Jelikož data byla přenášena v módu ve tvaru datového toku, tak konec výpisu (= konec souboru přenášených dat) způsobí uzavření datového kanálu.

Obr 2-6 Aktivní spojení FTP

V praxi si komunikaci protokolem FTP nebudeme kreslit, ale budeme si ji zobrazovat pomocí podrobného výpisu, který se aktivuje příkazem debug.

Klient spustí program ftp s paramentem jméno cílového serveru (např. ftp infoserv.ripe.net). V tabulce 2-5 je pak v prvním řádku vidět, že spojení bylo navázáno. Server vyžaduje autentizaci uživatele (2. řádek tabulky 2-5). Jako uživatel je zadán uživatel ftp (tj. anonymní uživatel – řetězec ftp je ekvivalentní s řetězcem anonymous).

Na řádku 3 je vyžádáno heslo. Pro anonymního uživatele se zadává uživatelova e-mailová adresa sloužící správci serveru pro statistiky.

Na 4. řádku se server představí a na 5. řádku pak zobrazí příkazový řádek programu ftp. Jako první příkaz jsem zadal příkaz debug, který zapne zobrazování podrobných informací o spojení (zapne režim ladění).

Na šestém řádku konečně uživatel zadává příkaz DIR, který je konvertován do protokolu FTP. Nejprve je však třeba vytvořit datový kanál, takže klient alokuje volný klientský port 1035 (tj. 4,11), o této alokaci je příkazem PORT informován server.

7. řádek říká, že příkaz PORT proběhl úspěšně, takže je možné odeslat požadavek na výpis adresáře příkazem LIST. Server pro výstup programu /bin/ls zřizuje datový kanál, do kterého vkládá výstup. Část tohoto výstupu je pak znázorněna na řádku 8.

Úspěšné ukončení přenosu je signalizováno příkazovým kanálem na řádku 9. Řádek 10 uvádí krátkou statistiku o přenosu. Konečně na řádek 11 může uživatel zadat další příkaz.

Tab. 2-5 Aktivní spojení

1.	C:\WINNT\system32>ftp infoserv.ripe.net Systém je připojen k infoserv.ripe.net. 220 infoserv.ripe.net FTP server (Version wu-2.6.1(1) ….
2.	Uživatel (infoserv.ripe.net:(none)): ftp 331 Guest login ok, send your complete e-mail address as password.
3.	Heslo:
4.	230-Welcome 194.149.105.131, 230- 230-This is the ftp-server of the RIPE Network Coordination Centre (NCC). … 230- 230 Guest login ok, access restrictions apply.
5.	ftp> debug Ladění Zapnuto
6.	ftp> dir ---> PORT 194,149,105,131,4,11
7.	200 PORT command successful. ---> LIST 150 Opening ASCII mode data connection for /bin/ls. total 922
8.	-r--r--r-- 1 ncc ripe 86 Mar 24 1992 .msg.logout -r--r--r-- 1 ncc ripe 89 Apr 24 1996 .msg.toomany -rw-r--r-- 1 ncc ripe 1205 Jan 11 2000 .msg.welcome -rw-rw-r-- 1 ncc ripe 2093 Sep 16 1998 About-ripe dr-xr-xr-x 2 ncc ripe 512 Jul 22 1996 bin … drwxr-xr-x 3 ncc ripe 3072 Jun 7 09:15 ww-connectivity
9.	226 Transfer complete.
10.	ftp: 1356 bajtů přijato za 0,92sekund 1,47kB/s
11.	ftp>

2.2.3 Pasivní režim komunikace protokolu FTP

Mnohdy může vadit, že se spojení pro datový kanál navazuje ze strany serveru na klienta. Tento problém odstraňuje pasivní režim komunikace, kdy klient navazuje spojení jak pro příkazový kanál, tak i pro datový kanál. To může být velice užitečné, chceme-li např. naší síť chránit filtrací na přístupovém směrovači.

Zatímco v případě aktivního spojení jsme pro zkoumání protokolu FTP nemohli použít program telnet, protože pro navázání datového kanálu bychom museli program telnet spustit na serveru, tak naopak pasivní režim komunikace si ukážeme nikoliv za využití programu ftp, ale programu telnet.

Obr. 2-7 Pasivní spojení FTP

2.2.4 Příkazy FTP

Příkazy protokolu FTP jsou přenášeny textově (v ASCII). Příkaz je vždy tvořen klíčovým slovem (např. USER). Klíčové slovo mohou následovat parametry oddělené mezerou. Příkaz je ukončen znaky CR (návrat vozíku) a LF (nový řádek).

Tab. 2-5 Příkazy FTP (přenášené sítí)

Příkaz FTP (přenášený sítí)	Obvyklý příkaz příkazového řádku	Význam
USER jméno-uživatele	user	Jméno uživatele
PASS heslo		Heslo
ACCT účet	account	Některé servery mohou vyžadovat kromě jména uživatele i název účtu, který může být využit pro přístup k některým datům.
CWD	cd	Nastavení aktuálního adresáře na serveru.
CDUP	cdup	Nastavení nadřízeného adresáře jako aktuálního adresáře na serveru.
SMNT cesta	-	Zavěšení souborového systému (mount).
QUIT	quit	Ukončení spojení
REIN	-	Reinicializace – uživatel je odhlášen, ale spojení příkazovým kanálem zůstává. Poté může následovat příkaz USER.
PORT port	-	Viz text
PASV		Přechod do pasivního režimu
TYPE kód	ascii, binary	Specifikace typu přenášeného souboru (první parametr) a řízení formáty pro zobrazení (druhý parametr). Příklad: TYPE A N Požaduje nastavení typu ASCII bez formátovacích znaků.
STRU struktura	-	Specifikuje strukturu přenášeného souboru. Např. STRU F Požaduje nastavení strukturu přenášeného souboru na souborovou strukturu (file).
MODE mód	-	Specifikuje mód přenášených dat. Např. MODE S Požaduje nastavení módu na tvar datového toku (stream).
RETR cesta	get	Stažení souboru ze serveru
STOR cesta	put	Přenesení souboru na server
STOU cesta	rununique + get	Obdoba STOR, avšak přenesený soubor bude mít jednoznačné jméno v adresáři (ftp nepřepíše existující soubor ale pozmění název)
APPE cesta	append	Přenese soubor na server. Jestliže na serveru existuje stejnojmenný soubor pak není soubor přepsán, ale o přenesená data rozšířen.
REST značka		Restart přenosu dat.
RNFR cesta	rename	Přejmenování souboru se provede dvěma příkazy FTP. Příkazem RNFR se zjistí, zda-li původní soubor vůbec na serveru existuje a příkazem RNTO se zadá nové jméno souboru.
RNTO cesta	rename
ABOR		Abnormální ukončení předchozího příkazu (pokud neskončil)
DELE cesta	delete	Zrušení souboru
RMD cesta	rmdir	Zrušení adresáře
MKD cesta	mkdir	Vytvoření adresáře
PWD	pwd	Zjištění aktuálního adresáře
LIST [cesta]	ls	Výpis obsahu adresáře
NLIST [cesta]	dir	Podrobný výpis obsahu adresáře
SITE řetězec		Příkaz pro jiné služby serveru. Jaké služby server poskytuje se zjistí příkazem: SITE HELP Např. SITE IDLE zjistí nastavení limitů nečinného spojení.
SYST	system	Dotaz na informace o systému serveru.
STAT [cesta]	status	Zobrazení aktuálního stavu.
HELP [příkaz]	remotehelp	Zjištění podporovaných příkazů serveru
NOOP		Prázdný příkaz

Je třeba však rozlišovat mezi příkazy zadávanými uživatelem a příkazy protokolu FTP. Např. pro výpis adresáře uživatel programu ftp zadá příkaz DIR avšak ten je konvertován na příkaz LIST protokolu FTP.

Na druhou stranu program ftp má mnohé interní příkazy, které často nesouvisí se síťovou komunikací, ale slouží pro větší komfort uživatele. Takovými příkazy jsou např.:

Příkaz hash, kterým může uživatel nastavit software klienta tak, že po přenesení 1 či 2 kB dat datovým kanálem se na obrazovce objeví znak dvojitý kříž a uživatel má tak iluzi, že se opravdu něco přenáší – že program „nezmrzl“.
Příkaz lcd, kterým uživatel může změnit aktuální adresář na lokálním stroji. Někdy bývá implementováno více příkazů týkajících se lokálního systému (začínajících proto na l). Obecně lze provádět všechny (externí) příkazy lokálního systému (lokálního interpretu příkazů) tak, že na příkazový řádek programu ftp napíšeme před příkaz vykřičník.
Velice důležitým příkazem je příkaz literal. Pomocí tohoto příkazu lze odeslat libovolný příkaz protokolu FTP, tj. vše co je argumentem příkazu literal se přímo vloží do protokolu TCP. Např. :
literal PWD
Zvláštní skupinou jsou příkazy začínající znakem m (jako multiple). Tyto příkazy umožňují používat znaky hromadného výběru jako je znak hvězdička v názvech souborů. Je tak možné jedním příkazem přenést více souborů. Nutno však podotknout, že tyto příkazy pouze za uživatele vygenerují několik příkazů protokolu FTP, které se pak postupně provádějí. Jako první příkaz použijí výpis vzdáleného adresáře na jehož základě generují jednotlivé příkazy. Jedná se tedy pouze o vlastnost softwaru klienta (byť komfortní), nikoliv o další sadu příkazů protokolu FTP.
Problémem přenosu meze různými operačními systémy (např. Microsoft a UNIX) je skutečnost, že pro jména souborů se u Microsoftu používají zpravidla velká písmena, kdežto na Unixu malá písmena. Je tedy otázkou, zda-li se ve jménech souborů nemají konvertovat písmena (velká na malá resp. malá na velká). Tato konverze se zpravidla ovládá příkazem case.

Kromě uvedených příkazů protokolu FTP se mohou ještě používat experimentální příkazy začínající znakem X. např. XCWD je experimentální obdobou příkazu CWD. Pro bližší informace doporučuji RFC-1123.

2.2.5 Proxy

Na úvod musím upozornit, že zde popisované proxy nesouvisí s proxy jak se s ním setkáváme v oblasti firewallů. Myšlenka spočívá v tom, že klient může zprostředkovat spojení mezi dvěma FTP servery. Na obr. 2-8 je znázorněna situace, kdy klient zprostředkuje přenos souboru ze serveru ftp.ripe.net na server ftp.pvt.cz.

Klient nejprve zřídí příkazový kanál se serverem ftp.ripe.net. Pomocí příkazu proxy zřídí další kanál (tzv. proxy kanál) se serverem ftp.pvt.cz. Nyní odešle na server ftp.pvt.cz příkaz PROXY (příkaz protokolu FTP). Server ftp.pvt.cz vyalokuje port na kterém bude čekat spojení pro datový kanál (IP-adresu a číslo vyalokovaného portu předá příkazovým kanálem klinetu). Vtip je v tom, že server si může myslet, že čeká na spojení od klienta. Avšak klient obratem předá IP-adresu a alokovaný port serveru ftp.ripe.net. Nyní již může server ftp.ripe.net navázat spojení pro datový kanál se serverem ftp.pvt.cz a do takto vytvořeného datového kanálu vložit kopii příslušného souboru. V tomto případě musí klient vydat jednomu serveru příkaz RETR (čti soubor) a druhému příkaz STOR (zapiš soubor).

Obr. 2-8 Proxy FTP

A konečně výpis komunikace v ladícím režimu:

2.2.6 Návratové kódy

Na jednotlivé klientem zadávané příkazy protokolu FTP server odpovídá hláškou s tříciferným návratovým kódem následovaným volitelným textovým objasněním návratového kódu. Tříciferný návratový kód má tvar:

xyz

kde:

x – může nabývat hodnot:

1                Pozitivní odpověď při zahájení nějaké akce. Před tím, než klient bude moci odeslat další příkaz lze očekávat další hlášku (o ukončení akce).

2                Pozitivní odpověď na provedení příkazu. Klient může zadat další příkaz.

3                Pozitivní odpověď na kterou musí klient udělat konkrétní akci. Např. po zadání jména uživatele je vyžadováno heslo.

4                Negativní odpověď  při chybě. Po odstranění chyby je možné příkaz zadat znovu.

5                Permanentní negativní odpověď. Např. o nepodporovaném příkazu.

y – může nabývat hodnot:

0                Syntaktická chyba.

1                Informativní hláška.

2                Chyba spojení.

3                Chyba autentizace.

4                Nespecifikovaná chyba.

5                Chyba signalizována souborovým systémem.

z – blíže určuje chybu.

Příklady:

125 Data connection already open; transfer starting.

230 User logged in, proceed.

331 User name okay, need password.

452 Insufficient storage space in system.

502 Command not implemented.

2.2.7 Abnormální ukončení příkazu

Abnormální ukončení právě prováděného příkazu (zpravidla datového přenosu) je prakticky jediným využitím příkazů protokolu Telnet (resp. protokolu NVT).

V tabulce 2-5 můžeme najít pro abnormální ukončení prováděného příkazu příkaz ABOR. Jenže mohlo by se stát, že server by zpracovával jednotlivé příkazy klienta postupně za sebou. Takže příkaz ABOR by zpracoval až předchozí příkaz skončí. Ale my chceme, aby předchozí příkaz skončil dříve, tj. aby příkaz ABOR zpracoval okamžitě, jakmile jej obdrží.

Software klienta je většinou nastaven tak, že je citlivý na stisk nějaké klávesové zkratky pro abnormální ukončení. Nechť je touto klávesovou zkratkou např. ^C (grafičtí klienti mohou mít tlačítko „ukončit“). Po stisku ^C klient jednak zastaví odesílání dat v datovém kanálu (pokud se data odesílají od klienta na server) a odešle dvojici příkazů:

Příkaz protokolu NVT pro abnormální ukončení procesu: <IAC IP><IAC DM>. Jsou to příkazy dva, protože za příkazem IP musí následovat ještě DM (datová značka). Server čte svou vstupní vyrovnávací paměť až po datovou značku. Vše co je po datovou značku ve zpracování přeskočí. TCP segment nesoucí datovou značku označí jako urgentní a ukazovátko urgentních dat (v záhlaví TCP segmentu) ukazuje právě na značku DM. Značka DM se zpracovává tak, že server jde po vyrovnávací paměti zpět od datové značky DM až najde první příkaz IAC. Tentokráte najde <IAC IP>.
Vlastní příkaz ABOR protokolu FTP.

Celkově tedy klient odešle 10 bajtů: <IAC IP><IAC DM>ABOR CR LF

Otázkou je zda-li jednotlivé implementace klienta FTP budou nastavovat příznak urgentních dat a odesílat příkazy IAC. To už je věcí tvůrců software klienta.

2.2.8 Anonymní FTP

Anonymní server je myšlenka, která se nepoužívá pouze pro FTP servery. Anonymní server umožňuje přístup libovolnému klientu, tj. přístup bez autentizace klienta.

Jelikož protokol FTP ve své podstatě s anonymními servery příliš nepočítal, tak i anonymní uživatelé zadávají při svém přístupu na FTP server jméno uživatele a heslo. Jako jméno uživatele se zpravidla používá buď řetězec anonymous nebo řetězec ftp. Oba řetězce mají stejný význam. Jako heslo je často vyžadována uživatelova e-mailová adresa. Ta provozovateli anonymního FTP serveru slouží pro vytváření statistik přístupu na server.

Některé anonymní servery umožňují přístup pouze klientům jejichž počítač má správný záznam v reverzním DNS, tj. těm k jejichž IP-adrese se v DNS nalezne jméno jejich počítače. Toto omezení má však velice sporný význam.

Obr. 2-9 Anonymní FTP

Anonymní FTP server slouží uživatelům pro stahování souborů z něj. Tj. na anonymním FTP serveru mohou firmy nabízet své informace. Na anonymní FTP servery se velice pohodlně přistupuje pomocí internetových prohlížečů.

Pakliže jsou anonymní FTP servery vystaveny v Internetu, pak jsou vystaveny velkému nebezpečí útoků na ně. Implementace FTP serverů proto velice často pro zvýšení bezpečnosti provádí trik znázorněný na obr. 2-9. Při spuštění FTP serveru jako procesu je na jeho počátku použito systémové volání pro změnu kořenového adresáře na adresář s daty, které pouze chce FTP server zpřístupnit. Tj. uměle se operační systém serveru bude pro tento proces tvářit tak, že kořenovým adresářem je pouze kořenový adresář s daty FTP serveru. Uživatelé přihlášení k tomuto serveru nebudou mít tak možnost se dostat do jiných adresářů operačního systému serveru.

V tomto případě je nutné ještě upozornit na skutečnost, že server nebude mít ani přístup k adresářům, kde je např. program ls používaný pro výpis adresáře, proto pod falešným kořenovým adresářem ještě nesmíme zapomenout navěsit např. adresář bin s programem ls. Bývá nutné zavěsit též adresář etc s falešným souborem passwd. Adresář bin však nemusí umožňovat uživatelům čtení– stačí možnost spustit program ls. Program ls sám pro sebe nesmí využívat ani sdílené knihovny operačního systému, protože k nim nebude mít přístup (musí mít staticky sestavené knihovny), proto je zajímavé si zobrazit velkost programu ls z adresáře ve kterém se běžně používá v operačním systému a z adresáře ze kterého jej používá anonymní FTP server.

Anonymní FTP server by rozhodně neměl být spuštěn pod superuživatelem, ale na počátku programu serveru je kromě změny kořenového adresáře použito volání pro změnu uživatele a skupinu uživatelů. Jako uživatel (resp. skupina uživatelů) se používá uživatel s minimálními přístupovými právy v operačním systému serveru umožňující ale korektní provoz FTP serveru.

Běžně se anonymní FTP servery používají pouze pro čtení souborů, proto správce anonymního FTP serveru vždy pečlivě u všech adresářů ruší právo zápisu do adresáře. V praxi se někdy anonymní FTP server používá i pro výměnu souborů mezi uživateli, tj. je potřeba aby anonymní uživatelé měli možnost zápisu. Většinou se to povolí pouze do jednoho adresáře. Tomuto adresáři se pak naopak nastaví možnost zápisu, ale znemožní se čtení adresáře (to nesouvisí s právem čtení souboru). Takže jeden uživatel tam může uložit data, ale nikdo si nepřečte co v adresáři je. Jiným kanálem (např. telefonem) se pak domluví s druhým uživatelem, aby si soubor stáhnul.

2.3 HTTP

Protokol HTTP (Hypertext Transfer Protocol) je výrazně mladší protokol. Jeho počátky jsou někde kolem roku 1990. Jeho předchůdcem byl dnes již téměř zapomenutý protokol Gopher. Dalším mezníkem byl protokol HTTP verze 0.9, který byl velice jednoduchý, proto se dočkal velkého množství implementací. Dnes aktuální verze 1.1 (RFC-2616) je nesrovnatelně komplikovanějším protokolem – snad i to je důvod, proč se dnešních dnů dožilo tak málo implementací.

2.3.1 Klient/server

Základní architekturou komunikace v protokolu HTTP je komunikace klient server. V případě, že se navazuje přímé spojení protokolem TCP mezi klientem a serverem (obr. 2-10), pak uživatel zapíše do okna prohlížeče identifikátor objektu (URI), jenž chce prohlížet, a klient nejprve z identifikátoru objektu vyřízne jméno serveru jež přeloží za pomocí DNS na IP-adresu ( 1 a 2). Poté klient naváže s takto získanou IP-adresou serveru spojení protokolem TCP.

Do takto vytvořeného kanálu vloží prohlížeč HTTP-dotaz 3 na který v témž spojení server odpoví HTTP-odpovědí 4. Prohlížeč následně zobrazí odpověď uživateli. Důležité je, že prohlížeč zobrazuje uživateli web-stránky. Každá web-stránka se většinou skládá z řady objektů. Každý objekt je nutné z web-serveru stáhnout jedním HTTP-dotazem. V protokolu HTTP starších verzí se pro každý dotaz vždy navazovalo nové TCP spojení. Takže prvním dotazem se stáhl základní text stránky ve kterém byla řada dalších odkazů, které bylo nutné stáhnout pro zobrazení stránky. V dalším kroku se pokud možno najednou navázalo s web-serverem pro stažení každého objektu TCP spojení. Tato strategie vede k vytvoření špičky v zátěži přenosové cesty.

Protokol HTTP verze 1.1 implicitně předpokládá, že TCP spojení bude mezi klientem a serverem navázáno jedno pro celou sadu dotazů („pro celou web-stránku“). Je možné jej uzavřít i po jednom dotazu i po více dotazech. Klient může odeslat v jednom spojení více dotazů aniž by vždy čekal na vyřízení předchozího dotazu (Pipelining).

Obr. 2-10 Architektura protokolu HTTP

Protokol HTTP verze 1.1 implicitně předpokládá, že do vytvořeného spojení se vkládá více dotazů a odpovědí na ně. Pakliže je požadováno spojení explicitně ukončit, pak je třeba do záhlaví vložit hlavičku:

Connection: Close

Komunikace v protokolu HTTP se zásadně skládá z dotazu a odpovědi. Relace mezi klientem a serverem je tvořena vždy pouze dotazem a odpovědí na tento dotaz. Starší verze protokolu HTTP dokonce navazovaly spojení protokolem TCP pouze na jednu relaci dotaz – odpověď. Novější verze umožňují využít navázané spojení na více relací dotaz – odpověď. Avšak i v případě, že jedním TCP spojením prochází více relací, tak tyto relace spolu nikterak nesouvisí.

Obr. 2-11 Dotaz (GET …) následovaný odpovědí (HTTP/1.1 200 …) protokolu HTTP, který byl proveden programem telnet (zobrazení stránky www.playboy.com pro odborníky)

Na obr. 2.1 je programem telnet navázáno spojení se serverem www.playboy.com na portu 80. Z klávesnice jsem pak zadal dotaz protokolu HTTP:

GET / HTTP/1.1 … metodou GET požadovaný obsah kořenového adresáře

Host: www.playboy.com … zadání virtuálního web-serveru

… prázdný řádek oddělující záhlaví od dat

Okamžitě přišla odpověď:

HTTP/1.1 200 OK …

Kupodivu některým uživatelům takováto komunikace s web-serverem nepostačuje, požadují příslušné informace graficky zobrazit (obr. 2-12). Avšak to je podstatně komplikovanější problém. Komunikace na obr. 2-11 zobrazila text formátovaný v jazyce HTML, který sám obsahuje pouze odkazy na obrázky, takže každý obrázek z web-stránky 2-12 musí být dodatečně z web-serveru stažen samostatnou komunikací dotaz/odpověď. Přičemž tyto komunikace jsou naprosto samostatné (byť by běžely jedním TCP spojením), tj. obrázek může být použit i na jiných stránkách či může být stažen samostatně (pravým tlačítkem myši v prohlížeči).

Obr. 2-12 Zobrazení příslušné web-stránky pro běžné uživatele

Jiným omezením protokolu HTTP je použití architektury klient/server. Ta neumožňuje odesílat asynchronní události ze serveru klientovi. Protokolem HTTP se tak těžko vytvářejí aplikace typu „burza“. Tj. kdy by pro uživatele bylo praktické v případě zajímavé směny cenného papíru, aby server upozornil klienta na tuto skutečnost. Server může tuto skutečnost tak sdělit klientovi nejdříve v okamžiku, kdy klient odešle nějaký dotaz na server.

Uživatel si většinou nastaví prohlížeč (klienta) tak, že získaný požadavek nejenom uživateli zobrazí, ale pokud je to možné, tak je též uloží na disk do paměti cache. Pří opakování dotazu pak může být uživateli informace zobrazena přímo z lokálního disku. Jsou nejrůznější strategie, kdy zobrazovat tyto informace a kdy má klient přenést informace ze serveru. Dokonce existuje i možnost, že se klient dotáže serveru, zda-li se informace nezměnily tím, že ze serveru přenese pouze záhlaví odpovědi. Některé odpovědi serveru mohou být označeny jako neuložitelné do paměti cache, pak je tam klient uložit nesmí.

Internetový prohlížeč nebývá klientem pouze protokolu HTTP. Zpravidla se jedná o integrovaného klienta, který „umí“ i protokol FTP a případně umí vyvolat klienty dalších protokolů:

Protokolů elektronické pošty.
Protokolu LDAP (tj. adresář).
Protokolu NNTP (tj. diskusní skupiny).
Telnet apod.

Protokol HTTP zavádí proxy, bránu a tunel. Jedná se o mezilehlé systémy, které mohou ležet na cestě mezi klientem a serverem. Na cestě od klienta k serveru může ležet libovolné množství těchto mezilehlých systémů. Z hlediska protokolu TCP se navazuje TCP spojení vždy mezi dvěma uzly. Tj. TCP spojení mezi klientem a první proxy, mezi první proxy a druhou proxy atd. Při popisu proxy, brány a tunelu se omezím nejprve na situaci, že mezi klientem a serverem je pouze jeden mezilehlý systém. Následně si pak řekneme, že umístěním více mezilehlých systému se vůbec nic nezmění.

Nejčastěji se proto tyto systémy používají tam, kde není možné přímo navázat TCP spojení mezi klientem a serverem. Tj. např. na firewallu oddělujícím intranet od Internetu.

2.3.2 Proxy

Proxy je systém skládající se ze dvou částí:

Ze serverové části, která přijímá požadavky klienta jakoby je přijímal cílový server. Požadavky však v zápětí předá klientské části.
Z klientské části, která převezme požadavky od serverové části, naváže TCP spojení s cílovým serverem a předá jménem klienta požadavky cílovému serveru k vyřízení.

Obr. 2-13 Proxy (na obrázek se již v dotazu klienta nevešla verze protokolu a hlavička Host)

Na obr. 2-12 je zobrazena konfigurace internetového prohlížeče. Je tam konfigurováno proxy pro protokol HTTP. Dále je tam konfigurace brány pro protokoly FTP a Gopher. Řádek začínající „Secure“ je konfigurací tunelu pro SSL.

Obr. 2-14 Konfigurace proxy, brány a tunelu v internetovém prohlížeči

2.3.3 Brána

Brána (gateway) je mezilehlý uzel, který pracuje obdobně jako proxy avšak s tím rozdílem, že mění aplikační protokol. Nejběžnějším případe brány je brána, jejíž serverová část od klientů přijímá požadavek v protokolu HTTP a mění jej na komunikaci v protokolu FTP (viz obr.2-13).

Obr. 2-15 Brána (na obrázek se již v dotazu klienta nevešla verze protokolu a hlavička Host)

2.3.4 Tunel

Tunel je trochu jiná písnička. Tunel totiž nemusí „rozumět“ přenášeným datům. Tunelem lze dokonce přenášet aplikační data zašifrovaná. Toho využívá protokol SSL (viz řádek Secure na obr. 2-12).

Činnost tunelu si objasníme na obr. 2-14. Klient přeloží jméno tunelu na IP-adresu (1 a 2). Klient naváže s tunelem TCP spojení. Do takto vytvořeného kanálu klient zpravidla vloží pouze příkaz (tj. metodu) CONNECT se jménem a portem cílového serveru 3. Tunel přeloží jméno cílového serveru na IP-adresu (5 a 6) a naváže s cílovým serverem TCP spojení na portu uvedeném v příkazu CONNECT.

Obr. 2-16 Tunel

Nyní má tunel navázány dvě obousměrná spojení. Každé spojní si představíme jako dvě roury (obr. 2.15): jedna roura je pro spojení tam a druhá pro spojení zpět (duplexní spoj).

Obr. 2.17 Tunel „navaří“ spojení na sebe

Tunel neudělá nic jiného, že roury „navaří na sebe“, tj. tunel aniž by věděl co přenáší, tak mechanicky co přijde od klienta předá do roury na cílový server. Obdobně vše co přijde ze serveru předá klientovi.

V takovémto spojení pak klient může začít protokolem SSL navazovat šifrované spojení.

2.3.5 Více mezilehlých uzlů

Jsou možné nejrůznější kombinace mezilehlých systémů na cestě od klienta až po cílový server.

Obr. 2-18 Řetězec mezilehlých systémů

2.3.6 URI

Identifikátorem objektů ve webovém světě jsou tzv. URI (Uniform Resource Identifiers). URI mohou být: Uniform Resource Names (URN), Uniform Resource Locators (URL) a Uniform Resource Characteristics (URC). V praxi se setkáváme pouze s URL.

Jednotlivé aplikační protokoly mají své schéma URI. URI specifikuje RFC-1738 jako

<schéma>:<na_schématu_závislá_část>

kde <schéma> může mj. být:

http Protokol HTTP

ftp Protokol FTP

mailto Odeslání elektronické pošty (protokol SMTP)

nntp Protokol NNTP (diskusní skupiny)

telnet Odkaz na relaci protokolem Telnet

file Soubor (např. na disku)

imap Protokol IMAP

ldap Protokol LDAP

pop Protokol POP3

Ve schématu (nikoliv v celém URI) nezávisí na tom, jestli použijeme velké nebo malé písmeno, tj. ftp je totéž jako FTP či Ftp.

V celém URI se mohou vyskytovat pouze znaky kódu US-ASCII. V případě, že je nutné zadat jiný znak, pak se tento znak uvodí znakem % následovaným šestnáctkový vyjádřením znaku. V šestnáctkovém vyjádření znaku můžeme psát jak velká písmena, tak i malá písmena pro šestnáctkové číslice A až F. Znaky ";", "/", "?", ":", "@", "=" a "&" jsou vyhrazeny pro speciální použití, tj. mají-li se použít v nějakém řetězci, pak musí být konvertovány do šestnáctkové soustavy a uvozeny procentem.

2.3.7 Relativní URI

Nezačíná-li URI názvem schématu, pak se jedná o relativní URI. Relativní URI je vždy vztaženo k nějaké bázi – nějakému absolutnímu URI. Bází může být URI zobrazovaného dokumentu nebo případně i předešlého dokumentu, tj. URI dokumentu, ze kterého byl odkaz proveden. V případě, že žádné takové URI neexistuje, pak může být použito implicitní URI celé aplikace.

2.3.8 HTTP dotaz

Struktura HTTP dotazu (i odpovědi) připomíná strukturu e-mailu. Na první pohled vidíme rozdíl pouze v prvním řádku. První řádek dotazu obsahuje tzv. metodu a první řádek odpovědi obsahuje tzv. stavový řádek.

HTTP dotaz se skládá (viz obr. 2-17) z:

· Metody. Protokol HTTP verze 1.1 podporuje metody: GET, POST, HEAD, OPTIONS, TRACE, CONNECT, PUT a DELETE. Metody PUT a DELETE nebývají implementovány.

· Záhlaví, které je tvořeno jednotlivými hlavičkami. Každá hlavička začíná klíčovým slovem (např. Host: ). Klíčové slovo je ukončeno dvojtečkou následovanou mezerou. Za mezerou pak mohou následovat parametry hlavičky. Celá hlavička je vždy ukončena koncem řádku CRLF. Pouze jediná hlavička je povinná, a to hlavička Host.

· Prázdného řádku (CRLF CRLF, kde první CRLF ukončuje poslední řádek hlavičky)

· Přenášených dat (volitelně).

Obr. 2-19 Struktura a příklad HTTP dotazu

Metoda má v protokolu HTTP verze 1.1 vždy tvar:

<Název metody> <URI> HTTP/1.1

kde je verze protokolu HTTP/1.1, což tč. aktuální verze. Uvedení verze je povinné. Pokud bychom uvedli jen název metody a URI, pak se jedná o dotaz v protokolu HTTP verze 0.9. Nesmíme se pak divit, že v odpovědi nedostaneme ani stavový řádek, ten byl totiž zaveden až ve verzi 1.0 (verze 1.0 neměla zase mj. hlavičku Host:).

Obr. 2-20 Rozbor URI prohlížečem (na cestě mezi klientem a serverem není proxy, brána ani tunel)

Pokud poprvé kontaktuji nějaký server, tak nemá smysl uvažovat u relativního URI o bázi ze zobrazeného dokumentu či z dokumentu ze kterého byl dokument zobrazen. Absolutní URI se tak rozloží na model (např. protokol HTTP, který implicitně navazuje spojení na port 80 serveru), jméno počítače, které se překládá v DNS (aby spojení vůbec mohlo být navázáno) a zbytek, tj. cestu a případně dotaz a fragment.

Server naopak relativní URI doplní na absolutní. Aplikací je HTTP-server (bylo navázáno spojení na portu 80), takže schéma je http. Jméno serveru se doplní z hlavičky host a zbytek server obdržel jako parametr metody.

Metoda GET

Metoda POST

Metoda HEAD

Metoda TRACE

Metoda OPTIONS

2.3.9 HTTP odpověď

HTTP-odpověď začíná stavovým řádkem, který má tvar:

<Verze> <Výsledkový kód> <Poznámka>

Kde verze je verzí protokolu HTTP ve které je odpověď formulována. Výsledkový kód specifikuje úspěšnost/neúspěšnost operace a poznámka textově objasňuje výsledek operace. Za stavovým řádkem následuje opět záhlaví tvořené hlavičkami. Záhlaví je ukončeno prázdným řádkem, který odděluje záhlaví od přenášených dat. V případě, že záhlaví obsahuje hlavičku “Transfer-Encoding: chunked“, pak za daty může být opět prázdný řádek následovaný zápatím. Zápatí je opět tvořeno hlavičkami. Nesetkal jsem se v praxi s případem, kdy by se zápatí použilo.

Příklad stavového řádku (kladná odpověď):

HTTP/1.1 200 OK

Za stavovým řádkem obdobně jako v případě HTTP-dotazu začíná záhlaví tvořené hlavičkami. Za záhlavím následuje prázdný řádek. Za prázdným řádkem mohou následovat data odpovědi.

Výsledkové kódy jsou trojciferné. První cifra charakterizuje odpověď:

1xx – informativní odpověď, zpracování pokračuje dále.
2xx – akce proběhla úspěšně.
3xx – přesměrování, tj. další akce musí být na jiné URI.
4xx – chyba klienta (např. syntaktická chyba v dotazu).
5xx – chyba serveru (např. chyba CGI-skriptu).

Přehled výsledkových kódů:

100 Continue

101 Switching Protocols

200 OK

201 Created

202 Accepted

203 Non-Authoritative Information

204 No Content

205 Reset Content

206 Partial Content

300 Multiple Choices

301 Moved Permanently

302 Found

303 See Other

304 Not Modified

305 Use Proxy

307 Temporary Redirect

400 Bad Request

401 Unauthorized

402 Payment Required

403 Forbidden

404 Not Found

405 Method Not Allowed

406 Not Acceptable

407 Proxy Authentication Required

408 Request Time-out

409 Conflict

410 Gone

411 Length Required

412 Precondition Failed

413 Request Entity Too Large

414 Request-URI Too Large

415 Unsupported Media Type

416 Requested range not satisfiable

417 Expectation Failed

500 Internal Server Error

501 Not Implemented

502 Bad Gateway

503 Service Unavailable

504 Gateway Time-out

505 HTTP Version not supported

Pokud se informace nevejde do stavového řádku, pak je do odpovědi přidána další informace v hlavičce Warning. Jedná se v podstatě o doplňující stavový řádek. Hlavička Warning má dva parametry oddělené mezerou: výsledkový kód a poznámku.

Nejčastěji se hlavička Warning používá k doplnění informací podávaných z paměti cache, tj. nikoliv z první ruky (ze serveru). Může se totiž stát, že cache vrací prošlé informace, protože např. proxy není schopna navázat spojení dále směrem k serveru (to jsou výsledkové kódy 110 až 112).

Přehled výsledkových kódů používaných v hlavičce Warning:

110 Response is stale

111 Revalidation failed

112 Disconnected operation

113 Heuristic expiration

199 Miscellaneous warning

2.4 Architektura elektronické pošty

Základní představa architektury elektronické pošty (obr. 2-22) na Internetu pochází z poloviny 70. let. Dnes je základem poštovní komunikace na Internetu norma RFC-821 z roku 1982 (tvar poštovní zprávy popisuje RFC-822). Tehdy uživatelé seděli u terminálů, ze kterých spouštěli poštovní klienty. Poštovní klient nemá nic společného se síťovou komunikací, poštovní klient je v podstatě pouze specializovaný textový editor. Tento textový editor umí uživateli zobrazit obsah zprávy z poštovní schrány, umí manipulovat se zprávami v poštovní schránce a totéž umí také s privátními poštovními schránkami uživatele. Dále poštovním klientem je možné zprávu pořídit a odeslat. Opět odesláním se nerozumí nějaká síťová komunikace, ale uložení zprávy do fronty zpráv.

Fronta zpráv je pak pravidelně procházena SMTP klientem, který navazuje spojení se vzdálenými SMTP servery, kterým zprávu předá.

SMTP server přijme zprávu a zjišťuje, zda-li je určena pro jeho lokální uživatele. V případě, že nikoliv, pak zprávu opět uloží do poštovní fronty, kterou obsluhuje jeho poštovní klient jenž se pokouší zprávu doručit směrem k adresátovi.

V případě, že adresát je lokálním uživatelem systému, pak SMTP server uloží přijatou zprávu do poštovní schránky adresáta. Zde je třeba upozornit, že poštovní server mívá přístupová práva ke všem uživatelům svého systému. Tj. SMTP server bývá spuštěn pod privilegovaným uživatelem. Pokud by tak útočník se dokázal prolomit do poštovního serveru, pak může získat neomezený přístup do systému. Proto je správnější jiný postup: poštovní server běží pod jiným uživatelem než superuživatgelem a přístup do poštovních schránek uživatelů se mu zajistí přes skupinová práva.

Uživatel má v systému zpravidla jednu poštovní schránku INBOX, kam SMTP server ukládá jeho příchozí poštu. Ona se ta poštovní schránka nejmenuje INBOX jako soubor, ale zpravidla má jméno shodné se jménem uživatele. Název INBOX pro ni používá protokol IMAP4.

Kromě toho si uživatel může zřídit i privátní poštovní schránky, kam si ukládá ze schránky INBOX došlou poštu. Privátní poštovní schránky nejsou obsluhovány SMTP serverem a bývají zřizovány pod domovským adresářem uživatele. Cílem je přimět uživatele k tomu, aby v „systémové“ schránce INBOX příchozí poštu nearchivovali. Tohoto cíle dosahují i někteří poštovní klienti tím, že pokud příchozí poštu uživateli zobrazí, tak ji automaticky přenesou do privátní poštovní schránky, kterou pokud uživatel nepojmenuje jinak, tak pojmenují INBOX nebo inbox, ale v domovském adresáři uživatele.

Internetová pošta má díky ukládání odchozí pošty do fronty a ukládání příchozí pošty do poštovní schránky jednu zásadní vlastnost. Tou je skutečnost, že uživatel může „odeslat“ mail, který si příjemce může vyzvednout ze své schránky až bude chtít. Tj. není nutné okamžitě navazovat spojení na příjemcův systém v době odeslání pošty. Příjemcův systém může být i vypnut v době, kdy odesilatel zprávu odesílá. Nepodaří-li se klientovi SMTP odeslat poštu, tak ji ponechá ve frontě. Zpráva pochopitelně nebude ve frontě do nekonečna. Správce systému má většinou nastavenu maximální dobu položky v poštovní frontě na 2-7 dní. Poté se pošta vrací odesilateli jako nedoručená.

Je to ještě komplikovanější. SMTP klient nemůže odeslat zprávu z mnoha důvodů. Je na správné konfiguraci aby v podstatě rozlišovala mezi dvěmi situacemi:

· Momentálně např. nelze poštu dále doručit, ale je pravděpodobné, že za jistou dobu to půjde (např. jméno cílového systému se přeložilo v DNS, ale systém je nedostupný).

· Zprávu nelze doručit pro chybu, kterou nelze odstranit (např. jméno vzdáleného systému je správně, ale uvedený adresát na systému neexistuje). V takovém případě je třeba zprávu neštosovat ve frontě, ale okamžitě vrátit odesilateli.

Obr. 2-22 Architektura SMTP

Na obr. 2-22 uživatel A chce odeslat zprávu elektronickou poštou uživateli B. Uživatel A pomocí svého poštovního klienta pořídí zprávu. Nakonec pořízenou zprávu „odešle“, avšak odeslání je pouze uložení zprávy do fronty. Klient SMTP prochází frontu až dorazí na naší zprávu. Zprávu se pokouší doručit na adresátův systém, pokud se mu to nepodaří, tak zprávu ponechá ve frontě.

V případě, že server zprávu přijme, pak zkoumá, zda-li je adresát zprávy lokálním uživatelem systému, pak mu zprávu uloží do jeho poštovní schránky. V případě, že adresát není lokálním uživatelem systému, tak zprávu uloží do fronty k odeslání dále.

Příjemce si pak může přijatou zprávu zpracovat svým poštovním klientem.

S příchodem osobních počítačů přišel zvrat i v používání elektronické pošty. Ve svém jádře elektronická pošta zůstala zachována, avšak uživatel již nechce sedět u terminálu poštovního serveru (byť emulovaného protokolem Telnet na svém PC), ale chce využívat aplikace na svém PC. Otázkou je, jak z PC poštu odeslat a jak na PC poštu přijmout.

Zatímco při odesílání pošty z PC lze vcelku bez problému opět použít protokol SMTP, tak pro příjem pošty z poštovního serveru na PC není protokol SMTP tím pravým. Co by to totiž znamenalo? Příjemce má své PC zapnuto zpravidla jen několik hodin. Mimo tuto dobu by zůstávala pošta v odesilatelově frontě a příjemcův systém by se jevil jako nedostupný. Dalším problémem je, že na příjemcově PC by musel běžet SMTP server. Zvolila se proto jiná strategie znázorněná na obr. 2-23.

Uživatel má svou příchozí poštovní schránku (INBOX) na poštovním serveru. Tj. z hlediska protokolu SMTP je poštovní server cílovou stanicí. Zůstává vyřešit, jak si vybírat INBOX ze svého PC.

Pro práci s poštovní schránkou uživatele na poštovním serveru jsou k dispozici dva protokoly (oba jsou podporovány jak klienty Microsoft, tak klienty Netscape):

Protokol POP3. Jedná se o velice jednoduchý protokol, kterým pracuje uživatel OffLine. Tj. z poštovního serveru si uživatel stáhne příchozí poštu na své PC a ukončí TCP spojení se serverem. Teprve po stažení pošty uživatel pracuje s jednotlivými poštovními zprávami. V případě, že chce uživatel poštu odeslat, pak použije protokol SMTP.
Protokol IMAP4. Jedná se o komplikovaný protokol, který umožňuje nejen pracovat OffLine, ale i OnLine. Uživatel může mít navázáno spojení s poštovním serverem delší dobu a být serverem průběžně informován o změnách ve své poštovní schránce. Protokol IMAP umožňuje též pracovat s privátními poštovními schránkami přímo z terminálu na serveru. Protokolem IMAP4 je možné také synchronizovat poštovní schránky na PC a na serveru. Schránky na serveru tak zůstávají zálohou schránek na PC. V případě, že chce uživatel poštu odeslat, pak také použije protokol SMTP. Použití protokolu IMAP je praktické zejména v případě, že občas chceme pracovat z PC a občas z terminálu serveru.

Obr. 2-23 Protokoly POP3 a IMAP4

Otázkou je kdy zvolit POP3 a kdy IMAP4. Odpověď je jak kdy. Např. pro velké poskytovatele internetových služeb je velice výhodný protokol POP3, protože pošta nezůstává na serveru (obr. 2-24). Uživatelé si ji stahují na svá PC. Při představě, že sto tisíc uživatelů má trvale svou poštu na serveru, pak žádná disková kapacita není dostatečná pro takové ohromné množství dat. To může být příležitost pro malé poskytovatele, kteří mohou poskytovat některým svým klientům nadstandardní službu privátních poštovních stránek na serveru.

Naopak pro menší firmy je výhodný protokol IMAP4, protože se tím provádí záloha poštovních schránek. A je jednodušší zálohovat jednu diskovou kapacitu, než aby si to dělal každý uživatel sám. Přitom ztráta obsahu poštovní schránky může pro vedoucího pracovníka způsobit i velké ekonomické škody. Je proto nutné při použití protokolu POP3 dbát na to, aby pošta byla zálohována např. na server, na diskety či na magnetickou pásku.

Obr. 2-24 Pošta v případě velkých poskytovatelů internetových služeb

Na obrázcích neuvádíme slovo poštovní server, ale SMTP agent. Je to proto, že na poštovním serveru je vždy SMTP klient pro odesílání pošty a SMTP server pro příjem pošty. Navíc software poštovního klienta musí v pravidelných intervalech procházet frontu a její položky se snažit odeslat. Tj. jedná se o službu (resp. démona), který stále běží. A jen v okamžiku odesílání jedné položky fronty se tento démon chová z hlediska protokolu TCP jako klient.

Otázkou je jak zorganizovat poštu ve vnitřní síti firmy. V případě, že máme více poštovních serverů, pak se osvědčilo použití jednoho centrálního poštovního serveru označovaného jako „mail hub“. Centrálním poštovní serverem pak prochází veškerá poštovní komunikace firmy. Zaznamenává se zde průchod všech poštovních zpráv firmy a je možné na jednom místě dohledat, zda-li mail odešel a kdy. Podobně jako u proxy je i na centrálním poštovním serveru možné kontrolovat, zda-li poštovní zprávy neobsahují viry. Kdyby byla možná přímá komunikace mezi jednotlivými systémy, pak by taková ochrana byla nutná na každém systému, což by mohlo být ekonomicky neúnosné.

Konfigurací poštovních serverů se zabývá postmaster. Jelikož je konfigurace poštovních serverů komplikovaná, tak postmasterem se musí člověk prostě narodit, proto sehnat a zaplatit dobrého postmastera není jednoduché. V případě centrálního poštovního serveru se veškeré konfigurační lahůdky soustředí na konfiguraci poštovního servu. Konfigurace lokálních poštovních agentů bývá jednoduchá (vše odesílají na centrální poštovní server). Často lze pro konfiguraci lokálního poštovního agenta použít nastavení vzniklé při instalaci systému.

Je několik možností jak nakonfigurovat centrální poštovní server firmy. Na počátku je třeba stanovit jaké budou zaměstnanci používat poštovní adresy. Jsou v podstatě dvě filosofie:

Poštovní adresy typu novak@obchod.firma.cz či dvorak@provoz.firma.cz.
Poštovní adresy typu Frantisek.Novak@firma.cz.

V prvním případě vnitřní síť firmy rozdělíme na DNS domény obchod.firma.cz, provoz.firma.cz atd. Pro doménu budeme provozovat lokální poštovní server (lokální poštovní agent). Přitom je možné obsluhovat na fyzicky jednom serveru i více domén.

Z internetu nám přicházejí poštovní zprávy pro novak@obchod.firma.cz na centrální poštovní server. Centrální poštovní server je nakonfigurován tak, aby všechny maily do domény obchod.firma.cz předával na server s1.obchod.firma.cz.

Na serveru s1.obchod.firma.cz má pak uživatel novak svou poštovní schránku (INBOX). Uživatel novak tak pravděpodobně bude mít dvě poštovní adresy:

· novak@s1.obchod.firma.cz

· novak@obchod.firma.cz

Obr. 2-25 Centrální poštovní server (mail hub)

Protože SMTP agent bude na serveru s1.obchod.firma.cz pravděpodobně nakonfigurován tak, aby akceptoval pro své lokální uživatele obě poštovní adresy.

Ve druhém případě uživateli přichází poštovní zpráva pro adresáta Frantisek.Novak@firma.cz na centrální poštovní server. Zde se tato adresa přeloží na adresu novak@obchod.firma.cz nebo na adresu novak@s1.obchod.firma.cz. To je již adresa doručitelná v rámci vnitřní sítě. Jinou možností centrálního poštovního serveru je nepřekládat adresu příjemce a držet informaci, že tento příjemce má poštovní schránky na serveru s1.obchod.firma.cz. Ten pak může jméno Frantisek.Novak akceptovat či přeložit na novak - to již závisí na konfiguraci lokálního mailového serveru.

Uživatel tak může mít už i tři poštovní adresy:

· novak@s1.obchod.firma.cz

· novak@obchod.firma.cz

· Frantisek.Novak@firma.cz

Centrální poštovní server je většinou nakonfigurován tak, že u odchozí pošty do Internetu přepisuje adresu odesilatele tak, aby každý odesilatel měl jen jednu adresu. A také adresy typu novak@s1.obchod.firma.cz do Internetu sdělují něco o vnitřní struktuře firmy, což může být potenciálním zdrojem informací i pro útočníky.

To, že uživatel má více adres vcelku ve vnitřní síti nevadí. Nepříjemné je to u konferencí v Internetu. Např. uzavřené konference (na bázi systému listserv) kontrolují adresu odesilatele. Pokud se uživatel může zaregistrovat do konference pod jedním jménem a pakliže tam pod jiným jménem zašle příspěvek, tak může být příspěvek odmítnut.

Má to takové nepříjemné ponaučení: pokud si chcete ušetřit práci, pak neumísťujte servery konferencí (mailman či listserv) do vnitřních podnikových sítí– umísťujte je do Internetu, na demilitarizované zóny nebo přímo na centrální poštovní server. V Internetu většinou totiž vystupujete pod jednou poštovní adresou. Navíc se takové chyby nejenom těžko zjišťují, ale zejména i těžko odstraňují. To má však i svůj rub. Pokud se jedná o vnitropodnikovou konferenci, pak její umístění do Internetu není z bezpečnostních důvodů většinou vhodné a stojí nám za to si dát jistou práci s konfigurací konference.

2.5 Formát poštovní zprávy

2.5.1 Přehled základních hlaviček z RFC-822

Hlavička	Význam
Received:	Tuto hlavičku připisuje na počátek mailu každá mailová gateway (mailový server), kterou zpráva prochází. Takže čteme-li hlavičky Received: od spodu nahoru, tak zjistíme celou trasu, přes které mailové servery zpráva šla. V této hlavičce se mohou vyskytovat slova: from – počítač ze kterého byla zpráva přijata by – počítač kterým byla zpráva přijata via – fyzická cesta with – síťový nebo poštovní protokol id – příjemcova identifikace zprávy for – pro koho je zpráva určena (naříklad je-li adresátem distribuční list, pak se zde zachová původní adresát – tj. distribuční list)
From:	Od
Sender:	Vyřizuje (sekretářka) – prakticky zde bývá např. informace o konferenci, přes kterou zpráva přišla
Date:	Datum odeslání (Den, datum, čas a časová zóna)
Reply-To:	Odpověď zasílejte na
In-Reply-To:	Odpovídáme Vám na vaší zprávu: Identifikace původní zprávy
To:	Adresát
Cc:	Na vědomí (Carbon Copy)
Bcc:	Tajná kopie - tato hlavička se před odesláním smaže (Blind Carbon Copy)
Message-Id:	Identifikace zprávy.
Keywords:	Klíčová slova charakterizující obsah
References:	Další odkazy
Subject:	Věc (krátká charakteristika obsahu zprávy)
Comments:	Komentář
Encrypted:	Šifrováno (zastaralé)
X-	Uživatelsky definovaná hlavička (uživatelem se rozumí autor software). Např. X-Mailer se často používá pro specifikaci programu, kterým odesilatel odesílá zprávu
Resent-	Při automatickém předávání zprávy (např. vrácení nedoručitelné zprávy) se před původní hlavičky vloží řetězec Resent- Např.Resent-From nebo Resent-Cc apod.

Příklad:

Received: from mh.pvt.cz (mh.pvt.cz [194.149.105.36])

          by cbu.pvtnet.cz  (8.8.5/8.7.3)

          with SMTP id PAA23028;

          Wed, 16 Apr 1997 15:10:14 +0200 (MET DST)

Received: from ncc.ripe.net by mh.pvt.cz

          with SMTP id AA08008 (5.67b/IDA-1.5

          for <registr@pvt.cz>);

          Wed, 16 Apr 1997 15:05:09 +0200

Received: by ncc.ripe.net

          id AA00228 (5.65a/NCC-2.41);

          Wed, 16 Apr 1997 13:55:02 +0200

Received: from mail.freedotnet.net

          by ncc.ripe.net with SMTP

          id AA00215 (5.65a/NCC-2.41);

          Wed, 16 Apr 1997 13:55:00 +0200

Received: from jon.freedotnet.net ([208.215.186.129])

          by homer.freedotnet.com (Netscape Mail Server v2.02)

          with ESMTP

          id AAA105 for <local-ir@ripe.net>;

          Wed, 16 Apr 1997 13:09:15 +0100

Reply-To: <jon.brody@freedotnet.net>

From: "Dr Jon Brody" <jon.brody@freedotnet.net>

To: <local-ir@ripe.net>

Subject: Re: Role?

Date: Wed, 16 Apr 1997 12:58:51 +0100

X-Mailer: Microsoft Internet Mail 4.70.1155

Text mailu

Hlavičky této zprávy se musí rozdělit na hlavičky začínající Received a ostatní hlavičky. Hlavičky Received přidávají na začátek zprávy poštovní servery, kterými zpráva prochází. Proto u hlaviček Received záleží na pořadí. Hlavička Received, kterou přidal první server je poslední. Hlavička Received před ní je hlavičkou, kterou přidal další server atd.

Čteme-li hlavičky Received od spodu nahoru, pak vidíme, že zpráva byla odeslána z počítače jon.freedotnet.net, pak ji zpracovával počítač homer.freedotnet.net (počítač mail.freedotnet.net je jen jiné jméno téhož počítače). Dále zpráva putovala na ncc.ripe.net, který ji předal na mh.pvt.cz a nakonec skončila na cbu.pvtnet.cz.

2.6 SMTP

Vlastní protokol SMTP (Simple Mail Transfer Protocol) je poměrně jednoduchý protokol. Jednotlivé příkazy jsou textové v kódu ASCII (podobně jako u protokolu FTP). Je proto snadné využívat program telnet např. pro odeslání poštovní zprávy protokolem SMTP.

Klient navazuje spojení protokolem TCP se serverem na portu 25. Klient vkládá do takto vytvořeného kanálu příkazy a server odpovídá odpovědí obsahující trojciferný stavový kód a následovaný textovým popisem chyby.

Příkazy klienta jsou čtyřznaková slova. Nezávisí na tom, zda-li se použijí velká či malá písmena (či jejich kombinace). Příkaz může být následován parametrem, který je oddělen mezerou. Příkaz je zakončen koncem řádku CRLF.

Příkaz
HELO klient	Klient se představuje serveru jménem počítače. Příkaz se často používá na počátku dialogu: C: helo libor.pvt.net S: 250 dns.terminal.cz Hello Libor.pvt.net, pleased to meet you
MAIL FROM: odesilatel	Odesilatel
RCPT TO: příjemce	Příjemce (tento příkaz se opakuje pro každého příjemce)
DATA	Chci odeslat zprávu
RSET	Aktuální translace bude abnormálně ukončena (veškeré přenesené informace ve FROM a TO budou zahozeny).
SEND FROM: odesilatel	Obdoba příkazu MAIL, ale zpráva má být zobrazena na terminálu příjemce. Nepoužívá se.
SOML FROM: odesilatel	Obdoba příkazu MAIL, ale zpráva má být zobrazena na terminálu nebo uložena do poštovní schránky příjemce. Nepoužívá se.
SAML FROM: odesilatel	Obdoba příkazu MAIL, ale zpráva má být zobrazena na terminálu a také uložena do poštovní schránky příjemce. Nepoužívá se.
VRFY adresa	Dotaz, zda-li příjemce zná uvedenou adresu. Server vrací plné jméno uživatele a jeho přesnou poštovní identifikaci.
EXPN adresa	Obdoba VRFY, ale umí pracovat nejen s jednotlivými uživateli, ale i s celými sezanmy uživatelů.
HELP [příkaz]	C: help S: 214-This is Sendmail version 8.9.3 S: 214-Topics: S: 214- HELO EHLO MAIL RCPT DATA S: 214- RSET NOOP QUIT HELP VRFY S: 214- EXPN VERB ETRN DSN S: 214-For more info use "HELP <topic>".
QUIT	Ukončení spojení.
TURN	Přepnutí role serveru a klienta. Pokud server tento příkaz potvrdí, pak klient očekává, že server začne s odesíláním poštovních zpráv ze serveru na klienta. Jelikož se tento příkaz nepovažuje za bezpečný, tak se nepoužívá. Nebezpečí spočívá v tom, že kdokoliv bez jakékoliv autentizace by mohl „vycucnout“ ze serveru frontu mailů.

Přehled stavových kódů

211 System status, or system help reply

214 Help message

220 <domain> Service ready

221 <domain> Service closing transmission channel

250 Requested mail action okay, completed

251 User not local; will forward to <forward-path>

354 Start mail input; end with <CRLF>.<CRLF>

421 <domain> Service not available,

450 Requested mail action not taken: mailbox unavailable

451 Requested action aborted: local error in processing

452 Requested action not taken: insufficient system storage

500 Syntax error, command unrecognized

501 Syntax error in parameters or arguments

502 Command not implemented

503 Bad sequence of commands

504 Command parameter not implemented

550 Requested action not taken: mailbox unavailable

551 User not local; please try <forward-path>

552 Requested mail action aborted: exceeded storage allocation

553 Requested action not taken: mailbox name not allowed

2.7 ESMTP

Rozšířením protokolu SMTP vznikl protokol ESMTP (Extensions SMTP). Princip rozšíření specifikuje RFC-1869. Základním problémem jakéhokoliv rozšíření je jeho zpětná komptabilita. ESMTP v tomto směru přichází s velice vtipným řešením.

Zatímco protokol SMTP zpravidla začíná svůj dialog příkazem HELO, tak ESMTP použije příkaz EHLO. Server buď odpoví:

Že se klient musel splést ve jméně příkazu, pak si odesilatel okamžitě uvědomí, že server je „pouze“ SMTP a pokračuje příkazem HELO.
Stavovým kódem 250 „že je vše v pořádku“ a klient okamžitě pozná, že server je ESMTP. Navíc server ve své odpovědi navíc uvede, které že rozšiřující příkazy podporuje:

C: ehlo Libor.pvt.net

S: 250-dns.terminal.cz Hello Libor.pvt.net, pleased to meet you

S: 250-EXPN

S: 250-VERB

S: 250-8BITMIME

S: 250-SIZE 8388608

S: 250-DSN

      S: 250-ONEX

S: 250-ETRN

S: 250 HELP

2.7.1 Potvrzení o doručení zprávy

Elektronická pošta v Internetu negarantuje doručení zprávy. Z nejrůznějších příčin může být zpráva na své pouti Internetem ztracena. Pro odesilatele zprávy je tak někdy zajímavé si nechat doručení zprávy potvrdit. Takové potvrzení může např. napsat ručně příjemce. Avšak nás zajímá možnost automatizace této činnosti.

Automatizovat notifikaci o doručení poštovní zprávy lze mj. dvěma způsoby:

Rozšířením ESMTP označovaného DSN, které notifikuje doručení poštovní zprávy do schránky uživatele na serveru.
MIME rozšířením realizovným hlavičkou Disposition-Notification-To. Toto rozšíření notifikuje zobrazení zprávy příjemcem. Zobrazení však neznamená, že by si příjemce zprávu skutečně přečetl nebo jí snad porozuměl.

Prakticky je rozdíl v obou mechanismech v tom, že rozšíření DSN interpretuje ESMTP server, tj. ESMTP server generuje notifikační zprávu. Kdežto MIME je interpretováno až poštovním klientem (např. MS Outlook). Tj. notifikační zprávu generuje poštovní klient.

Skutečnost zdali Váš poštovní klient podporuje jedno z těchto rozšíření či dokonce obě dvě závisí na tvůrci tohoto software (jedná se přece jenom o rozšíření). V případě použití obou notifikací obdržíte zpět dvě zprávy. První, že zpráva byla doručena do schránky a druhou, že zpráva byla příjemci zobrazena.

2.8 POP3

Post Office Protocol verze 3 je jednoduchý protokol, kterým si uživatel může ze své poštovní schránky na poštovním serveru stáhnout zprávy do lokálních poštovních schránek na svém PC. Je určen pro práci OffLine s poštovním serverem. POP3 je specifikován v RFC-1939.

Příkazy protokolu POP3 (jsou vždy čtyřznakové):

1. Autentizační stav:

§ Příkazem USER zadává uživatel své jméno. Příklad:
C: USER dostalek
S: +OK Password required for dostalek.

§ Příkazem PASS zadává uživatel své heslo (příkaz je volitelný). Příklad:
C: PASS heslo
S: +OK dostalek has 2 message(s) (3605 octets).
(tj. přihlášení proběhlo dobře; na serveru máš 2 zprávy dlouhé dohromady 3605 bajtů).

§ Příkazem QUIT může uživatel ukončit spojení.

2. Transakční stav:

§ Příkaz STAT počet zpráv v poštovní schránce a celkovou velikost poštovní schránky:
C: STAT
+OK 2 3605

§ Příkaz LIST vrací seznam jednotlivých zpráv v poštovní schránce (co zpráva, to jeden řádek). U každé zprávy je uvedeno její pořadové číslo a její velkost:
C: LIST
S: +OK 2 messages (3605 octets)
S: 1 1196
S: 2 2409

§ Příkazem RETR stahujeme zprávu ze serveru na PC; jako parametr se použije číslo zprávy, která se má stahovat:
C : RETR 2

§ Příkazem DELE se ruší zpráva v poštovní schránce na serveru. Jako parametr se zadává číslo rušené zprávy.
C: DELE 2
S: +OK Message 2 has been deleted.

§ NOOP je prázdný příkaz:
C: NOOP
S: +OK

§ Příkazem RSET lze opět oživit zprávy zrušené během aktualní relace:
C: RSET
S: +OK Maildrop has 2 messages (3605 octets)

§ Příkazem TOP lze vypsat počátek zprávy. Syntaxe je
TOP číslo_zprávy počet_řádek těla zprávy

3. Stav UPDATE

§ Ukončení relace se provede opět příkazem QUIT. V tomto okamžiku se provede fyzické zrušení všech zpráv označených jako zrušené.

Příklad (stažení zprávy ze serveru):

C:\> telnet t1.pvt.cz 110

S: +OK QPOP (version 2.1.4-R4-b5a) at t1.pvt.cz starting.

<3774.978040846@t1.pvt.cz>

C: USER dostalek

S: +OK Password required for dostalek.

C: PASS heslo

S: +OK dostalek has 2 message(s) (3605 octets).

C: LIST
S: +OK 2 messages (3605 octets)
S: 1 1196
S: 2 2409

C: RETR 2

S: +OK 1196 octets

S: X-UIDL: b27991db2a4199a85f593d76b58338c7

S: Received: from dns.terminal.cz (dns.terminal.cz [195.70.130.1])

by t1.pvt.cz (8.9.3/8.9.3) with ESMTP id XAA04273

for <dostalek@t1.pvt.cz>; Thu, 28 Dec 2000 23:21:10 +0100 (MET)

… záhlaví a text zprávy

2.9 IMAP4

Protokol IMAP (Internet Message Access Protocol) v verze 4 je specifikován RFC-2060. Tato specifikace je někdy též označována jako IMAP4rev1, protože je revizí původní normy protokolu IMAP4 specifikované v RCF-1730.

IMAP4 je sofistikovaný protokol určený pro práci s poštovními schránkami na serveru z PC v režimu OnLine (i OffLine). V jednom okamžiku můžeme pracovat se svými poštovními schránkami z více aplikací. Dokonce některé aplikace navazují současně dvě TCP spojení se serverem IMAP4 (např. MS Outlook 2000). Jedno pro práci s poštovními schránkami a druhé pro práci s jednotlivými položkami (poštovními zprávami). Server protokolu IMAP používá port 143/tcp.

Na obr. 2-26 jsou popsány jednotlivé stavy v protokolu IMAP4. Po navázání spojení zpravidla nastane „Neautentizovaný stav“, kdy je nutná autentizace klienta (nebo ukončení příkazem LOGOUT). Výjimkou je situace, kdy server okamžitě po navázání klientovi sdělí, že je již předem s přihlášením automaticky autentizován (PREAUTH). V praxi jsem se však s předautentizací nesetkal.

V autentizovaném stavu může klient pracovat s poštovními schránkami na serveru jako se soubory, tj.může poštovní schránku vytvořit, zrušit, přejmenovat apod. Příkazem SELECT (nebo EXAMINE) klient otevře konkrétní poštovní schránku a přejde do režimu „Otevřená schránka“ ve kterém může pracovat s jednotlivými položkami otevřené poštovní schránky (např. položky přenést ze serveru na klienta apod.).

Obr. 2-26 Stavy v protokolu IMAP4

Příkazy CAPABILITY, NOOP a LOGOUT jsou na stavu nezávislé, proto je možné je zadávat kdykoliv.

2.10 Konference

Zatímco elektronickou poštu odesílá odesilatel jednomu čí více adresátům, tak s elektronickými konferencemi je to komplikovanější. Podstatou elektronické konference je, že chceme informaci odesílat více uživatelům – členům konference.

Takový požadavek lze uspokojit několika způsoby, mj.: ručně , pomocí aplikace (např. mailman,listserv, majordomo apod.)či protokolem NNTP.

Ručně bychom postupovali tak, že bychom si v rámci lokálního poštovního klienta vytvořili skupinovou poštovní adresu, která by obsahovala všechny členy konference. Informace bychom pak posílali na tuto skupinovou adresu. Problém je v tom, že každý člen naší konference si musí ručně vytvořit skupinovou adresu a každý člen konference může ve své skupinové adrese zapomenout na nějakého člena a to pokaždé na jiného člena. Skupinové adresy lze vytvářet také na serverech (jako tzv. aliasy). Jejich nevýhoda spočívá v tom, že správce serveru musí tuto skupinovou adresu udržovat ručně.

Tento mechanismus automatizuje aplikace listserv. Jedná se o server, který má svou poštovní adresu konference řekněme konference@firma.cz. Členové konference pak své příspěvky do konference zasílají na adresu konference@firma.cz, která pak rozešle příspěvek všem členům konference. Záhlaví zprávy je zpravidla doplněno o hlavičku „Reply-To: konference@firma.cz“, tj. aby příjemce v případě, že chce odpovědět, mohl velice jednoduše ve své poštovní aplikaci zvolit tlačítko „Odpovědět“ a automaticky tak vytvořil příspěvek do konference. Drobný háček spočívá v tom, že pokud Vás příspěvek rozčílí a chcete autorovi něco peprného odpovědět, tak si neuvědomíte, že to nelze pouze volbou tlačítka „Odpovědět“, ale že musíte opsat z hlavičky From jméno odesilatele a vyplnit jej do hlavičky To, a tak svou peprnou odpověď odešlete úplně všem… .

Konference dělíme na otevřené a uzavřené a také na moderované a nemoderované. Členem otevřené konference se může stát kdokoliv kdo pošle na administrativní adresu konference (řekněme konference-request@firma.cz) poštovní zprávu obsahující v těle pouze jediný řádek:

SUBSCRIBE konference jméno příjmení

Asi se divíte, že příkaz neobsahuje vaši elektronickou adresu, ta se vezme ze záhlaví vašeho mailu (z hlavičky From). Obdobně odhlásit se z konference můžete e-mailem obsahujícím jediný řádek:

UNSUBSCRIBE konference

Některé konference místo příkazu SUBSCRIBE používají příkaz SIGNUP nebo příkaz JOIN. Proto je nejlépe před tím, než začnete s konferencí komunikovat do ní poslat e-mail obsahující příkaz

HELP

A konference vám sama pošle návod obsahující popis příkazů, které akceptuje. Pokud se změní vaše e-mailová adresa, tak je třeba přede změnou adresy se z konference odhlásit a s novou adresou se znovu přihlásit. Pokud nestihnete se ze staré adresy odhlásit, tak se to udělá tak, že odešlete e-mail jakoby ze staré adresy např. programem telnet jak je popsáno v kapitole SMTP.

Do uzavřené konference se nedá takto jednoduše přihlásit. Je třeba kontaktovat správce konference, který vás do konfiguračního souboru konference musí přidat ručně.

Nemoderovaná konference automaticky přeposílá příspěvky svých členů všem účastníkům konference. Naopak příspěvek zaslaný do moderované konference je nejprve zobrazen moderátorovi konference, který posoudí, má-li se příspěvek rozeslat nebo nikoliv.

Listserv má i další funkce. Tou nejdůležitější je archiv příspěvků. Konference příspěvky archivuje. Pomocí příkazů zasílaných e-mailem je možné se tak dostat ke starším příspěvkům. Jaká je syntaxe těchto příkazů zjistíme z e-mailu obdrženého na zmíněný příkaz HELP. Budou tam i příkazy, kterými zjistíme jednotlivé konference, které server zajišťuje a k jednotlivým konferencím můžeme zjistit i členy konference.

Zjišťování informací pomocí e-mailů ze serverů bylo velice populární v dobách, kdy neexistovaly web-servery. Dnes naopak archivy konferencí mají brány pro protokol HTTP, takže k informacím v archivech konferencí se snadno dostaneme pomocí běžných prohlížečů. Jinou bránou listservu je brána do konferencí na bázi protokolu NNTP, tj. příspěvek do konference je pak šířen do některé z diskusních skupin NNTP.

Základní vlastností konferencí na bázi aplikace listserv je skutečnost, že příspěvky jsou doručovány do poštovních schránek členů konference, tj. pokud jste měsíc na dovolené, tak o žádný příspěvek nepřijdete, protože všechny máte ve své poštovní schránce.

2.11 Diskusní skupiny

Příspěvky do diskusních skupin (news) na bázi protokolu NNTP jsou udržovány na news-serverech (NNTP serverech). Uživatel si může konkrétní příspěvek ze serveru stáhnout a přečíst. Příspěvky jsou na serverech udržovány jen omezenou dobu (řádově dny) a poté jsou zrušeny, takže pokud si příspěvek nestačíte přečíst, tak máte smůlu.

Příspěvky jsou udržovány na serverech, ale mohou být také předávány mezi servery vzájemně. To je velice komplikovaná záležitost, která se neřídí žádnou autoritou, ale pouze zvykovým právem. Takže konfigurace takového news-serveru je opravdu věda. Konfigurace news-serverů zpravidla spadá do kompetence stejných šamanů, kteří se starají o poštovní servery. Jedním z kritérii pro volbu poskytovatele připojení k Internetu je stav jeho news-serveru.

Problém je v šíření příspěvků mezi servery. Z celosvětového pohledu existuje několik významných toků kterými tečou příspěvky. Tyto toky jsou tak mohutné, že v průměru mohou zabírat stovky Mb/s přenosového pásma pro vlastní konektivitu poskytovatele. Takže takový news-server může být docela drahou záležitostí, proto se hledají lacinější přenosové cesty specializované pro příspěvky. Takovou cestou je např. satelitní šíření příspěvků – podobně jako je satelitní vysílání televize.

Jelikož news může být docela nákladná věc, tak se nedivte, že poskytovatelé mohou bránit přístupu na své news-servery klientům konkurence.

V intranetu můžeme organizovat privátní diskusní skupiny, které se nešíří do Internetu. V Česku jsem se nesetkal s tím, že by nějaká organizace šířila kompletní celosvětové příspěvky do svého intranetu. Spíše je umožňováno přistupovat klientům vnitřní sítě na news-server poskytovatele. I když protokol NNTP sám nepodporuje nějaké proxy, brány či tunely, tak průchod firewallem pro klienty vnitřní sítě na news-server poskytovatele nebývá problém – spustí se pro tyto účely na firewallu generická proxy. Většinou totiž není požadováno, aby klienti přistupovali na více jak jeden news-server do Internetu.

V případě, že čtete nějaký příspěvek v diskusní skupině, pak máte dvě možnosti odpovědi. Jednak můžete odpovědět protokolem NNTP dalším příspěvkem do diskuse v diskusní skupině a jednak můžete odpovědět e-mailem autorovi příspěvku.

Do diskusní skupiny můžete přistupovat buď jako anonymní uživatel nebo diskusní skupina může být určena pouze pro uživatele, kteří se autentizují. Autentizace je možná např. jménem a heslem či dokonalejšími způsoby jako je zabezpečený přístup přes SSL či TLS.

Velice zajímavé jsou názvy diskusních skupin – jdou podobné DNS jménům počítačů. Např. počítač se může jmenovat server.firma.cz. Ve jméně počítače je nejglobálnější doména zcela vpravo (cz.) pak zprava na druhém místě je doména nižší úrovně (firma) atd. Tj. DNS jméno se čte jakoby zprava doleva.

Naproti tomu názvy diskusních skupin se čtou zleva doprava. Skupina cz.zamestnani.nabidky se čte: jedná se o skupinu „nabídky“, která je podskupinou „zaměstnání“ jež je podskupinou hlavní skupiny „cz“.

Hlavních skupin je celá řada:

comp – diskusní skupiny o počítačích

net –diskusní skupiny o počítačových sítích

alt – alternativní (zábavné skupiny), alt.binaries obsahuje binární data, alt.sex netřeba komentovat.

Jednotlivé národní skupiny začínají identifikací státu:

cz - Česko

pl – Polsko

at – Rakousko

Významné firmy mají také své hlavní skupiny: microsoft, novell atd. Nebo prostě je nějaké velké zájmové téma jako třeba o Linuxu existuje hlavní skupina linux atd.

2.11.1 Formát zprávy

Formát diskusního příspěvku (news article) specifikuje RFC-1036. Formát je obdobný formátu zprávy elektronické pošty. Dokonce i mnohé hlavičky jsou stejné. Budou nás tedy zajímat pouze hlavičky které jsou specifické pro diskusní příspěvek.

Hlavička Path

Tato hlavička je obdobou hlavičky Received u e-mailu. Zatímco každý poštovní server připisoval novou hlavičku Received na začátek zprávy, tak hlavička Path je jen jedna. Jména news-serverů, kterými zpráva prochází, se zapisují zleva a oddělují se vykřičníkem.

PATH: news.nextra.cz!newsfeed1.online.no!nextra.com

Vyjadřuje, že zpráva šla ze serveru nextra.com na server newsfeed1.online.no a skončila na serveru news.nextra.cz.

Hlavička Newsgroups

Tato hlavička vyjadřuje diskusní skupinu pro kterou je zpráva určena. Např:

Newsgroups: cz.zamestnani.nabidky

Hlavička Message-ID

Tato hlavička nese jednoznačnou identifikaci příspěvku (zprávy).

Hlavička Expires

Tato hlavička explicitně vyjadřuje, kdy vyprší platnost zprávy. Není-li uvedena, pak se zpráva zruší po uplynutí doby nastavené správcem news-serveru.

Hlavička Control

Obsahuje-li zpráva tuto hlavičku pak se jedná o služební zprávu komunikace mezi news-servery.

Hlavička Approved

Tato hlavička se používá u moderovaných konferencí. Hlavička obsahuje informaci o tom , kdo povolil zprávu šířit do diskusní skupiny.

Hlavička Lines

Hlavička obsahuje počet řádků těla příspěvku.

2.11.2 Protokol NNTP

Protokol NNTP je specifikován v RFC-977. Server protokolu NNTP naslouchá na protu 119/tcp.

Po navázání spojení se news-server představí:

200 news.provider.cz InterNetNews NNRP server INN 2.2.2 13-Dec-1999 ready (posting ok).

Nyní může klient začít podávat příkazy. Jelikož příkazy protokolu NNTP jsou opět v ASCII, tak je opět možné pro komunikaci s news-serverem použít program telnet – např. z Windows 2000:

C:\WINNT>telnet news.provider.cz 119

První řádek odpovědi je vždy stavovým řádkem říkajícím jak jsme byli úspěšní. Stavový řádek začíná trojciferným stavovým kódem. Trojciferné stavové kódy jsou obdobné jako u protokolů FTP a HTTP:

100 help text follows

199 debug output

200 server ready - posting allowed

201 server ready - no posting allowed

202 slave status noted

205 closing connection - goodbye!

211 n f l s group selected

215 list of newsgroups follows

220 n <a> article retrieved - head and body follow 221 n <a> article retrieved - head follows

222 n <a> article retrieved - body follows

223 n <a> article retrieved - request text separately 230 list of new articles by message-id follows

231 list of new newsgroups follows

235 article transferred ok

240 article posted ok

335 send article to be transferred. End with <CR-LF>.<CR-LF>

340 send article to be posted. End with <CR-LF>.<CR-LF>

400 service discontinued

411 no such news group

412 no newsgroup has been selected

420 no current article has been selected

421 no next article in this group

422 no previous article in this group

423 no such article number in this group

430 no such article found

435 article not wanted - do not send it

436 transfer failed - try again later

437 article rejected - do not try again.

440 posting not allowed

441 posting failed

500 command not recognized

501 command syntax error

502 access restriction or permission denied

503 program fault - command not performed

Klient protokolu NNTP může být ve dvou situacích:

· Jedná se o koncového klienta zpravidla sedícího u PC, který se chce zapojit do diskusní skupiny, tj. chce číst zprávy a přispívat do diskuse novými zprávami.

· Jedná se o news-server, který jako klient chce získat nové příspěvky z jiného serveru nebo chce odeslat nové příspěvky na vzdálený server.

Koncový klient

Koncový klient potřebuje zjistit, jaké vůbec skupiny existují, to může klient zjistit příkazem LIST:

C: LIST

S: 215 Newsgroups in form "group high low flags".

S: 3dfx.d3d.drivers 0000004241 0000004157 y

S: 3dfx.d3d.drivers.diamond 0000001229 0000001213 y

S: 3dfx.d3d.drivers.orchid 0000000260 0000000258 y

S: …

Prvním řádkem odpovědi je stavový řádek se stavovým kódem 215 (že to dopadlo dobře a seznam skupin že následuje). Na dalších řádcích jsou pak uváděny jednotlivé skupiny. První skupinou je skupina „3dfx.d3d.drivers“. Server má momentálně k dispozici pro tuto skupinu zprávy. Nejvyšší číslo zprávy na serveru v této skupině je 4241 a nejnižší je 4157. Poslední písmenko y sděluje, že je možné přispívat do této skupiny.

Obr. 2-28 MS Outlook Express zobrazuje stejnou informaci graficky