Spam a bezpečnost ové komunikace

Transkript

1 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Diplomová práce Spam a bezpečnost ové komunikace Jan Tischler Vedoucí diplomové práce: Ing. Jan Kubr leden 2007

2 Poděkování Chtěl bych na tomto místě poděkovat své mamce, bez jejíž podpory a pochopení bych se nedostal až sem. Rovněž bych rád poděkoval vedoucímu diplomové práce Ing. Janu Kubrovi za to, že se ujal vedení mé diplomové práce a za jeho rady a komentáře.

3 Prohlášení Prohlašuji, že jsem svou práci vypracoval samostatně, pouze s použitím literatury a zdrojů uvedených v seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne

4 Abstrakt Ve své diplomové práci se zabývám nevyžádanou elektronickou poštou a možnostmi jejího filtrování. Práce seznamuje s protokoly pro přenos elektronické pošty a strukturou u, jež jsou nutné pro pochopení principů a odhalení slabých míst. Dále nastiňuje původ nevyžádaných zpráv a jejich varianty. Hlavním těžištěm je analýza metod pro boj se spamem a z toho vycházející návrhy, doporučení a implementace vylepšení. Klíčová slova: , spam, filtrování. Abstract My diploma thesis deals with unsolicited electronic mail and its filtering possibilities. The thesis acquaints with protocols used to transfer and handle electronic mail which are necessary for the understanding of basic principles and revealing of weaknesses. Subsequently it outlines the origin of unsolicited messages and their variants. Emphasis of this work is on the analysis of methods for counteracting spam with suggestions and implementation for improvements. Keywords: , spam, filtering.

5 Obsah 1 ÚVOD Historie ová adresa Struktura u Hlavička u Tělo zprávy Protokoly pro správu pošty SMTP (Simple Mail Transfer Protocol) POP3 (Post Office Protocol, verse 3) IMAP4 (Internet Message Access Protocol, verse 4) Zabezpečení protokolů SSL TLS Autentizační mechanismy Podpisové certifikáty a šifrování SPAM Definice Podstata spamu Proč jsem příjemcem spamu? Rozdělení spamu Podle formy Podle obsahu sdělení Podle charakteristických znaků ( ) Spam a zákon Zákony v Česku a EU OPT-IN Zákon v USA OPT-OUT Mezinárodní iniciativy FILTROVÁNÍ SPAMU Prevence ze strany uživatele Umístění filtru Posouzení účinnosti a přesnosti Konkrétní metody Autorizace odesilatele Analýza obsahu textu Porovnávání signatur Blacklist Whitelist Greylisting Alternativní způsoby Komplexní řešení Software VÝSLEDKY ANALÝZY A NÁVRHY ZLEPŠENÍ IMPLEMENTACE Implementační záměr Popis implementace Experimentální hodnocení ZÁVĚR POUŽITÉ ZDROJE... 71

6 Seznam obrázků Diplomová práce Obrázek 2-1: Běžný přenos zprávy...15 Obrázek 2-2: SMTP fáze MUA-MTA...16 Obrázek 2-3: MTA-MTA fáze...17 Obrázek 2-4: Mailgate a Firewall...18 Obrázek 2-5: Relaying, Open relay...19 Obrázek 2-6: Stavový diagram protokolu POP Obrázek 2-7: Stavový diagram protokolu IMAP...25 Obrázek 2-8: Šifrované spojení s SSL...28 Obrázek 2-9: Symetrické šifrování...30 Obrázek 2-10: Podepsání a zašifrování zprávy asymetrickým šifrováním...30 Obrázek 3-1: Procento spamu v elektronické poště za poslední 4 roky...35 Obrázek 3-2: Globální intenzita spamu v rámci měsíce (12/2006)...36 Obrázek 3-3: Obrázek jako náhrada za text spamu...41 Obrázek 4-1: Sender-ID mechanismus...49 Obrázek 4-2: Schéma použití Domain Keys...50 Obrázek 4-3: Učící se Bayesovský filtr...53 Obrázek 4-4: Topologie sítě DNSBL serverů spamhaus.org...58 Obrázek 4-5: Diagram Greylistingu...59 Obrázek 4-6: Zapojení SMTP proxy zprostředkovatele...61 Obrázek 4-7: Kaskáda pro zpracování zpráv...63 Obrázek 4-8: Příklad prolnutí funkcí programů...63 Obrázek 6-1: Volání externího modulu z Postfixu...67 Seznam tabulek Tabulka 3-1: Chyby při klasifikaci spamu...47 Tabulka 3-2: Bězně používané blacklisty...57 Tabulka 5-1: MySQL tabulka 'triplet'...68 Seznam příloh Příloha A: Obsah přiloženého CD Příloha B: Tabulka antispamových produktů - 2 -

7 Diplomová práce 1 ÚVOD Jako téma pro diplomovou práci jsem si zvolil analýzu metod filtrování nevyžádané pošty, tzv. spamu. V době, kdy jsem se nad tímto tématem zamýšlel poprvé (přelom roku 2004 a 2005), byl pro mne, stejně jako pro mnoho uživatelů osobních počítačů na celém světě, nezanedbatelným problémem příval komerčních sdělení, převážně směrujících do našich ových schránek. Tento problém se stal hlavní myšlenkou mé práce a motivací pro hlubší porozumění věci. Pod označením (nebo také ) rozumím zprávu elektronické pošty. se stal za léta existence Internetu jedním z hlavních komunikačních prostředků, který používá stále více lidí. Masivní rozšíření spamu je pro většinu uživatelů elektronické pošty komplikací a je celosvětová snaha problém řešit. Mnoho uživatelů, mě nevyjímaje, má založenou ovou schránku na některém z fre ových serverů 1. Z počátku jsme všichni pocítili problém spamu velmi silně, avšak do této chvíle (rok 2006) se situace v této oblasti výrazně zlepšila. Bylo zdokonaleno množství existujících metod a další nové postupy byly zavedeny. Po jejich nasazení byl počet nevyžádaných zpráv snížen na minimum. Pokud se ale zaměříme na organizace a společnosti, jež poskytují svým zaměstnancům přístup na internet a používají pro obchodní či jinou komunikaci, téměř vždy je třeba učinit opatření související s filtrováním nevyžádané pošty. Tato opatření je třeba učinit tak, aby byl přísun spamu k uživateli minimální a použít metody přímo na serveru příchozí pošty. Ve své práci se snažím v jednotlivých kapitolách shrnout procesy a protokoly související s přenosem a zpracováním ových zpráv a charakterizovat rysy spamu jako nevyžádané pošty. Kapitola, která se zabývá analýzou metod filtrování, pak představuje komplexní souhrn nejpoužívanějších metod, jejich výhod a nedostatků. Z poznatků získaných v této kapitole pak vychází návrhy na zlepšení. Poznámka: U analyzovaných metod většinou uvádím příklady použití z kategorie opensource programů. Je to proto, že k těmto programům je poskytována sdílnější dokumentace (na rozdíl komerčních produktů, kde si firma chce uchovat svoje výrobní tajemství, nebo je program předmětem patentu). V některých příkladech uvádím existující názvy domén, validní IP adresy či existující ové adresy. Činím tak čistě z ilustrativních důvodů, nikoliv s úmyslem kohokoliv poškodit. 1 Servery poskytující zdarma po zaregistrování ovou schránku, z českých seznam.cz, centrum.cz, aj

