IP, verze 2.2. ást 9: Elektronická pošta

Rodina protokol

TCP/IP v. 2.2

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

Rodina protokol TCP/IP, verze 2.2

ást 9: Elektronická pošta Ji í Peterka, 2005

Rodina protokol

TCP/IP v. 2.2

Co je elektronická pošta?

• je to služba! – m že být realizována r znými zp soby, v r zném prost edí

• existují r zné "koncepce" elektronické pošty – nap . Mail602, ccMail, MS Mail, X.400, SMTP, ….. – liší se formátem zpráv, adresami, p enosovými mechanismy, ... – obecn jsou vzájemn nekompatibilní • pro možnost vzájemné spolupráce vyžadují existenci poštovních bran  J.Peterka, MFF UK, 2004

• 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í "vlastn ná" žádnou firmou, vychází z pln otev ených standard

2

Rodina protokol

TCP/IP v. 2.2

Elektronická pošta jako služba

• je rychlá –

asy doru ování se m í na minuty a sekundy

• je laciná – i když záleží na konkrétním zp sobu p ipojení

• je pohodlná – mnoho úkon lze zautomatizovat, nap . t íd ní došlých zpráv, p íprava odpov dí

• je efektivní – m že být provázána s dalšími aplikacemi – umož uje snadné hromadné rozesílání

 J.Peterka, MFF UK, 2004

• funguje „off-line“ zp sobem – nevyžaduje sou asnou 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 p enosovým mechanismem – ke zprávám lze p idávat prakticky libovolné p ílohy 3

Rodina protokol

TCP/IP v. 2.2

Filosofie SMTP pošty

• za íná skromn , postupn se obohacuje – p vodn vznikla jako velmi jednoduchá služba – jako elektronická obdoba "office memo"

• další vlastnosti a schopnosti se p idávaly teprve postupn , po ov ení jejich ú elnosti a funk nosti – vývoj je "inkrementální", není nutné vy azovat d ív jší vybavení • by nepodporuje nové funkce  J.Peterka, MFF UK, 2004

• p vodn : – pouze krátké texty v istém ASCII

• nyní: – možnost formátování textu, vkládání obrázk atd. – možnost p enosu netextových p íloh – podpora národních abeced (há ky& árky) – …….. 4

Rodina protokol

TCP/IP v. 2.2

Architektura SMTP pošty

• vychází z modelu klient/server – poštovní 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í

– poštovní 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 – p enos zpráv, download – formát zpráv, formát adres, p ílohy, …

• p enos zpráv: – definuje protokol SMTP (Simple Mail Transfer Protocol)

• formát zpráv a adres – definuje doporu ení RFC822

• download – stahování zpráv ze schránky na poštovním serveru – definuje protokol POP3, IMAP ….

• rozší ení – definuje standard MIME

5

Rodina protokol

TCP/IP

Vývoj elektronické pošty

v. 2.2

• p vodn : – server i klient b ží na stejném po íta i • typicky: mainframe, minipo íta • výhoda: mohu si p edávat zprávy jako jednotlivé soubory p ímo p es sdílené adresá e

• dnes: – server a klient b ží na r zných po íta ích • typicky: – poštovní klient na "serverovém" po íta i, – klient na uživatelov PC, nebo na notebooku apod  J.Peterka, MFF UK, 2004

• d sledek odd lení klienta a serveru: – bylo nutné vyvinout prost edky pro komunikaci mezi poštovní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

• d sledek: – možnost práce klienta v off-line režimu • není nutné trvalé propojení serveru a klienta

– možnost spolupráce r zných klient se stejným serverem

6

Rodina protokol

TCP/IP v. 2.2

P edstava server a klient Poštovní servery komunikují prost ednictvím protokolu SMTP

poštovní server Zdebb žíží Zde poštovní poštovní klient klient

vzdálený klient  J.Peterka, MFF UK, 2004

Zdebb žíží Zde poštovní poštovní klient klient

poštovní server POP3

POP3

Pro tuto komunikaci bylo nutné vyvinout nové mechanismy 7

Rodina protokol

TCP/IP v. 2.2

• Varianta 1 (mén

Umíst ní poštovní schránky astá)

– poštovní schránka je na poštovním serveru • poštovní klient musí mít ke schránce trvalý a dostate n rychlý p ístup • výhoda: uživatel si m že "sednout" ke kterémukoli po íta i v síti, a mít plnohodnotný p ístup ke své pošt .

