Doručitelnost ů

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Doručitelnost ů DIPLOMOVÁ PRÁCE Richard Šůstek Brno, jaro 2015

2 Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Richard Šůstek Vedoucí práce: doc. RNDr. Vlastislav Dohnal, Ph.D. ii

3 Poděkování Na tomto místě bych rád poděkoval vedoucímu této práce, doc. RNDr. Vlastislavu Dohnalovi, Ph.D za odborné konzultace a vstřícnost, kterou mi věnoval. Dále bych chtěl poděkovat panu Vítězslavu Janečkovi z firmy Kentico software, s.r.o. za poskytnutí velmi užitečných rad a informací z praxe, které jako Product owner pro On-line marketing získal. V poslední řadě bych chtěl poděkovat své přítelkyni za její trpělivost a podporu, které si velmi cením. iii

4 Shrnutí Práce se věnuje doručitelnosti ů a faktorům, které ji ovlivňují. V práci jsou rozebrány způsoby, které lze aplikovat pro její zlepšení. V teoretické části je také navržen systém, který lze použít při vytváření aplikace spravující ové kampaně a jejich odběratele. Tento systém pomůže vývojářům rozšířit stávající systém o nové nápady, které pomohou zvýšit doručitelnost a zlepší práci s odběrateli. Součástí práce je také implementace vlastního modulu v CMS systému Kentico, ve kterém je provedena integrace s jedním z největších ESP - SendGridem. iv

5 Klíčová slova Doručitelnost ů, reputace, autentizace, spam, spam filtr, Send- Grid, Kentico CMS v

6 Obsah 1 Úvod Reputace Reputace IP adresy Míra stížností Past na spamy Recyklované pasti Klasické pasti Podvržené pasti Doporučení Neznámí uživatelé Počet odesílaných ů Konzistence v odesílání ů Blacklisty Whitelisty Autentizace Reputace domény Měření reputace SenderScore SenderBase Doporučení Budování reputace Autentizace Motivace a klasické útoky Autentizační metody ISP a využití autentizačních metod DKIM Prvky Princip Výhody a nevýhody Shrnutí DomainKeys Shrnutí SPF Princip Syntaxe vi

7 3.5.3 Shrnutí SenderID Shrnutí Filtrování podle obsahu Analýza hlavičky u Analýza těla u Bayesův spam filtr Existující ové filtry Typy ových filtrů Serverové filtry SpamAssassin Anti-Spam SMTP Proxy Server Lokální filtry Thunderbird Outlook Zlepšování doručitelnosti na straně aplikace Motivace Získávání odběratelů Opt-out Opt-in Confirmed opt-in Double opt-in Shrnutí Udržování seznamu odběratelů Odstraňování neexistujících ových adres Odstraňování neaktivních odběratelů Frekvence odesílání ů Preference uživatelů a typy ů Kontrola HTML Kontrola verzí u Workflow Vyhodnocování kampaní Naplnění práva Česká republika USA Shrnutí Implementace modulu v Kentico CMS SendGrid vii

8 7.2 Integrace s Kentico CMS Architektura modulu Synchronizace a implementace Event notification Spam checker Google analytics Domain Keys Address whitelist BCC Click/open tracking Shrnutí Závěr Literatura A Seznam elektronických příloh viii

9 Seznam obrázků 2.1 y označené za spam Schéma FBL Blacklist Výsledek dotazu na DKIM záznam Výsledek dotazu na SPF záznam Rozhraní aplikace MxToolBox SenderID Filtrovaní ů Ukázka filtrovacího pravidla v aplikaci Thunderbird Nastavení frekvence odesílání ů u Bonobos Architektura modulu Ukázka synchronizovaného nastavení Ukázka desynchronizovaného nastavení Ukázka možností nastavení Event notification aplikace Ukázka šablony pro bounce notifikaci Ukázka první části spam reportu Ukázka druhé části spam reportu ix

10 1 Úvod V této diplomové práci se budu zabývat problematikou doručitelnosti ových zpráv. V dnešní době tvoří většinu světové ové komunikace nevyžádaná pošta (spam). Jejich poměr se často uvádí v rozmezí 80-95%. Stále se hledají nové techniky pro zachycení spamu a propuštění legitimního u. Následkem toho je stále složitější odeslat tak, aby byl skutečně doručen svému příjemci. Problém to může být jak pro malé, tak zejména pro velké firmy odesílající velké množství ů. Nicméně, at už jednotlivci nebo firmy, které využívají ovou komunikaci, chtějí dosáhnout toho, aby co nejvíce jejich ů bylo správně doručeno. Cílem práce je proto rozebrat nejdůležitější faktory ovlivňujících doručitelnost, navrhnout sadu doporučení a systém, který lze aplikovat pro dosažení co nejvyšší doručitelnosti. Součástí je i implementace vlastního modulu pro Kentico CMS, ve kterém aplikuji vybrané techniky, které vylepší současný stav systému a pomohou uživatelům dosáhnout lepší doručitelnosti. Téma jsem si vybral zejména z důvodu jeho aktuálnosti a množství rozličných způsobů, které lze využít pro zlepšení doručitelnosti. Spousta těchto technik je, dle mého názoru, také opomíjena i přesto, že jejich význam pro doručitelnost je velký. Lze také předpokládat, že zájem o tyto techniky bude růst z důvodu stále rostoucího významu ové komunikace a ového marketingu. V teoretické části se budu nejprve věnovat třem základním faktorům ovlivňující doručitelnost. Těmi jsou reputace (kap. 2), autentizace (kap. 3) a obsahové filtrování (kap. 4). Pozornost budu věnovat nejen jejich významu, ale i výhodám, nevýhodám a doporučením. V další části rozeberu typy ových filtrů a principy jejich fungování (kap. 5). Poslední teoretická část je věnována navržení systému, který lze aplikovat při vývoji aplikace spravující odběratele a ové kampaně (kap. 6). Příkladem takové aplikace jsou zejména CMS systémy. V praktické části pak popíšu implementaci vlastního modulu a jeho funkce (kap. 7). 1

11 2 Reputace V této kapitole se zaměřím na reputaci, která ve světě u znamená vlastně to, jak určitou doménu 1 nebo IP adresu, ze které jsou odesílány y, vidí ISP (Internet service provider poskytovatel připojení k internetu) a jaký to má vliv na doručitelnost ů. Dále rozeberu nejdůležitější faktory, které ovlivňují reputaci a způsoby, jakými můžeme reputaci měřit a budovat. Významné společnosti poskytující ové služby, jako je SendGrid 2 nebo Return Path, se shodují na tom, že reputace je zdaleka nejvýznamnější faktor ovlivňující to, zda bude přijat ISP příjemcem a to, zda skončí v ové schránce příjemce nebo bude zahozen. Proto je velmi důležité vědět, jakým způsobem reputace ovlivňuje doručitelnost ů, zejména v případech, kdy jde o odesílání velkého počtu ů (desetitisíce měsíčně a více), z důvodu, že jednotliví ISP si uchovávají statistiky přijímaných ů a čím více jich je, tím více jsou obezřetní. Cílem všech ISP je filtrovat nevyžádanou poštu a propustit pouze legitimní y. 2.1 Reputace IP adresy Reputace IP adresy, jak její název sám napovídá, je reputace konkrétního serveru s danou IP adresou, který je zodpovědný za odeslání daného u. Každý přijímaný musí vždy projít přes ISP příjemce, který automaticky zaznamenává informace o u a jeho původu. Na základě řady metrik tento ISP ohodnotí odesílatele u a bud propustí dál (často k dalšímu filtrování), nebo jej úplně zahodí. Mezi tyto metriky patří zejména: míra stížností, past na spamy, 1. V případě ové adresy simpleaddress@example.com je doménou vše za zavináčem. V tomto případě bude doménou example.com 2. SendGrid je zodpovědný za 2% veškeré ové komunikace na světě, měsíčně odešle přes 14 miliard ů 2

12 2. REPUTACE SenderScore Přijaté y % % % % % % % % % % Tabulka 2.1: Doručitelnost dle SenderScore neznámí uživatelé, počet odesílaných ů, konzistence v odesílání ů, blacklisty, whitelisty a autentizace. Tyto metriky budou podrobněji rozebrány v následujících podkapitolách. Výzkum [5] společnosti Return Path zjistil, že y odesílané z IP adres, které mají nízkou reputaci, se ani nedostanou k dalšímu filtrování nebo verifikace entity (autentizace) a jsou často ihned zahozeny. V tabulce 2.1 je možné vidět, jak výše reputace ovlivňuje přijetí 3 u. Výzkum také ukázal, že téměř žádný legitimní nepochází od odesílatelů, kteří mají SenderScore menší než 71. Na druhou stránku 14% ze všech ů je odesláno těmi nejlepšími odesílateli se SenderScore Pouze 0.03% z nich je označeno za spam 3. Inbox placement rate 3

13 2. REPUTACE a celkem 98% je doručeno svým příjemcům. Z tohoto důvodu považuji za důležité zajímat se o SenderScore a pravidelně jej kontrolovat. Dále se v této práci zaměřím na techniky, které pomohou udržet toto skóre vysoké. Na obrázku 2.1 lze vidět, že pouze nejlepší odesílatelé zdaleka převyšují ty, kteří mají skóre jen o něco nižší (95-98). Cílem by tedy mělo být dosažení maximálního skóre, kterým je a tohle si dlouhodobě udržet, protože i sebemenší odchylky se mohou projevit v mnohonásobně nižší doručitelnosti ů. Obrázek 2.1: y označené za spam zdroj: [5] Míra stížností Stížnosti jsou relevantní pouze v případech, kdy skutečně dorazí do schránky svého příjemce a ten jej z vlastní vůle označí za spam nebo nevyžádanou poštu. Tento způsob se označuje jako FBL (Feedback loop nebo Complaint feedback loop). FBL dává uživateli možnost bud přímo ze své ové schránky, přes telefon, nebo pomocí jiné formy technické podpory označit (nutno podotknout, 4

14 2. REPUTACE že forma označování jinou formou než v rámci ové schránky bude dnes minimální) příchozí za nevyžádanou poštu svému ISP/ESP, který pak odešle informace o této stížnosti odesílateli e- mailu. Kromě toho, že označování ů za spam má vliv na reputaci odesílatele, jde zároveň i o velmi prospěšný způsob, jak může odesílatel ů monitorovat úspěšnost své kampaně a případně odebrat ty ové adresy, jejichž majitelé odeslali stížnost. Díky tomu už v budoucnu nebudou tomuto uživateli žádné další y odesílány. Pokud by tento uživatel nebyl odstraněn, je zde riziko, že bude znova zasílat stížnost, která uživatele poškodí. V dnešní době Feedback loop podporuje většina velkých poskytovatelů ových schránek 4. Obrázek 2.2: Schéma FBL zdroj: vlastní Obrázek2.2 znázorňuje schéma fungování FBL. Prvním krokem je registrace odesílatele u u jednotlivých ISP nebo poskytovatelů ových služeb, kteří podporují Feedback loop. Osobně bych doporučil se registrovat zejména u těch poskytovatelů, kteří zastupují většinu vlastních kontaktů. V případě komerčních nebo komunitních subjektů to může být nejčastěji Gmail, AOL, Yahoo a Seznam.cz z českých zástupců. Po úspěšné registraci bude poskytovatel odesílat veškeré stížnosti, které podá uživatel ové schránky od daného odesílatele zpět odesílateli ve speciálním formátu ARF. ARF, neboli Abuse reporting format, je standardní formát pro FBL, který jako první definoval Yakov Shafranovich v dubnu 2005 [6], 4. Mezi tyto patří: AOL, Gmail, Yahoo, Hotmail, Comcast, Seznam, Mail.ru, Fastmail, Terra, Synacor a další 5