8 Diplomová práce Historie Původ u jako komunikačního prostředku sahá přibližně do roku 1965, kdy byla jedna z jeho prvních variant použita pro komunikaci mezi uživateli sálových počítačů pracujících v režimu sdílení času. Mezi prvními takovými systémy byly Q32 ve firmě System Development Company a CTSS na univerzitě MIT. Omezením bylo, že komunikace mohla probíhat pouze mezi uživateli tohoto sálového počítače. Na začátku sedmdesátých let vytvořil Ray Tomlinson se svými kolegy první programy pro lokální posílání ů SNDMSG a READMAIL pro operační systém TENEX, který společně vyvíjeli. Následně SNDMSG modifikoval pro použití na síti ARPANET 1 tak, že ho rozšířil o program CPYNET, jenž umožňoval poslání souborů po síti. Tomlinson rovněž rozšířil systém adresace uživatelů o notaci user@host a s pomocí oddělil uživatele a systém, což se stalo později standardem pro zápis ové adresy. S odstupem času došlo k mnoha rozšířením programů SNDMSG a READMAIL např. o možnost řazení a zpracování zpráv (program RD), integraci obou programů do jednoho programu, schopného odesílat i přijímat y (program WRD, později MSG). Prvním dokumentem, který sjednotil více formátů u v síti ARPANET do jedné ucelené specifikace, byl RFC 2 733, jenž byl později nahrazen RFC 822. Na počátku osmdesátých let byl přenos ů také prováděn prostřednictvím jednoduchého UUCP 3 protokolu na univerzitě v Berkeley, kde byl vyvinut operační systém BSD Unix. Protokol umožňoval přenos dat mezi systémy typu Unix pomocí dočasného vytáčeného připojení nebo připojení po sériové lince. Pracoval na principu ulož a pošli dál (store-and-forward), informace určené k odeslání se ukládaly do fronty, a po navázání spojení byly poslány na cílový počítač. Eric Allman později vytvořil program DELIVERMAIL, který spojoval dohromady více služeb pro přenos ů a prakticky vytvořil přepínač (switch) namísto integrované schopnosti store-and-forward. Na tomto principu byl následně vytvořen program SENDMAIL, distribuovaný spolu s BSD Unixem, jenž se stal nejčastěji používaným SMTP serverem v Internetu. V srpnu roku 1982 byla uvedena v [RFC 821] první verze protokolu SMTP (Simple Mail Transfer Protocol) základní standard pro přenos elektronické pošty tak, jak ji známe dnes. O něm pojednává kapitola Více informací na [LIVING1] 2.2 ová adresa Stejně jako u normální pošty, je pro posílání elektronické pošty nutná existence adresy. Hlavním rozdílem mezi nimi je jejich zápis a také to, že pro odeslání u je třeba identifikovat příjemce i odesilatele. ová adresa byla v minulosti definována různě. Jednou z dřívějších podob, v systémech s protokolem UUCP, byla tzv. bang! notace, která udávala cestu zprávy přes jednotlivé počítače. Názvy jednotlivých počítačů, přes které zpráva do cíle putovala, byly oddělené znakem!. Zápis utzoo!decvax!harpo!eagle!mhtsa!ihnss!ihuxp!greg, čteno zprava doleva, pak znamená cestu z počítače greg přes ihuxp, ihnss,, a decvax do cíle utzoo. Tento způsob adresace měl značnou nevýhodu v tom, že cestu musel vytyčit člověk a to bylo bez dostatečné znalosti topologie sítě obtížné. 1 První rozsáhlá síť s přepínáním paketů; předchůdce dnešního Internetu 2 Request For Comments; doporučení pro standardy na Internetu 3 Unix-to-Unix Copy Protocol - 4 -

9 2 Diplomová práce Současná obecná podoba ové adresy dle [RFC2822] je charakterizována zápisem kde local-part (lokální část) je obvykle uživatelské jméno adresáta, případně jeho alias domain (doménová část) značí doménové jméno počítače, na němž má uživatel ovou schránku; musí odpovídat plně kvalifikovanému doménovému jménu, což je úplné a unikátní jméno systému. Pokud např. pavilonopic je jméno hostitelského počítače, pak úplné jméno je např. pavilonopic.zoo.cz.. Tečka na konci se v adrese nevyskytuje a v zápisu pouze symbolizuje, že za jménem již nenásleduje žádná přípona. Více na [FQDN]. Skutečná adresa může vypadat např. jako dozor@zoo.cz Doporučená délka lokální části adresy je 64 znaků a doménového jména maximálně 255 znaků. Jeden znak v tomto případě znamená jeden oktet (8-bitů). Lokální část ové adresy je citlivá na velikost písmen (case sensitive) a může se skládat pouze z následující podmnožiny ASCII znaků: 1. malá a velká písmena abecedy a-z A-Z 2. čísla znaky! # $ % & ' * + - / =? ^ _ ` { } ~ 4. znak. (tečka), pokud není na počátku ani na konci lokální části adresy Navíc je povoleno jako lokální část adresy použít řetězec v uvozovkách (znak s hodnotou 34 v ASCII tabulce), který může obsahovat i zakázané znaky s předřazeným zpětným lomítkem. Např. je platná ová adresa, ale použití podobných variant není doporučeno [RFC 3696]. Ačkoliv je podle RFC použitelná množina znaků poměrně velká, v praxi je rozsah znaků omezen výrazněji. Většina poskytovatelů ové schránky, stejně jako běžně používané SMTP servery, akceptuje znaky uvedené výše v bodech 1, 2 a 4. Z bodu 3. pouze podtržítko _, případně pomlčku - (viz .cz, atlas.cz, aol.com). Vzhledem k citlivosti na velikost písmen lokální části by měl SMTP server dbát na to, aby zachoval nezměněný tvar. V cílovém systému by totiž mohlo dojít k případu, že uživatel opice a Opice budou dvě osoby! K tomu může snadno dojít v jakémkoliv systému, kde každý uživatel má automaticky přiřazenou ovou schránku, uživatelské jméno obsahuje velká písmena a lokální část jeho ové adresy odpovídá uživatelskému jménu. Rozlišování velikosti písmen je díky tomuto jevu spíše komplikace. Poznámka: Po otestování několika SMTP serverů a poskytovatelů ové schránky na rozlišování velikosti písmen v lokální části jsem došel k závěru, že je zcela ignorována. Uživateli je doručen s adresou zapsanou v jakékoliv kombinaci malých a velkých písmen. Povolené znaky doménové části adresy, která je necitlivá na velikost písmen (case insensitive), jsou dle specifikace doménových jmen [RFC 1035]: 1. malá a velká písmena abecedy a-z, A-Z 2. čísla znak. (tečka), pouze jako oddělující znak mezi názvy subdomény a domény 4. znak (pomlčka), pokud není na začátku nebo na konci označení domény nebo subdomény - 5 -

