Rodina protokol TCP/IP, verze 2.2. ást 9: Elektronická pošta

Transkript

1 v. 2.2 Katedra softwarového inženýrství, Matematicko-fyzikální fakulta, Univerzita Karlova, Praha Rodina protokol, verze 2.2 ást 9: Elektronická pošta Jií Peterka, 2005

2 v. 2.2 Co je elektronická pošta? je to služba! mže být realizována rznými zpsoby, 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 poštovní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,

3 v. 2.2 Elektronická pošta jako služba 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 J.Peterka, MFF UK,

4 v. 2.2 Filosofie SMTP pošty 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í by 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,

5 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 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 poštovním serveru definuje protokol POP3, IMAP. rozšíení definuje standard MIME J.Peterka, MFF UK,

6 v. 2.2 Vývoj elektronické pošty 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: poštovní klient na "serverovém" poítai, klient na uživatelov PC, nebo na notebooku apod dsledek oddlení klienta a serveru: bylo nutné vyvinout prostedky 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 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,

7 v. 2.2 Pedstava server a klient Zde Zde bží bží poštovní klient poštovní server POP3 Poštovní servery komunikují prostednictvím protokolu SMTP poštovní server POP3 Zde Zde bží bží poštovní klient Pro tuto komunikaci vzdálený klient bylo nutné vyvinout nové mechanismy J.Peterka, MFF UK,

8 v. 2.2 Umístní poštovní schránky Varianta 1 (ménastá) poštovní schránka je na poštovním serveru poštovní 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ší) poštovní schránka je rozdlena již pijaté, 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ítai (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 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é explicitn "stahovat" (download) J.Peterka, MFF UK,

9 v. 2.2 Pedstava 2. varianty Poštovní schránka uživatele s adresou jiri@peterka.cz Zde Zde se se hromadí pouze dosud nevyzvednuté zprávy Poštovní server (uzel mail.czn.cz) Osobní Osobnípoíta poítauživatele, na na který který si si stahuje stahuje svou svou poštu poštu (pomocí protokolu POP3) POP3) Veškerá pošta pošta uživatele se se hromadí zde, zde, a zde zde je je také takézpracovávána (zde (zde si si uživatel pouští pouštísvého poštovního klienta) klienta) J.Peterka, MFF UK,

10 v. 2.2 "Anatomie" poštovní zprávy 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 podoby souboru nap. datový soubor, zvukový klip apod. J.Peterka, MFF UK,

11 v. 2.2 Pedstava Hlavika (header) prázdná ádka Tlo (body) To: To: From: From: 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 slidy v PowerPointu. S pozdravem J. J. Peterka definuje RFC 822 Píloha (attachment) J.Peterka, MFF UK,

12 v. 2.2 Formát zpráv el. pošty 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,

13 v. 2.2 Hlavika dle RFC 822 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,

14 v. 2.2 Položky hlaviky - píklady 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á Received: 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,

15 v. 2.2 Píklad: hlavika mailu Received: by scretchy (mbox peterka) Wed Apr 12 21:14: ) X-From_: Wed Apr 12 21:13: Received: from smtp.kolej.mff.cuni.cz (smtp.kolej.mff.cuni.cz [ ]) by scretchy.czech.net with ESMTP id VAA05330 for Wed, 12 Apr :13: Received: from venca.kolej.mff.cuni.cz (venca.kolej.mff.cuni.cz [ ]) by smtp.kolej.mff.cuni.cz (8.9.2/8.9.0) with ESMTP id VAA39163 for Wed, 12 Apr :13: (CEST) Date: Wed, 12 Apr :13: (CEST) From: Vasek Petricek To: Jiri Peterka Subject: Diplomova prace VPN Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii J.Peterka, MFF UK,

16 v. 2.2 Píklad (doruení mailu).. Received: Received: from from venca.kolej.mff.cuni.cz venca.kolej.mff.cuni.cz by by smtp.kolej.mff.cuni.cz smtp.kolej.mff.cuni.cz.. poštovní klient.. Received: Received: from from smtp.kolej.mff.cuni.cz smtp.kolej.mff.cuni.cz by by scretchy.czech.net scretchy.czech.net.. scretchy.czech.net.. Received: Received: by by scretchy scretchy (mbox (mbox peterka) peterka).. uložení do poštovní schránky uživatele "peterka" smtp.kolej.mff.cuni.cz venca.kolej.mff.cuni.cz pozdjší download pomocí pomocípop3 J.Peterka, MFF UK,