– d íve: • je to praktické pouze v prost edí lokální sít (sít LAN)

– dnes: • lze používat i na dálku, skrze protokol IMAP

• Varianta 2 ( ast jší) – poštovní schránka je rozd lena • již p ijaté, ale dosud nevyzvednuté zprávy se nachází na poštovním serveru • již vyzvednuté zprávy se uchovávají u uživatele, na jeho po íta i (v rámci poštovního klienta)

• Varianta 3: (webmail) – poštovní schránka i klient jsou na serveru, uživatel s nimi pracuje na dálku • prost ednictvím WWW stránek – webmail

• prost ednictvím vzdáleného p ístupu – terminálový p ístup …


Nov Nov došlou došloupoštu poštujejenutné nutné explicitn explicitn "stahovat" "stahovat"(download) (download)

8

Rodina protokol

TCP/IP v. 2.2

P edstava 2. varianty Poštovní Poštovníschránka schránkauživatele uživatele ssadresou [email protected] [email protected] Zde Zdese sehromadí hromadípouze pouze dosud dosudnevyzvednuté nevyzvednutézprávy zprávy

Poštovní server (uzel mail.czn.cz)  J.Peterka, MFF UK, 2004

Osobnípo po íta íta uživatele, uživatele,na nakterý kterýsisi Osobní stahujesvou svoupoštu poštu(pomocí (pomocíprotokolu protokoluPOP3) POP3) stahuje Veškerápošta poštauživatele uživatelese sehromadí hromadízde, zde, Veškerá zdejejetaké takézpracovávána zpracovávána(zde (zdesisi aazde uživatelpouští pouštísvého svéhopoštovního poštovníhoklienta) klienta) uživatel 9

Rodina protokol

TCP/IP v. 2.2

"Anatomie" poštovní zprávy

• Každá zpráva má tyto ásti: – hlavi ku (header) – t lo (body) – voliteln : p ílohu (attachment)

• Hlavi ka obsahuje:

– P edm t 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, ….

• T lo – obsahuje vlastní text zprávy

– adresu p íjemce • P íloha: (p íjemc ) – v zásad cokoli, co lze – adresu odesilatele "zabalit" do podoby souboru – datum vzniku/odeslání • nap . datový soubor, zvukový klip apod.


10

Rodina protokol

TCP/IP

P edstava

v. 2.2

Hlavi ka (header) prázdná prázdná ádka ádka

T lo (body)

To: To:[email protected] [email protected] From: From:[email protected] [email protected] Date:Tue, Date:Tue,17 17Nov Nov1998 199809:23:17 09:23:17+0100 +0100 Subject: Subject:Pozvanka Pozvankana nakurz kurzel. el.posty posty

Dobry Dobryden, den, potvrzuji potvrzujikonani konanikurzu kurzuel. el.posty postydne dne 23.11.1998, 23.11.1998,aavvpriloze prilozeposilam posilamslidy slidy vvPowerPointu. PowerPointu. SSpozdravem pozdravem J.J.Peterka Peterka

definuje definuje RFC RFC 822 822

P íloha (attachment)  J.Peterka, MFF UK, 2004

11

Rodina protokol

TCP/IP v. 2.2

Formát zpráv el. pošty

• “p vodní” pošta v rámci TCP/IP definovala pouze syntaxi a sémantiku hlavi ky (v doporu ení RFC 822) – t lo brala jako “ ernou sk í ku” – p ílohy neuvažovala v bec

• dnes existuje rozší ení (standard MIME), které z ásti specifikuje i formát t la zprávy – a zavádí možnost použití p íloh


• RFC 822 p edpokládá, že hlavi ka je tvo ena posloupností položek – p esn definuje syntaxi i sémantiku jednotlivých položek hlavi ky, relevantních pro doru ení zprávy • ... do toho spadá mj. i p esná syntaxe adres

– o t le zprávy p edpokládá pouze to, že jej tvo í ASCII text (a následuje za hlavi kou, od které je odd leno prázdnou ádkou) 12

Rodina protokol

TCP/IP v. 2.2

Hlavi ka dle RFC 822

• hlavi ka zprávy je tvo ena • po adí položek v hlavi ce položkami (header fields) není p edepsáno (pouze doporu eno) • každá položka za íná na nové • je definováno mnoho ádce (a na první pozici) r zných položek, nejsou • každá položka je uvozena všechny povinné klí ovým slovem (zakon eným dvojte kou), za kterým • skladba položek pamatuje na následuje vlastní obsah položky r zné “nestandardní” situace, nap .: – obsah n kterých položek je interpretován “strojem”, a proto je jeho syntaxe definována p esn (nap . adresy, data apod.) – jiné položky jsou ur eny pouze uživateli, a formát jejich obsahu je vícemén volný (nap . Subject)