10 2 Diplomová práce Po srovnání reálné podoby lokální části a doménové části adresy je vidět, že se jedná takřka o stejný soubor znaků, pouze s několika výjimkami. Všechna výše uvedená omezení a zjednodušení jsou v podstatě výhodou a zápis ové adresy se tím stává snazší a přehlednější. 2.3 Struktura u Aby bylo možno poznat do detailu, je třeba se podívat důkladněji na jeho anatomii. Tato znalost poslouží k lepší orientaci v protokolech pro správu pošty a pozdějšímu pochopení principu funkce některých filtrů nevyžádané pošty. ová zpráva se skládá ve své podstatě ze dvou částí, hlavičky (header) a těla zprávy (body). Hlavička musí předcházet tělu (analogie ze života), a vzájemně je musí oddělovat jedna prázdná řádka (zakončená <CR><LF>) Hlavička u Hlavička poskytuje běžnému uživateli informace, od koho přišel, komu byl určen, jaký je předmět zprávy a kdy byla odeslána a tedy pro něj není příliš významná. Ve skutečnosti však jde o důležitou součást u a podle jejích údajů se řídí servery, přes které zpráva prochází, a ve větší míře nástroje pro filtrování nevyžádané pošty. Každá informace v hlavičce má své jméno a hodnotu a nachází se na samostatném řádku. Smí být reprezentována pouze jako tisknutelné znaky 7-bit ASCII 1 kódu (decimálně včetně), tedy k záznamu těchto znaků postačuje kódování do sedmi bitů. Obecně by měl být dle specifikace celý přenášen pomocí SMTP protokolu v 7-bitovém kódování. To se velice brzy projevilo jako nedostačující, zejména pro informace obsažené v těle zprávy a proto byla vydána série RFC označená jako MIME (Multipurpose Internet Mail Extension), která tento nedostatek řeší. Syntaxe zápisu hlavičkové informace (záhlaví) je <název>: <hodnota> kde název začíná velkým písmenem na začátku řádku, je následován dvojtečkou a od hodnoty je oddělen mezerou. Hodnota pak může být zalomena na více řádků, kde druhý a další začínají mezerou nebo tabulátorem (viz [RFC 2822], sekce 2.2). Poznámka.: V následujícím textu diplomové práce je označním hlavička (header) nebo hlavička u míněn celý blok, který předchází tělu, a pojem záhlaví (header field) označuje jeden konkrétní konkrétní údaj. Některá záhlaví jsou povinná (např. From:, To:, Date:), přidání jiných závisí na okolnostech. Během putování zprávy obvykle nejsou průchozími body (MTA 2 ) údaje v záhlaví nijak měněny, MTA pouze přidá další záhlaví Received: (viz níže) a případně další, pokud je potřeba. Pokud MTA některé údaje v záhlaví nezná, posílá je dál v nezměněné podobě. Klasická záhlaví 1 American Standard Code for Information Interchange; standard pro reprezentaci znaků, čísel, symbolů a kontrolních znaků pro použití v komunikaci a uchovávání dat. 2 Mail Transfer Agent, viz Chyba! Nenalezen zdroj odkazů

11 2 Diplomová práce Následující seznam obsahuje běžně používaná záhlaví, s poukazem na případné bezpečnostní nesrovnalosti a chyby v jejich použití. Jako zdroj některých informací byl použit [STOPSPAM]. Apparently-To: Zprávy s mnoha adresáty občas mají dlouhý seznam záhlaví ve formě Apparently-To: rth@bieberdorf.edu (jeden adresát na každé řádce). Tato záhlaví nejsou ve skutečném u běžná a obyčejně jsou příznakem použití většího seznamu adresátů (tzv. mailing listu). V současnosti jsou programy pro hromadné odesílání pošty dost chytré na to, aby negenerovaly hromadu těchto záhlaví. Bcc: (Blind Carbon Copy - slepá průklepová kopie). Běžně je toto záhlaví používáno ve stejném smyslu, jako Cc: (viz níže), ale nevyskytuje se v hlavičce při přenosu mezi servery. Kouzlo slepé kopie je totiž v tom, že ostatní příjemci nevidí, že zpráva byla určena i pro někoho jiného. Tuto vlastnost zprostředkovává odesílající MTA a na každou adresu v seznamu Bcc: kopii zprávy a vyplní záhlaví To:. Bcc: by tedy mělo existovat pouze ve zprávě odesílané z MUA 1 k prvnímu MTA. Pokud je toto záhlaví vidět v příchozí zprávě, je to indikace, že je něco v nepořádku! Slepé kopie jsou populární mezi spammery, neboť často zmatou nezkušeného uživatele, který dostanoe dopis, jenž vypadá jako že mu není adresován. Cc: (Carbon Copy) průklepová kopie analogie s psacím strojem. Tento údaj záhlaví je rozšířením záhlaví To: a specifikuje další adresáty. Některé programy s nimi zacházejí různě při tvorbě odpovědi (např. při volbě Odpovědět všem Outlook Express). Comments: je nestandardní neformátované pole záhlaví. Je nejčastěji k vidění ve formě "Comments: autentizovaný odesilatel je <rth@bieberdorf.edu>". Takové záhlaví je přidáno některými mailery (např. programem Pegasus Mail) k identifikaci odesilatele, ale je často také ručně přidáno spammery (samozřejmě s nesprávnou informací). Je třeba s ním zacházet pozorně. Date: Toto záhlaví obsahuje to, co by člověk normálně očekával. Specifikuje obyčejně datum napsání a odeslání zprávy. Pokud je toto záhlaví vynecháno, může být přidáno některým z mail serverů nebo jiným počítačem po cestě, kterou zpráva putuje. Mělo by se brát trochu s rezervou, neboť je na světě překvapivě mnoho počítačů se špatně nastaveným časem. Errors-To: Specifikuje adresu pro chyby generované programem pro obsluhu ů. Např. zprávy vrácené jako "neznámý adresát" jsou, místo na odesilatelovu, vráceny na tuto adresu. Není to příliš běžné záhlaví, protože odesilatel obvykle chce odvykle dostat chybová hlášení na svou adresu. Většina mail serverů to dělá automaticky. From: udává adresu odesilatele. Tento údaj není příliš směrodatný, neboť může být snadno nahrazen falešnou hodnotou. Message-Id: (také Message-id:, Message-ID:) by měl být unikátní identifikátor, který je přiřazen každé zprávě - obvykle prvním mailserverem, na který se dostane. Obecně je to ve formě "<hatmatilka@doména>", hatmatilka může být absolutně cokoli a doména je jméno stroje, který ID vygeneroval a přiřadil. Nepříliš často obsahuje hatmatilka i uživatelské jméno odesilatele. Zpráva, jejíž ID je špatné (např. prázdný řetězec, nebo bez ), nebo doména obsažená v Message-Id není doménou původu zprávy, je pravděpodobně falešná. In-Reply-To: toto záhlaví přiřadí zprávě ID jiné předchozí zprávy, na kterou tato odpovídá. Umožňuje například MUA nebo na webovém rozhraní, poskládat zprávy do kaskády odeslaných zpráv a jejich odpovědí. To zvyšuje přehlednost v obsáhlejší komunikaci. Newsgroups: Toto záhlaví se rovněž vyskytuje pouze v u, který má spojitost s Usenetem - kopie zpráv zaslaných do Usenetu, i odpovědi na ně. V prvním případě 1 Mail User Agent, viz Chyba! Nenalezen zdroj odkazů

