Katedra softwarového inženýrství, Matematicko-fyzikální fakulta UK

Transkript

1 v. 2.2 Katedra softwarového inženýrství, Matematicko-fyzikální fakulta, Univerzita Karlova, Praha, verze 2.2 Jií Peterka, 2005 v. 2.2 Co je elektronická pošta? je to služba! mže být realizována rznými zpso, v rzném prostedí existují rzné "koncepce" elektronické pošty nap. Mail602, ccmail, MS Mail, X.400, SMTP,. liší se formátem zpráv, adresami, penosovými mechanismy,... obecn jsou vzájemn nekompatibilní pro možnost vzájemné spolupráce vyžadují existenci ch bran v Internetu se používá tzv. SMTP-pošta založená na jedné konkrétní koncepci (na bázi protokolu SMTP a RFC 822) stejná koncepce elektronické pošty mže být použita i jinde mimo Internet není proprietární není "vlastnná" žádnou firmou, vychází z pln otevených standard J.Peterka, MFF UK, v. 2.2 Elektronická pošta jako služba v. 2.2 Filosofie SMTP pošty je rychlá asy doruování se mí na minuty a sekundy je laciná i když záleží na konkrétním zpsobu pipojení je pohodlná mnoho úkon lze zautomatizovat, nap. tídní došlých zpráv, píprava odpovdí je efektivní mže být provázána s dalšími aplikacemi umožuje snadné hromadné rozesílání funguje off-line zpsobem nevyžaduje souasnou aktivitu komunikujících stran ve stejném ase odesilatel mže psát své zprávy tehdy, když se to hodí jemu píjemce mže zpracovávat došlou poštu tehdy, kdy se to zase hodí jemu dnes je elektronická pošta univerzálním penosovým mechanismem ke zprávám lze pidávat prakticky libovolné pílohy zaíná skromn, postupn se obohacuje pvodn vznikla jako velmi jednoduchá služba jako elektronická obdoba "office memo" další vlastnosti a schopnosti se pidávaly teprve postupn, po ovení jejich úelnosti a funknosti vývoj je "inkrementální", není nutné vyazovat dívjší vybavení nepodporuje nové funkce pvodn: pouze krátké texty v istém ASCII nyní: možnost formátování textu, vkládání obrázk atd. možnost penosu netextových píloh podpora národních abeced (háky&árky). J.Peterka, MFF UK, J.Peterka, MFF UK, v. 2.2 Architektura SMTP pošty v. 2.2 Vývoj elektronické pošty vychází z modelu klient/server server (mail server): v terminologii ISO/OSI: MTA, Message Transfer Agent zajišuje transport zpráv shromažuje zprávy pro ty úastníky, kteí nejsou momentáln dostupní klient v terminologii ISO/OSI: UA, User Agent umožuje íst, psát a jinak zpracovávat jednotlivé zprávy vytváí uživatelské rozhraní Standardy el. pošty musí pokrývat penos zpráv, download formát zpráv, formát adres, pílohy, penos zpráv: definuje protokol SMTP (Simple Mail Transfer Protocol) formát zpráv a adres definuje doporuení RFC822 download stahování zpráv ze schránky na m serveru definuje protokol POP3, IMAP rozšíení definuje standard MIME J.Peterka, MFF UK, pvodn: server i klient bží na stejném poítai typicky: mainframe, minipoíta výhoda: mohu si pedávat zprávy jako jednotlivé soubory pímo pes sdílené adresáe dnes: server a klient bží na rzných poítaích typicky: klient na "serverovém" poítai, klient na uživatelov PC, nebo na notebooku apod dsledek oddlení klienta a serveru: lo nutné vyvinout prostedky pro komunikaci mezi m serverem a jeho "vzdáleným" klientem" pro "stahování" zpráv je používán nejvíce protokol POP3 pro odesílání zpráv lze použít SMTP dsledek: možnost práce klienta v off-line režimu není nutné trvalé propojení serveru a klienta možnost spolupráce rzných klient se stejným serverem J.Peterka, MFF UK, , verze 2/2 1