– že odesilatelem je n kdo jiný než p vodní iniciátor zprávy, – odpovídat se má jinam než na adresu odesilatele – ............. 13

Rodina protokol

TCP/IP v. 2.2

Položky hlavi ky - p íklady

• s pevnou syntaxí: – From: kdo danou zprávu napsal – To: komu je zpráva ur ena – Date: datum a as odeslání – Sender: kdo zprávu odeslal (je-li to n kdo jiný než autor) – Reply-to: komu je t eba adresovat odpov (je-li to n kdo jiný než Sender i From) – Return-Path: kam vrátit zprávu, je-li nedoru itelná – Received: informace o p enosu (1 "p eskoku")  J.Peterka, MFF UK, 2004

• s volnou syntaxí: – Subject: p edm t zprávy – položky uvozené X- (nap . X-Mailer apod.), jsou ur eny k rozši ování možností RFC 822 • X-Charset: znaková sada • X-Mailer: druh klienta • X-Sender: jiná adresa odesilatele • …..

zzpohledu pohleduRFC RFC822 822 pp edstavují edstavujíkomentá komentá ee 14

Rodina protokol

TCP/IP v. 2.2

P íklad: hlavi ka mailu

Received: by scretchy (mbox peterka) Wed Apr 12 21:14:33 2000) X-From_: [email protected] Wed Apr 12 21:13:54 2000 Received: from smtp.kolej.mff.cuni.cz (smtp.kolej.mff.cuni.cz [195.113.25.225]) by scretchy.czech.net with ESMTP id VAA05330 for <[email protected]>; Wed, 12 Apr 2000 21:13:48 +0200 Received: from venca.kolej.mff.cuni.cz (venca.kolej.mff.cuni.cz [195.113.27.82]) by smtp.kolej.mff.cuni.cz (8.9.2/8.9.0) with ESMTP id VAA39163 for <[email protected]>; Wed, 12 Apr 2000 21:13:44 +0200 (CEST) Date: Wed, 12 Apr 2000 21:13:44 +0200 (CEST) From: Vasek Petricek To: Jiri Peterka <[email protected]> Subject: Diplomova prace VPN Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII  J.Peterka, MFF UK, 2004

15

Rodina protokol

TCP/IP

P íklad (doru ení mailu)

v. 2.2

…. …. Received: Received:from fromvenca.kolej.mff.cuni.cz venca.kolej.mff.cuni.cz by smtp.kolej.mff.cuni.cz by smtp.kolej.mff.cuni.cz …. ….

…. …. Received: Received:from fromsmtp.kolej.mff.cuni.cz smtp.kolej.mff.cuni.cz by scretchy.czech.net by scretchy.czech.net …. …. …. …. Received: Received:by byscretchy scretchy(mbox (mboxpeterka) peterka) …. ….

poštovní klient

scretchy.czech.net

uložení do poštovní schránky uživatele "peterka"

smtp.kolej.mff.cuni.cz venca.kolej.mff.cuni.cz pozd pozd jší jšídownload download pomocí pomocíPOP3 POP3  J.Peterka, MFF UK, 2004

16

Rodina protokol

TCP/IP v. 2.2

Adresy v elektronické pošt

• D íve byly poštovní adresy typu

schránka@po íta – byly pevn vázány na konkrétní po íta , a docházelo k velkým problém m p i „st hování“ uživatel , p i zm n poštovního serveru apod. • uživatel musel obeslat všechny své partnery, a informovat je o zm n své adresy

• nap .: [email protected] (viz p edchozí p íklad)  J.Peterka, MFF UK, 2004

• 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 íta e

• nap .:

[email protected] 17

Rodina protokol

TCP/IP

P edstava doru ování

v. 2.2

cz cz to: to:[email protected] [email protected]

skute né doru ení alias: pošta s adresou [email protected] pat í uživateli peterka

peterka peterka

DNS (MX záznam): veškerou poštu pro peterka.cz doru ovat na scretchy.czech.net

schránka uživatele peterka

po íta scretchy.czech.net

Doru Doru ení eníbude budestejné, stejné,jako jakokdyby kdybyadresa adresabyla [email protected] [email protected]  J.Peterka, MFF UK, 2004