12 2 Diplomová práce specifikuje diskusní skupiny, do kterých byla zpráva zaslána a v druhém případě diskusní skupiny do nichž byla poslána zpráva, na kterou je odpovídáno. Sémantika tohoto záhlaví je předmětem menší "svaté války", která zaručuje, že obě množiny sémantik budou v dohledné budoucnosti bez rozdílu používány. Priority: Absolutně volně pojaté záhlaví, které přiřazuje u prioritu. Většina programů ho ignoruje. Je často používáno spammery, obvykle ve formě "Priority: urgent" (nebo něco podobného), ve snaze zvýšit šance na přečtení jejich zprávy. Received: je jedno z nejdůležitějších záhlaví. Obsahuje totiž nejrelevantnější informace o tom, kudy zpráva po cestě k cíli prošla a odhaluje případné nesrovnalosti v jejím původu. Při každém předání zprávy mezi klientem a serverem provede MTA vytvoří své záhlaví Received: a přidá ho na začátek hlavičky před již existující záznamy. Syntaxe běžného záhlaví Received: je: Received: from <doména_klienta> by <doména_serveru> with <protokol> id <id_zprávy> [for < ová_adresa_příjemce>] ; <datum_a_čas> Jako doména_klienta je většinou uvedena adresa předávajícího stroje ve jmenném tvaru a v závorce za ní převedená na číselnou IP adresu (viz [RFC 2821]), případně typ služby, která zprávu zpracovala. Doména_serveru je doménové jméno stroje, který záhlaví vygeneroval. Protokol může být SMTP nebo ESMTP, nebo například HTTP, pokud byla zpráva odeslána přes webové rozhraní. Datum_a_čas odpovídá momentu zpracování zprávy serverem a je v klasickému UNIX formátu. Další použití a informace k tomuto záhlaví jsou v sekci o SMTP protokolu. References: Toto záhlaví je, až na kopie příspěvků z Usenetu, v u celkem ojedinělé. Je používáno na Usenetu k identifikaci příspěvku "výše", na který zpráva odpovídá; pokud se objeví v u, je to obvykle jenom kopie záhlaví Usenetu. Může se také objevit v em poslané odpovědi na příspěvek Usenetu, které poskytuje ID příspěvku, na nějž je odpovídáno. Reply-To: Specifikuje adresu pro odpovědi. Přestože má záhlaví mnoho legitimních užití (např. když váš software zkomolí adresu v záhlaví From: a vy chcete dostávat odpovědi na správnou adresu), je také často používáno spammery na odvrácení stížností. Často naivní spammer, který chce shromáždit odpovědi na svou zprávu, použije k tomuto účelu záhlaví Reply-To:. Častěji však adresa uvedená v tomto záhlaví u nevyžádané pošty je buď neplatná, nebo patří nevinné oběti. Return-Path: Záhlaví je přidáno do u ve chvíli, kdy ji přijme cílový SMTP server. Je do něj přepsána adresa z obálky (viz SMTP protokol) poskytnutá serveru v příkazu MAIL TO:, aby byla zachována informace o původním odesilateli. V případě, že zpráva je chybové hlášení od místního serveru (odchozí zpráva nebyla doručena), obsahuje toto záhlaví prázdnou adresu <>. Sender: V u neobvyklé záhlaví (často nahrazeno či doplněno záhlavím X-Sender:), se může vyskytovat v hlavičce v případě kopie příspěvku z Usenetu 1. Mělo by obsahovat adresu původního odesilatele; v případě příspěvků Usenetu jde o spolehlivější identifikátor, než obsah řádky From:. Subject: Naprosto volně pojaté pole, specifikované odesilatelem, jenž obsahuje předmět zprávy. To: Obvykle obsahuje příjemce zprávy. Může být jeden, stejně jako jich může být více. Některé servery mají nastaven limit na určitý počet adres v záhlaví To: spolu s Cc: a Bcc:. Pokud je tento limit překročen, odmítnou zprávu odeslat, případně posuzují jako rozesílání spamu [YAHOO1]. Je dobré si uvědomit, že záhlaví nemusí obsahovat opravdovou adresu příjemce! 1 Sít diskusních skupin, kategoricky členěných podle tématu

13 2 Diplomová práce X- záhlaví Tento termín označuje záhlaví začínající velkým X a pomlčkou. Úmluva je taková, že X- záhlaví jsou nestandardní a mají pouze informační charakter. Naopak jméno jakékoliv nestandardního záhlaví s informačním charakterem by mělo začínat prefixem "X-". Tato úmluva bývá však často porušována. X-záhlaví je hojně využíváno spam filtry a antivirovými programy pro označení výsledků testů, podle kterých se pak řídí program pro správu pošty, kterému jsou předřazeny. X-záhlaví je tedy bezpočet. Následuje ukázka těch běžnějších. X-Confirm-Reading-To: odesilatel vyžaduje automatické potvrzení o přečtení nebo doručení na adresu uvedenou v záhlaví. Obvykle je ignorováno, ale některé programy ho berou v potaz (např. MS Outlook či Outlook Express, novější verze požádají o svolení informovat odesilatele). X-Abuse: obsahuje informaci, kam oznámit zneužití ové adresy, ze které zpráva přišla. X-Antivirus:, X-Virus-Scanner, X-Virus-Scanned: používají antivirové programy běžně ke své identifikaci. Variace tohoto záhlaví je závislá na výrobci programu. X-SpamDetected:, X-VirusDetected: indikují např. číselnou hodnotou, zda se jedná o virus či spam. Hodnota 0 obvykle znamená negativní. X-Distribution: V reakci na problémy se spammery, kteří užívali Pegasus Mail, autor tohoto programu přidal toto záhlaví. Jakákoliv zpráva odeslaná Pegasus mailem většímu počtu adresátů má přidáno záhlaví ve tvaru X-Distribution: bulk, které říká že jde o hromadnou zprávu. To má sloužit jako pomůcka pro filtrování pošty na straně příjemce. X-Errors-To: stejně jako Errors-To: specifikuje adresu pro zasílání chybových hlášení. Pravděpodobně ale není tolik bráno v potaz. X-Mailer: je volně pojaté záhlaví určené pro identifikaci programu, s jehož pomocí byla zpráva odeslána odesilatelem. Protože většina nevyžádané pošty je odesílána jednoúčelovými programy, je tento údaj určen jako informace pro filtry. X-Priority: představuje další údaj o prioritě, jenž je používán např. Eudora mailerem k přiřazení priority zprávě (která je v programu zobrazena graficky). X-Sender: je ová analogie k záhlaví Sender: v Usenetu. Záhlaví údajně identifikuje odesilatele s větší spolehlivostí, než údaj From:. V podstatě je ale stejně obtížně zfalšovatelné a tedy by mělo být bráno se stejnou rezervou, jako záhlaví From:. X-UIDL: unikátní identifikátor používaný POP protokolem pro vybírání pošty ze serveru. Obyčejně je přidáno "po cestě" mezi ovým klientem příjemce a jeho mail serverem. Pokud ale dorazí zpráva na server s vypněným X-UIDL: záhlavím, pravděpodobně je to nesmysl (není tu žádný zjevný důvod pro jeho existenci v tomto momentě, ale někdy je z neznámých příčin spammery přidáno). MIME záhlaví Tato záhlaví souvisí s rozšířeným MIME obsahem těla u a napomáhají při prohlížení zprávy ke správné interpretaci údajů. V této sekci jsou zmíněny typy MIME záhlaví a jejich hodnoty, zbytek je popsán v následující sekci. Mime-Version: (také MIME-Version:) je záhlaví, které specifikuje jakou verzi MIME protokolu používá odesilatel. V současnosti je to verze 1.0. Klient, který není MIME kompatibilní záhlaví ignoruje, pro ostatní je to indikace, že zpráva obsahuje další MIME záhlaví udávající kódování, apod. Content-Type: je další MIME záhlaví, sdělující MIME-kompatibilnímu programu, jaký typ obsahu má ve zprávě nebo její části očekávat. Obvykle je hodnota text/plain nebo text/html (prostý text nebo html) následována na další řádce dodatkem charset=, jenž udává znakovou sadu tohoto textu. Pokud je tělo zprávy složeno z více částí, typicky - 9 -