2 v. 2.2 Pedstava server a klient v. 2.2 Umístní schránky Zde Zde bží bží klient server POP3 Poštovní servery komunikují prostednictvím protokolu SMTP server POP3 Zde Zde bží bží klient Pro tuto komunikaci vzdálený klient lo nutné vyvinout nové mechanismy J.Peterka, MFF UK, Varianta 1 (mén astá) schránka je na m serveru klient musí mít ke schránce trvalý a dostaten rychlý pístup výhoda: uživatel si mže "sednout" ke kterémukoli poítai v síti, a mít plnohodnotný pístup ke své pošt. díve: je to praktické pouze v prostedí lokální sít (sít LAN) dnes: lze používat i na dálku, skrze protokol IMAP Varianta 2 (astjší) schránka je rozdlena již pijaté, ale dosud nevyzvednuté zprávy se nachází na m serveru již vyzvednuté zprávy se uchovávají u uživatele, na jeho poítai (v rámci ho klienta) Varianta 3: (webmail) schránka i klient jsou na serveru, uživatel s nimi pracuje na dálku prostednictvím WWW stránek webmail prostednictvím vzdáleného pístupu terminálový pístup Nov Novdošlou poštu poštu je je nutné nutné J.Peterka, MFF UK, 2004 explicitn "stahovat" (download) 8 v. 2.2 Pedstava 2. varianty v. 2.2 "Anatomie" zprávy Poštovní schránka uživatele s adresou jiri@peterka.cz Zde Zde se se hromadí pouze dosud nevyzvednuté zprávy Osobní poíta uživatele, na na který který si si Poštovní server stahuje svou svou poštu poštu (pomocí protokolu POP3) pošta se zde, (uzel mail.czn.cz) Veškerá pošta uživatele se hromadí zde, a zde zde je je také takézpracovávána (zde (zde si si uživatel pouští pouštísvého ho klienta) J.Peterka, MFF UK, Každá zpráva má tyto ásti: hlaviku (header) tlo (body) voliteln: pílohu (attachment) Hlavika obsahuje: adresu píjemce (píjemc) adresu odesilatele datum vzniku/odeslání Pedmt zprávy (subject) jednoádkový, výstižný popis toho, o co jde další atributy zprávy nap. naléhavost, požadavek na potvrzení píjmu, Tlo obsahuje vlastní text zprávy Píloha: v zásad cokoli, co lze "zabalit" do podo souboru nap. datový soubor, zvukový klip apod. J.Peterka, MFF UK, v. 2.2 Pedstava v. 2.2 Formát zpráv el. pošty Hlavika (header) prázdná ádka Tlo (body) Píloha (attachment) To: To: Josef.Novak@post.cz From: From: jiri@peterka.cz jiri@peterka.cz Date:Tue, Date:Tue, Nov Nov :23: Subject: Subject: Pozvanka Pozvankana na kurz kurz el. el. posty posty Dobry den, den, potvrzuji konani kurzu el. el. posty dne dne , a v priloze posilam slidy v PowerPointu. S pozdravem J. J. Peterka definuje RFC 822 pvodní pošta v rámci definovala pouze syntaxi a sémantiku hlaviky (v doporuení RFC 822) tlo brala jako ernou skíku pílohy neuvažovala vbec dnes existuje rozšíení (standard MIME), které zásti specifikuje i formát tla zprávy a zavádí možnost použití píloh RFC 822 pedpokládá, že hlavika je tvoena posloupností položek pesn definuje syntaxi i sémantiku jednotlivých položek hlaviky, relevantních pro doruení zprávy... do toho spadá mj. i pesná syntaxe adres o tle zprávy pedpokládá pouze to, že jej tvoí ASCII text (a následuje za hlavikou, od které je oddleno prázdnou ádkou) J.Peterka, MFF UK, J.Peterka, MFF UK, , verze 2/2 2

3 v. 2.2 Hlavika dle RFC 822 v. 2.2 Položky hlaviky - píklady hlavika zprávy je tvoena položkami (header fields) každá položka zaíná na nové ádce (a na první pozici) každá položka je uvozena klíovým slovem (zakoneným dvojtekou), za kterým následuje vlastní obsah položky obsah nkterých položek je interpretován strojem, a proto je jeho syntaxe definována pesn (nap. adresy, data apod.) jiné položky jsou ureny pouze uživateli, a formát jejich obsahu je vícemén volný (nap. Subject) poadí položek v hlavice není pedepsáno (pouze doporueno) je definováno mnoho rzných položek, nejsou všechny povinné skladba položek pamatuje na rzné nestandardní situace, nap.: že odesilatelem je nkdo jiný než pvodní iniciátor zprávy, odpovídat se má jinam než na adresu odesilatele... J.Peterka, MFF UK, s pevnou syntaxí: From: kdo danou zprávu napsal To: komu je zpráva urena Date: datum a as odeslání Sender: kdo zprávu odeslal (je-li to nkdo jiný než autor) Reply-to: komu je teba adresovat odpov (je-li to nkdo jiný než Senderi From) Return-Path: kam vrátit zprávu, je-li nedoruitelná informace o penosu (1 "peskoku") s volnou syntaxí: Subject: pedmt zprávy položky uvozené X- (nap. X-Mailer apod.), jsou ureny k rozšiování možností RFC 822 X-Charset: znaková sada X-Mailer: druh klienta X-Sender: jiná adresa odesilatele. z pohledu RFC 822 pedstavují komentáe J.Peterka, MFF UK, v. 2.2 Píklad: hlavika mailu v. 2.2 Píklad (doruení mailu) scretchy (mbox peterka) Wed Apr 12 21:14: ) X-From_: petricek@kolej.mff.cuni.cz Wed Apr 12 21:13: ( [ ]) with ESMTP id VAA05330 for <jiri@peterka.cz>; Wed, 12 Apr :13: venca.kolej.mff.cuni.cz (venca.kolej.mff.cuni.cz [ ]) (8.9.2/8.9.0) with ESMTP id VAA39163 for <jiri@peterka.cz>; Wed, 12 Apr :13: (CEST) Date: Wed, 12 Apr :13: (CEST) From: Vasek Petricek <petricek@kolej.mff.cuni.cz> To: Jiri Peterka <jiri@peterka.cz> Subject: Diplomova prace VPN Message-ID: <Pine.BSF @venca.kolej.mff.cuni.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii J.Peterka, MFF UK, venca.kolej.mff.cuni.cz venca.kolej.mff.cuni.cz klient scretchy scretchy (mbox (mbox peterka) peterka) uložení do schránky uživatele "peterka" venca.kolej.mff.cuni.cz pozdjší download pomocí POP3 POP3 J.Peterka, MFF UK, v. 2.2 Adresy v elektronické pošt v. 2.2 Pedstava doruování Díve ly adresy typu schránka@poíta ly pevn vázány na konkrétní poíta, a docházelo k velkým problémm pi sthování uživatel, pi zmn ho serveru apod. uživatel musel obeslat všechny své partnery, a informovat je o zmn své adresy nap.: peterka@ (viz pedchozí píklad) Dnes se používají spíše adresy typu uživatel@doména kde uživatel je jakýkoli alias (v podstat jakýkoli text) nap. Jiri.Peterka, Peterka_Jiri, J.Peterka a doména je jméno DNS domény nikoli jméno konkrétního poítae nap.: jiri@peterka.cz J.Peterka, MFF UK, to: to: jiri@peterka.cz skutené doruení alias: pošta s adresou jiri@peterka.cz patí uživateli peterka J.Peterka, MFF UK, cz cz peterka DNS (MX záznam): veškerou poštu pro peterka.cz doruovat na schránka uživatele peterka poíta Doruení bude bude stejné, stejné, jako jako kdy kdy adresa adresa la la peterka@, verze 2/2 3