18

Rodina protokol

TCP/IP v. 2.2

• Adresa m že mít dv

Adresy dle RFC822 ásti:

– adresu dle RFC822 • s pevn danou syntaxí, bez há k a árek

– komentá (nepovinný) • m že obsahovat i há ky a árky (pouze p i použití MIME)

• P íklady: – Ji í Peterka <[email protected]> – [email protected] (Ji í Peterka) – [email protected]

• Zápis adresy v podob tzv. URL odkazu (nap . v rámci WWW stránek): – mailto:[email protected]

• 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 pr klepák" – obdoba dopisu „na v domí“, 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, 2004

19

Rodina protokol

TCP/IP v. 2.2

RFC822 vs. SMTP

• P edstava: – “zpráva je list papíru, který se vloží do obálky a teprve ta se p enáší”

• RFC 822 definuje, co a jak má být napsáno na “listu papíru” • SMTP definuje “obálku” a zp sob jejího p enosu (i co má být napsáno na této obálce) – n které z položek hlavi ky “listu” jsou kopírovány na “obálku”, mj. adresa p íjemce a odesilatele  J.Peterka, MFF UK, 2004

• SMTP je p enosovým mechanismem pro p enos zpráv (“obálek”) – využívá spolehlivých p enosových služeb protokolu TCP (ale m že být implementován i nad jinými spolehlivými p enosovými protokoly) – chápe p enášená data jako text •

len ný na ádky pomocí CR+LF

• tvo ený 7-bitovými ASCII znaky

!!!!!

20

Rodina protokol

TCP/IP v. 2.2

Doru ování podle MX záznam

• p enos zprávy prost ednictvím SMTP má v zásad on-line charakter – odesílající uzel komunikuje p ímo s koncovým p íjemcem pošty a o ekává, že tento je ke komunikaci p ipraven

• proto musí být p íjemce trvale dosažitelný !!! – nebo pošta p esm rována na vhodný mail spool – eší se pomocí MX (Mail eXchanger záznam )  J.Peterka, MFF UK, 2004

DNS:

cz cz

peterka.cz, peterka.cz,MX, MX,100, 100,mspool.czech.net mspool.czech.net peterka.cz, MX, 10, scretchy.czech.net peterka.cz, MX, 10, scretchy.czech.net

peterka peterka snaž se doru it na stroj scretchy.czech.net, pokud to nejde tak na stroj mspool.czech.net

• •

MX záznamy mají priority • nižší íslo = vyšší priorita prost ednictvím priorit se stanoví po adí poštovních server , tak aby vždy byl n který z nich dosažitelný on-line

pošta je vždy dou ena na server s nejvyšší prioritou, který je práv dostupný

21

Rodina protokol

TCP/IP v. 2.2

P íklad – sí s dial-up p ipojením mail.upstream.com

mail.czech.net

mail.small.cz

mail server upstream providera

Internet sí providera •

v dob kdy sí p íjemce (odpovídající domén small.cz, tj. s uzlem mail.small.cz) není dostupná, je pošta pro uživatele v domén small.cz doru ována na uzel mail.czech.net (mail spool) –

•

event. záložní mail.upstream.com, pokud mail.czech.net není dostupný).

až se mail.small.cz stane dostupným, pošta k n mu sama "p ete e" –

DNS DNSdomény doménysmall.cz: small.cz: small.cz, 100, mail.upstream.com small.cz, 100, mail.upstream.com small.cz, small.cz,10, 10,mail.czech.net mail.czech.net small.cz, small.cz,0,0,mail.small.cz mail.small.cz

fakticky: ostatní poštovní servery pravideln testují jeho dostupnost a pokud ji zjistí, zahájí p enos všech zpráv ze spoolu


22

Rodina protokol

TCP/IP

SMTP dialog

v. 2.2

• odesilatel naváže spojení s ur eným p íjemcem

• p íkazy SMTP mají textový charakter (nap . – p íjemce je ur en dle MX záznam v DNS HELO, RCPT, ...) – pokud se neda í jej ur it z DNS, snaží se odesilatel interpretovat ást adresy za zaviná em jako jméno konkrétního po íta e

– na port 25 (kde eká SMTP server) • spojení využívá TCP

– odpov di jsou zásadn íselné (trojmístné obdobn jako v p ípad protokolu FTP)