14 2 Diplomová práce textu a příloh (hodnota multipart/mixed ), je následně uvedeno boundary=, a jeho hodnota představuje řetězec oddělující jednotlivé části, který je v těle navíc předcházen dvěma pomlčkami (znak - ). Každá taková část má potom uvedeny své vlastní hodnoty Content-Type: a Content-Transfer-Encoding:. Hodnot tohoto záhlaví je obecně velmi mnoho, 3 výše uvedené pokládám za nejpoužívanější, zbytek lze vidět pohromadě v [RFC 2046]. Content-Transfer-Encoding: Toto záhlaví se vztahuje k MIME, standardnímu způsobu přiložení netextového obsahu k u. Nemá žádnou přímou souvislost s doručením u, ale ovlivňuje, jak MIME-kompatibilní program naloží s obsahem zprávy resp. v jakém kódování jsou data přenášena. Výstupem všech níže zmíněných kódování je 7bit ASCII, vhodné pro přenos. Záhlaví může nabývat hodnot 7bit (klasické 7bitové US- ASCII), quoted-printable (používané pro kódování textu, který obsahuje znaky mimo rozsah US-ASCII) a base64 (obvykle použito pro kódování binárních dat). Zvláštním případem jsou 8bit (možno použít pouze u SMTP serverů s podporou 8BITMIME přenosu [RFC 1652]) a binary (není určeno pro elektronickou poštu). Content-Description: doplňuje popisek části těla u, ve které se nachází. Content-ID: přiřazuje části těla identifikátor, používaný při typu obsahu (content-type) multipart/related k odkazu na určitou část těla. Content-Disposition: udává, jak má klient naložit s přílohou u. Implicitní hodnota je inline, která říká klientovi, že MIME část má být zobrazena automaticky při zobrazení zprávy, tedy hned po jejím zpracování. Druhou alternativou je hodnota attachment. Část tohoto typu je zobrazena jako ikonka, případně popisek a ový klient nabídne po interakci s uživatelem uložení na disk nebo její zobrazení (viz [RFC 2183]) Tělo zprávy V těle zprávy se nachází vlastní obsah u a jeho formální složení je dáno dvěma omezeními: znaky <CR> a <LF> se v těle nesmí vyskytovat odděleně, ale pouze jako pár symbolizující konec řádku. řádek nesmí být delší než 998 znaků (bez koncového symbolu) a měl by být 78 znaků. Omezení 78 znaků je zavedeno kvůli textovým terminálům, které obvykle zobrazují 80 znaků na řádek. Většinou dochází k zalomení delších řádků ještě na straně MUA. Realita je taková, že mnoho MUA ani MTA tyto délky nerespektují. Faktem ale zůstává, že tělo zprávy smí při přenosu obsahovat pouze znaky v 7-bit US-ASCII kódování tedy omezený rozsah tisknutelných znaků, stejně jako hlavička. Pro anglicky mluvící uživatele to pro komunikaci dostačuje, ale např. v jazycích založených na latince se vyskytuje diakritika, která již pomocí 7 bitů zakódovat nelze. Rozšíření v tomto ohledu představuje rozšíření MIME (Multipurpose Internet Mail Extension, definované v sérii [RFC ]). MIME Rozšíření dovoluje přenášet: text v těle zpráv v jiné znakové sadě než US-ASCII, rozšiřitelnou množinu různých formátů v těle zpráv netextového typu, těla zpráv složená z více částí, informace v záhlavích v jiné znakové sadě než US-ASCII

15 2 Diplomová práce Je tedy možné přenášet zprávy psané cizojazyčně a posílat ve zprávě přílohy jako obrázky, prezentace, video soubory, apod. MIME je zároveň významné i pro protokol HTTP 1, kde pomocí Content-Type: záhlaví identifikuje server, jaká data klientovi posílá. Tělo MIME zprávy složené z více částí má strukturu stromu, jehož kořenem je část definovaná v hlavičce u a listy jsou vždy části non-multipart. To umožňuje vložení dalších složených (multipart) částí jako vnitřní uzly stromu. Typickým příkladem je zpráva obsahující výňatek webové stránky s obrázky, kterou je pak klient schopen zrekonstruovat do srozumitelné podoby. Nepovolené znaky v záhlaví jsou převedeny na tzv. kódované slovo (encoded word) ve tvaru =?charset?encoding?encodedtext?=, kde charset je libovolná registrovaná znaková sada (obvykle stejná jako v těle zprávy), encoding je buď Q, odpovídající kódování quoted-printable nebo B jako base64, encodedtext je zakódovaný text. Typický předmět zprávy s diakritikou Subject: Půjdeme na oběd? pak vypadá v hlavičce např. jako Subject: =?iso ?q?p=f9jdeme_na_ob=ecd=3f?= Množina MIME-multipart (tělo zprávy je rozdělena do více částí) má více kategorií, které specifikují vlastnosti částí zprávy a jejich vzájemné vazby. Základní kategorie jsou mixed, alternative, digest a parallel; minimální implementace vyžaduje alespoň mixed a digest. Ostatní jsou volitelné a jejich popis pokrývají samostatné RFC doporučení. Kategorie multipart/mixed je používána pro posílání souborů různých typů inline nebo jako příloh (v závislosti na záhlaví Content-Disposition:) a pokud není uvedeno jinak, implicitní typ jednotlivých částí je prostý text (text/plain). Naproti tomu kategorie multipart/digest slouží k posílání celých ů jako příloh, kde jednotlivé části jsou implicitně typu message/rfc822. Toto uspořádání je vhodné, pokud chce uživatel odeslat podezřelý /spam k analýze, protože přiložená zpráva je zachována v původní konzistenci, včetně jejích hlaviček. Při typickém přeposlání zprávy se totiž bere v potaz pouze tělo zprávy a pár základních informací ze záhlaví. Zajímavou kategorií je multipart/alternative, která říká MUA, že každá část zprávy je de facto stejná, pouze reprezentovaná v jiném formátu. Jednotlivé části jsou seřazeny podle jejich věrohodnosti (resp. přesnosti vůči originální informaci), od nejméně věrohodné až po nejvíce. MUA se při zpracování zprávy rozhodne podle podmínek a vhodnou část zobrazí. Typickým příkladem je zpráva ze dvou částí jedné ve formátu prostý text a druhé v HTML s odstavci, obarvením a různou velikostí písmen. Pokud klient disponuje pouze zobrazením v textovém režimu (např. terminál) nebo má preferované zobrazení zprávy v textové podobě, použije část typu prostý text, v opačném případě zobrazí verzi v HTML. Toho je často využíváno v nevyžádané poště, kdy spammer 2 do jedné části vloží smysluplný prostý text a do druhé HTML části své reklamní sdělení. Spam filtr, který analyzuje pouze obsah typu prostý text pak nemusí poznat, že se jedná o spam. Některé další kategorie budou zmíněny v kontextu následujících sekcích. V následujícím příkladu je znázorněna zpráva s tělem složeným z více částí, konkrétně text s přiloženým obrázkem ve formátu JPG s názvem point.jpg. 1 HyperText Transfer Protocol 2 Formální označení pro člověka rozesílajícího nevyžádanou poštu

