4. Elektronická pošta a její správa.

4. Elektronická pošta a její správa. 4.1 Princip a elektronické pošty Elektronická pošta, nebo-li e-mail, je jednou z nejpoužívanějších služeb Internetu. Hlavní výhodou této poštovní služby oproti klasické poště je rychlost. E-mail je adresátovi kdekoliv na světě doručen během několika minut, maximálně hodin. Dopis šířený elektronickou poštou nemusí obsahovat pouze text, lze k němu připojit prakticky jakýkoliv soubor, tedy i obrázek či zvuk. Protože se mnoho uživatelů připojuje k serveru elektronické pošty vytáčenou telefonní linkou, umožňují současní e-mailoví klienti jednak časově úsporné metody práce s elektronickou poštou, jednak zpřístupňují těmto uživatelům i jiné na připojení méně náročné služby, jako je přenos souborů pomocí FTP serverů apod. Historie elektronické pošty začíná již v době sálových počítačů a prvních minipočítačů. Uživatelé této pošty pracovali na terminálech připojených k centrálnímu sálovému počítači nebo minipočítači. Příkladem takovéhoto systému elektronické pošty může být systém PROFS (Professional Office System) od IBM. Hlavní impuls rozvoji elektronické pošty dalo masové rozšíření lokálních sítí LAN. Tyto počátky e-mailu byly charakteristické neexistencí všeobecně uznávaných a používaných standardů. Jako server elektronické pošty (e-mailový server) vystupoval běžný server (který fungoval jako úložiště zpráv"). Osobní počítače na síti LAN zapisovaly zprávy do příslušných souborů na souborovém serveru a ten současně nabízel soubory pro sdílení prostřednictvím síťového operačního systému. Tímto jednoduchým způsobem probíhala výměna elektronické pošty. Ke směrování e-mailu mezi jednotlivými servery sloužily protokoly specifické podle každého producenta příslušného softwaru. Příkladem takového systému elektronické pošty je Microsoft Mail nebo Lotus cc:mail. Tyto e-mailové systémy pro sítě LAN fungují velice dobře ovšem jen na úrovni jedné organizační jednotky či její části, na vyšší úroveň se ale rozšířit nedají, protože narůstají problémy související s propojováním velkého počtu e-mailových serverů v rozsáhlých sítích. Další generace systémů elektronické pošty pro lokální sítě používala pro konverzaci klientů se serverem zpráv mechanismu vzdáleného volání procedur (Remote Procedure Calls, RPC). Tato generace poštovních serverů vytváří za provozu několik běžících procesů; server již tedy není pouhým souborovým serverem. Výhodou tohoto systému elektronické pošty je vyšší bezpečnost a možnosti zpracování pošty přímo na serveru. Díky bezpečnosti a možnému zpracování na serveru se již v rámci elektronické pošty dají rozšířit výrazně služby o další aplikace (řízení, elektronické bankovnictví apod.). A jak funguje elektronická pošta? Zprávu elektronické pošty vytváříme prostřednictvím určitého uživatelského rozhraní, které běží na osobním počítači, na sálovém počítači mainframe nebo na minipočítači (zprávu může ale generovat přímo i počítač). Toto softwarové uživatelské rozhraní zpravidla spolupracuje s další aplikací, která definuje funkce pro vlastní komunikaci se serverem elektronické pošty (obvykle se jedná o knihovnu DLL). Knihovna, případně knihovna spolu s uživatelským rozhraním, se nazývá uživatelský agent nebo-li Mail User Agent (MUA). Uživatelský agent se spojí se serverem elektronické pošty - domovský server uživatele, kde běží příslušná aplikace pro přenos pošty - Mail Transfer Agent (MTA). Na tento server uživatel odesílá e-mailové zprávy; server je pak nasměruje dále do sítě. Zpráva může na své cestě k domovskému serveru svého adresáta projít i několika agenty MTA. Na domovský server přichází také danému uživateli pošta od ostatních uživatelů. Podle jednoho z možných hledisek můžeme dnešní elektronickou poštu v architektuře klient/server vyjádřit pojmy offline, online a odpojeného modelu. Offline model: klient se připojuje k serveru jen občas a načte od něj vždy veškerou poštu. Zprávy, které si klient načetl a stáhl k sobě, se ze serveru odstraní. Veškeré další zpracování zpráv probíhá již na klientovi; server se již o těchto zprávách a o jejich osudu 1

nedozví nic. Tento model používá protokol POP (Post Office Protocol). Offline model může podporovat také protokol IMAP (Internet Message Access Protocol), který ale nejlépe pracuje v online nebo v odpojeném modelu. Online model: klient ustaví relaci (spojení) se serverem a veškerá práce s e-mailem probíhá v rámci této relace. Veškerou práci s poštou řídí klient, fyzicky však probíhá na serveru. Jako příklady implementace tohoto modelu si můžeme uvést protokol IMAP a souborové systémy NFS (Network File System) a CIFS (Common Internet File System). Odpojený model: tento model je určitým přechodem mezi offline a online modelem. Klient se připojí k serveru, načte si některé vybrané zprávy a zpracuje je v režimu offline. Později se k serveru připojí znovu a předá veškeré provedené změny zpět serveru. (Těmito změnami mohou být například úpravy zpráv nebo seznamu adres, odstranění zpráv, odpovědi na zprávy apod.) Hlavním místem pro ukládání zpráv je zde server, na klientovi se ukládají pouze dočasně. V tomto režimu může pracovat například protokol IMAP. Z hlediska času stráveného na lince připojení je tento model nejúspornější a proto i nejvhodnější pro připojení vytáčenou telefonní linkou. Schema přenosu pošty mezi poštovním klientem a serverem Aby naše zpráva nalezla správného adresáta, musí se stejně jako u počítačů v síti Internet používat jedinečné adresy. Jedinečnost adresy se zabezpečuje jejím složením ze dvou částí ze jména domény, kde je příslušná poštovní schránka uložena a jména (či přezdívky) uživatele, jemuž je tato schránka slouží. A právě správce příslušné domény (či jejího serveru) bdí nad tím, aby nedošlo k duplikaci jmen a tedy adres poštovních schránek. Možný tvar adresy poštovní schránky, uložené na poštovním serveru Univerzity Palackého pro uživatele Jana Novákaka by pak byl: jenda.novak@aix.upol.cz Tuto adresu pak používá poštovní klient i server ke směrování e-mailů do příslušné poštovní schránky z počítače umístěného kdekoliv na světě. 2

4.2 Přehled používaných e-mailových protokolů Formát zpráv podle RFC 822 Dokument RFC číslo 822 definuje formát zpráv elektronické pošty. To znamená, že RFC 822 definuje formát dat, která mohou přenášet protokoly POP3 (Post Office Protocol), SMTP (Simple Mail Transport Protocol) a další protokoly určené pro přenos e-mailu. Podle definice v dokumentu RFC 822 se e-mailová zpráva skládá ze dvou hlavních komponent - z obálky a vlastního obsahu zprávy. Obálka obsahuje informace související s přenosem a doručením zprávy. Dále obsahuje informace, které jsou nutné pro odeslání odpovědi na zprávu. Obálka tedy obsahuje přinejmenším e-mailovou adresu odesílatele a příjemce zprávy. Vlastní obsah zprávy se dělí do dvou částí, a sice na hlavičku (záhlaví) a tělo zprávy. - Hlavička obsahuje informace, které automaticky vygeneruje uživatelský agent na odesílacím uzlu a které aktualizuje každý agent MTA, přes něhož zpráva prochází. Hlavička obsahuje identifikátor (ID) zprávy a datové a časové razítko, které označují okamžik zpracování zprávy každým agentem MTA. Uživatelský agent přijímajícího uzlu může hlavičku zprávy zkomprimovat, přeformátovat, nebo dokonce úplně skrýt. Hlavička však nicméně zprávě zůstává. - Tělo e-mailu obsahuje vlastní zprávu neboli text, který odesílatel sestavil. Odesílatel může být člověk anebo také počítačový program. Tělo zprávy se od hlavičky odděluje prázdným řádkem. V mnoha implementacích formátu zpráv podle RFC 822 na Internetu se mlčky předpokládá, že žádný řádek zprávy nebude delší než l 000 bajtů a že žádná zpráva nebude větší než 64 KB. Odesílatel pochopitelně nemůže předem vědět, kudy se zpráva bude dopravovat, a nemůže tedy ani vědět, jestli náhodou nepůjde přes uzly, pro něž platí toto omezení. Zpráva, která těmto podmínkám nevyhovuje, se tedy musí před odesláním vhodně zakódovat a po přijetí ji přijímající uživatelský agent opět dekóduje. Protokol POP Protokol POP (Post Office Protocol) je e-mailový protokol, který se dá použít v offline modelu, architektuře klient/server elektronické pošty. Protokol POP byl za dobu své historie několikrát přepracován, poslední verzí je POP3, tedy verze 3 protokolu POP. Protokol POP3 popisuje podrobněji dokument RFC číslo 1939. Protokol POP pracuje tedy v režimu offline: klient se připojí k serveru a dotáže se na novou poštu. Server mu předá veškeré připravené zprávy, které jsou určeny pro tohoto konkrétního e-mailového klienta. Klient protokolu POP však nemůže načítat zprávy z e-mailového serveru selektivně: bere vždycky všechno nebo nic". Po načtení zpráv již e-mailový klient může jednotlivé zprávy upravovat nebo mazat, přičemž k těmto operacím již komunikaci se serverem nepotřebuje. Klient POP3 odesílá na server POP3 příkazy a zpět přebírá odpovědi. Příkazy protokolu POP3 tvoří vždy jeden řádek textu ASCII, který začíná jedním z určené množiny klíčových slov. Odpověď protokolu POP3 se pak skládá z jednoho nebo více řádků. První řádek odpovědi indikuje úspěch nebo selhání dotazu a obsahuje text +OK nebo -ERR (v tomto pořadí). Protokol POP3 je popsán jako stavový automat. Stavový automat je jakýsi hypotetický stroj, který se vždy může nacházet jen v jednom z určité množiny předem definovaných stavů. 3

Automat reaguje na vstupní situaci a při splněni určitých kritérií se přepne (přejde) z jednoho stavu do jiného. Protokol POP3 má jako stavový automat celkem tři možné stavy: je to autorizační stav, transakční stav a aktualizační stav. Po ustavení spojení s klientem se e-mailový server nachází v autorizačním stavu. Jakmile klient prokáže svoji totožnost a úspěšně obhájí svoje oprávnění, vstoupí automat do transakčního stavu. Po skončeni práce odešle klient příkaz QUIT a automat přejde do aktualizačního stavu. V tomto stavu provede veškeré nadefinované zpracování pošty a nakonec se vrátí zpět do autorizačního stavu. Každý příkaz protokolu POP3 je možné zadat jen v určitém stavu (stavech). V protokolu POP3 může klient odeslat serveru uživatelské oprávnění (uživatelské jméno a heslo); tímto způsobem probíhá regulace přístupu k e-mailu a jeho zprávám. Jestliže klient zadá příkaz USER, odešle se heslo ve formě prostého textu ASCII. Rozšíření protokolu POP3 definuje příkaz APOP, ve kterém se heslo před odesláním zašifruje. U příkazu APOP tak server POP3 odešle klientovi při jeho prvotním připojení pozdrav" v podobě prostého ASCII textu. Pozdrav obsahuje řetězec, který je pro každé klientské spojení jedinečný. Klient připojí k řetězci přijatému od serveru svoje heslo v podobě prostého textu a vypočte otisk (hash) celého řetězce algoritmem MD5. Uživatelské jméno a otisk zprávy podle algoritmu MD5 odešle klient na server jako parametry příkazu APOP. Samotný protokol POP3 se implementuje velice často. Koncovým uživatelům nabízejí přístup k e-mailu prostřednictvím protokolu POP3 a pomocí klientů POP3 prakticky všichni poskytovatelé služeb Internetu (ISP). Servery POP3 naslouchají na portu 110 protokolu TCP. Protokol POP3 popisují podrobněji dokumenty RFC číslo 1957, 1939 a 1725. Protokol SMTP Protokol SMTP (Simple Mail Transport Protocol) je jednoduchý protokol pro přenos elektronické pošty. Protokol SMTP se zpravidla používá pro přenos e-mailu od klienta k serveru a také ze serveru na jiný server. SMTP je protokol typu požadavek-odpověď. Příkazy i odpovědi mají tvar textu ASCII a ukončuji se dvojicí znaků CR/LF. Odpovědi obsahují také tříznakový číselný kód, který udává návratový status. Podle tohoto číselného kódu se může také řídit stavový automat protokolu. Protokol SMTP běží ve vrstvě nad protokolem TCP (Transmission Control Protocol). Odesílající uzel SMTP zadá zpravidla ihned po ustavení spojení TCP příkaz HELO, kterým odesílatel oznamuje svoji totožnost. Dále odesílající uzel SMTP zadá příkaz MAIL. Druhý server odpoví zprávou OK, která znamená, že je připraven k příjmu e-mailu. Poté odesílající uzel SMTP zadá příkaz RCPT, v němž oznamuje požadovaného příjemce pošty. Přijímající uzel SMTP ve své odpovědi sdělí, jestli poštu pro tohoto příjemce akceptuje. Pokud je zpráva určena pro několik příjemců, musí se takovýmto způsobem dohodnout příjem pošty pro každého zvlášť. Po dokončení všech dohod se zpráva konečně odešle. E-mailová zpráva se odesílá příkazem SMTP DATA. Protokol SMTP definuje dále příkaz VRFY, který slouží pro ověření existence dané uživatelské poštovní schránky a pro zjištění podrobných informací o uživateli. Příkaz EXPN protokolu SMTP rozvíjí poštovní konference. Dalším příkazem protokolu SMTP je příkaz TURN, který obrací směr ustaveného spojení - to znamená, že se obrátí směr celého toku elektronické pošty a odesílající server SMTP se nabízí jako příjemce. Někteří administrátoři z bezpečnostních důvodů příkazy VRFY a TURN zakazují. Protokol SMTP je navržen také pro efektivní přenos více zpráv jedinému příjemci nebo více příjemcům v jediné relaci mezi klientem a serverem. Transportní protokol SMTP popisuje podrobněji dokument RFC číslo 821. Dokument RFC 822 popisuje syntaxi a sémantiku e-mailových zpráv, které se přenášejí pomocí protokolu popsaného v dokumentu RFC 821. V pozdějších dokumentech RFC se struktura zprávy dále rozšířila. 4

Servery SMTP směrují e-mail podle doménového jména vyznačených příjemců, které má tvar služby DNS (Domain Name Service). Přesněji řečeno, servery SMTP směrují e-mailové zprávy podle záznamů MX v DNS. Záznam MX registruje doménové jméno a definuje pro něj předávací uzel (hostitel) protokolu SMTP, kterému se pošta směrovaná do této domény má odeslat. K protokolu SMTP byla nadefinována celá řada různých rozšíření. Registruje je IANA (Internet Assigned Numbers Authority), která je organizační jednotkou výboru IAB (Internet Architecture Board). Více informací najdete na intemetové adrese http://www.iana.org. Rozšíření protokolu SMTP jsou definovány takovým způsobem, že zachovávají zpětnou kompatibilitu. To znamená, že pokud jeden nebo oba z dvojice komunikujících serverů SMTP dané rozšířeni nepodporuje, pak se jednoduše nepoužije. Protokol UUCP Protokol UUCP (Unix-to-Unix Copy Protocol) je v pravém slova smyslu protokol pro přenos souborů. Přesto se používá také pro přenos elektronické pošty: e-mailová zpráva se zabalí" do tenké obálky s adresou a poté se předá protokolu UUCP. Protokol UUCP se zpravidla používá jako alternativa k protokolu SMTP, a to zejména při přenosu e-mailu přes vytáčené telefonní spojení. Podrobnosti najdete v dokumentu RFC číslo 976. Protokol IMAP verze 4 Protokol IMAP (Internet Message Access Protocol) je vhodný zejména v případě, kdy uživatel provozuje klientský software elektronické pošty na přenosném počítači. S protokolem IMAP může uživatel selektivně načíst na lokální počítač jednotlivé vybrané zprávy, nebo dokonce jejich části. Tato funkce má smysl právě při přístupu k e-mailu po pomalé telefonní lince z přenosného počítače. Protokol IMAP popisuje dokument RFC 2060, a to jako stavový automat. V každém z definovaných stavů smí klient zadat e-mailovému serveru určitou omezenou množinu příkazů protokolu IMAP. Některé z těchto příkazů způsobí přechod stavového automatu protokolu do jiného stavu, kde má opět smysl jiná množina příkazů. V protokolu IMAP může tedy klient načíst z poštovního serveru vybrané zprávy a poté se odpojit. V odpojeném stavu pak může klient modifikovat libovolné z načtených zpráv. Protokol IMAP přiřazuje každé zprávě jedinečný identifikátor, který je platný mezi všemi relacemi IMAP, jaké může jeden klient ustavit; jinak by se nedala poštovní schránka správně synchronizovat. Příkazy protokolu IMAP se skládají z identifikátoru a jména příkazu, za kterým následují případné parametry. Server vrací jako odpověď značku (tag). Podle této značky může klient spojit danou odpověď s původním příkazem. V protokolu IMAP může totiž jeden klient vydat několik příkazů po sobě a nemusí čekat na odpověď, proto je potřeba odpovědi zvlášť označit. Klient pochopitelně musí mít naprostou jistotu, že je každá značka skutečně jedinečná. Jestliže používá zásobník volných značek, pak mu stačí, že je tento zásobník dostatečně velký a že se žádná značka nepoužije znovu, dokud se ze serveru nevrátí odpověď s danou značkou. Server může vygenerovat také odpověď, která není spojena s žádným konkrétním rozpracovaným příkazem. Těmto odpovědím se říká neoznačené odpovědi (untagged responses) a používá se pro ně speciální značka, hvězdička (*). Výsledkem příkazu protokolu IMAP může být mimo jiné: Odpověď OK znamená úspěšné dokončení dříve odeslaného příkazu. Odpověď OK může také znamenat doplňující informace k neoznačené odpovědi. Odpověď NO znamená neúspěšné dokončení předchozího příkazu, pokud je označena; jako neoznačená slouží k vyjádření varovných hlášení.. 5

Odpověď BAD označuje nesprávný příkaz nebo argument, je-li označena; bez označení znamená závažný problém v protokolu. Odpověď PREAUTH vystupuje vždy jako neoznačená; znamená, že není potřeba zadávat příkaz LOGIN. Odpověď BYE je také vždy neoznačená; znamená, že server ukončil relaci. Protokol IMAP je složitější než protokol POP3 a jeho implementace je obtížnější. Protokol IMAP klade dále vyšší nároky na ukládací prostor e-mailového serveru, protože na serveru se mohou shromažďovat staré zprávy. Na druhé straně se dá předpokládat, že na e-mailovém serveru funguje odpovídající pravidelné zálohování, které přispívá k integritě dat. Pomocí protokolu IMAP se dají také implementovat aplikace pro skupinovou práci (groupware), protože IMAP podporuje zpracování pošty na straně serveru i sdílené poštovní schránky. (Sdílená poštovní schránka je taková schránka, ke které může přistupovat několik různých příjemců.) V protokolu IMAP je dále možné implementovat prohledávání e-mailových zpráv, které jsou dosud uloženy na serveru; prohledávané zprávy se tedy nemusí kopírovat na klienta. Jestliže protokol IMAP běží nad protokolem TCP, naslouchá server IMAP na portu 143. Protokol IMAP je popsán v dokumentech RFC číslo 2060, 1731 a 1730. Rozšíření MIME Dokument RFC číslo 822 popisuje strukturu zpráv přenášených protokolem SMTP. Tato struktura zpráv má však určité nedostatky, a proto dokumenty RFC číslo 2049, 2048, 2047,2046 a 2045 definují alternativní strukturu zpráv, které se dají také přenášet protokolem SMTP. Tato struktura se jmenuje MIME (Multipurpose Internet Mail Extensions, víceúčelové rozšíření intemetové pošty). Před zavedením standardu MIME byl Internet omezen pouze na přenos čistě textových dat ve formátu ASCII - to znamená, že data se sice přenášela jako bajty, ale nejvyšší bit každého bajtu musel být vždy roven 0. Standard MIME i přes tento nedostatek umožňuje provádět přenosy binárních dat. Binárními daty se zde rozumí taková data, jejichž bajty obsahují libovolné kombinace možných 8 bitů. Poznamenejme ale ještě, že MIME nemá v žádném případě nahradit dokument RFC 822; MIME pouze rozšiřuje možnosti e-mailových zpráv, které odpovídají definici RFC 822. Toto rozšíření je navíc zpětně kompatibilní. Typy zpráv MIME Dokument RFC 822 definuje zprávu jako prostý text bez žádné další struktury. MIME definuje oproti tomu hned několik typů obsahu, a to pro textová a binární data. Každý ze základních typů má další podtypy. Velikost zprávy je stále omezena na 64 KB; zprávy větší než 64 KB se tedy musí rozdělit na menší zprávy a v cíli se opět sestaví. Standard MIME dovoluje také rekurzi - jinými slovy, zpráva MIME může v těle obsahovat část, která je sama zprávou MIME atd. MIME definuje šest možných typů těla zpráv: Text. Typ Text slouží k přenosu vlastního těla zprávy. Podtyp Plain (prostý text) je implicitní a odpovídá obsahu podle dokumentu RFC 822. Další možné podtypy jsou například Rich Text Formát (RTF), který podporuje speciální formátování znaků, jako je například tučné písmo a kurzíva. U typu Text může být znaková sada rovna US-ASCII nebo některé ze sad ISO-8859-1 až ISO-8859-10. Image. Typ Image znamená, že příslušná data obsahují obrázek. Jako podtypy jsou definovány formáty GIF (Graphic Image Formát) a MPEG (Motion Picture Experts Group). 6

Audio. Typ Audio označuje zvuková data, jako například hlasový záznam nebo hudbu. Application. U typu Application se data přenášejí ve formátu konkrétní aplikace, tedy například jako sešit aplikace Microsoft Excel nebo dokument aplikace Microsoft Word. Možné podtypy jsou: - Octet-Stream, který znamená, že s daty není spojena žádná aplikace - Office Document Architecture (ODA) označuje data spojená s aplikací rodiny Microsoft Office - PostScript (od Adobe) představuje tisková data o vysoké kvalitě. Structured. Strukturovaný typ Structured se někdy také nazývá vícedílný - multipart. Ve strukturovaném typu se nepřenášejí data jako taková, ale určitá kombinace již uvedených typů. Pro typ Structured jsou dále definovány celkem čtyři podtypy: - Alternativě, který znamená, že stejná data jsou uvedena v různých formátech, jako například prostý text ASCII, formát RTF nebo formát aplikace Word (.doc). Přijímající e-mailová aplikace si může podle svých možností svobodně vybrat libovolný z nabízených datových typů. - Digest znamená, že obsahem zprávy je otisk (hash) zprávy. Každou jednotlivou část těla zprávy tvoří samostatná zpráva. Tento podtyp si musí hlídat zejména brány, protože ty provádějí nad otisky zpráv odpovídající operace. - Parallel představuje zprávu, jejíž různé části se mají přehrávat současně - například zvukový a video záznam. - Mixed označuje zprávu, která se skládá ze směsi různých částí, například audio, video a text. Message.Typ Message znamená, že tělo obsahuje zprávy. Definuje dále tyto podtypy: - RFC 822, který označuje běžnou e-mailovou zprávu. - Partial znamená, že tato zpráva je jen částí zprávy. Pomocí tohoto podtypu se odesílají po částech zprávy větší než 64 KB. - External Body představuje odkaz na soubor, který je vůči e-mailové zprávě externí. Tento podtyp zpravidla definuje odkaz na větší soubor, jenž lze posléze načíst pomocí protokolu FTP (Filé Transfer Protocol). Metody kódování MIME Metody kódování MIME slouží k převodu dat z binárního tvaru, v němž se využívá všech osm bitů, do reprezentace pomocí 7bitového kódu ASCII. Tímto převodem se zajistí bezproblémový přenos dat po Internetu, protože velká část přenosových zařízení sítě dokáže zpracovávat pouze data ve formátu ASCII. Dříve se tato úprava dat prováděla pomocí schémat UUENCODE (kódování dat) a UUDECODE (dekódování dat). Hlavička MIME definuje pole se jménem Content Transfer Encoding (přenosové kódování obsahu), které nabývá jedné ze šesti možných hodnot: Quoted-Printable. Kódování Quoted-Printable se používá pro taková data, z nichž většina znaků je již znaky 7bitového ASCII (tedy například pro zprávy psané některým ze skandinávských jazyků). Myšlenka tohoto kódování spočívá v tom, že se znaky základního ASCII ponechají beze změny a kódují se pouze znaky s jedničkovým 7

nejvyšším bitem. Drtivá část výsledné zprávy je tím pádem čitelná i bez cílového dekódování. Base64. Data, která jsou výsledkem kódování Base64, jsou bez zpětného dekódováni nečitelná. Velikost kódované zprávy se zvětšuje o jednu třetinu. Algoritmus kódování převádí každou skupinu tří znaků (tedy 24 bitů) do čtyř znaků ASCII po 6 bitech (tedy opět do 24 bitů). Bity původního znaku se rozdělí mezi několik znaků, které tvoří výstup této kódovací metody. Všechny znaky se převádějí do množiny 65 znaků, které jsou společné standardům US-ASCII, EBCDIC a ISO 646; společně se jim říká abeceda Base64. Ty znaky z kódovaného proudu dat, které se v abecedě Base64 nenacházejí, se při dekódováni ignorují. Diky tomu se do datového proudu mohou vkládat navíc znaky konců řádků, které zajistí správný průchod zprávy mezilehlými e-mailovými bránami. Binary. Hodnota Binary znamená, že k žádnému kódování fakticky nedochází, v proudu dat se mohou vyskytovat i znaky mimo sadu ASCII a řádky mohou být delší, než kolik pro úspěšný přenos zpráv dovoluje protokol SMTP. Seven-Bit. Hodnota Seven-Bit opět znamená, že se žádné kódování neprovádí; všechny znaky patří do sady ASCII a řádky jsou krátké, takže protokol SMTP může zprávu úspěšně přenést. Eight-Bit. Kódování se neprovádí ani u Eight-Bit; řádky textu jsou opět dostatečně krátké, v textu se však mohou vyskytovat i znaky mimo sadu ASCII. X-Token. Při kódování X-Token se konkrétní metoda kódování privátně potvrzuje mezi odesilatelem a příjemcem protokolu SMTP. Explicitní deklarace kódování Binary, Seven-Bit a Eight-Bit má sloužit zejména pro budoucí rozšíření funkcí MIME. Všechny tři uvedené typy kódování tedy znamenají, že sice pro ně v současné době není definován žádný mechanismus kódování, budoucí implementace však mohou podle konkrétního typu provádět odpovídající kódování dat. Rozšíření S/MIME Standard S/MIME (Secure/Multipurpose Internet Mail Extensions) definuje protokol pro rozšíření elektronické výměny zpráv o bezpečnostní mechanismy. S/MIME nabízí šifrování zpráv a obsahuje digitální podpisy. Standard S/MIME se v současné době vyvíjí pod hlavičkou pracovní skupiny IETF. Podrobnější informace o pracovní skupině IETF najdete na adrese http://www.ietf.org/html.charters/smime-charter.html. Podle standardu S/MIME se obsah zprávy šifruje pomoci symetrické šifry a klíč se poté šifruje algoritmem veřejného klíče. S ohledem na předpisy vlády Spojených států přitom standard doporučuje šifrování algoritmem RC2 ve zřetězeném blokovém šifrování (CBC), přičemž pro odesílání zpráv se použije 40bitový klíč. Pro samostatné verze aplikací, jejichž implementace je omezena jen na území Spojených států, doporučuje standard S/MIME šifrování obsahu pomocí algoritmu DES (Data Encryption Standard) nebo Triple DES. U přijatých zpráv vyžaduje standard S/MIME podporu algoritmů otisku zprávy MD2 a MD5. Pro odesílané zprávy se jako algoritmus otisku zprávy doporučuje pouze MD5. V rámci přijímání zpráv vyžaduje S/MIME podporu certifikátů X.509 verze l. S/MIME však současně pro příjem zpráv doporučuje (avšak nevyžaduje) podporu certifikátů X.509 verze 2 a 3. Podpora certifikátů X.509 verze l je současně doporučena pro odesílané zprávy. Podle výkladu vlády Spojených států musí každá implementace standardu S/MIME podporovat klíče algoritmu RSA pro šifrování odchozích zpráv o velikosti od 512 do l 024 bitů. Samotný standard S/ MIME však doporučuje podporu klíčů o velikosti až 2 048 bitů. Standard S/MIME využívá certifikátů X.509. Společnost VeriSign vytvořila infrastrukturu pro vydávání a podporu těchto certifikátů. RSA Data Security nabízí toolkit se jménem TIPEM, 8

který obsahuje objektový kód jazyka C pro práci s digitálními podpisy, digitálními certifikáty a pro formátování zpráv. Podporu standardu S/MIME ohlásila také celá řada dalších společností, jako například Microsoft, Lotus, VeriSign, Netscape a Novell. Služby MOSS neboli PEM-MIME Služby MOSS (MIME Object Security Services) představují návrh standardu (dokument RFC 1848), který by docela dobře mohl nahradit standard PEM (Privacy Enhanced Mail). Podle definice standardu MIME se e-mailová zpráva skládá z několika různých částí. Standard S/MIME aplikuje vždy jediný bezpečnostní algoritmus na celou zprávu - tedy na všechny části zprávy MIME. Standard MOSS definuje oproti tomu mechanismus, podle něhož lze různé části jedné zprávy zašifrovat pomocí různých algoritmů nebo pomocí stejného algoritmu, ale s různými klíči. Standardu MOSS se někdy také říká PEM-MIME. Tento standard je terčem poměrně časté kritiky, protože mimo jiné není dostatečně striktní. Definice standardu MOSS je totiž natolik volná, že jeden e-mailový agent, který této definici vyhovuje, může vygenerovat takovou zprávu, kterou jiný agent nepřečte, přestože sám také definici standardu odpovídá. Standard PEM Kořeny standardu PEM (Privacy Enhanced Mail) sahají až do období práce skupiny Privacy and Security Research Group, kterou založil výbor IAB (Internet Architecture Board) v polovině osmdesátých let. Standard PEM dokumentuje RFC 1421. PEM definuje celou řadu funkcí: Důvěrnost, díky níž je zpráva srozumitelná pouze oprávněným příjemcům. Tato ochrana dat je aktivní nejen během přepravy dat (tedy například při přenosu po síti LAN), ale také v době, kdy je zpráva již uložena v poštovní schránce příjemce. Autentizační služba stvrzuje, že daná zpráva pochází skutečně od toho odesílatele, který se za odesílatele prohlašuje. Služba integrity, která zabezpečuje příjem zprávy přesně ve stejné podobě, v jaké byla odeslána to znamená, že zajišťuje neporušenost zprávy během přepravy. Nemožnost zapření znamená, že odesílatel nemůže zprávu později popřít a tvrdit, že ji vůbec neodeslal. Jinými slovy, pomoci mechanismu PEM může příjemce dokázat, že daná zpráva pochází skutečně jen od jediného možného odesílatele. Zprávy PEM využívají jako přenosový mechanismus protokol SMTP; standard PEM kromě toho předpokládá, že daná zpráva je ve formátu popsaném v dokumentu RFC 822. PEM provádí šifrování zpráv pomocí algoritmu DES v módu CBC. Symetrický šifrovací klíč algoritmu DES se každému příjemci odesílá v podobě šifrované algoritmem podpisu s veřejným klíčem. K ověřování veřejných klíčů stanovených příjemců využívá PEM certifikátů X.509. Společnost RSA Data Security nabízí bezplatnou nekomerční implementaci standardu PEM, a to pod názvem RIFEM. Více informací najdete v textovém souboru ftp://ripen.rsa. Standard PGP Standard PGP (Pretty Good Privacy, dost dobré soukromí") využívá kryptografie privátního klíče, kryptografie veřejného klíče a otisky zpráv. PGP zabezpečuje důvěrnost zpráv (to znamená, že dešifrovat a přečíst může zprávu pouze oprávněný příjemce) a autentizaci zpráv (příjemce bezpečně zná totožnost odesílatele). Mějte ale na paměti, že standard PGP zajišťuje soukromí souborů, nikoli pouze elektronické pošty. 9

Důvěrnost zajišťuje standard PGP šifrováním zpráv pomocí symetrické blokové šifry IDEA (Intemational Data Encryption Algorithm) s náhodně vygenerovaným klíčem o délce 128 bitů. Tento klíč se vloží do hlavičky zprávy, která se posléze zašifruje pomocí šifry RSA s veřejným klíčem. Jako klíč šifry RSA se použije veřejný klíč příjemce elektronické pošty. Příjemce nejprve dešifruje hlavičku zprávy pomocí svého vlastního privátního klíče příjemce a tak zjistí náhodně vygenerovaný klíč, jímž byla zašifrována původní zpráva. K zabezpečení autentizace dat se ve standardu PGP využívá technika digitálních podpisů. Zprávu nejprve zpracuje algoritmus MD5, který vyrobí 128bitovou basovanou hodnotu. Uvedená hodnota se poté zašifruje pomocí algoritmu RSA, jehož vstupním klíčem je privátní klíč odesílatele. Takto zašifrovaná basovaná hodnota se zepředu připojí ke zprávě. Příjemce opět převezme tuto šifrovanou basovanou hodnotu a dešifruje ji pomocí veřejného klíče odesílatele. Dále příjemce dešifruje vlastní zprávu a nezávislým způsobem vypočte otisk zprávy podle algoritmu MD5. Takto vypočtený otisk zprávy by měl být totožný s přijatou a dešifrovanou hodnotou. PGP definuje celkem tři možné délky klíčů: Běžná" varianta má klíče o délce 384 bitů. Komerční" varianta má klíče o délce 512 bitů. Vojenská" varianta má klíče o délce l 024 bitů. Veřejné a privátní klíče uživatelů ukládá PGP na disk počítače, a to do souborů, kterým se řiká A:e)'-rings. Tyto klíče se ukládají pochopitelně v zašifrované podobě. Každý uživatel musí při přístupu ke klíčům zadat svoje heslo. Z hesla se vytvoří otisk zprávy pomocí algoritmu MD5. Tento otisk zprávy se použije jako klíč pro zašifrování klíčů šifrou IDEA. Standard PGP má však jednu dosti podstatnou slabinu, která je společná všem kryptografíckým systémům pracujícím s veřejným klíčem: jak zajistit, že je veřejný klič správný a že skutečně náleží konkrétnímu uživateli. V digitálních podpisech vygenerovaných systémem PGP a v šifrovaných zprávách může být nejvyšší bit bajtů roven jedné. Tyto zprávy se tím pádem mohou, ale nemusí správně přenést přes e-mailové servery, protože některé servery předpokládají v nejvyšším bitu každého bajtu vždy nulu. Standard PGP obsahuje proto schéma, které mapuje každé tři znaky do čtyř znaků, v nichž je již nejvyšší bit správně roven nule. Standard PGP je k dispozici pro celou řadu různých platforem, například pro Microsoft Windows, DOS, Unix, Macintosh a VMS. Dají se sehnat jak bezplatné freewarové, tak i komerční verze softwaru pro PGP. Některé verze těchto systémů však nevyhovují vývozním omezením vlády Spojených států. Z toho důvodu byla vytvořena speciální mezinárodní verze PGP; jmenuje se PGP5I a vznikla vytištěním kódu PGP5 v knižní podobě. Exportuje se tedy kniha, nikoli samotný kód. Kód se poté scanováním přenesl do počítače. Takovýto postup již požadavkům vlády Spojených států pro export technologií vyhovuje. 10

4.3 E-mailoví klienti Funkci poštovního klienta může vykonávat velmi mnoho programů. V systémech typu Unix se používají programy mail a komfortnější pine. Z nejpoužívanějších v běžných uživatelských OS můžeme uvést Pegassus Mail pro MS DOS nebo Windows, Outlook nebo Outlook Express pro Windows, či Pine pro UNIX. Princip práce, který je u všech klientů podobný, si vysvětlíme na programu Outlook Express. Ten je součástí balíku programů pro práci s Internetem ve všech verzích Windows od Windows 95 SE. Pine Tento e-mailový klient určený pro unixovské systémy pracuje výhradně v textovém režimu. Přesto se jedná o velmi efektivní a propracovaný nástroj nejen pro čtení a odesílání elektronické pošty, ale i pro její automatické zpracování. Program pine se obvykle spouští povelem pine chceme-li zpracovávat nejprve došlou poštu. Kromě toho lze tento program spustit analogicky jako program mail, tzn. povel pine adresa slouží k odeslání pošty na danou adresu a povel pine -f folder otevírá ke zpracování poštovní přihrádku folder. V každé situaci (kromě režimů editace odesílaného dopisu, adresáře, prohlížení nápovědy a některých případů, kdy program vyžaduje odpověď na konkrétní otázku) je dostupné MAIN MENU pomocí klávesy M. Hlavní menu obsahuje informaci o verzi programu a aktuální poštovní přihrádce. V menu se lze pohybovat buď pomocí kurzoru, nebo zadáním jednoznakových povelů (kláves), přičemž velká a malá písmena se nerozlišují. Jejich přehled je v dolní části obrazovky. Protože se na spodní část displeje nevejdou všechny použitelné povely, je k dispozici povel O - OTHER CMDS (Další povely). Většinou je jeden z povelů předvolen, tzn. uplatní se po stisknutí klávesy <Enter>. Předvolba je indikována tak, že v dolním menu je nápověda k předvolenému povelu umístěna do hranatých závorek.? HELP obsahuje stručný přehled základních povelů programu pine. C COMPOSE MESSAGE vyvolá editor pico, ve kterém je možno editovat odesílaný dopis. I FOLDER INDEX zobrazí přehled dopisů v aktuální poštovní přihrádce. L FOLDER LIST zobrazí přehled všech uživatelových poštovních přihrádek. A ADDRESS BOOK umožňuje editaci a vyhledávání položek v e-mailových adresářích. S SETUP je určen pro konfiguraci tisku a osobní konfiguraci programu pine. 11

Hlavní panel programu Pine. Veškerá submenu (obrazovky), do kterých se uživatel v programu pine dostane, obsahují seznam použitelných povelů (nápovědu) v dolní části obrazovky. Jedním z těchto povelů je obvykle Help (Pomoc). Tak je možno využívat široký repertoár povelů, aniž by bylo nutno číst jakýkoli manuál. Stejně tak přívětivě se chová pine k uživateli, pokud je třeba vybrat soubor, poštovní přihrádku, skupinu Netnews nebo vyhledat adresu. Pine nabídne seznam možností, ve kterém se potom pohodlně provede volba. Do režimu odesílání pošty se dostaneme pomocí povelu C - COMPOSE MESSAGE (Sestavení a odeslání dopisu). Povel C je dostupný podobně jako povel M - MAIN MENU. Po zadání povelu se vyvolá editor pico a objeví se obrazovka s menu pro sestavení a odesílání dopisu. V horní části je hlavička dopisu, kde stačí vyplnit standardní pole To:. Hlavička je zřetelně oddělena od prostoru pro vlastní sdělení dopisu. Na rozdíl od jiných obrazovek programu pine se editor pico ovládá Ctrl-sekvencemi (např. zadání povelu Send (Odešli) se provede jako ^X, tzn. současným stisknutím kláves <Ctrl> a <x>, tj. <Ctrl-x> ). Pico je jednoduchý editor, který splňuje základní požadavky kladené na editaci textů. Lze pomocí něho mazat, vkládat a přenášet části textů, hledat zadané řetezce i kontrolovat pravopis ( Spell checking - pouze UNIX Pine!). Editor pico lze použít mimo pine samostatně povelem pico název-souboru Poznámka: Některé terminály používají Ctrl-sekvence pro řízení přenosu dat a blokují tím jejich použití v editoru pico. V tomto případě můžeme klávesu <Ctrl> nahradit sekvencí <Esc> <Esc>. Při odeslání dopisu tedy místo současného stisknutí <Ctrl-x> postupně stiskneme klávesy <Esc> <Esc> <x>. V poli To: hlavičky se uvádí e-mailová adresa příjemce. Program dává možnost zadat ji plně (tj. včetně znaku @), popř. pomocí nickname (přezdívka), která byla předtím zadána v některém z adresářů elektronické pošty. Těchto adresářů může mít každý uživatel několik a také skupina uživatelů může sdílet společný adresář (viz odst.3.4). 12

Standardní hlavička programu pine obsahuje dále pole Cc: (Carbon copy). Sem se píší adresy těch uživatelů, kterým se dává dopis na vědomí. Pole Subject: slouží ke stručné specifikaci obsahu zprávy (tj. "Věc"). Pole Attchmnt: je určeno k připojování příloh k dopisům a především k připojování binárních souborů. Připojení souboru jako přílohy docílíme umístěním kurzoru do pole Attchmnt: a použitím povelu ^J ( Attach - Připoj). Doporučuje se takto připojovat pouze binární soubory, běžné textové soubory je vhodné vložit přímo do těla dopisu v poloze kurzoru povelem ^R ( Read file - Načti soubor). Pokud je kurzor umístěný v nějakém poli hlavičky, můžeme ji rozšířit pomocí povelu ^R ( Rich Header - Rozšířená hlavička). Poté přibudou pole: Bcc: Blind carbon copy - zde se specifikují adresy příjemců kopie, u nichž není žádoucí, aby tuto skutečnost adresát věděl Newsgrps: k odesílání dopisů do skupin NetNews Fcc: odesílaný dopis se dokumentuje v určité poštovní přihrádce - souboru K psaní textu dopisu je účelné využít vestavěný editor pico nebo použít alternativní editor povelem ^_ (pouze pro UNIX Pine!). Pico používá triviální zarovnávání, není tedy nutné oddělovat jednotlivé řádky pomocí klávesy <Enter>. Standardně fungují šipky, <Backspace> a <Enter>, text v poloze kurzoru se nepřepisuje, ale je vkládán (těmito vlastnostmi se pico poněkud podobá vnitřnímu editoru F4 programu Norton Commander ). Přehled základních povelů vyvoláme stisknutím ^G ( Get Help - Pomoc). Chceme-li přenést část textu na jiné místo, umístíme kurzor na první znak přenášené části a označíme ho povelem ^^ (tj. <Ctrl-^>, Set mark - Označ). Poté přemístíme kurzor na poslední znak a zadáme ^K ( Delete line - Vymaž řádku nebo označený text a umísti do paměti). Vyříznutý text lze následně vyvolat v poloze kurzoru povelem ^U (Undelete Line - Obnov dříve vymazanou řádku nebo část textu). 13