15 2. REPUTACE který se vyvinul v dnes nejčastěji používaný standard RFC Tento standard přinesl zavedení nového MIME 5 typu: multipart/report Past na spamy Pasti na spamy (anglicky spam traps ) označují ové adresy, které využívá mnoho anti-spamových a jiných organizací pohybujících se v oblastech bezpečnosti k identifikaci spamu a především jeho původce. Často je lze nalézt i pod pojmem Honeypot [7]. Tato ová adresa není používána žádným skutečným uživatelem, ale je aktivně monitorována. Veškerý přijatý je považován za nevyžádaný, protože se jeho vlastník nepřihlásil k žádnému odběru zpráv. Podle toho, jakým způsobem dojde ke vzniku takové ové adresy, můžeme rozdělit past na spamy do 3 základních kategorií [8]: recyklované pasti, klasické pasti a podvržené pasti Recyklované pasti Pod tuto kategorii patří ové adresy, které byly založeny za řádným účelem používání, ale z nějakého důvodu se jejich majitel rozhodl je zrušit. Typickým příkladem může být firemní ová adresa, jako např. RichardS@companyA.com. V okamžiku, kdy uživatel RichardS odejde ze společnosti CompanyA, jeho ová adresa je zrušena. Pokud na takovou ovou adresu přijde e- mail, ISP jej nedoručí a pošle tzv. hard bounce zpět odesílateli se zprávou, že se jedná o nenalezenou ovou adresu. V ideálním případě by měl původce u ihned po přijetí zprávy odstranit tuto ovou adresu ze svého seznamu odběratelů tak, aby v budoucnu již nebyly na tuto adresu odesílány žádné y. 5. Multi-purpose internet mail extensions - protokol umožňující používat diakritiku, digitální podpisy nebo přidávat soubory k elektronické poště. Dnes tento protokol využívají i další protokoly a aplikace (například HTTP). 6

16 2. REPUTACE V určitém okamžiku se ISP může rozhodnout, že ovou adresu opět aktivuje a dovolí ji přijímat y. Tímto okamžikem ji v podstatě konvertují na recyklovanou past, protože očekávají, že e- maily doručené na tuto adresu jsou nevyžádané, nebo odesílatelé nerespektují odstranění této adresy po přijetí hard bounce. Neexistuje standardizovaná doba, po jaké může být adresa konvertována v past, ale běžně se předpokládá prodleva alespoň 12 měsíců [9], aby měli případní administrátoři/systémy dostatek času ovou adresu odstranit ze svých kontaktů. y, které budou opakovaně odesílány na tuto adresu, značí špatnou práci s udržováním vlastních odběratelů, nebo mohou poukazovat na nekalé praktiky, nebo například skupovaní ových adres. Vzhledem k faktu, že není možné zjistit, která ová adresa zastává funkci spamové pasti, je třeba dbát na to, abychom udržovali čistý 6 seznam ových adres a pravidelně odstraňovali neaktivní odběratele Klasické pasti Klasické pasti označují ty ové adresy, které byly založeny přímo za účelem lákat potenciální spammery. Tyto adresy nebyly nikdy používány žádným uživatelem a nebyly přihlášeny k žádnému odběru ových zpráv (tzv. newsletter) a díky tomu se veškerý , který na tuto adresu přijde, považuje za spam a velmi výrazně snižuje reputaci jeho odesílatele. Studie [10] provedená na tohle téma poukázala na to, že jeden odeslaný do takové pasti může způsobit snížení SenderScore 7 až o více jak 20 bodů a snížení počtu doručených ů na 81% a méně. Někteří ISP mohou také přidat IP adresy odesílatele na některý z blacklistů a tím ještě více poškodit reputaci odesílatele. 6. Čistým seznamem ových adres je myšlen seznam, který obsahuje pouze ové adresy uživatelů, kteří mají zájem dostávat y a vykazují určitou formu aktivity. 7. Sender s score je systém ohodnocení jednotlivých IP adres dle jejich reputace v rozmezí od Čím větší je reputace, tím roste šance na doručení u 7

17 2. REPUTACE Podvržené pasti Tyto ové adresy byly, stejně jako klasické pasti, vytvořeny přímo za tímto účelem, ale na rozdíl od nich byly zveřejněny na určitých webových stránkách, kde čekají, než je nějaký automatický robot přečte a uloží. Tyto ové adresy často bývají skryty tak, že je může vidět pouze někdo, kdo zkoumá zdrojový kód webové stránky 8, ale není to pravidlem. Častou praktikou mohou být jednoduché podvodné webové stránky, na kterých je tato ová adresa použita Doporučení Neexistuje stoprocentní sada instrukcí, která by zaručila, že y neskončí v těchto pastích, ale je zde několik doporučení, která mohou významně snížit tohle riziko. Mezi tato doporučení patří: odmítání nesprávných ových adres ( me@@mail.uk, richards[neco]gmail.net apod.) adres, odmítání pracovních a generických adres ( sales@company.com, it@company.com ), zasílání uvítacích zpráv s potvrzujícím odkazem. Po potvrzení si můžeme být jisti, že daná adresa je skutečná a její uživatel vynaložil úsilí k jejímu potvrzení. Tento způsob se také nazývá Double opt-in a bude probrán podrobněji dále v této práci. Je také doporučeno odesílat tyto y z jiného serveru (IP adresy) než ten, který se používá k odesílání komerčních zpráv, aby nedocházelo ke zbytečnému snižování reputace u neexistujících adres, používání CAPTCHA při přijímání ových adres z online formulářů, poskytování možnosti uživateli změnit ovou adresu, 8. Skrýt určité elementy na webové stránce je velmi jednoduché použitím vhodných CSS stylů, jako např. display:none. 8

18 nekupování a nepoužívání ových adres od třetích stran. 2. REPUTACE Ze seznamu lze odvodit, že v podstatě všechna tato doporučení může implementovat prakticky kdokoliv. Je čistě na správci systému, aby vzal do úvahy výše uvedené věci a vyhnul se tak případným problémům se ztracenými a nedoručenými y Neznámí uživatelé Neznámí uživatelé (anglicky unknown users ) označují podíl nenalezených uživatelů (resp. jejich ových adres) a celkového množství odesílaných ů. Za problematickou hodnotu podílu nenalezených uživatelů se považuje 1% z celkového počtu odeslaných ů [10]. Velký podíl neznámých uživatelů může svědčit zejména o špatné tvorbě a udržovatelnosti seznamu odběratelů. Z tabulky2.1 vyplývá, že čím větší je podíl neznámých uživatelů, tím je zpravidla menší výsledná reputace subjektu. Nelze zde najít přesnou korelaci, protože zde vstupuje mnoho dalších faktorů, ale jde z toho jednoduše odvodit, že ti, kdo mají velkou reputaci, mají zároveň nízkou míru nevalidních ů. Může to být dáno například tím, že takový subjekt vyžaduje ověření ových adres (viz. Double opt-in) a dále spravuje své uživatele. V případě nenalezení uživatele je SMTP serverem vrácena zpravidla zpráva s kódem 5xx, kde xx označuje konkrétní chybu. Problémem je, že každý ISP je unikátní a tyto kódy se mohou lišit. Přehled základních kódů lze nalézt například v dokumentaci SendGridu [11] Počet odesílaných ů To, kolik ů odesíláme je, často stejně důležité jako jejich obsah. ISP, kteří zpracovávají y, je uchovávají a analyzují. To, jak často a v jakém množství jsou y odesílány, je jeden z faktorů, které ISP pozorně kontrolují. Cílem je nalézt určitou konzistenci v tom, jak často budou y rozesílány. V případě, že měsíc neodešleme ani jeden a pak se 9

19 2. REPUTACE najednou rozhodneme odeslat ů v rámci nové kampaně, je dost možné, že nás někteří ISP budou považovat za spammery a nepropustí tyto y dál ke svým příjemcům. To, zda e- mail bude přijat nebo ne v tomto kontextu, závisí především na jeho reputaci, kterou si ale musíme předem vybudovat. Z tohoto důvodu se často můžeme setkat s termínem IP warming, který označuje postupný proces, kdy odesíláme pouze určité množství ů za určitou časovou jednotku (zpravidla den) z konkrétní IP adresy. Cílem takového procesu je stát se legitimním odesílatelem v očích ISP. Pokud plánujeme odesílat měsíčně méně než ů, neměli bychom upoutat zvýšenou pozornost ISP, ale pokud toto množství budeme výrazně převyšovat, je doporučeno y rozdělit na několik částí [12]. V případě, že se rozhodneme využít IP warming, je nutné si předem spočítat, jaké množství budeme odesílat. Neexistuje žádné přesné číslo nebo poměr, který bychom mohli využít, ale můžeme se inspirovat doporučením Sengridu, který je jednou z nejznámějších světových společností v oblastech marketingu. Jeho doporučení je ve stanovení celkového počtu ů, které chceme odeslat měsíčně a vydělení tohoto čísla 30 (resp. počtem dnů v daném měsíci). Pokud tedy chceme měsíčně odeslat ů, měli bychom jich denně odeslat přibližně 1666 (50 000/30). V případě, že se jedná o novou IP adresu, neměli bychom ze začátku odesílat více jak ů denně. ISP si uchovávají měsíční výsledky všech odeslaných ů na jejich servery a k dostačujícímu seznámení s odesílatelem by mělo dojít právě během těchto 30 dnů. S tím, jak poroste reputace IP adresy, je možné počet ů zvyšovat Konzistence v odesílání ů ISP uchovávají i informace o tom, kdy a kolik ů bylo odesláno z dané IP adresy. Pokud toto množství značně kolísá, může to způsobit snížení reputace. Ideální situace pro ISP je, pokud je odesílané množství z konkrétní IP adresy stabilní a konzistentní [40]. V případě sdílených IP adres je situace snadnější, protože poskytovatel služeb obvykle sám vyrovnává množství, které jde z určité IP adresy. Pokud je tohle množství příliš velké, může některé uživa- 10

20 2. REPUTACE tele přemístit pod jinou IP adresu a naopak, pokud je množství malé, může přidat další uživatele pod danou IP adresu. U dedikovaných IP adres je situace o něco složitější, protože zde není nikdo, kdo by kontroloval konzistenci v počtu odesílaných ů, ale je pouze na nás, abychom si to pohlídali. Není podstatné mít každý den nebo týden naprosto stejný počet odeslaných ů, ale měli bychom se vyhnout situacím, kdy toto množství značně kolísá. Nemělo by se stát, že 3 týdny neodešleme žádný a pak jich najednou odešleme ISP se to může zdát podezřelé a může naše y zahodit nebo je začít propouštět po částech. Nelze určit přesný počet ů, které bychom měli posílat. Je zde příliš mnoho faktorů (zejména celkové množství ů, reputace a obsah), ale všechny zdroje se shodují na tom, že konzistence je velmi důležitý parametr, který všichni velcí ISP zohledňují [13]. Pokud provozujeme vlastní SMTP server, máme tzv. dedikovanou IP adresu. Pokud využíváme služeb některých ESP, je možné, že IP adresa, ze které jsou odesílány naše y, bude rozesílat i y jiných zákazníků. V takovém případě se jedná o sdílenou IP adresu. Dedikovaná i sdílená IP adresa má své výhody a nevýhody a záleží především na okolnostech a požadavcích firmy, kterou by měla zvolit. V případě dedikovaných adres máme jedinečnou kontrolu nad naší reputací. Jsme jediní, kdo využívá tuto IP adresu k odesílání ů, a tím padá veškerá odpovědnost pouze na nás. V takové situaci je důležité věnovat pozornost zejména IP warmingu a reputaci, protože nové IP adresy nemají žádnou historii, na základě které by její y byly filtrovány a ISP často omezují počet přijatých e- mailů z takového zdroje. U dedikovaných IP adres je také potřeba vyhnout se přílišným výkyvům v objemu odesílaných ů, protože ty mohou také poškodit reputaci. U sdílených adres toto není potřeba vůbec řešit, protože ESP se stará o udržení určité hladiny objemu odeslaných ů sám. Sdílené IP adresy ale mají tu nevýhodu, že nekalé praktiky dalších zákazníků mohou poškodit naši vlastní doručitelnost. Další nevýhodou je také to, že pokud se rozhodneme přejít k jinému ESP nebo přejít na dedikovanou IP adresu, musíme začít od znovu a budovat reputaci od začátku. Pro malou až střední společnost nebo jednotlivce bez větších ambicí a růstu, je dle mého názoru plně dostačující mít sdílenou IP ad- 11