16 2 Diplomová práce Hlavička obsahuje řádek Content-Type: multipart/mixed; boundary=zde-oddeleno který vyznačuje zprávu rozdělenou na více částí s oddělovacím řetězcem zde-odděleno. Výběr oddělovacího řetězce je v režii klienta a nesmí kolidovat s obsahem zprávy. Obvykle je volen dostatečně dlouhý náhodný řetězec. Tělo zprávy má strukturu Sdeleni pro uzivatele MIME nekompatibilnich klientu... --zde-oddeleno Content-type: text/plain; charset="iso " Content-Transfer-Encoding: quoted-printable Jestli m=e1=9a hlad, tak dej v=ecd=ect a m=f9=9eeme vyrazit. Nav=EDc pos=ed= l=e1m jeden =E8en=FD bod. J. --zde-oddeleno Content-Type: image/jpeg; name= point.jpg Content-Transfer-Encoding: base64 Content-Description: obrazek jednoho pixelu /9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcUFhYaHSUfG hsjhbywicwgiyynksopgr8tmc0omcuoksj/2wbdaqchbwoichmkchmoghyakcgokcgokcgokcgokcgokcgokc gokcgokcgokcgokcgokcgokcgokcgokcgokcgokcj/waarcaabaaedasiaahebaxeb/8qafqabaqaaaaaaaaa AAAAAAAAAAAP/xAAUEAEAAAAAAAAAAAAAAAAAAAAA/8QAFAEBAAAAAAAAAAAAAAAAAAAAAP/EABQRAQAAAAAA AAAAAAAAAAAAAAD/2gAMAwEAAhEDEQA/AKgA/9k= --zde-oddeleno-- Zde je dobře vidět oddělení jednotlivých částí a u každé z částí specifikované vlastnosti MIME obsahu. Textová část je zakódována jako quoted-printable, podřetězce začínající znakem = následovaným dvěma dalšími znaky jsou zakódované znaky s diakritikou. Poslední výskyt oddělovacího řetězce, zakončený dvěma pomlčkami navíc, indikuje konec MIME zprávy. Část před prvním výskytem oddělovače je ignorována a obvykle obsahuje informaci pro MIME nekompatibilní klienty. Tělo ové zprávy může - vzhledem ke stromové struktuře a mnoha typům obsahu MIME - nabývat docela komplexních podob. Tomu je třeba přizpůsobit i jeho zpracování při diagnostice, zda se jedná o nevyžádanou poštu. Ve své podstatě ale stačí několik málo funkcí pro dekódování obsahu zakódovaných částí a např. rekurzivní procházení jednotlivých částí do určité hloubky. 2.4 Protokoly pro správu pošty Pro práci s elektronickou poštou jsou v podstatě zapotřebí dva, resp. tři aplikační protokoly na textové bázi nad TCP/IP spojením. Jsou to protokoly SMTP, který zajišťuje přenos zpráv mezi počítači, POP, který slouží pro stahování došlých zpráv ze serveru k uživateli a v poslední řadě protokol IMAP, jenž umožňuje práci s poštou přímo na serveru. Společným rysem těchto protokolů je mj. princip spojení typu klient-server. Komunikace probíhá tak, že klient na server vysílá žádosti (příkazy), resp. data, a server posílá zpět odpovědi. Příkazy klienta jsou většinou necitlivé na velikost písmen. Odpovědi serveru většinou obsahují na začátku řádku číslo, udávající stav nebo výsledek provedení příkazu s doplňujícím textem, nebo v případě protokolu POP3 pouze indikaci pozitivní a negativní odpovědi. Textová báze protokolů se vyznačuje tím, že všechny informace během komunikace putují jako text tisknutelné znaky a každá řádka je ukončena párem znaků <CR><LF> 1. 1 Carriage Return + Line Feed; typické ukončení řádky pro systémy typu DOS

17 2 Diplomová práce V dalším textu bude použito několik zkratek sloužící pro označení programů pracujících s poštou, které nyní vysvětlím. MUA (Mail User Agent) - poštovní program, ve kterém uživatel sestavuje zprávu a odesílá ji na server, případně umožňuje uživateli zprávy stahovat a číst (Outlook, The Bat, pine, apod.) MTA (Mail Transport Agent) - komplexní program (smtp/mail server) zajišťující doručení zprávy na cílovou adresu, případně. (Sendmail, Postfix, aj.) MDA (Mail Delivery Agent) program, jenž přebírá zprávy od lokálního MTA, dále je třídí, přeposílá apod. (např. Procmail) SMTP (Simple Mail Transfer Protocol) SMTP je relativně jednoduchý protokol a je v současnosti základním protokolem pro přenos elektronické pošty. V první specifikaci byl uveden v [RFC 821] a později doplněn v [RFC 2821]. Jeho důležitou vlastností je tzv. předávání ů (mail relaying) v síti Internet, mezi vzájemně dostupnými počítači přes spojení TCP/IP v lokálních sítích, případně mezi jinými počítači, které nevyužívají protokoly postavené na transportní vrstvě TCP. V souvislosti s předáváním ů je důležitý pojem obálka (envelope). Je to datová struktura, kterou uchovává server pro své potřeby po dobu zpracování zprávy a slouží k jejímu směrování. Skládá se z údaje odesilatel (reverse-path) a příjemci (forward-path). Odesilatel na obálce určuje opravdového odesilatele u, nezávisle na obsahu záhlaví From: apod. Příjemci určují všechny adresy, na které bude zpráva odeslána. Obálka je generována v průběhu komunikace mezi klientem a serverem na základě příkazů MAIL, RCPT a RSET. Podle principu komunikace zmíněného výše musí server na všechny příkazy klienta odpovědět tříciferným kódem status provedení příkazu - následovaným dalšími informacemi. Význam číselných odpovědí by se dal shrnout do tří kategorií: přijetí hodnota dočasné odmítnutí hodnota permanentní odmítnutí hodnota Ne všechny hodnoty odpovědí jsou v rozsahu obsazeny. Chování v závislosti na odpovědích podrobně popisuje [RFC 2821] v sekci 4.2. Příkazy SMTP protokolu: HELO HELO name Pozdrav Hello slouží k identifikaci klienta po připojení na server. Systém a klient se tímto způsobem dohodnou, že jsou oba v iniciálním stavu a teprve poté mohou pokračovat v ostatních transakcích. Jako argument name je předáváno úplné doménové jméno klienta. Pokud počítač žádné smysluplné jméno nemá (např. kvůli dynamicky přiřazené IP adrese), musí se identifikovat svojí numerickou IP adresou v hranatých závorkách. Server odpovídá odezvou (250) následovanou svým doménovým jménem. EHLO EHLO name Pokud klient podporuje rozšířený SMTP protokol (ESMTP), pak se ohlásí pomocí EHLO a v případě negativní odpovědi by měl vyzkoušet původní HELO. Většina soudobých SMTP serverů podporuje obě varianty. Rozdíl spočívá v tom, že v odpovědi na EHLO vrací server seznam implementovaných příkazů z ESMTP protokolu a například také maximální velikost zprávy, kterou je schopen přijmout