• poté dochází ke vzájemnému dialogu – ob strany si p edávají d ležité "identifika ní" údaje • mj. údaje, p edstavující “nápisy na obálce”)

– teprve pak je p enesena vlastní zpráva (“list”)  J.Peterka, MFF UK, 2004

23

Rodina protokol

TCP/IP v. 2.2

• • • • • • • • • • • • • • • • •

SMTP dialog - p íklad

220 scretchy.czech.net SMTP service ready HELO smtp.post.cz 250 scretchy.czech.net hello smtp.post.cz MAIL FROM: From: [email protected] 250 sender ok RCPT TO: <[email protected]> 250 recipient ok RCPT TO: <[email protected]> To: To:[email protected] [email protected] 250 recipient ok Cc: Cc:[email protected] [email protected] DATA 354 Enter mail, end with "." on a line by itself { hlavi ka zprávy dle RFC 822} {t lo zprávy dle RFC822} . {te ka jako zakon ující znak} 250 mail accepted {ukon ení p enosu dat} QUIT 221 scretchy.czech.net {ukon ení spojení}


24

Rodina protokol

TCP/IP v. 2.2

Netextové p enosy

• P vodn : – SMTP pošta byla ur ena jen pro p enos krátkých textových zpráv v " istém ASCII"

• Problém:

• bez há k & árek, bez formátování, r zných druh písma

– p enosové mechanismy (protokol SMTP) jsou koncipovány tak, aby garantovaly p enos textových zpráv složených ze 7-bitových znak • není stanoveno co se má stát, když znaky budou 8bitové !!!  J.Peterka, MFF UK, 2004

ešení: MIME

– pokud se n kdo pokusí p enést n co jiného než 7-bitové znaky, není garantováno jak to dopadne • m že to dopadnou dob e • ale: "nejvyšší bity" mohou být o ezány (nastaveny na 0) apod. kv kv lilitomu tomunení nenímožné možné(bez (bez dalších dalšíchopat opatení) ení)ppenášet enášetpoštou poštou 8-bitová 8-bitovádata data(nap (nap. .há há ky kyaa árky árkyvvtextu textu i ibinární binárníppílohy) ílohy)

25

Rodina protokol

TCP/IP v. 2.2

Netextové p enosy – kde je problém?

• problém je s p ílohami – pokud by k textové zpráv byl p iložen datový soubor, nemusel by "projít" • datový soubor je obecn tvo ený 8-bitovými byty

• 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

• princip ešení: – všechno co je 8-bitové se p evede na 7-bitové, p enese a pak zase vrátí do p vodní podoby – ALE: toto lze u init mnoha r znými zp soby – nejv tší problém je v tom, aby se lidé dohodli na spole ném postupu • tak aby p íjemce vždy v d l, co a jak má provést s obdrženou zprávou

• problém je i s formátováním – formátovací znaky jsou také 8bitové  J.Peterka, MFF UK, 2004

26

Rodina protokol

TCP/IP v. 2.2

ešení "netextových" p enos

• "nesystematická" ešení: – týkají se pouze "p ibalování" p íloh – UUENCODE • varianta "p ibalování" p íloh, pocházející ze sv ta Unixu

– BinHex • varianta pocházející ze sv ta po íta Macintosh

– ……..

• systematické ešení: standard MIME – Multipurpose Internet Multimedia Extensions –

eší problém p íloh i otázku použití národních abeced a formátování zpráv


• MIME – je podporován v tšinou nov jších poštovních klient

• 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 podoby souboru

• umož uje psát esky – v t le zprávy, p edm tu zprávy i v komentá ových ástech adres!!!

• umož uje provázání poštovního klienta s aplikacemi – tak aby uživateli sta ilo kliknout na ikonku s p ílohou, a klient v d l co má s p ílohou ud lat (jak ji "vybalit" a kterému programu ji p edat)

27

Rodina protokol

TCP/IP v. 2.2

Co definuje MIME?

• Kódování – 2 zp soby p evedení 8-bitových dat do 7-bitové podoby: • Quoted Printable a Base64

• Typování dat – zavádí tzv. MIME type (je dvousložkový), aby bylo možné definovat co jsou data za a bylo 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 aby mohly být ve zpráv vyjád eny informace související s p ílohami, kódováním atd. • zavádí nové položky do hlavi ky • umož uje aby t lo zprávy m lo více složek


28

Rodina protokol

TCP/IP v. 2.2

Kódování v MIME

• 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  J.Peterka, MFF UK, 2004