4 v. 2.2 Adresy dle RFC822 v. 2.2 RFC822 vs. SMTP Adresa mže mít dv ásti: adresu dle RFC822 s pevn danou syntaxí, bez hák a árek komentá (nepovinný) mže obsahovat i háky a árky (pouze pi použití MIME) Píklady: Jií Peterka <jiri@peterka.cz> jiri@peterka.cz (Jií Peterka) jiri@peterka.cz Zápis adresy v podob tzv. URL odkazu (nap. v rámci WWW stránek): mailto:jiri@peterka.cz existují 3 kategorie adresát zpráv: kategorie To: "hlavní píjemce", obdoba adresáta úedního dopisu kategorie Cc: Carbon Copy, tj. "kopie skrz prklepák" obdoba dopisu na vdomí, který má jiného hlavního adresáta (v kategorii To:) kategorii Bcc: Blind Carbon Copy, doslova "slepá kopie" píjemce Bcc: kopie se dozví o píjemcích v kategorii To: a Cc: píjemci v kategoriích To: a Cc: se nedozví o píjemcích v kategorii Bcc: v každé kategorii mže být více píjemc (libovoln mnoho) J.Peterka, MFF UK, Pedstava: zpráva je list papíru, který se vloží do obálky a teprve ta se penáší RFC 822 definuje, co a jak má být napsáno na listu papíru SMTP definuje obálku a zpsob jejího penosu (i co má být napsáno na této obálce) nkteré z položek hlaviky listu jsou kopírovány na obálku, mj. adresa píjemce a odesilatele SMTP je penosovým mechanismem pro penos zpráv ( obálek ) využívá spolehlivých penosových služeb protokolu TCP (ale mže být implementován i nad jinými spolehlivými penosovými protokoly) chápe penášená data jako text lenný na ádky pomocí CR+LF tvoený 7-bitovými ASCII znaky!!!!! J.Peterka, MFF UK, v. 2.2 Doruování podle MX záznam v. 2.2 Píklad sí s dial-up pipojením penos zprávy prostednictvím SMTP má v zásad on-line charakter odesílající uzel komunikuje pímo s koncovým píjemcem pošty a oekává, že tento je ke komunikaci pipraven proto musí být píjemce trvale dosažitelný!!! nebo pošta pesmrována na vhodný mail spool eší se pomocí MX (Mail exchanger záznam) cz cz peterka DNS: snaž se doruit na stroj, pokud to nejde tak na stroj mspool.czech.net 100, 100, mspool.czech.net mspool.czech.net 10, 10, mail.upstream.com mail.czech.net mail.small.cz v dob kdy sí píjemce (odpovídající domén small.cz, tj. s MX záznamy mají priority uzlem mail.small.cz) není dostupná, je pošta pro uživatele v DNS DNS domény domény small.cz: small.cz: domén small.cz doruována na uzel mail.czech.net (mail spool) small.cz, nižšííslo = vyšší priorita small.cz, 100, 100, mail.upstream.com event. záložní mail.upstream.com, pokud mail.czech.net není small.cz, small.cz, 10, 10, mail.czech.net mail.czech.net prostednictvím priorit se stanoví poadí dostupný). small.cz, small.cz, 0, 0, mail.small.cz mail.small.cz ch server, tak a vždy l až se mail.small.cz stane dostupným, pošta k nmu sama nkterý z nich dosažitelný on-line "petee" fakticky: ostatní servery pravideln testují jeho dostupnost pošta je vždy douena na server s nejvyšší a pokud ji zjistí, zahájí penos všech zpráv ze spoolu J.Peterka, MFF UK, 2004 prioritou, který je práv dostupný 21 J.Peterka, MFF UK, mail server upstream providera Internet sí providera v. 2.2 SMTP dialog v. 2.2 SMTP dialog - píklad odesilatel naváže spojení s ureným píjemcem píjemce je uren dle MX záznam v DNS pokud se nedaí jej urit z DNS, snaží se odesilatel interpretovat ást adresy za zavináem jako jméno konkrétního poítae na port 25 (kdeeká SMTP server) spojení využívá TCP poté dochází ke vzájemnému dialogu ob strany si pedávají dležité "identifikaní" údaje mj. údaje, pedstavující nápisy na obálce ) teprve pak je penesena vlastní zpráva ( list ) píkazy SMTP mají textový charakter (nap. HELO, RCPT,...) odpovdi jsou zásadn íselné (trojmístné - obdobn jako v pípad protokolu FTP) J.Peterka, MFF UK, SMTP service ready HELO smtp.post.cz 250 hello smtp.post.cz MAIL FROM: <nekdo@post.cz> 250 sender ok From: nekdo@post.cz RCPT TO: <jiri@peterka.cz> 250 recipient ok RCPT TO: <jirka@peterka.cz> To: To: jiri@peterka.cz 250 recipient ok Cc: Cc: jirka@peterka.cz DATA 354 Enter mail, end with "." on a line itself { hlavika zprávy dle RFC 822} {tlo zprávy dle RFC822}. {teka jako zakonující znak} 250 mail accepted {ukonení penosu dat} QUIT 221 {ukonení spojení} J.Peterka, MFF UK, , verze 2/2 4