18 2 Diplomová práce V tomto stádiu je možné odhalit potencionální zneužití služby. Pokud se klient ohlásí jako někdo jiný než ve skutečnosti je, za pomoci DNS dotazu to lze snadno zjistit. Stejně tak pokud uvede neplatnou adresu. MAIL MAIL FROM: <reverse-path> [parametry] Příkaz začíná transakci zprávy. Reverse-path udává ovou adresu (povinně ve špičatých závorkách), odkud zpráva přišla a MTA na jejím základě nastaví odesilatele na obálce. Za určitých okolností může být hodnota argumentu nulová ( <> ), pokud se jedná o odmítnutou zprávu, aby nedošlo k zacyklení. Nepovinné parametry sdělují dodatečné informace o zprávě, např. že přenos bude probíhat v 8-bitovém kódování. Příkaz by měl být vyslán pouze tehdy, když není zpracovávána jiná zpráva, neboť maže údaje na obálce. RCPT RCPT TO:<forward-path> [parametry] Zapisuje na obálku příjemce zprávy uvedeného v parametru forward-path. Pokud je příjemců více, posílá klient příkaz opakovaně. Volitelně je možné specifikovat i cestu, přes které hostitele bude zpráva předávána (viz [RFC 2821], sekce ). DATA DATA Po odeslání příkazu a pozitivní odpovědi (354) server považuje vše následující od klienta za data u (tedy hlavičku a tělo). Data by měla obsahovat pouze znaky v 7-bit ASCII kódování. Sekvence <CR><LF>.<CR><LF>, tedy samotná tečka na ukončeném řádku, indikuje konec dat. Poté co server tuto sekvenci obdrží, dochází ke zpracování celé zprávy. RSET RSET Slouží ke zrušení aktuální transakce zprávy. Všechny informace z obálky musí být vymazány, vrácena pozitivní odpověď (250) a server se vrací do počátečního stavu jako po vyslání EHLO/HELO příkazu. Odeslání příkazu RSET bezprostředně po HELO má ve výsledku stejný efekt jako příkaz NOOP, neboť obálka ještě není naplněna. VRFY VRFY string Tímto příkazem odesilatel ověřuje, je-li parametr string uživatelským jménem nebo názvem schránky na serveru. String má podobu User Name <local-part@domain> nebo local-part@domain. Návratová hodnota je buď pozitivní (250) a obsahuje uživatelské jméno a adresu schránky nebo pouze adresu, případně negativní (55X) s vysvětlením nesrovnalosti. [BERN1] doporučuje odeslání neutrální odpovědi (252) s obecným textem z bezpečnostních důvodů, neboť tento příkaz může být zneužit pro získání ových adres ze serveru (příkaz VRFY * by měl vyvolat odpověď se seznamem všech uživatelů serveru). EXPN EXPN string Dotaz, zda je argument string mailing listem 1. Jde o obdobu příkazu VRFY. Odpověď může být víceřádková, obsahující všechny osoby z dotazovaného seznamu. NOOP NOOP [string] Příkaz se používá k udržení spojení při životě a nemá žádný vliv na ostatní operace. Volitelný parametr je serverem ignorován a pokaždé vrácena pozitivní odpověď. QUIT QUIT Indikuje, že odesilatel končí přenos a protistrana (server) musí odeslat odpověď a následně uzavřít spojení. Klient musí počkat, dokud od serveru nepřijde odpověď. Příkaz může být použit kdykoliv a v souvislosti s ním jsou přerušeny všechny probíhající transakce. V minimální nutné implementaci jsou podporovány příkazy EHLO, HELO, MAIL, RCPT, DATA, RSET, NOOP, QUIT a VRFY. Pro celý mechanismus odeslání zprávy však více méně dostačují HELO, MAIL, RCPT, DATA a QUIT. Činnost protokolu by se dala v zásadě rozdělit do fáze MUA-MTA, kdy je odeslána pošta z počítače uživatele na SMTP server odchozí pošty, a fáze MTA-MTA, ve které dochází k vlastnímu směrování zprávy do cíle. Ve fázi MTA-MTA se vlastně jedná o spojení serveru se 1 Seznam uživatelů, resp. ových adres, kteří spadají do konkrétní skupiny adresátů příchozí pošty

19 2 Diplomová práce serverem, ale jako klient se chová server, který předává . Doplňující fázi MTA-MUA pokrývá následně zmíněný protokol POP3. Následující obrázek znázorňuje cestu zprávy v běžném případě. Uživatel dozorce pracuje v zoologické zahradě a jeho počítač má přiděleno jméno dozor.zoo.cz. Napsal svému kolegovi, který je na stáži v Německu a má účet na serveru tier.de. Doména odesilatele a příjemce je barevně odlišena. Sekvence operací, které proběhnou během zaslání zprávy je popsána následujícími body: 1) Přenos zprávy pomocí protokolu SMTP od uživatele na server v doméně ZOO.CZ (MUA-MTA) 2) DNS dotaz typu MX, kde se SMTP server dotazuje na server pro výměnu pošty v doméně TIER.DE 3) v odpovědi je vrácen seznam MX serverů asociovaných s doménou TIER.DE 4) SMTP přenos zprávy mezi servery (MTA-MTA) 5) stažení zprávy pomocí protokolu POP3 ze serveru k uživateli. Obrázek 2-1: Běžný přenos zprávy Fáze MUA-MTA Uživatel napíše ve svém MUA zprávu a odesílá ji adresátovi. MUA se tedy naváže spojení se SMTP serverem naslouchajícím na TCP portu 25. Před vlastním odesláním MUA sestaví základní podobu hlavičky u a předá ho serveru. V momentě, kdy server úspěšně přijme zprávu, všechny další operace probíhají již mimo režii MUA. V závislosti na své konfiguraci provede MTA přepis adres a přidá další záznamy do hlavičky. Pošta pro lokální počítač (uživatele) se uloží do příslušného mailboxu a čeká na vyzvednutí adresátem. Zprávy adresované mimo doménu se zařadí do fronty pro odchozí poštu. Tato fronta je v pravidelných intervalech kontrolována a mailserver se pokouší zprávu odeslat. Po úspěšném pokusu je zpráva z fronty odstraněna, případně při odpovědi pokouší maily odeslat. Pokud se zprávu podaří odeslat, je z fronty odstraněna. V opačném případě je zaslána odesílateli zpráva o chybě a dle nastavení časové lhůty (obvykle v řádu desítek hodin až dnů) se server dále snaží zprávu odeslat. Pokud se to nepodaří, pošle server odesílateli zprávu o nedoručitelnosti a zprávu z fronty odstraní