17 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émm pi sthování uživatel, pi zmn poštovního serveru apod. uživatel musel obeslat všechny své partnery, a informovat je o zmn své adresy nap.: peterka@scretchy.czech.net (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,

18 v. 2.2 Pedstava doruování to: to: cz cz peterka DNS (MX záznam): veškerou poštu pro peterka.cz doruovat na scretchy.czech.net skutené doruení schránka uživatele peterka alias: pošta s adresou jiri@peterka.cz patí uživateli peterka poíta scretchy.czech.net Doruení bude bude stejné, stejné, jako jako kdyby kdyby adresa adresa byla byla peterka@scretchy.czech.net J.Peterka, MFF UK,

19 v. 2.2 Adresy dle RFC822 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,

20 v. 2.2 RFC822 vs. SMTP 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,

21 v. 2.2 Doruování podle MX záznam 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 scretchy.czech.net, pokud to nejde tak na stroj mspool.czech.net peterka.cz, peterka.cz, MX, MX, 100, 100, mspool.czech.net mspool.czech.net peterka.cz, peterka.cz, MX, MX, 10, 10, scretchy.czech.net scretchy.czech.net MX záznamy mají priority nižšííslo = vyšší priorita prostednictvím priorit se stanoví poadí poštovních server, tak aby vždy byl nkterý z nich dosažitelný on-line pošta je vždy douena na server s nejvyšší prioritou, který je práv dostupný J.Peterka, MFF UK,

22 v. 2.2 Píklad sí s dial-up pipojení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 doruová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 nmu sama "petee" fakticky: ostatní poštovní servery pravideln testují jeho dostupnost a pokud ji zjistí, zahájí penos všech zpráv ze spoolu DNS DNS domény domény small.cz: small.cz: small.cz, small.cz, 100, 100, mail.upstream.com 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 J.Peterka, MFF UK,

23 v. 2.2 SMTP dialog 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,

24 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: <nekdo@post.cz> 250 sender ok RCPT TO: <jiri@peterka.cz> 250 recipient ok RCPT TO: <jirka@peterka.cz> 250 recipient ok DATA 354 Enter mail, end with "." on a line by 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 scretchy.czech.net {ukonení spojení} From: nekdo@post.cz To: To: jiri@peterka.cz Cc: Cc: jirka@peterka.cz J.Peterka, MFF UK,

25 v. 2.2 Netextové penosy Pvodn: SMTP pošta byla 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, aby 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 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,

26 v. 2.2 Netextové penosy kde je problém? problém je s pílohami pokud by k textové zpráv byl piložen datový soubor, nemusel by "projít" datový soubor je obecn tvoený 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 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í podoby ALE: toto lze uinit mnoha rznými zpsoby nejvtší problém je v tom, aby se lidé dohodli na spoleném postupu tak aby píjemce vždy vdl, co a jak má provést s obdrženou zprávou J.Peterka, MFF UK,

27 v. 2.2 ešení "netextových" penos "nesystematická" ešení: týkají se pouze "pibalování" píloh UUENCODE varianta "pibalování" píloh, pocházející ze svta Unixu BinHex varianta pocházející ze svta 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 vtšinou novjší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 tle zprávy, pedmtu zprávy i v komentáových ástech adres!!! umožuje provázání poštovního klienta s aplikacemi tak aby 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) J.Peterka, MFF UK,

28 v. 2.2 Co definuje MIME? Kódování 2 zpsoby pevedení 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ádeny informace související s pílohami, kódováním atd. zavádí nové položky do hlaviky umožuje aby tlo zprávy mlo více složek J.Peterka, MFF UK,

29 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 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 píklad: A,B,C..Z,a,b..,8,9,+,/ "lánek" bude kódován jako "ygzhbmvr " J.Peterka, MFF UK,

30 v. 2.2 Pedstava kódování Base64 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 Z 26 a 27 b.. 43 r.. 51 z / J.Peterka, MFF UK,

31 v. 2.2 MIME type 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. nap. i i WWW server audio k urení typu typu stránek video které kterévrací 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,

32 v. 2.2 Nové položky v hlavice zprávy 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,

33 v. 2.2 Píklad zprávy v HTML Received:... MIME-Version: 1.0 Content-Type: text/html Tlo zprávy tvoí text ve formátu 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> Tlo zprávy (HTML stránka) </body> </html> J.Peterka, MFF UK,

34 v. 2.2 From: "Jiri Peterka" 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: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_nextpart_000_0002_01bca f560" použitý poštovní klient X-Mailer: Microsoft Outlook Express pedmt zprávy v kódování Base-64 oddlovaástí zprávy =_NextPart_000_0002_01BCA F560 Content-Type: text/plain; charset="iso " Content-Transfer-Encoding: quoted-printable Dobr=FD den, popis 1. ásti zprávy 1. ást: text 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 popis 2. ásti zprávy (typ dat, jméno vloženého souboru, použité kódování)... obsah souboru mime.doc, v kódování quoted-printable =_NextPart_000_0002_01BCA F560-- konec zprávy J.Peterka, MFF UK,

35 v. 2.2 Píklad: poštovní klient nepodporuje MIME Odesílaná zpráva J.Peterka, MFF UK,