21 2. REPUTACE resu. Sdílené IP jsou levnější a odpadá zde režie a řízení objemu odesílaných ů a udržování konzistence v jejich odesílání. U velkých společností, které mají velkou bázi uživatelů a plánují odesílat velké množství ů, je výhodné si zřídit dedikovanou IP adresu. Většina ESP nabízí jak dedikované, tak i sdílené IP adresy Blacklisty DNSBL, častěji známé jako blacklisty/blocklisty jsou on-line databáze, které, zjednodušeně řečeno, uchovávají informace o jednotlivých IP adresách, které byly označeny za původce spamu. Blacklisty jako takové neovlivňují (a nemohou ovlivňovat) to, zda z této IP bude doručen, ale slouží pouze jako služba, kterou ISP využívají při kontrole původce u. ISP se dotazuje na to, zda je daná IP adresa zaznamenána blacklistem nebo ne a na základě odezvy se sám dle interních pravidel rozhodne, co dál s em. Existuje množství různých blacklistů, které lze rozdělit na veřejné a interní. Každý blacklist má samozřejmě jinou množinu záznamů a žádný ISP zcela určitě nevyužívá všechny dostupné blacklisty. Místo toho si ISP vybere ty největší a nejznámější, které pak použije pro kontrolu ů. Mezi nejznámější veřejné blacklisty patří zejména: Spamhaus ( Barracuda Reputation Block List ( SpamCOP ( MX ToolBox ( a MultiRBL ( Jakým způsobem může fungovat blacklisting lze vidět na přiloženém obrázku2.3. Velký počet označení ů za spam je nejčastější příčinou, kdy se daná IP adresa ocitne na nějakém blacklistu, protože ISP poskytují tato data těm blacklistům, se kterými spolupracují. Pokud se IP adresa dostane na nějaký blacklist, je doporučeno co nejrychleji zjistit, o který blacklist se jedná a provést kroky k jejímu odstranění. 12

22 2. REPUTACE Obrázek 2.3: Blacklist zdroj: [14] Většina veřejných blacklistů poskytuje instrukce pro odstranění z blacklistu po splnění jejich podmínek. To, jestli se IP adresa vyskytuje na daném blacklistu, jde zpravidla jednoduše zjistit přímo na webových stránkách blacklistu, ale vzhledem k počtu různých blacklistů může být zdlouhavé a časově náročné kontrolovat to u každého zvlášt. Proto vznikají i služby, které tohle dělají za nás. Nejznámější je Debouncer, který v současné době získává data ze 124 různých blacklistů Whitelisty Whitelist naopak od blacklistu obsahuje seznam domén/ip adres, od kterých chceme dostávat y. V dnešní době je používaný zejména na straně příjemce a pouze v případě, kdy je doručen do naší schránky. Může se stát, že ISP označí nesprávně za spam. V takových případech je vhodné nastavit daného příjemce do whitelistu. Odesílatel u nemůže ovlivnit to, jak se uživatelé zachovají, ale v případě, že registruje problémy s doručitelností e- 13

23 2. REPUTACE mailů, by bylo vhodné upozornit uživatele jak na svých ových stránkách (např. po odeslání objednávky, registraci uživatele apod.), tak přímo i v u Autentizace Autentizace je jeden z faktorů, který je čím dál více prosazovaný a používaný. Autentizací prokazujeme, že je skutečně od nás a ne od spammera nebo někoho, kdo se vydává za nás. Autentizace je nutná především pro bankovní, poštovní a jiné oficiální organizace, ale profitovat z ní budou všichni. Využíváním autentizace také pozitivně ovlivňujeme reputaci [15]. 2.2 Reputace domény Na rozdíl od reputace IP adresy se doménová reputace váže přímo na konkrétní doménu (např. company.com, example.com apod.). Dnes se na reputaci domény nebere velký ohled, ale je velmi pravděpodobné, že v budoucnu se bude tato technika stále více prosazovat zejména kvůli přechodu IPV4 sítí na IPV6 [16]. Reputace vázaná na doménu má specifické charakteristiky, mezi které můžeme zařadit: přenositelnost reputace a s ní spojená snadná výměna serveru a IP adresy (možnost přidání nových IP adres a změna ESP bez ztráty již vybudované reputace), při změně IP adresy serveru není potřeba znova použít IP warming, nemožnost vyřešit problémy s reputací pouhou změnou IP adresy a předpoklad poctivějšího přístupu ze strany odesílatelů z důvodu snahy udržení dobré reputace. 2.3 Měření reputace Pravidelné monitorování reputace je nezbytné pro předcházení potencionálních problémů. Měřením reputace se zabývá několik růz- 14

24 2. REPUTACE ných společností. Zjistit reputaci jakékoliv IP adresy nebo domény lze zpravidla pomocí jednoduchého formuláře, který tyto společnosti poskytují na svých webových stránkách. Mezi nejznámější a nejpoužívanější služby patří: SenderScore, SenderBase, AOL Postmaster, McAfee TrustedSource a ReputationAuthority Nejznámějšími a nejpoužívanějšími jsou SenderScore a Sender- Base, které blíže rozepíšu v následujících podsekcích SenderScore Reputace je v rámci SenderScore udávána hodnotami a platí, že čím větší je toto číslo, tím lépe. Skóre se počítá z aktivity posledních 30 dnů a ukazuje, jak si daná IP adresa vede v porovnání s jinými IP adresami. SenderScore je v současnosti nejvyužívanější službou pro měření reputace a je provozován firmou Return Path. Cílem by mělo být dosažení alespoň 80-ti bodové hranice, která značí dobrého odesílatele. V případě dlouhodobě dobré reputace je možné zažádat o certifikační status určený pro kvalitní odesílatele [17] SenderBase SenderBase je produkt společnosti Cisco a poskytuje možnost měření reputace pomocí tří statusů [41]: good dobrá reputace označující ověřeného odesílatele, poor označuje odesílatele, od kterého byla zaznamenána podezřelá nebo nekalá aktivita. ové zprávy od tohoto odesílatele budou pravděpodobně filtrovány a neutral - nejčastěji značí nedostatek dat a y projdou podrobnějším filtrovacím procesem. 15

25 2. REPUTACE Doporučení Žádná z monitorovacích služeb neumožňuje ruční úpravu reputace. Reputace je vždy stanovena automaticky dle chování odesílatele. Mé doporučení je proto pravidelně monitorovat SenderScore i Sender- Base a v případě problémů s reputací co nejrychleji reagovat. V případech, kdy není zřejmé, co je příčinou snížené reputace, je možné kontaktovat technické oddělení těchto služeb, které zpravidla poskytne bližší informace o příčině problému a možném řešení. 2.4 Budování reputace Vybudování dobré reputace by mělo být cílem každého, kdo se angažuje v oblasti odesílání ů. Jde o proces, který v dobrém případě trvá měsíc a v horším případě trvá věčně. To, zda se nám povede vybudovat dobrou reputaci, záleží na mnoha faktorech, z nichž spousta byla načrtnuta v této kapitole, ale pro úplnost a celistvost je vhodné je shrnout. Nicméně je dobré mít na paměti, že vybudováním dobré reputace by naše snaha neměla polevit. Ztratit reputaci je velmi snadné, ale získat ji zpět vyžaduje o to větší úsilí. Pro vybudování a udržení dobré reputace je nutno zaměřit se především na následující body: odesílat konzistentní množství ů v kampaních, zasílat relevantní obsah, který bude odběratele zajímat (eliminace stížnostní, větší šance prokliků, zobrazení ů apod.), pravidelně odstraňovat odběratele, kteří dlouhodobě nevykazují žádnou aktivitu, kontrolovat validitu ových adres ( y posílané na nevalidní/neexistující adresy mohou snižovat reputaci), používat ovou autentizaci, při použití dedikované IP adresy použít IP warming, pravidelně monitorovat blacklisty a 16

26 2. REPUTACE přihlásit se k odběru FBL a zpracovávat je. Při dodržení těchto zásadních bodů by neměl být problém vybudovat dobrou reputaci. Nutno ovšem podotknout, že pro úspěšné přijetí u není reputace jediným měřítkem, ale vstupují zde i další faktory. y především podléhají dalšímu filtrování (zejména obsahu a HTML kódu) po jejich přijetí ze strany ISP. 17

27 3 Autentizace Autentizace ových zpráv je způsob, kterým ISP může rozpoznat odesílatele příchozích zpráv a potvrdit, že tato zpráva skutečně pochází od tohoto odesílatele. Pokud identita odesílatele nemůže být ověřena, ISP může zprávu odmítnout, nebo ji podrobit dalšímu filtrování. Výsledek autentizace tak může sloužit jako podklad pro to, zda bude přijat, nebo podroben dalšímu filtrování [3]. Google na svém blogu [18] zveřejnil, že od roku 2004, kdy začal adoptovat autentizační standardy, dramaticky klesla schopnost spammerů imitovat domény a vydávat se za jiné uživatele. Google uvádí, že přibližně 91.4% ze všech legitimních ů je autentizováno metodou DKIM (DomainKey Identified ) a/nebo SPF (Sender Policy Framework) [18]. 3.1 Motivace a klasické útoky ová autentizace je důležitá především proto, že se zaměřuje na jeden z nejzávažnějších problémů SMTP, kterým je chybějící autentizace na straně protokolu. SMTP definuje 2 záznamy v hlavičce u identifikující adresu příjemce a odesílatele jako: MAIL FROM a RCPT TO. Adresa odesílatele není v základním nastavení podrobena kontrole, zda tento odesílatel může zasílat y za tuto ovou adresu (resp. její doménu). Díky tomu je velmi snadné podvrhnout hlavičku u tak, že zpráva bude vypadat, jako by přišla z jiné adresy. Podvržení u se označuje jako spoofing. Spoofing je technika využívaná především v rámci Phishingu (česky označovanému jako rhybaření [19]) za účelem získaní citlivých údajů (hesla, čísla kreditních karet, uživatelských jmen apod.) majitelů ových adres. Podvodný se často maskuje jako od populárních webových stránek, jako jsou aukční portály, sociální sítě nebo internetové bankovnictví. může obsahovat 18

28 3. AUTENTIZACE loga těchto webových stránek a všech dalších náležitostí u tak, že je k nerozpoznání od toho pravého. V těchto ech často útočníci vyzývají ke změně nebo potvrzení uživatelských údajů a odkazují na stránku, kde to uživatelé mohou změnit. Za odkazem se ovšem vždy skrývá podvodná stránka (možno zjistit pomocí domény) nebo reklama. Nezkušený uživatel často nepozná rozdíl, protože adresa odesílatele je shodná s tím, co zná. Vše ostatní na první pohled vypadá validně. Phishing je velký problém i v dnešní době. Webový server Getcybersafe.ca se zaměřil právě na tyto y a výsledné statistiky jsou alarmující. Denně je odesláno na 156 milionů phishingových zpráv, 16 milionů jich projde přes filtry, 8 milionů jich je otevřeno, 800 tisíc odkazů je kliknuto a uživatelů se stane obětí phishingu a poskytne své citlivé informace [20]. Phishingové y nepoškozují pouze koncové uživatele, ale i společnosti, za které se podvodníci vydávají. Pravděpodobnost, že tito uživatelé budou nadále využívat služeb společnosti, klesá až o 44% [21]. ová autentizace se snaží řešit právě tento problém a slouží k ověření a případnému zablokování podvodných ů. Pokud osoba stojící za doménou nepoužije autentizaci, neexistuje zde způsob, kterým by ISP mohl rozlišit podvodné odesílatele a může být doručen. Naopak pokud je autentizován, je velmi pravděpodobné, že jej ISP zablokuje a nebude doručen do schránky příjemce. Například Google blokuje 100% ů, které nejsou autentizovány pomocí DKIM [21]. Nutno podoktnout, že to, zda bude doručen, v tomto případě závisí především na klasických faktorech ovlivňujících doručitelnost jako je reputace a samotný obsah zprávy [22]. 3.2 Autentizační metody Autentizace ových zpráv lze rozdělit na dvě základní kategorie: Autentizace IP adres a Kryptografická autentizace. 19

29 3. AUTENTIZACE Autentizace IP adresy spočívá ve vytvoření vztahu mezi doménou odesílatele a seznamu IP adres, které jsou zmocněny odesílat v rámci této domény (SPF). Kryptografická autentizace naopak podepisuje asymetrickým digitálním klíčem, pomocí kterého lze ověřit identitu odesílatele zprávy (DKIM). V praxi se dnes využívají 4 různé druhy autentizačních metod: DKIM, DomainKeys, SenderID a SPF. Žádná z těchto metod neřeší vše a každá má své výhody a nevýhody. SPF a SenderID vyžadují pouze umístění souboru na server, který si příjemce může ověřit. Díky tomu jsou i snadnější na implementaci. Neposkytují však takovou záruku bezpečnosti jako DKIM a DomainKeys, které přímo v hlavičce u obsahují kód, který se ověřuje pomocí veřejného klíče odesílatele. Vzhledem k faktu, že každý ESP implementuje jiný druh autentizace, je důležité implementovat více metod současně. Jako ideální se ukazuje implementace DKIM, SenderID a SPF současně. DKIM je výsledek sloučení DomainKeys a IdentifiedInternetMail a ESP, který podporuje DomainKeys, bude s velkou pravděpodobností podporovat i DKIM, proto není potřeba jej implementovat ISP a využití autentizačních metod Jak jsem již zmínil v předešlé kapitole každý ESP se sám rozhoduje, který typ autentizace bude implementovat, a proto je téměř povinností odesílatele využívat více typů autentizace současně. V tabulce3.1 lze nalézt přehled několika světových ESP a autentizačních metod, které využívají [23]. 3.3 DKIM DomainKeys Identified Mail spojuje dřívější návrhy DomainKeys od Yahoo a Identified Internet mail od Cisco systems. DKIM je mecha- 20

30 3. AUTENTIZACE ESP DKIM DomainKeys SenderID SPF Gmail Ano Ano Ne Ano AOL Ano Ne Ano Ano Hotmail Ano Ne Ne Ano Yahoo! Mail Ano Ano Ne Ano Verizon Ne Ne Ne Ano AT & T Ano Ano Ano Ne RoadRunner Ne Ne Ne Ano Tabulka 3.1: Autentizační metody ISP nizmus, kterým mohou být ové zprávy kryptograficky podepsány. Podepisující doména díky tomu bere odpovědnost za odeslání těchto zpráv. Příjemci zprávy si mohou ověřit pravost podpisu (a tím celé zprávy) po získání veřejného klíče podepisující domény z DNS záznamu, a tím si mohou být jisti, že zprávu podepsal vlastník soukromého klíče. Soukromý klíč musí vždy zůstat v utajení a měl by jej mít k dispozici pouze vlastník domény. V případě prozrazení soukromého klíče je možné zprávy podepsat a použití autentizace pak ztrácí na významu. Pokud dojde k prozrazení soukromého klíče a odeslání nevyžádaných zpráv z této domény, může také dojít k výraznému poškození reputace domény [24] Prvky DKIM popisuje dvě skupiny prvků. Ti, kteří podepisují, jsou označování jako Signers a ti, kteří ověřují pravost podpisu, jako Verifiers. Podepisující prvky mohou být zejména MUAs 1, MSAs 2 a MTAs 3. Pro podepsání ové zprávy je vitální, aby tak bylo učiněno v rámci administrační domény podepisující organizace. Mezi 1. Mail User Agents označuje ové/poštovní klienty, které slouží k přijímání, odesílání a správě elektronické pošty. Mezi nejznámější MUAs patří např. Microsoft Outlook a Mozilla Thunderbird 2. Mail Submission Agents jedná se o počítačový program, který přijímá e- mailové zprávy od MUA a předává je dále ke zpracování MTA. 3. Mail Transfer Agents označuje počítačový program, který přenáší elektronickou poštu z jednoho počítače na druhý při použití klient server architektury. MTA implementuje jak přijímací, tak odesílací část SMTP. 21

31 3. AUTENTIZACE ověřovací subjekty patří MTAs, MDAs 4 a MUAs. Nejčastěji je podepisování i ověřování uskutečněno na straně MTA Princip DKIM je kompatibilní se současným ovým systémem a nevyžaduje žádné podstatné změny v infrastruktuře. V ové zprávě se DKIM projevuje pouze přidáním nového pole DKIM-Signature do hlavičky u. Toto pole obsahuje sadu atributů, které označují podepisující doménu, samotný podpis (hlavičky + tělo zprávy), hash těla zprávy, použitý algoritmus, selektor, verzi, čas podpisu, metodu pro získání veřejného klíče a další. Kompletní seznam atributů včetně jejich popisu lze nalézt v protokolu RFC4871 [24]. Příklad DKIM hlavičky z reálné ové zprávy: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=steampowered.com; s=smtp; h=date:message-id:content-type:subject: MIME-Version:Reply-To:From:To; bh=/lrhm+mkids84gexlwmtdagi22t1garijego3gqbze0=; b=khr4mj+trzja/bqvajrqdnaaiona+zsd7hj1z8fuk4hbw+bk Icc+6SVyCPOVgWhwzjdsR22vHbPaTtCxAyY5J7Q7rokcLshgNi ojq6nllxxbkm4kc1/wi4k+x8ndeolyfl3md0nfvbperhrt/fbe swwagkl6dnet2ychk+nc5ru=; Rozbor jednotlivých součástí podpisu je k dispozici v tabulce3.2. Veřejný klíč podpisovatele je uložen jako TXT záznam [26] v DNS, pod kterou jsou ové zprávy odesílány. Tento klíč je uložen ve speciální subdoméně, která začíná selektorem (získaný z atributu s ), povinnou částí _domainkey a nakonec samotnou doménou. Verifikující prvek musí nejprve tento veřejný klíč získat a až poté může ověřit, že ová zpráva byla podepsána odpovídajícím soukromým klíčem. Pro získání veřejného klíče z příkladu výše můžeme 4. Mail Delivery Agents popisuje program, který je zodpovědný za přijímání ových zpráv do schránky lokálního příjemce. Označuje se také jako LDA Local Delivery Agent. Nejznámější unixový zástupce MDA je postfix. 22

32 3. AUTENTIZACE v DKIM verze a Algoritmus použitý na vytvoření podpisu q Způsob vyzvednutí veřejného klíče c Způsob kanonizace hlavičky a těla u [25]. d Podepisovaná doména s Selektor h Seznam polí v hlavičce, které jsou součástí podpisu bh DKIM Hash těla zprávy b Podpis Tabulka 3.2: DKIM podpis použít dotaz na DNS. Pod operačním systémem Windows lze použít příkazový řádek. Příklad takového dotazu může být: nslookup -type=txt smtp._domainkey.steampowered.com V případě, že k dané doméně je přiřazen TXT záznam, je tento záznam vrácen, jak lze vidět na obrázku 3.1. Obrázek 3.1: Výsledek dotazu na DKIM záznam zdroj: vlastní 23

33 3. AUTENTIZACE Po ověření autentizace bude do hlavičky u přidáno nové políčko Authentication-results, které obsahuje výsledek všech použitých autentizačních metod oddělených středníkem. V případě úspěšné autentizace bude výsledek vypadat následovně: Authentication-Results: mx.google.com; spf=pass (google.com: domain of noreply@steampowered.com designates as permitted sender) smtp.mail=noreply@steampowered.com; dkim=pass header.i=@steampowered.com Výhody a nevýhody DKIM technologie je jedna z možných autentizačních technik a jako taková má určité výhody a nevýhody. Mezi její výhody patří zejména: eliminace phishingových ových zpráv od určité domény (za předpokladu, že bude ISP filtrovat příchozí y a ověřovat autentizaci), příjemce ví odkud ová zpráva přichází a může si to ověřit, hashování celé zprávy zaručuje její integritu, buduje důvěryhodnější reputační systém (vytvářejí se i databáze domén rozesílajících validní obsah), zvyšuje pravděpodobnost, že ová zpráva bude doručena do schránky příjemce už jen díky přítomnosti autentizace, spammeři nemohou negativně ovlivnit reputaci domény zasíláním podvodných ů (takové y nejsou k odpovědnosti dané domény/serveru) a nevyžaduje žádné změny nebo speciální software pro koncové uživatele. Mezi nevýhody lze pak zařadit: 24

34 3. AUTENTIZACE změny v obsahu nebo hlavičky podepsané ové zprávy při cestě k příjemci způsobí neplatnost podpisu z důvodu potencionálního narušení integrity, ověření je třeba udělat u každé ové zprávy zvlášt a vyžaduje určitý výpočetní čas, který by jinak nebyl potřeba, žádným způsobem nenaznačuje, že obsah ové zprávy je validní a nejde o spam. Pouze říká, odkud byl odeslán a nepředepisuje, co by se mělo s ovou zprávou stát po úspěšné/neúspěšné validaci. To, zda zpráva bude přijata nebo zahozena, záleží pouze na nastavení poštovního serveru nebo ového klienta Shrnutí V dnešní době, kdy velkou část ových zpráv tvoří spamy, je téměř povinností pro všechny seriózní firmy i jednotlivce zakomponovat DKIM autentizaci do své infrastruktury, případně to vyžadovat po svém ISP. Velcí poskytovatelé ových služeb již zpravidla DKIM podporují a zprovoznění je často otázkou jednoduchého nastavení v aplikaci poskytovatele a nahrání veřejného klíče ke své doméně v DNS. 3.4 DomainKeys DomainKeys označuje předchůdce DKIMu a popisuje jej RFC 4870 [27]. I přesto, že tento framework pro autentizaci ů byl vydán teprve v roce 2007, je dnes již považován za historický. Původně byl vytvořen společností Yahoo jako prostředek boje proti spamu a phishingu. Princip fungování je velmi podobný DKIMu, ale existuje zde několik odlišností mezi, které patří [28]: možnost použití pouze jednoho podepisujícího algoritmu (RSA), nemožnost podepsat hlavičku spolu s tělem u, 25

35 3. AUTENTIZACE nemožnost delegovat podepisování na vnější subjekty a neexistující timeout podpora pro verifikaci DNS záznamů Shrnutí V dnešní době je již bezpředmětné se zabývat DomainKeys a pozornost by měla být věnována především jeho nástupci, který pracuje na stejném principu a k tomu přidává širší podporu a více konfiguračních možností. 3.5 SPF Sender Policy Framework (SPF) označuje poměrně jednoduchý mechanizmus detekování zfalšovaných ových zpráv, tj. zpráv, které záměrně použijí jinou doménu, než ze které skutečně jsou (tato aktivita se označuje jako spoofing [29]). SPF je popsán v RFC 7208 [30] Princip SPF funguje na principu povolených IP adres, které mohou odesílat v rámci určité domény. Vlastník domény v takovém případě vytvoří speciální TXT záznam v DNS, kde specifikuje, které počítače (IP adresy) jsou autorizovány posílat ové zprávy za danou doménu. Příjemci ové zprávy pak stačí nahlédnout do tohoto TXT záznamu a zkontrolovat, zda IP adresa odesílatele je zahrnuta v tomto seznamu. V případě, že tato IP adresa nebude nalezena v TXT záznamu (a doména aplikuje SPF), je možné nahlížet na ovou zprávu jako na podvodnou, protože je odeslána z neověřeného zdroje. TXT záznam je publikován a spárován s konkrétní doménou. Získat SPF záznam lze podobně jako u DKIMu dotazem na DNS. V případě našeho příkladu (viz. Odkaz na příklad DKIMu) by dotaz vypadal následovně: nslookup -type=txt steampowered.com Výsledkem je TXT záznam3.2, který obsahuje SPF specifikaci s výčtem konkrétních IP adres, které jsou oprávněny odesílat z do- 26

36 3. AUTENTIZACE Obrázek 3.2: Výsledek dotazu na SPF záznam zdroj: vlastní mény steampowered.com. Ověřit SPF záznam je také možné prostřednictvím on-line služeb, jako například MxToolBox3.3 ( nebo Kitterman ( MxToolBox poskytuje grafický a přehledný výstup spolu s popisem jednotlivých částí SPF záznamu pro jeho snadnější interpretaci Syntaxe SPF definuje syntaxi, která může být použita pro vyjádření určitých pravidel, která budou aplikována pro ověření příchozích ových zpráv s danou doménou. Pro vyjádření syntaxe mohou být použity: mechanizmy (mechanisms), kandidáti (qualifiers), modifikátory (modifiers) a makra (macros). 27

37 3. AUTENTIZACE Obrázek 3.3: Rozhraní aplikace MxToolBox zdroj: Příklad pravidla, které říká, že doména neposílá žádné y, a proto by všechny y odesílané z této domény měly být odmítnuty. v=spf1 -all Pravidlo, které povoluje odesílat ové zprávy z jakékoliv adresy pouze v rozmezí Všechny y z jiných IP adres by měly být považovány za neoprávněné a odmítnuty jejich příjemcem. v=spf1 ip4: /16 -all Syntaxe SPF je poměrně komplexní a její kompletní rozbor spolu s dalšími příklady je možné nalézt v RFC 7208 [30] nebo na oficiálním webu SPF [31] Shrnutí V souvislosti s SPF je velmi těžké hledat potencionální nevýhody. Dle mého názoru neexistuje žádný podstatný důvod pro nevyužití SPF. SPF pomůže chránit vlastní doménu a může zabránit jejímu zneužití třetími stranami. Nejpodstatnější nevýhoda je, že SPF nekontroluje 28

38 3. AUTENTIZACE a nevaliduje From: v hlavičce u z důvodu komplexnosti, kterou by to přineslo [32]. V praxi to znamená, že , který v From: zvolí jinou doménu, než ze které ve skutečnosti je, ale je z povolené IP adresy, projde úspěšně SPF autentizací. Možnou nevýhodou také může být, že špatná konfigurace může způsobit blokaci ů ze stran ISP, takové přehmaty budou ale pravděpodobně velmi rychle opraveny. Za další potencionální nevýhodu by bylo možné označit to, že SPF samo o sobě negarantuje, že daný není spam. Smyslem SPF ale není garance nezávadnosti ové zprávy, ale zabránit zneužití konkrétní domény a tu spárovat s konkrétními poštovními servery. Z tohoto důvodu nelze tohle považovat za nevýhodu SPF, ale za její vlastnost. 3.6 SenderID SenderID je technika autentizace navržená Microsoftem v rámci experimentální RFC 4406 [33]. Princip fungování SenderID lze vidět na přiloženém obrázku3.4. Tato technika je z velké části vytvořena na základě SPF a používá stejné principy i syntaxi DNS záznamů. Smyslem SenderID mělo být odstranění v podstatě jediné nevýhody SPF, kterou je ignorace ových adres v hlavičce u (From, Sender, Resent-From, Resent-Sender) [34]. Od roku 2006, kdy bylo RFC 4406 vydáno, však nedošlo k žádné aktualizaci a oficiální web [32] SPF označuje SenderID za neúspěšný pokus o rozšíření SPF na validaci adres v hlavičce ové zprávy Shrnutí V tabulce zobrazující používané techniky poskytovatelů ových služeb 3.1 lze vidět, že SenderID používají pouze AOL a AT & T. Lze předpokládat, že SenderID nebude mít širší zastoupení ani u méně známých poskytovatelů. Vzhledem k faktu, že práce na něm stagnují, je možné v blízké době předpokládat jeho vymizení. Již článek z roku 2004 [42] vyjadřoval znepokojení nad jeho současnou formou. Zdá se, že ani Microsoft neplánuje práce na SenderID obnovit. To podporuje fakt, že i Hotmail (provozovaný Microsoftem) přestal v roce 2012 využívat SenderID a přešel k SPF [43]. 29

39 3. AUTENTIZACE Obrázek 3.4: SenderID zdroj: [35] 30

40 4 Filtrování podle obsahu ová autentizace a reputace IP adres nejsou jediné způsoby, podle kterých se určuje, zda je příchozí legitimní nebo ne. E- maily mohou po svém přijetí na mail serveru projít obsahovým filtrováním, které kromě výše zmíněných technik zkoumá také samotný obsah a význam zprávy. Zkoumat pouze zdroj není dostačující, protože i důvěryhodné zdroje mohou rozesílat nevyžádanou poštu a mohou zneužívat své reputace. Existují i odesílatelé, kteří budují reputaci jen proto, aby toho vzápětí zneužili. Reputace těchto odesílatelů bude samozřejmě klesat, ale než se tak stane, může už být nezanedbatelné množství ových zpráv úspěšně odeslané. Filtrování podle obsahu lze implementovat na různých vrstvách. V tomto kontextu se jedná zejména o zpracování na straně serveru a na straně uživatele. Existuje i ový filtr, který lze nainstalovat samostatně na počítač uživatele. Takový program se odlišuje tím, že pracuje s e- maily přímo na serveru a je možné jej proto používat v kombinaci s libovolným ovým klientem. Tento typ filtru je možné použít jen v případě, kdy máme přístup k ovému serveru [4]. Typy ových filtrů jsou podrobněji rozebrány v kapitole 5. Chtěl bych upozornit na rozdíl mezi obecným filtrováním ů, filtrováním obsahu ů a ovými filtry, protože tyto pojmy lze snadno zaměňovat. ové filtry označují programy, které vykonávají ové filtrování. ové filtrování se skládá z více různých metod. Mezi tyto metody patří již zmíněné obsahové filtrování, zkoumaní reputace a autentizace (viz. obrázek 4.1). V této kapitole se budu dále věnovat obsahovým filtrům a technikám, které využívají [2]. 4.1 Analýza hlavičky u Samotnému obsahu u vždy předchází tzv. hlavička u, která identifikuje a popisuje daný . Formát hlavičky a polí, které může obsahovat, je definován v RFC 2822 [37]. V základu jsou povinná pouze dvě pole: From a Date. Zpravidla ale každý e- mail bude obsahovat mnohem více polí. Minimálně zde budou přítomna pole identifikující adresáta, jako je To, Cc a Bcc. 31

41 4. FILTROVÁNÍ PODLE OBSAHU Obrázek 4.1: Filtrovaní ů zdroj: vlastní Spammeři odesílají velké množství ů a využívají k tomu často praktiky, které již v hlavičce u vzbuzují podezření. Mezi největší indikátory spamu patří [38]: prázdné To pole, zcela chybějící To pole, adresa příjemce pouze v Bcc nebo Cc polích, nevalidní ové adresy, použití stejné ové adresy v To a From polích, chybějící nebo nevalidní Message-Id a velké množství adresátů v To, Bcc nebo Cc polích. 32

42 4. FILTROVÁNÍ PODLE OBSAHU Tohle je velmi základní výčet vlastností, které mohou značit spam. Ve skutečnosti je testů, kterými hlavička u prochází, mnohem více. Testy jsou také sofistikovanější. Za nejlepší zdroj informací bych označil oficiální webové stránky SpamAssasinu, kde je k dispozici přehled všech testů, které SpamAssasin integruje. Spolu s popisem testu je zde k dispozici i skóre značící jeho významnost v základní konfiguraci [39]. Významnost jednotlivých testů si mohou uživatelé přizpůsobovat dle svých potřeb. Přehled těchto testů nicméně slouží pouze pro ilustraci, protože každý ový filtr může využívat odlišná pravidla. 4.2 Analýza těla u Tělo u (označováno jako body ) je to, co vidí uživatel, když otevře . Testování probíhá stejně jako v případě analýzy hlavičky. Největší charakteristiky spamu jsou v případě těla u: y obsahující pouze HTML verzi ( by měl obsahovat i textovou verzi bez HTML), značná odlišnost verze bez a s HTML (může znamenat, že se odesílatel snaží vyhnout filtrování použitím zprávy, která vypadá jinak pro lidi a stroje), velký poměr obrázku k textu (může indikovat snahu o vyhnutí se textovému filtrování použitím obrázků), zprávy obsahující fráze a slova vyskytující se v aktuální nevyžádané poště (např. lottery win, muscle growth, cheap viagra apod.), zprávy, kdy se tělo u skládá z velkého množství prázdných řádků, barvy textu splývající s barvou pozadí, použití nevalidního HTML zprávy, které obsahují odkaz, jehož URL je na blacklistu a 33

43 4. FILTROVÁNÍ PODLE OBSAHU zprávy s tzv. HTML obfuscation (skrývání pravého významu HTML). Testů, kterými lze podrobit tělo u, je mnoho. Opět zde záleží na konkrétním programu a jeho nastavení. 4.3 Bayesův spam filtr Bayesovo filtrování spamu lze označit za nejvíce sofistikovaný způsob výpočtu pravděpodobnosti, s jakou se obsah u rovná spamu. Na rozdíl od jednoduchých obsahových filtrů, které mohou zkoumat pouze jednotlivá slova nebo fráze obsažené v u, se Bayesův filtr postupně automaticky učí z legitimních ů a spamů. Bayesův spam filtr dokáže rozeznat dobrý od toho špatného díky předešlým akcím jeho uživatelů. Každému slovu, frázi, ale i HTML kódu obsaženého v u (včetně hlavičky) je přiřazeno skóre. Jednotlivá skóre se poté použijí k výpočtu finálního skóre, které určuje pravděpodobnost, s jakou se jedná o spam. Skóre se jednotlivým elementům přiřazuje na základě analýzy předešlých e- mailů. Pokud je slovo lottery obsaženo v 99% ech, které uživatelé klasifikovali jako spam, je této frázi přiřazeno vysoké skóre. Naproti tomu, pokud se slovo christmas vyskytuje převážně jen v legitimních ech, je mu přiřazeno skóre nízké. Pokud obsahuje oboje slova, není jasné, zda se jedná o spam nebo legitimní . Výsledné skóre pak bude záviset na dalších slovech a frázích obsažených v u, které budou zkoumány stejným způsobem. Vždy se zkoumá obsah celého u a ne pouze výskyt určitých slov. Čím větší databázi má Bayesův filtr k dispozici, tím může být účinnější. Jsou zde ale situace, kdy i při větší databázi bude méně účinný. Důvodem je počet uživatelů a jejich různorodost. Každý uživatel má jiné preference a dostává jiné y. To, co pro jednoho uživatele je spam, může pro jiného být všední a legitimní . Bayesův filtr nebere v potaz preference těchto uživatelů, a proto může docházet k chybným výpočtům. Čím menší je proto počet uživatelů, a čím větší je interní databáze Bayesova spam filtru, tím je účinnější [36]. Sofistikovanější spammeři využívají tzv. Bayesian poisoning jako útok na Bayesův spam filtr. Smyslem této metody je přidání 34

44 4. FILTROVÁNÍ PODLE OBSAHU extra dat do u, která mají za úkol zmást databázi spam filtru. To se děje přidáním slov, která se jinak vyskytují v legitimních ech. Pokud je označen za spam, dojde ke snížení hodnoty těchto slov, protože byla součástí spamu. V opačném případě dojde k přijetí spamu a zvýšení hodnot u slov, která by jinak byla označena za spam. V obou případech je dopad na efektivitu Bayesova filtrování negativní. 35

45 5 Existující ové filtry ové filtry lze označit za množinu programů, které zajišt ují samotné filtrování ů (lze filtrovat příchozí i odchozí ové zprávy), tzn., rozhodují o tom, zda bude přijat, pozměněn, přeposlán nebo zahozen. Pro vyhodnocení ové zprávy tyto programy využívají zejména technik, které jsem rozebral v předešlých kapitolách. Obecně lze říci, že rozhodovací proces záleží na: konkrétním programu a jeho implementaci, konfiguraci programu, době používání, použitých externích zdrojích (blacklisty, whitelisty) a aktuálních technikách spammerů. Žádné dva různé filtry nepracují úplně stejně, ale liší se jak způsobem implementace, tak i výčtem použitých technik. Situace je ale složitější, protože i stejný program může vyhodnocovat y jinak. Závisí to jednak na jeho konfiguraci a také na databázi, kterou si tyto programy zpravidla vytvářejí na základě přijímaných ů. Zmiňuji to zejména z toho důvodu, že neexistuje sada jednoznačných pravidel, která zajistí, že s daným obsahem bude vždy přijat jako legitimní. Tyto filtry se také adaptují v čase na základě aktuální technik spammerů a , který byl dnes přijat, nemusí v budoucnu být. Spammeři stále mění taktiky, jakými se snaží obejít filtry, a proto je potřeba, aby tyto programy s nimi držely krok. Přestože tyto programy pracují různě, je důležité vědět, jaké principy tyto filtry používají a při psaní u se soustředit na tyto principy tak, aby riziko nepřijetí u bylo co nejmenší. 5.1 Typy ových filtrů ové filtry lze rozdělit na dvě základní kategorie: serverové filtry a lokální filtry. 36

46 5. EXISTUJÍCÍ OVÉ FILTRY Serverové filtry Serverové filtry jsou programy, které jak jejich název napovídá, provádějí filtrování ů na straně serveru při jejich přijetí. Filtrovat y na serveru bude zcela jistě každý solidní poskytovatel ových služeb (Gmail, Seznam.cz, Centrum.cz apod.). y, které jsou filtrovány na této úrovni, se nedostanou ke svému příjemci, který se ani nedozví o jejich existenci. Filtrování na serveru je velmi důležité, protože žádný poskytovatel nechce zahltit své uživatele velkým množstvím nevyžádaných ů, ale je třeba dávat pozor i na tzv. false positives, kdy dojde k vyfiltrování legitimních ů. Z toho důvodu by pravidla na straně serveru neměla být příliš přísná, ale měla by zahrnovat určitou toleranci. Mezi zástupce této kategorie patří například: SpamAssassin, Anti-Spam SMTP Proxy Server, DSpam a SpamBayes SpamAssassin SpamAssassin je nejznámější open-source program určený pro filtrování ových zpráv. Integruje většinu metod, které jsou rozebrány v této práci. Výhodou je především jeho komplexnost, integrace téměř s jakýmkoliv systémem a flexibilita uživatelského nastavení. SpamAssassin slouží také jako podklad pro mnoho komerčních spam filtrů na trhu [45, 46]. Primární typy testů, které SpamAssassin obsahuje pro ohodnocení ové zprávy, jsou následující [47]: analýza hlavičky u, analýza těla u, Bayesovo filtrování, automatická kontrola adres z blacklistů a whitelistů, 37

47 5. EXISTUJÍCÍ OVÉ FILTRY testování reputace odesílatele (SenderScore), manuální kontrola adres z blacklistů a whitelistů, kolaborační databáze pro identifikaci spamu, testování autentizace (DKIM, SPF), DNS Blocklisty a další. I přesto, že je SpamAssassin open-source, je velmi používaným a z českých společností jej například využívá i Seznam.cz [60] Anti-Spam SMTP Proxy Server Anti-Spam SMTP Proxy Server (zkráceně označovaný jako ASSP) je stejně jako SpamAssassin vydán jako open-source program. Mezi jeho nejvýznamnější funkce pro detekci spamu patří [48, 49]. Bayesovo filtrování, kontrola adres z blacklistů, kontrola SPF autentizace, kontrola URI v blacklistech, sledování IP reputace (SenderBase), analýza hlavičky i těla u a další Lokální filtry Lokální filtry označují programy, které jsou schopny filtrovat y lokálně u uživatele. Tyto programy umožňují zpravidla nastavit jednoduchá pravidla pro filtrování příchozích ů na základě obsahu zprávy, výskytu určitých slov nebo třeba filtrování některých odesílatelů. Kromě těchto jednodušších pravidel dnes tyto programy často umožňují integraci i se serverovými spam filtry pro lepší úroveň detekce spamu. Příkladem může být využití X-Spam-Status hlavičky v u, kterou přidává SpamAssassin po vyhodnocení 38

48 5. EXISTUJÍCÍ OVÉ FILTRY u [44], nebo i přímá integrace, kdy ový klient použije tento program. V takovém případě musí ový klient podporovat integraci s daným filtrem. Lokální filtrování nemá za cíl nahradit serverové filtrování, jde pouze o další vrstvu ochrany nebo třídění ů. Existuje velké množství různých ových klientů. Mezi nejznámější patří zejména Thunderbird a Outlook Thunderbird Thunderbird je ový klient od firmy Mozilla, která je mimo jiné odpovědná za vývoj populárního internetového prohlížeče Firefox. V souvislosti s ovým filtrováním poskytuje Thundebird možnost vytváření vlastních filtrů, které na základě vlastnosti ové zprávy (jako je odesílatel, tělo u, nadpis apod.) a jednoduchého pravidla (obsahuje, neobsahuje, začíná na apod.) může uskutečnit nějakou akci (dát do jiné složky, smazat , přeposlat e- mail, nastavit prioritu apod.). Tento filtr je poměrně jednoduchý a slouží spíše pro uživatelské filtrování. Ukázku filtrovacího pravidla lze vidět na obrázku 5.1. Thunderbird nicméně podporuje i doplňky, kterými lze dosáhnout pokročilého filtrování. Nejznámějším doplňkem je FiltaQuilla, která přináší mnoho možností pro pokročilé filtrování (zejména pomocí vlastních regex pravidel) [51] Outlook Outlook je produkt společnosti Microsoft a kromě ového klienta obsahuje i aplikaci na správu kontaktů, úkolů, kalendáře a poznámek. Nejčastěji je používán ve firmách ve spolupráci s Microsoft Exchange serverem. Microsoft Outlook v základní instalaci podporuje tzv. pravidla (rules), která uživateli umožňují třídit poštu. Princip fungování je stejný jako v případě aplikace Thunderbird. Stejně tak podporuje i přidávání vlastních doplňků (anglicky add-on). Vzhledem k širší uživatelské základně je nabídka doplňků pro Microsoft Outlook znatelně větší. 39

49 5. EXISTUJÍCÍ OVÉ FILTRY Obrázek 5.1: Ukázka filtrovacího pravidla v aplikaci Thunderbird zdroj: vlastní 40

50 6 Zlepšování doručitelnosti na straně aplikace Cílem této kapitoly je uvedení nejdůležitějších technik (resp. funkcionalit), které by měla aplikace sloužící ke správě a odesílání ů mít, aby přispěla ke zlepšení doručitelnosti. Vycházet budu především z teoretických poznatků předešlých kapitol. 6.1 Motivace V dnešní době roste význam digitálního marketingu a stále více firem využívá bud specializovaných aplikací pro správu jejich ových kampaní, nebo upravuje svůj stávající software. Cílem a motivací těchto firem je především zlepšení jejich postavení na trhu. Stále častěji se také dnes můžeme setkat s podvodnými y (phishing, spoofing), které mohou poškodit reputaci značky a snížit důvěru uživatele číst a dále pracovat s y. Cíle, ke kterým by měly firmy, dle mého názoru, směrovat, jsou především: odesílání ů, o které uživatelé mají zájem, faktické doručení ů do schránky příjemců, zabezpečení ů proti jejich zneužití a naplnění právních povinností. Hlavní zodpovědnost vždy záleží na člověku, ale aplikace může mít velký vliv na výsledek lidského snažení. To platí zejména o částech, které by měly být automatizované. V této kapitole se dále zaměřím na funkcionality, které považuji za nejdůležitější při tvorbě kvalitní aplikace pro správu a odesílání ů. Tyto zahrnují [1]: získávání odběratelů, udržování seznamu odběratelů, kontrola HTML, 41

51 6. ZLEPŠOVÁNÍ DORUČITELNOSTI NA STRANĚ APLIKACE kontrola verzí u, aplikování workflow, vyhodnocování kampaní, naplnění práva. 6.2 Získávání odběratelů Způsob, jakým získáme odběratele, může velmi podstatně ovlivnit celkovou doručitelnost všech našich ů. Pokud například zašleme uživatelům, jejichž jsme našli někde na webových stránkách (a pomineme, že se jedná o nelegální taktiku dle zákona č. 480/2004 Sb.), tak je důvodné předpokládat, že cílení uživatelé nebudou mít zájem dostávat tyto y a mohou je nahlásit jako spam. Čím více takových uživatelů bude, tím větší je šance, že se brzy dostaneme na nějaký blacklist a ISP začnou blokovat naše y. Existují 4 základní typy seznamu odběratelů: opt-out, opt-in, confirmed opt-in a double opt-in Opt-out Opt-out je tvořen odběrateli, kteří při určité akci (nákup, registrace apod.) implicitně dávají souhlas k zasílání reklamním ů na jejich ovou adresu. Na webové stránce je zpravidla napsáno, že provedením této akce dávají souhlas k zasílání ů. Tento text může být často umístěn i tak, že si ho uživatel ani nevšimne. List odběratelů tímto způsobem roste nejrychleji ze všech metod, ale je zde i velká šance, že tito uživatelé neměli vůbec zájem o to, dostávat e- maily. Nemusí ani vědět, že tento souhlas udělili, a v důsledku toho budou naše y ignorovat, nebo je v horším případě nahlásí jako 42

52 6. ZLEPŠOVÁNÍ DORUČITELNOSTI NA STRANĚ APLIKACE spam. Uživatel má později možnost se z odběru odhlásit (odtud optout), nicméně tento způsob získávání odběratelů nelze doporučit Opt-in Na rozdíl od opt-out tento způsob znamená, že uživatelé nikdy nejsou automaticky přidání jako odběratelé. Proto, aby se uživatel stal odběratelem, musí vyplnit a odeslat přihlašovací formulář nebo zaškrtnout políčko (checkbox), že s odběrem souhlasí (např. při dokončování objednávky apod.). Tento způsob je lepší než opt-out, ale stále má problémy. Uživatel může například zadat bud neexistující, nebo cizí ovou adresu. V nejhorším případě pak dojde někomu, kdo o nás nikdy neslyšel a označí za spam Confirmed opt-in Confirmed opt-in je podobný listu typu opt-in. Rozdíl je, že uživateli je zaslán tzv. děkovací , ve kterém je odkaz, který umožní uživateli odhlášení z odběru. Pokud tedy dojde někomu cizímu, kdo nemá o odběr zájem, může se jednoduše odhlásit. Tato metoda ovšem ukrývá podstatný problém. Uživatelé, kteří tento e- mail neočekávali, mohou mít (oprávněný) strach klikat na jakýkoliv odkaz. Tato situace může nejčastěji nastat, pokud někdo využije cizí nebo náhodnou ovou adresu. Další nevýhodou je možné zneužití třetí osoby s cílem poškodit nás a naši reputaci. Pokud například provozujeme e-shop a naše aplikace využívá confirmed opt-in metodu, může se stát, že konkurent cíleně vytvoří skript, který bude automaticky vyplňovat přihlašovací formulář množstvím náhodných a cizích ů. Uživatelé, kterým náš dojde, nás budou označovat za spammery a postupem času bude naše reputace klesat. Důsledkem bude, že skutečným zákazníkům přestanou chodit y o objednávkách a budou si myslet, že jim neodpovídáme. Výsledkem může být jejich přechod ke konkurenci. 43

53 6. ZLEPŠOVÁNÍ DORUČITELNOSTI NA STRANĚ APLIKACE Double opt-in Double opt-in je metoda, ve které uživatelům pro přihlášení k odběru zašleme s odkazem, na který musí přistoupit, aby registrace proběhla úspěšně. Tento odkaz slouží jako ověření, že daná e- mailová adresa existuje, a že uživatelé souhlasí s tím, že jim budeme zasílat y. Tento způsob je zdaleka nejlepší, protože tím získáváme uživatele, u kterých je největší šance, že mají zájem číst to, co jim budeme zasílat. Na první pohled by se nevýhodou této metody mohlo zdát, že uživatelé budou líní nebo neochotní projít celým procesem. Otázkou potom ale je, zda odběratelé, kteří by nebyli schopni kliknout na jednoduchý potvrzovací odkaz, budou číst a odpovídat na naše y Shrnutí Z popisu výše uvedených metod vyplívá, že užívání jiné metody než double opt-in nelze doporučit. To platí především pro toho, kdo chce mít kvalitní seznam odběratelů. Získat velké množství odběratelů není dnes těžké. Na internetu lze najít nepřeberné množství ových adres. Kvantita by ale v tomhle případě nikdy neměla převažovat nad kvalitou. 6.3 Udržování seznamu odběratelů ové adresy nejsou věčné. Uživatelé je mění, ruší a zakládají nové. Stejně tak uživatelé mění postupem času své preference a vyvíjí se. Z toho důvodu by aplikace měla: odstraňovat neexistující ové adresy, odstraňovat neaktivní odběratele, umožnit odběrateli změnit frekvenci odesílání ů a umožnit odběrateli zvolit typy ů, které chce dostávat. Tyto funkce značně pomohou udržet aktuální a kvalitní seznam odběratelů. To se ve výsledku promítne ve větší procento přečtených 44

54 6. ZLEPŠOVÁNÍ DORUČITELNOSTI NA STRANĚ APLIKACE ů, větší aktivitě za strany odběratelů, menšímu počtu nedoručených ů a nakonec ve větší celkové doručitelnosti všech e- mailů Odstraňování neexistujících ových adres Aplikace by měla automaticky sledovat bounce y a přiřazovat je ke konkrétním příjemcům. V případě výskytu Hard bounce, která značí nenalezenou ovou adresu, by mělo dojít k okamžitému zastavení odesílání veškerých ů na tuto adresu. Soft bounce značí pouze dočasnou nemožnost doručit a v takovém případě bych doporučil odstranit odběratele po 2-3 bounce ů v jednom měsíci Odstraňování neaktivních odběratelů Z různých důvodů se může stát, že odběratelé přestanou mít zájem o naše y a přestanou je číst. Aplikace by měla sledovat otevření ů uživatelem a ukládat tyto informace pro pozdější zpracování. Problémem je, že nelze se stoprocentní jistotou zjistit přečtení u uživatelem. U HTML ů lze otevření u sledovat pomocí vloženého obrázku s identifikací příjemce v jeho URL. Při otevření u se tento obrázek stáhne z našeho serveru a my můžeme na základě URL zjistit, kdo otevřel. HTML obrázku může vypadat například takhle: <img alt="hi" src=" tracking_image.png?source=richard@ .com"> Identitu odběratele, který otevřel , lze zjistit díky přítomnému query stringu 1 source v URL obrázku. Aplikace samozřejmě musí každému odběrateli vygenerovat jinou URL obrázku, aby jej bylo možné identifikovat. Tento způsob je také naivní a lze jej jednoduše zneužít. V praxi by bylo vhodnější využít například hash, který byl vygenerován na základě jednoznačné identifikace odběratele, který poté porovnáme. Takový hash pak není možné napodobit 1. Query string označuje parametr v url adrese vyskytující se za písmenem? nebo & 45

55 6. ZLEPŠOVÁNÍ DORUČITELNOSTI NA STRANĚ APLIKACE bez znalosti jeho výpočtu. Problémem je, že uživatelé mohou mít ve svém ovém klientu nastaveno blokování obrázků nebo čtou y pouze v plain text verzi, která nemůže obsahovat HTML. Takoví uživatelé mohou číst naše y, ale my je nebudeme moct rozlišit. Pro pokrytí těchto případů doporučuji využít tzv. angažovací . Angažovací bychom poslali odběratelům, od kterých jsme například 12 měsíců nezaznamenali žádnou aktivitu. Obsahem u je text, který se dotazuje odběratele, zda chce nadále dostávat y a odkaz vyjadřující souhlas s odběrem. Pokud by odběratel po určité době nestvrdil tento souhlas, byl by automaticky odstraněn ze seznamu odběratelů Frekvence odesílání ů Každý odběratel by měl mít možnost změnit frekvenci, s jakou mu budou zasílány y. To je důležité zejména pro odesílatele, kteří často zasílají y. Někteří lidé mohou být velmi brzy frustrovaní z toho, jak často jim jsou zasílány y a zvyšuje to šanci, že nás začnou ignorovat, že se odhlásí z odběru nebo nás nahlásí za spammera. Takový uživatel by si mohl zvolit, zda chce dostávat např. každý týden, měsíc nebo jen při výjimečných událostech apod. Dnes je na marketing kladen čím dál větší důraz a je možné předpokládat, že s tím, jak se aplikace vyvíjí, bude tuto možnost podporovat stále více společností. Na obrázku 6.1 lze krásně vidět, jak by to mohlo vypadat v praxi Preference uživatelů a typy ů Kromě nastavení frekvence odesílání ů by aplikace měly odběratelům umožnit nastavit i oblasti, které je nejvíce zajímají, a ze kterých by chtěli dostávat y. Například internetové obchody často mají široký sortiment, ale zákazníka může zajímat pouze určitá část. V ideálním případě by si uživatel zvolil, že ho zajímá sortiment ledniček a mrazáků, ale už nechce dostávat y o zahradním nářadí, protože nemá zahradu, a y, které se týkají zahrad, vždy ignoruje. Tohle se samozřejmě nevztahuje pouze na internetové obchody, ale všechny možné blogy, zpravodajské servery, internetová 46

56 6. ZLEPŠOVÁNÍ DORUČITELNOSTI NA STRANĚ APLIKACE Obrázek 6.1: Nastavení frekvence odesílání ů u Bonobos zdroj: fóra apod. Umožnění uživateli zvolit konkrétní preference bude mít zcela jistě za následek větší angažovanost a také umožní odesílateli lépe cílit na určité skupiny uživatelů. 6.4 Kontrola HTML V ideálním případě by veškeré odchozí y měly být validní dle World Wide Web Consortium [50]. Spam filtry kontrolují HTML a především neuzavřené tagy mohou negativně ovlivnit skóre, které filtry u udělí. Před odesláním ů by proto měla aplikace umožnit kontrolu validity u a upozornit odesílatele na případné problémy. Pro validace je možné použít SOAP API přímo od W3C dostupné na ové filtry jsou samozřejmě mnohem sofistikovanější a provádějí mnoho různých testů. Pro legitimního uživatele je, dle mého názoru, základní kontrola HTML zcela dostačující. Předpokládá se, že seriózní odesílatel nebude v u používat fráze a slova vysky- 47

57 6. ZLEPŠOVÁNÍ DORUČITELNOSTI NA STRANĚ APLIKACE tující se ve spamech, provádět obfuskaci HTML, odkazovat na URL z blacklistů apod. Šance, že legitimní odesílatel bude využívat techniky typické pro spammery, jsou velmi malé. Je ovšem možné provést i sofistikovanější kontrolu u a to např. nainstalováním SpamAssassinu a jeho integrování do aplikace. Nevýhodou tohoto přístupu je netriviální integrace s aplikací, nutnost instalace SpamAssassinu a fakt, že konfigurace jednotlivých instancí SpamAssassinu u různých ISP se může znatelně lišit. Z mého pohledu zde převládají negativa a reálný přínos bude zanedbatelný. 6.5 Kontrola verzí u V sekci 4.2 jsem psal, že spamové filtry negativně postihují y, jejichž HTML a textová verze se značně odlišují. Ještě horším případem je, když textová verze zcela chybí. Obecně lze říct, že povinností toho, kdo píše, je ujistit se, že tyto verze budou podobné. Člověk není neomylný a aplikace může v tomto případě pomoci. Nejsnadnějším způsobem, jak toho dosáhnout, je nepovolit odeslání e- mailu, pokud není textová verze vyplněná. Dalším možným způsobem je odstranění HTML tagů a porovnání samotného textu. Tyto verze nemusí být naprosto stejné, ale čím si budou podobnější, tím věrohodněji bude působit nejen na spam filtry. V neposlední řadě lze implementovat i způsob, kdy se textová verze u bude vytvářet automaticky na základě HTML verze. Tento způsob je použitelný pro případy, kdy očekáváme, že pisatel e- mailu bude zpravidla posílat textové zprávy. Marketingové y bývají ale často plné obrázků, které nahrazují text. V takových případech je důležité, aby tvůrce u věnoval textové verzi zvýšenou pozornost. Není výjimkou, že HTML verze marketingových ů se skládá pouze z obrázků. Takový není odsouzen k vyfiltrování, ale je zpravidla dbán větší důraz na další indikátory jako je reputace odesílatele, validní autentizace a minulá aktivita příjemců tohoto odesílatele. 48

58 6.6 Workflow 6. ZLEPŠOVÁNÍ DORUČITELNOSTI NA STRANĚ APLIKACE Tvorbu marketingových ů mohou mít na starosti především grafici, marketéři a kodéři. V případě, že bude výsledný odeslán velkému množství odběratelů, je velmi důležité, aby splňoval určitá kritéria a byl v souladu s cíli firmy. Mohou nastat situace, kdy nechceme, aby je tvůrce ů mohl skutečně odeslat. Důvodem je zejména ochrana firmy a její reputace. Tento scénář lze řešit použitím workflow. Tvůrce u tak může vytvořit , ale jeho odeslání bude podmíněno souhlasem někoho jiného. Aplikace by měla podporovat alespoň základní workflow, které umožní rozesílat y pouze určitým skupinám uživatelů. Workflow nemá přímý vliv na doručitelnost ů, ale mohou nastat situace, kdy použití workflow zamezí problémům s jejich doručitelností. Příkladem může být dotčený zaměstnanec, který úmyslně odešle urážející . Tento bude uživateli vnímán velmi negativně a způsobí nárůst stížností (označení za spam) a odhlášení z odběru ů. Kromě poškozené reputace firmy dojde také ke snížení IP reputace a problémům s doručitelností ů. 6.7 Vyhodnocování kampaní V kapitole 2.4 jsem mluvil o tom, že pro vybudování dobré reputace, a s tím spojenou zvýšenou doručitelnost ů, je velmi důležité odesílat relevantní obsah, který příjemce zajímá. V případě, že nevíme, jak jsou naše y vnímány odběrateli, je těžké dosáhnout zlepšení. Velmi důležité je proto zabudovat do aplikace mechanizmus, pomocí kterého bude možné sledovat, jak příjemci interagují s našimi y. Měřit a vyhodnocovat lze zejména otevření ů (více v subsekci 6.3.2) a prokliky. K tomu, abychom mohli účinně měřit prokliky, je třeba, aby každému hypertextovému odkazu (<a> tag) vyskytujícímu se v u, byl přiřazen query string, který bude identifikovat danou kampaň. Vývojář systému může zvolit jakékoliv query stringy, ale vzhledem k popularitě a rozšířenosti Google Analytics se již používají tyto query stringy [52]: utm_source - název zdroje (Google, domain.com, Marketing e- apod.), 49

59 6. ZLEPŠOVÁNÍ DORUČITELNOSTI NA STRANĚ APLIKACE utm_medium - název zdroje ( , banner, PPC apod.), utm_term - nejčastěji obsahuje hledané výrazy (keywords), utm_content - identifikuje konkrétní reklamu (nejčastěji použitý pro A/B testy) a utm_campaign - identifikuje konkrétní kampaň. Z toho listu je zřejmé, že v ech nebudou využity všechny vyjmenované typy, ale jen ty, které budou v konkrétním případě relevantní. Velkou výhodou použití tohoto formátu je to, že lze pak jednoduše sledovat výsledky kampaně přímo v Google analytics. Nicméně aplikace by sama měla sledovat a uchovávat statistiky prokliků, aby bylo možné s daty dále pracovat v rámci aplikace a bez použití externích zdrojů. Příklad URL adresy využívajících tento způsob sledování kampaní: utm_medium= &utm_content=image_link& utm_campaign=summer_sale 6.8 Naplnění práva Obchodní y musejí v České republice a ve většině vyspělých zemí na světě splňovat určité náležitosti. Jejich nesplnění může mít, kromě nenaplnění práva, také nepřímý vliv na doručitelnost ů. Každý komerční musí například odběrateli umožňovat jednoduše a zdarma se odhlásit z odběru těchto ů 2. Odběratel nejspíše označí za spam, pokud v u nemá možnost jasně a zřetelně se odhlásit z odběru. Nepřímý vliv mohou mít i jiné náležitosti, které právo vyžaduje u těchto ů. Na odběratele může působit nevěrohodně, pokud se odlišuje od jiných obchodních ů a neobsahuje například identifikaci odesílatele, platnou 2. Zpravidla se jedná o tzv. unsubscribe link 50

60 6. ZLEPŠOVÁNÍ DORUČITELNOSTI NA STRANĚ APLIKACE zpětnou adresu apod. Cílem aplikace by měla být kontrola, zda odesílaný obchodní obsahuje potřebné náležitosti (ty, které lze kontrolovat) a neumožnit odeslat, dokud nebudou splněny. I když se nejedná o přímou souvislost s doručitelností, považuji tyto právní povinnosti za důležité, a proto rozeberu seznam požadavků vztahujících se na Českou republiku a USA Česká republika V České republice je šíření obchodního sdělení rozebráno v 7 zákona č. 480/2004 Sb. Zákon povoluje rozesílání obchodních sdělení, pouze pokud jsou splněny následující náležitosti [53]: uživatel dal souhlas k odesílání, každý obsahuje jasnou a zřetelnou možnost odhlášení z odběru ů, je jasně označen jako obchodní sdělení, neukrývá totožnost odesílatele a je zaslán společně s platnou zpáteční adresou, na kterou by uživatel případně zaslat informace o tom, že si nepřeje nadále dostávat obchodní y USA V USA od roku 2003 existuje CAN-SPAM zákon, který se zabývá problematikou odesílání obchodních ů. Hlavní požadavky tohoto zákona jsou: uvedení pravdivých informací v hlavičce u ( From, To a Reply-To ), předmět u musí korespondovat s obsahem, označení u za obchodní sdělení/reklamu, uvedení vlastní fyzické adresy, 51

61 6. ZLEPŠOVÁNÍ DORUČITELNOSTI NA STRANĚ APLIKACE umožnění uživatelům zdarma a jednoduše se odhlásit z odběru budoucích obchodních ů a skutečně odhlásit uživatele z odběrů do 10-ti pracovních dnů. Plné znění zákona, spolu s příklady jednotlivých situací, lze nalézt na oficiálních webových stránkách státního obchodního úřadu (Federal trade commission) [54]. 6.9 Shrnutí Cílem této kapitoly je navrhnout způsoby a metody, které lze naprogramovat v rámci aplikace, a které v přímém i nepřímém důsledku přispějí ke zlepšení doručitelnosti ů. Z logiky jednotlivých metod lze předpokládat, že dojde také ke zlepšení vztahu s odběrateli a zlepšení reputace firmy/značky jako takové. Aplikace nicméně nemůže zaručit, že odesílané y budou správné, vždy bude v konečném důsledku záležet na člověku samotném. 52

62 7 Implementace modulu v Kentico CMS V předešlé kapitole jsem navrhl systém, který lze využít při tvorbě aplikace zodpovědné za ovou komunikaci. Smyslem této části je implementovat vybrané techniky v CMS 1 Kentico CMS. Po prozkoumání stávajících možností Kentico CMS a možného přínosu mého modulu jsem se rozhodl pro implementaci integrace se systémem SendGrid. Modul má za cíl spravovat vybrané aplikace přímo z prostředí Kentico CMS a automatizovaně zpracovávat data z různých aplikací, které SendGrid zasílá na základě uživatelských požadavků. 7.1 SendGrid SendGrid patří mezi nejlepší poskytovatele ových služeb. Primárně slouží jako SMTP server pro odesílání velkého množství e- mailů. SendGrid poskytuje mnoho vlastních aplikací, které pomohou zákazníkům smysluplně a účinně spravovat y a kontakty. Primárním cílem je pomoci zákazníkům dosáhnout co nejvyšší doručitelnost ů a pomoci jim vyhodnocovat ové kampaně. 7.2 Integrace s Kentico CMS Integrace s Kentico CMS je docíleno využitím Web API [55], které SendGrid poskytuje svým zákazníkům. Komunikace je tedy docíleno skrze HTTP protokol a jeho POST/GET dotazovacích metod. PUT a DELETE metody nejsou v modulu využity, protože je SendGrid pro tento účel nevyužívá. SendGrid podporuje mnoho způsobů, jakým jej lze integrovat s externími systémy. Pro tento modul jsem zvolil integraci s tzv. aplikacemi SendGridu, jejichž kompletní výčet lze najít v oficiální dokumentaci [57]. Součástí modulu jsou následující aplikace: Event notification, 1. Content management system - systém pro správu webových aplikací 53

63 Spam checker, Google analytics Domain keys, Address whitelist, BCC, Click tracking a Open tracking. 7. IMPLEMENTACE MODULU V KENTICO CMS Modul umožňuje nakonfigurovat tyto aplikace přímo z Kentico CMS a automatizovaně zpracovávat data, která SendGrid v rámci některých aplikací zasílá (např. notifikace o nedoručených ech apod.). Součástí modulu nejsou všechny aplikace, které SendGrid nabízí, ale vybral jsem ty nejdůležitější a nejpřínosnější. 7.3 Architektura modulu Zdrojový kód jsem implementoval jako samostatný projekt 2 a uživatelské rozhraní spolu s konfigurací jako samostatný modul v Kentico CMS. Modul v Kentico CMS označuje ucelenou jednotku poskytující určitou funkcionalitu, která může obsahovat vlastní uživatelská rozhraní, nastavení, třídy (resp. databázové tabulky) apod. Podrobnější informace o modulech v Kentico CMS lze nalézt v dokumentaci [58]. Základní architekturu modulu lze vidět na obrázku 7.1. Jádro synchronizace tvoří abstraktní třída SynchronizationAbstract, která registruje jednotlivé aplikace ze SendGridu a umožňuje jejich konfiguraci a synchronizaci. Data, která odesílá SendGrid jsou zachycena pomocí frameworku ASP.NET Web API 2 [59]. Modul lze jednoduše rozšířit o další aplikace vytvořením vlastní C# třídy implementující třídu Synchronization abstract. Tato abstraktní třída obsahuje mnoho pomocných metod pro synchronizaci a dvě abstraktní metody, které musí programátor implementovat. Tyto metody jsou: 2. Class library 54

64 IsSynchronized() a Synchronize(). 7. IMPLEMENTACE MODULU V KENTICO CMS. První zmíněná metoda slouží k identifikování, zda je nastavení v Kentico CMS shodné s nastavením u SendGridu a druhá metoda slouží k přenesení nastavení z Kentico CMS do SendGridu. Obrázek 7.1: Architektura modulu zdroj: vlastní 7.4 Synchronizace a implementace Aby se nastavení z Kentico CMS promítly do SendGridu, je potřeba je synchronizovat. Pro tento účel jsem vytvořil vlastní uživatelské rozhraní, které porovná aktivní konfigurace na SendGridu a v Kentico CMS. V případě, že se konfigurace liší, systém upozorní, že je 55

65 7. IMPLEMENTACE MODULU V KENTICO CMS třeba provést synchronizaci. Ukázku z rozhraní lze vidět na obrázcích 7.2 a 7.3. Obrázek 7.2: Ukázka synchronizovaného nastavení zdroj: vlastní Event notification Event notification aplikace umožňuje využít tzv. Webhooky, které zašlou data na vybranou URL skrze HTTP POST s informací o určité akci, která právě nastala. Mezi tyto akce, na které se lze navázat, patří například doručení u, bounce, zahození u, označení u za spam jeho příjemcem apod. Modul umožňuje uživateli přímo z Kentico CMS nastavit monitorování: bounce ů, zahozených ů a označení za spam (viz ). Modul také umožňuje nastavit, zda mají být odběratelé, u kterých tato akce nastala, automaticky odhlášeni z odběru všech kampaní. 56

66 7. IMPLEMENTACE MODULU V KENTICO CMS Obrázek 7.3: Ukázka desynchronizovaného nastavení zdroj: vlastní U bounce 3 ů lze také nastavit jejich limit, než bude odběratel odhlášen. Dále je také možné nastavit ovou adresu, kam budou notifikace o těchto akcích odesílány, aby mohly být případně zpracovány člověkem, který posoudí jejich validitu. Důvodem je to, že například u zahozených ů nemusí být vždy jasné, jaký byl důvod jejich zahození. Je třeba, aby člověk přečetl chybovou hlášku a učinil adekvátní akce. Ve většině případů je nicméně dostatečné nechat systém automaticky odhlásit odběratele a až na základě notifikace může uživatele znova zprovoznit. Velkou výhodou je to, že se vše děje automaticky v okamžiku, kdy tato akce nastane. Výčet všech možností lze vidět na obrázku 7.4. Pro zasílání notifikací jsou využity ové šablony s kontextovými makry tak, aby si je mohl uživatel sám upravit na základě svých potřeb. Více informací o ových šablonách lze nalézt v dokumentaci [56] Kentico CMS. Ukázku takové šablony je vidět na 3. Bounce y v tomhle kontextu značí pouze soft bounce, hard bounce je zařazen do kategorie zahozených ů 57

67 7. IMPLEMENTACE MODULU V KENTICO CMS Obrázek 7.4: Ukázka možností nastavení Event notification aplikace zdroj: vlastní obrázku Spam checker Spam checker je velmi vhodná pro situace, kdy uživatelé systému mohou odesílat y. V CMS systémech, Kentico CMS nevyjímaje, je to samozřejmost. K tomu, aby se předešlo odesílání ů, které mohou být přijímacími servery považovány za spam, je možné nechat text u ověřit. Spam checker využívá interně SpamAssas- 58

68 7. IMPLEMENTACE MODULU V KENTICO CMS Obrázek 7.5: Ukázka šablony pro bounce notifikaci zdroj: vlastní sin, který hodnotí y na stupnici Aplikace umožňuje nastavit minimální skóre, které musí splňovat, aby byl předán SMTP serveru k odeslání. V případě, že má nižší skóre než je definováno, je zahozen. Modul automaticky nastaví, aby Send- Grid odeslal report tohoto u na interní URL, která jej zpracuje a následně odešle uživateli, který je definován v nastavení modulu. Uživatel tak uvidí, jaký neprošel kontrolou a proč. Ukázka reportu z vadného u je na obrázcích 7.6 a 7.7. Notifikační lze opět nastavit pomocí ových šablon s využitím kontextových maker. 59

69 7. IMPLEMENTACE MODULU V KENTICO CMS Obrázek 7.6: Ukázka první části spam reportu zdroj: vlastní Obrázek 7.7: Ukázka druhé části spam reportu zdroj: vlastní 60