• Base64 – kóduje všechny znaky – vezme binární kódy všech znak , • se adí je do posloupnosti • rozd lí je na šestice, tím získá ísla od 0 do 63 • ísla použije jako indexy do p evodní tabulky – A,B,C..Z,a,b…..,8,9,+,/

– p íklad: • " lánek" bude kódován jako "yGzhbmVr " 29

Rodina protokol

TCP/IP

P edstava kódování Base64

v. 2.2

l C 8

6

á C

E

n 1

6

E

e 6

k

5

6

B

1100 1000 0110 1100 1110 0001 0110 1110 0110 0101 0110 1011 110010 000110 110011 100001 011011 100110 010101 101011

50

6

51

33

27

38

21

43

y

G

z

h

b

m

V

r


Kódovací tabulka 0 1 ….. 25 26 27 …. 43 …. 51 52 53 …. 61 62 63

A B ….. Z a b …. r …. z 0 1 …. 9 + /

30

Rodina protokol

TCP/IP v. 2.2

MIME type

• MIME pot ebuje definovat, co jsou p enášená data za – kv li jejich následnému zpracování

• zavádí dvousložkový "MIME type"

• podtyp (subtype) up es uje o co se jedná • nap .:

– "typ/podtyp" (type/subtype)

• typ má 7 možností: – text MIME MIMEtyp typpoužívá používá nap – image nap. .iiWWW WWWserver server kkur – audio ur ení enítypu typustránek stránek které – video kterévrací vracíklientovi 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)  J.Peterka, MFF UK, 2004

– – – –

text/html (text v HTML) text/plain ( istý text) image/gif, image/jpeg application/msword • má být "p edhozeno" 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 31

Rodina protokol

TCP/IP v. 2.2

Nové položky v hlavi ce zprávy

• MIME postupuje inkrementáln – p idává nové položky do hlavi ky • m že, RFC 822 íká: když n jaké položce nerozumíš, ignoruj ji

• p íklad: – Content-Type: text/plain • t lo zprávy obsahuje istý text

– Content-Type: text/html • t lo zprávy je v html

– Content-Type: text/plain; charset="iso-8859-2" – Content-Transfer-Encoding: quoted-printable • t lo zprávy obsahuje istý text v ISO-8859-2, který je zakódovaný pomocí Quoted-printable

• další položky vyjad ují použitou verzi MIME, definují vícesložkovou strukturu t la zprávy atd.  J.Peterka, MFF UK, 2004

32

Rodina protokol

TCP/IP v. 2.2

P íklad zprávy v HTML Received: .....

MIME-Version: 1.0 Content-Type: text/html

T lo zprávy tvo í text ve formátu HTML

From: News Dispatcher To: Multiple recipients of list NEWS-DISPATCH-HTML Subject: Pentium II 400-MHz/Gates & Marimba/The …..

CNET NEWS.COM Dispatch,<br /> <br /> <body><br /> <br /> August 14, 1997

T lo zprávy

(HTML stránka)


33

Rodina protokol

TCP/IP

From: "Jiri Peterka"

použito kódování quoted-printable

v. 2.2

Jméno p íjemce v kódování Q-P

To: "=?iso-8859-2?Q?Petr_Koubsk=FD?="

použitý jazyk

použito kódování Base-64

Subject: =?iso-8859-2?B?yGzhbmVrIG8gTUlNRQ==?= Date: Fri, 15 Aug 1997 13:36:18 +0200 MIME-Version: 1.0

p edm t zprávy v kódování Base-64

odd lova

ástí zprávy

Content-Type: multipart/mixed; boundary="----=_NextPart_000_0002_01BCA980.3622F560"

použitý poštovní klient X-Mailer: Microsoft Outlook Express 4.71.1008.3

------=_NextPart_000_0002_01BCA980.3622F560 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Dobr=FD den,

1. ást: text zprávy

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_01BCA980.3622F560 Content-Type: application/msword; name="mime.doc" Content-Transfer-Encoding: quoted-printable

popis 2. ásti zprávy

(typ dat, jméno vloženého souboru, použité kódování)


2. ást: p iložený soubor

.... obsah souboru mime.doc, v kódování quoted-printable ….. ------=_NextPart_000_0002_01BCA980.3622F560--

konec zprávy

34

Rodina protokol

TCP/IP v. 2.2

P íklad: poštovní klient nepodporuje MIME

Odesílaná zpráva


35

IP, verze 2.2. ást 9: Elektronická pošta

Recommend Documents