20 2 Diplomová práce Obrázek 2-2: SMTP fáze MUA-MTA Výpis komunikace mezi klientem (MUA) a SMTP serverem (MTA) může vypadat např. takto: S: 220 smtp.zoo.cz ESMTP Postfix C: HELO dozor.zoo.cz S: 250 Hello dozor C: MAIL FROM:<dozor@zoo.de> S: 250 Ok C: RCPT TO:<kollege@tier.de> S: 250 Ok C: DATA S: 354 End data with <CR><LF>.<CR><LF> C: From: dozor@zoo.cz C: To: kollege@tier.de C: Subject: pozdrav C: Date: Thu, 21 Nov :10: C: C: Bud zdrav. C: Jenom jsem se chtel zeptat, jak se ti dari. C: Franta C:. S: 250 Ok: queued as C: QUIT S: 221 Bye Nyní se zaměříme na hlavičku zprávy: From: dozor@zoo.cz To: kollege@tier.de Subject: pozdrav X-Mailer: The Bat v2.78 jsou záhlaví ve zprávě v momentě, kdy odchází z počítače dozor.zoo.cz; po přijetí serverem smtp.zoo.cz bude hlavička vypadat přibližně následovně: Received: from dozor.zoo.cz (dozor.zoo.cz [ ]) by smtp.zoo.cz (8.8.5) id 004A21; Thu, 21 Nov :10: From: dozor@zoo.cz To: kollege@tier.de Subject: pozdrav Date: Thu, 21 Nov :10: Message-Id: < @smtp.zoo.cz> X-Mailer: The Bat v2.78 Fáze MTA-MTA Poté, co došlo k předání zprávy serveru smtp.zoo.cz, se server snaží doručit zprávu do cílové adresy. Z ové adresy příjemce separuje doménovou část a provede DNS dotaz na name server v této doméně. Dotaz je typu MX (mail exchange) a v odpovědi jsou vráceny názvy všech serverů pro zpracování pošty, jako plně kvalifikovaná doménová jména, spolu s jejich prioritou. Viz ilustrační výpis získaný příkazem dig. Zvýrazněná část říká, že v cílovém systému jsou dva mail servery s prioritou 10 a 20. Čím nižší číslo, tím vyšší priorita

21 2 Diplomová práce tier.de IN MX 10 mx.tier.de. tier.de IN MX 20 mx2.tier.de. Smtp.zoo.cz naváže spojení s cílovým serverem vyšší priority a pokusí se mu doručit zprávu. Pokud se mu to nepodaří, zkusí použít server s nižší prioritou. Pokud by v DNS tabulce nebyl žádný MX záznam, pokusí se MTA o doručení přímo na IP adresu počítače tier.de, která odpovídá tzv. A záznamu v tabulce DNS (viz [RFC 2821], sekce 5.). Komunikace mezi SMTP servery je pak obdobná situaci, kdy MUA posílá data svému lokálnímu MTA. Přijímající MTA na straně tier.de může být zároveň POP3 serverem, ze kterého může zprávy uživatel číst. Pokud se nejedná o tentýž počítač, dochází ještě k zapsání zprávy na POP3 server. Obrázek 2-3: MTA-MTA fáze Když mx.tier.de dokončí zpracování zprávy a uloží ji pro uživatele k vyzvednutí, hlavička došlé zprávy má následující tvar: Received: from smtp.zoo.cz (smtp.zoo.cz [ ]) by mx.tier.de (8.8.5/8.7.2) with ESMTP id LAA20869 for <kollege@tier.de>; Thu, 21 Nov :12: Received: from dozor.zoo.cz (dozor.zoo.cz [ ]) by smtp.zoo.cz (8.8.5) id 004A21; Thu, 21 Nov :10: From: dozor@zoo.cz To: kollege@tier.de Date: Thu, 21 Nov :10: Message-Id: < @smtp.zoo.cz> X-Mailer: The Bat v2.78 Subject: pozdrav Tento poslední soubor hlaviček je ten, který vidí uživatel kollege ve zprávě, když si jí stáhne a přečte. Následuje podrobnější vysvětlení některých záhlaví: Received: from smtp.zoo.cz (smtp.zoo.cz [ ]) Tento byl přijat od počítače s názvem smtp.zoo.cz, který se ve skutečnosti jmenuje smtp.zoo.cz (tj. identifikoval se správně) a má IP adresu by mx.tier.de (8.8.5/8.7.2) with ESMTP id LAA20869 Stroj, který zprávu přijal - mx.tier.de - použil pro zpracování pošty program Sendmail, verze 8.8.5/ Zpráva byla přijata s pomocí ESMTP, server jí přiřadil ID (identifikační číslo) LAA To slouží pro interní použití, aby mohl administrátor dohledat zprávu v logsouborech. for <kollege@tier.de>;

22 2 Diplomová práce Zpráva byla adresována Mějme na paměti, že tento hlavičkový údaj nemá spojitost s To: řádkou (viz sekce Whatever). Thu, 21 Nov :12: Poštovní přenos se uskutečnil ve čtvrtek (Thursday), 21. listopadu (21 Nov) 2006, v 11:12:18 středoevropského času. Received: from dozor.zoo.cz (dozor.zoo.cz [ ]) by smtp.zoo.cz (8.8.5) id 004A21; Thu, 21 Nov :10: (PST) Tento řádek dokumentuje předání u z dozor.zoo.cz (pracovní stanice dozorce) do smtp.zoo.cz; Stroj odesílající zprávu se ohlásil jako dozor.zoo.cz, což je pravdivá informace, a jeho IP adresa je Na mail serveru běží program sendmail verze 8.8.5, a pro vnitřní použití přiřadil dopisu ID číslo 004A21. Message-Id: < @smtp.zoo.cz> Zprávě bylo přiřazeno toto ID (strojem smtp.zoo.cz), aby jí bylo možno identifikovat. To se ovšem liší od SMTP a ESMTP ID čísel v položce Received:, protože je přiřazeno zprávě po celou dobu její existence, narozdíl od ostatních ID, které jsou asociované pouze se specifickou poštovní transakcí na konkrétním stroji a nemají žádný význam pro jakýkoliv jiný počítač. Mailgate a firewall Rád bych zmínil ještě několik nestandardních případů, kdy je cesta zprávy komplikovanější, doplněné pro názornost schématem. Mailgate v případě větších podniků s rozsáhlejší sítí může existovat více lokálních serverů, které obsluhují elektronickou poštu pro pobočky v jednotlivých městech (v případě zoo.cz např. MTA1 v Praze a MTA2 v Brně) a veškerá pošta z podnikové sítě odchází přes jeden nadřazený server. Obdobně pro příchozí poštu provede tento server rozhodnutí, na který vnitřní server zpráva dále poputuje. Firewall z bezpečnostních důvodů zprostředkovává komunikaci mezi lokální podnikovou sítí a Internetem stroj nazývaný firewall. Zvenku se všechny počítače ve vnitřní síti jeví jako by měly IP adresu firewallu. Na tomto stroji mohou také fungovat služby pro filtrování pošty a antivirovou kontrolu. Obrázek 2-4: Mailgate a Firewall