5 v. 2.2 Netextové penosy v. 2.2 Netextové penosy kde je problém? Pvodn: SMTP pošta la urena jen pro penos krátkých textových zpráv v "istém ASCII" bez hák&árek, bez formátování, rzných druh písma penosové mechanismy (protokol SMTP) jsou koncipovány tak, a garantovaly penos textových zpráv složených ze 7-bitových znak není stanoveno co se má stát, když znaky budou 8- bitové!!! ešení: MIME Problém: pokud se nkdo pokusí penést nco jiného než 7-bitové znaky, není garantováno jak to dopadne mže to dopadnou dobe ale: "nejvyšší bity" mohou být oezány (nastaveny na 0) apod. kvli kvli tomu tomu není nenímožné (bez (bez dalších dalších opatení) penášet poštou poštou 8-bitová data data (nap. (nap. háky háky a a árky árky v textu textu i i binární binárnípílohy) J.Peterka, MFF UK, problém je s pílohami pokud k textové zpráv l piložen datový soubor, nemusel "projít" datový soubor je obecn tvoený 8-bitovými ty problém je i s národními abecedami nelze používat znaky národních abeced, protože ty je nutné kódovat do 8 bit problém je i s formátováním formátovací znaky jsou také 8- bitové princip ešení: všechno co je 8-bitové se pevede na 7-bitové, penese a pak zase vrátí do pvodní podo ALE: toto lze uinit mnoha rznými zpso nejvtší problém je v tom, a se lidé dohodli na spoleném postupu tak a píjemce vždy vdl, co a jak má provést s obdrženou zprávou J.Peterka, MFF UK, v. 2.2 ešení "netextových" penos v. 2.2 Co definuje MIME? "nesystematická" ešení: týkají se pouze "pibalování" píloh UUENCODE MIME je podporován vtšinou novjších ch klient varianta "pibalování" píloh, pocházející ze svta Unixu BinHex varianta pocházející ze svta poíta Macintosh umožuje bezproblémovou práci s pílohami jedna zpráva mže mít i více píloh, pílohou mže být cokoli co lze "zabalit" do podo souboru. umožuje psát esky systematickéešení: standard MIME v tle zprávy, pedmtu zprávy i v komentáových ástech adres!!! Multipurpose Internet Multimedia umožuje provázání ho Extensions klienta s aplikacemi eší problém píloh i otázku použití národních abeced a formátování zpráv tak a uživateli stailo kliknout na ikonku s pílohou, a klient vdl co má s pílohou udlat (jak ji "vybalit" a kterému programu ji pedat) Kódování 2 zpso pevedení 8-bitových dat do 7-bitové podo: Quoted Printable a Base64 Typování dat zavádí tzv. MIME type (je dvousložkový), a lo možné definovat co jsou data za a lo možné odvodit, jak mají být zpracována nap. text/html, image/gif Rozšíení formátu zprávy zavádí rozšíení formátu dle RFC822, tak a mohly být ve zpráv vyjádeny informace související s pílohami, kódováním atd. zavádí nové položky do hlaviky umožuje a tlo zprávy mlo více složek J.Peterka, MFF UK, J.Peterka, MFF UK, v. 2.2 Kódování v MIME v. 2.2 Pedstava kódování Base64 Quoted-printable tisknutelné ASCII znaky ponechává tak jak jsou ostatní kóduje do trojice znak, nap. =C8 rovnítko a hexadecimální kód znaku v použité znakové sad píklad: "lánek" bude kódován jako "=C8l=E1nek" je to vhodné tam, kde je málo netisknutelných znak Base64 kóduje všechny znaky vezme binární kódy všech znak, seadí je do posloupnosti rozdlí je na šestice, tím získáísla od 0 do 63 ísla použije jako indexy do pevodní tabulky A,B,C..Z,a,b.,8,9,+,/ píklad: "lánek" bude kódován jako "ygzhbmvr " l á n e k 0 A C 8 6 C E 1 6 E B y G z h b m V r Kódovací tabulka 1 B.. 25 Z 26 a 27 b 43 r 51 z / J.Peterka, MFF UK, J.Peterka, MFF UK, , verze 2/2 5

6 v. 2.2 MIME type v. 2.2 Nové položky v hlavice zprávy MIME potebuje definovat, co jsou penášená data za kvli jejich následnému zpracování zavádí dvousložkový "MIME type" "typ/podtyp" (type/subtype) typ má 7 možností: text MIME typ typ používá image nap. i i WWW server audio k urení typu typu stránek video které vrací klientovi application všechno ostatní druhy dat multipart když má zpráva více složek message když je obsahem zprávy jiná zpráva) podtyp (subtype) upesuje o co se jedná nap.: text/html (text v HTML) text/plain (istý text) image/gif, image/jpeg application/msword má být "pedhozeno" MS Wordu ke zpracování application/pdf multipart/mixed složená zpráva message/rfc822 obsahem je jiná zpráva formátovaná dle RFC 822 J.Peterka, MFF UK, MIME postupuje inkrementáln pidává nové položky do hlaviky mže, RFC 822 íká: když njaké položce nerozumíš, ignoruj ji píklad: Content-Type: text/plain tlo zprávy obsahuje istý text Content-Type: text/html tlo zprávy je v html Content-Type: text/plain; charset="iso " Content-Transfer-Encoding: quoted-printable tlo zprávy obsahuje istý text v ISO , který je zakódovaný pomocí Quoted-printable další položky vyjadují použitou verzi MIME, definují vícesložkovou strukturu tla zprávy atd. J.Peterka, MFF UK, v. 2.2 Píklad zprávy v HTML... MIME-Version: 1.0 Content-Type: text/html From: News Dispatcher <ne-disp@cnet.com> To: Multiple recipients of list NEWS-DISPATCH-HTML <NEWS-DISPATCH-HTML@DISPATCH.CNET.COM> Subject: Pentium II 400-MHz/Gates & Marimba/The. <html> <head> <title>cnet NEWS.COM Dispatch, August 14, 1997</title> <body> </body> </html> Tlo zprávy tvoí text ve formátu HTML Tlo zprávy (HTML stránka) v. 2.2 From: "Jiri Peterka" <peterka@ksi.ms.mff.cuni.cz> použito kódování quoted-printable Jméno píjemce v kódování Q-P To: "=?iso ?q?petr_koubsk=fd?=" <pkoubsky@softnov.cz> použitý jazyk použito kódování Base-64 Subject: =?iso ?b?ygzhbmvrig8gtulnrq==?= Date: Fri, 15 Aug :36: pedmt zprávy v kódování Base-64 MIME-Version: 1.0 Content-Type: multipart/mixed; oddlova ástí zprávy boundary="----=_nextpart_000_0002_01bca f560" použitý klient X-Mailer: Microsoft Outlook Express =_NextPart_000_0002_01BCA F560 Content-Type: text/plain; charset="iso " 1. ást: Content-Transfer-Encoding: quoted-printable text zprávy Dobr=FD den, popis 1. ásti zprávy v p=f8=edloze pos=edl=e1m sl=edben=fd =E8l=E1nek o problematice = standardu MIME. í ý á S pozdravem J. Peterka =_NextPart_000_0002_01BCA F560 Content-Type: application/msword; name="mime.doc" Content-Transfer-Encoding: quoted-printable 2. ást: piložený soubor J.Peterka, MFF UK, popis 2. ásti zprávy... obsah souboru mime.doc, v kódování quoted-printable. (typ dat, jméno vloženého souboru, použité kódování) =_NextPart_000_0002_01BCA F560-- konec zprávy J.Peterka, MFF UK, v. 2.2 Píklad: klient nepodporuje MIME Odesílaná zpráva J.Peterka, MFF UK, , verze 2/2 6