Doručitelnost ů

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

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

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

Shrnutí Práce se věnuje doručitelnosti e-mailů 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í e-mailové 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

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

Obsah 1 Úvod................................ 1 2 Reputace.............................. 2 2.1 Reputace IP adresy..................... 2 2.1.1 Míra stížností.................... 4 2.1.2 Past na spamy.................... 6 2.1.2.1 Recyklované pasti............ 6 2.1.2.2 Klasické pasti............... 7 2.1.2.3 Podvržené pasti............. 8 2.1.2.4 Doporučení................ 8 2.1.3 Neznámí uživatelé................. 9 2.1.4 Počet odesílaných e-mailů............. 9 2.1.5 Konzistence v odesílání e-mailů......... 10 2.1.6 Blacklisty...................... 12 2.1.7 Whitelisty...................... 13 2.1.8 Autentizace..................... 14 2.2 Reputace domény...................... 14 2.3 Měření reputace....................... 14 2.3.1 SenderScore..................... 15 2.3.2 SenderBase..................... 15 2.3.3 Doporučení..................... 16 2.4 Budování reputace..................... 16 3 Autentizace............................ 18 3.1 Motivace a klasické útoky................. 18 3.2 Autentizační metody.................... 19 3.2.1 ISP a využití autentizačních metod........ 20 3.3 DKIM............................. 20 3.3.1 Prvky......................... 21 3.3.2 Princip........................ 22 3.3.3 Výhody a nevýhody................ 24 3.3.4 Shrnutí........................ 25 3.4 DomainKeys......................... 25 3.4.1 Shrnutí........................ 26 3.5 SPF.............................. 26 3.5.1 Princip........................ 26 3.5.2 Syntaxe........................ 27 vi

3.5.3 Shrnutí........................ 28 3.6 SenderID........................... 29 3.6.1 Shrnutí........................ 29 4 Filtrování podle obsahu..................... 31 4.1 Analýza hlavičky e-mailu................. 31 4.2 Analýza těla e-mailu.................... 33 4.3 Bayesův spam filtr..................... 34 5 Existující e-mailové filtry.................... 36 5.1 Typy e-mailových filtrů................... 36 5.1.1 Serverové filtry................... 37 5.1.1.1 SpamAssassin.............. 37 5.1.1.2 Anti-Spam SMTP Proxy Server..... 38 5.1.2 Lokální filtry.................... 38 5.1.2.1 Thunderbird............... 39 5.1.2.2 Outlook.................. 39 6 Zlepšování doručitelnosti na straně aplikace......... 41 6.1 Motivace........................... 41 6.2 Získávání odběratelů.................... 42 6.2.1 Opt-out....................... 42 6.2.2 Opt-in........................ 43 6.2.3 Confirmed opt-in.................. 43 6.2.4 Double opt-in.................... 44 6.2.5 Shrnutí........................ 44 6.3 Udržování seznamu odběratelů.............. 44 6.3.1 Odstraňování neexistujících e-mailových adres. 45 6.3.2 Odstraňování neaktivních odběratelů...... 45 6.3.3 Frekvence odesílání e-mailů............ 46 6.3.4 Preference uživatelů a typy e-mailů....... 46 6.4 Kontrola HTML....................... 47 6.5 Kontrola verzí e-mailu................... 48 6.6 Workflow........................... 49 6.7 Vyhodnocování kampaní.................. 49 6.8 Naplnění práva....................... 50 6.8.1 Česká republika................... 51 6.8.2 USA......................... 51 6.9 Shrnutí............................ 52 7 Implementace modulu v Kentico CMS............ 53 7.1 SendGrid........................... 53 vii

7.2 Integrace s Kentico CMS.................. 53 7.3 Architektura modulu.................... 54 7.4 Synchronizace a implementace.............. 55 7.4.1 Event notification.................. 56 7.4.2 Spam checker.................... 58 7.4.3 Google analytics.................. 61 7.4.4 Domain Keys.................... 61 7.4.5 Address whitelist.................. 61 7.4.6 BCC......................... 61 7.4.7 Click/open tracking................ 62 7.5 Shrnutí............................ 62 8 Závěr................................ 63 9 Literatura.............................. 64 A Seznam elektronických příloh................. 73 viii

Seznam obrázků 2.1 E-maily označené za spam................. 4 2.2 Schéma FBL......................... 5 2.3 Blacklist........................... 13 3.1 Výsledek dotazu na DKIM záznam............ 23 3.2 Výsledek dotazu na SPF záznam............. 27 3.3 Rozhraní aplikace MxToolBox............... 28 3.4 SenderID........................... 30 4.1 Filtrovaní e-mailů...................... 32 5.1 Ukázka filtrovacího pravidla v aplikaci Thunderbird.. 40 6.1 Nastavení frekvence odesílání e-mailů u Bonobos... 47 7.1 Architektura modulu.................... 55 7.2 Ukázka synchronizovaného nastavení.......... 56 7.3 Ukázka desynchronizovaného nastavení......... 57 7.4 Ukázka možností nastavení Event notification aplikace 58 7.5 Ukázka šablony pro bounce notifikaci.......... 59 7.6 Ukázka první části spam reportu............. 60 7.7 Ukázka druhé části spam reportu............. 60 ix

1 Úvod V této diplomové práci se budu zabývat problematikou doručitelnosti e-mailových zpráv. V dnešní době tvoří většinu světové e-mailové 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 e-mailu. Následkem toho je stále složitější odeslat e-mail 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í e-mailů. Nicméně, at už jednotlivci nebo firmy, které využívají e-mailovou komunikaci, chtějí dosáhnout toho, aby co nejvíce jejich e-mailů 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 e-mailové komunikace a e-mailové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 e-mailový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 e-mailové 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

2 Reputace V této kapitole se zaměřím na reputaci, která ve světě e-mailu znamená vlastně to, jak určitou doménu 1 nebo IP adresu, ze které jsou odesílány e-maily, vidí ISP (Internet service provider poskytovatel připojení k internetu) a jaký to má vliv na doručitelnost e-mailů. 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í e-mailové 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 e-mail bude přijat ISP příjemcem a to, zda skončí v e-mailové 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 e-mailů, zejména v případech, kdy jde o odesílání velkého počtu e-mailů (desetitisíce měsíčně a více), z důvodu, že jednotliví ISP si uchovávají statistiky přijímaných e-mailů 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í e-maily. 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 e-mailu. Každý přijímaný e-mail musí vždy projít přes ISP příjemce, který automaticky zaznamenává informace o e-mailu a jeho původu. Na základě řady metrik tento ISP ohodnotí odesílatele e-mailu a bud propustí e-mail 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ě e-mailové 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é e-mailové komunikace na světě, měsíčně odešle přes 14 miliard e-mailů 2

2. REPUTACE SenderScore Přijaté e-maily 0-10 2% 11-20 6% 21-30 10% 31-40 11% 41-50 13% 51-60 20% 61-70 36% 71-80 58% 81-90 79% 91-100 92% Tabulka 2.1: Doručitelnost dle SenderScore neznámí uživatelé, počet odesílaných e-mailů, konzistence v odesílání e-mailů, 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 e-maily 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 e-mailu. Výzkum také ukázal, že téměř žádný legitimní e-mail nepochází od odesílatelů, kteří mají SenderScore menší než 71. Na druhou stránku 14% ze všech e-mailů je odesláno těmi nejlepšími odesílateli se SenderScore 99-100. Pouze 0.03% z nich je označeno za spam 3. Inbox placement rate 3

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 99-100 a tohle si dlouhodobě udržet, protože i sebemenší odchylky se mohou projevit v mnohonásobně nižší doručitelnosti e-mailů. Obrázek 2.1: E-maily označené za spam zdroj: [5] 2.1.1 Míra stížností Stížnosti jsou relevantní pouze v případech, kdy e-mail 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é e-mailové schránky, přes telefon, nebo pomocí jiné formy technické podpory označit (nutno podotknout, 4

2. REPUTACE že forma označování jinou formou než v rámci e-mailové schránky bude dnes minimální) příchozí e-mail 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í e-mailů za spam má vliv na reputaci odesílatele, jde zároveň i o velmi prospěšný způsob, jak může odesílatel e-mailů monitorovat úspěšnost své kampaně a případně odebrat ty e-mailové adresy, jejichž majitelé odeslali stížnost. Díky tomu už v budoucnu nebudou tomuto uživateli žádné další e-maily 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ů e-mailový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 e-mailu u jednotlivých ISP nebo poskytovatelů e-mailový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 e-mailové 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

2. REPUTACE který se vyvinul v dnes nejčastěji používaný standard RFC 59652. Tento standard přinesl zavedení nového MIME 5 typu: multipart/report. 2.1.2 Past na spamy Pasti na spamy (anglicky spam traps ) označují e-mailové 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 e-mailová adresa není používána žádným skutečným uživatelem, ale je aktivně monitorována. Veškerý přijatý e-mail 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é e-mailové adresy, můžeme rozdělit past na spamy do 3 základních kategorií [8]: recyklované pasti, klasické pasti a podvržené pasti. 2.1.2.1 Recyklované pasti Pod tuto kategorii patří e-mailové 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í e-mailová adresa, jako např. RichardS@companyA.com. V okamžiku, kdy uživatel RichardS odejde ze společnosti CompanyA, jeho e-mailová adresa je zrušena. Pokud na takovou e-mailovou 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 e-mailovou adresu. V ideálním případě by měl původce e-mailu ihned po přijetí zprávy odstranit tuto e-mailovou adresu ze svého seznamu odběratelů tak, aby v budoucnu již nebyly na tuto adresu odesílány žádné e-maily. 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

2. REPUTACE V určitém okamžiku se ISP může rozhodnout, že e-mailovou adresu opět aktivuje a dovolí ji přijímat e-maily. 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 e-mailovou adresu odstranit ze svých kontaktů. E-maily, 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í e-mailových adres. Vzhledem k faktu, že není možné zjistit, která e-mailová adresa zastává funkci spamové pasti, je třeba dbát na to, abychom udržovali čistý 6 seznam e-mailových adres a pravidelně odstraňovali neaktivní odběratele. 2.1.2.2 Klasické pasti Klasické pasti označují ty e-mailové 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 e-mailových zpráv (tzv. newsletter) a díky tomu se veškerý e-mail, 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 e-mail 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 e-mailů 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 e-mailových adres je myšlen seznam, který obsahuje pouze e-mailové adresy uživatelů, kteří mají zájem dostávat e-maily a vykazují určitou formu aktivity. 7. Sender s score je systém ohodnocení jednotlivých IP adres dle jejich reputace v rozmezí od 0-100. Čím větší je reputace, tím roste šance na doručení e-mailu 7

2. REPUTACE 2.1.2.3 Podvržené pasti Tyto e-mailové 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 e-mailové 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 e-mailová adresa použita. 2.1.2.4 Doporučení Neexistuje stoprocentní sada instrukcí, která by zaručila, že e-maily 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 e-mailových adres ( me@@mail.uk, richards[neco]gmail.net apod.) odmítání @abuse a @postname 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 e-maily 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í e-mailových adres z online formulářů, poskytování možnosti uživateli změnit e-mailovou 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

nekupování a nepoužívání e-mailový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 e-maily. 2.1.3 Neznámí uživatelé Neznámí uživatelé (anglicky unknown users ) označují podíl nenalezených uživatelů (resp. jejich e-mailových adres) a celkového množství odesílaných e-mailů. Za problematickou hodnotu podílu nenalezených uživatelů se považuje 1% z celkového počtu odeslaných e-mailů [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 e-mailů. Může to být dáno například tím, že takový subjekt vyžaduje ověření e-mailový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]. 2.1.4 Počet odesílaných e-mailů To, kolik e-mailů odesíláme je, často stejně důležité jako jejich obsah. ISP, kteří zpracovávají e-maily, je uchovávají a analyzují. To, jak často a v jakém množství jsou e-maily odesílány, je jeden z faktorů, které ISP pozorně kontrolují. Cílem je nalézt určitou konzistenci v tom, jak často budou e-maily rozesílány. V případě, že měsíc neodešleme ani jeden e-mail a pak se 9

2. REPUTACE najednou rozhodneme odeslat 300 000 e-mailů v rámci nové kampaně, je dost možné, že nás někteří ISP budou považovat za spammery a nepropustí tyto e-maily 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í e-mailů 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ž 10 000 e-mailů, neměli bychom upoutat zvýšenou pozornost ISP, ale pokud toto množství budeme výrazně převyšovat, je doporučeno e-maily 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 e-mail marketingu. Jeho doporučení je ve stanovení celkového počtu e-mailů, 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 50 000 e-mailů, 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 1000-2000 e-mailů denně. ISP si uchovávají měsíční výsledky všech odeslaných e-mailů 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 e-mailů zvyšovat. 2.1.5 Konzistence v odesílání e-mailů ISP uchovávají i informace o tom, kdy a kolik e-mailů 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

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 e-mailů, 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 e-mailů, 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ý e-mail a pak jich najednou odešleme 50 000. ISP se to může zdát podezřelé a může naše e-maily zahodit nebo je začít propouštět po částech. Nelze určit přesný počet e-mailů, které bychom měli posílat. Je zde příliš mnoho faktorů (zejména celkové množství e-mailů, 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 e-maily, bude rozesílat i e-maily 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í e-mailů, 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í e-maily 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 e-mailů, 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 e-mailů 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

2. REPUTACE resu. Sdílené IP jsou levnější a odpadá zde režie a řízení objemu odesílaných e-mailů 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í e-mailů, je výhodné si zřídit dedikovanou IP adresu. Většina ESP nabízí jak dedikované, tak i sdílené IP adresy. 2.1.6 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 e-mail z této IP bude doručen, ale slouží pouze jako služba, kterou ISP využívají při kontrole původce e-mailu. 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 e-mailem. 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 e-mailů. Mezi nejznámější veřejné blacklisty patří zejména: Spamhaus (http://www.spamhaus.org/), Barracuda Reputation Block List (http://www.barracudacentral.org/rbl), SpamCOP (http://www.spamcop.net/), MX ToolBox (http://mxtoolbox.com/supertool.aspx) a MultiRBL (http://multirbl.valli.org). Jakým způsobem může fungovat blacklisting lze vidět na přiloženém obrázku2.3. Velký počet označení e-mailů 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

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ů. 2.1.7 Whitelisty Whitelist naopak od blacklistu obsahuje seznam domén/ip adres, od kterých chceme dostávat e-maily. V dnešní době je používaný zejména na straně příjemce a pouze v případě, kdy e-mail je doručen do naší schránky. Může se stát, že ISP označí e-mail nesprávně za spam. V takových případech je vhodné nastavit daného příjemce do whitelistu. Odesílatel e-mailu nemůže ovlivnit to, jak se uživatelé zachovají, ale v případě, že registruje problémy s doručitelností e- 13

2. REPUTACE mailů, by bylo vhodné upozornit uživatele jak na svých e-mailových stránkách (např. po odeslání objednávky, registraci uživatele apod.), tak přímo i v e-mailu. 2.1.8 Autentizace Autentizace je jeden z faktorů, který je čím dál více prosazovaný a používaný. Autentizací prokazujeme, že e-mail 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

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. 2.3.1 SenderScore Reputace je v rámci SenderScore udávána hodnotami 0-100 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]. 2.3.2 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. E-mailové zprávy od tohoto odesílatele budou pravděpodobně filtrovány a neutral - nejčastěji značí nedostatek dat a e-maily projdou podrobnějším filtrovacím procesem. 15

2. REPUTACE 2.3.3 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í e-mailů. 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í e-mailů v kampaních, zasílat relevantní obsah, který bude odběratele zajímat (eliminace stížnostní, větší šance prokliků, zobrazení e-mailů apod.), pravidelně odstraňovat odběratele, kteří dlouhodobě nevykazují žádnou aktivitu, kontrolovat validitu e-mailových adres (e-maily posílané na nevalidní/neexistující adresy mohou snižovat reputaci), používat e-mailovou autentizaci, při použití dedikované IP adresy použít IP warming, pravidelně monitorovat blacklisty a 16

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í e-mailu není reputace jediným měřítkem, ale vstupují zde i další faktory. E-maily především podléhají dalšímu filtrování (zejména obsahu a HTML kódu) po jejich přijetí ze strany ISP. 17

3 Autentizace Autentizace e-mailový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 e-mail 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 e-mailů je autentizováno metodou DKIM (DomainKey Identified Email) a/nebo SPF (Sender Policy Framework) [18]. 3.1 Motivace a klasické útoky E-mailová 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 e-mailu 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 e-maily za tuto e-mailovou adresu (resp. její doménu). Díky tomu je velmi snadné podvrhnout hlavičku e-mailu tak, že zpráva bude vypadat, jako by přišla z jiné adresy. Podvržení e-mailu 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ů e-mailových adres. Podvodný e-mail se často maskuje jako e-mail od populárních webových stránek, jako jsou aukční portály, sociální sítě nebo internetové bankovnictví. E-mail může obsahovat 18

3. AUTENTIZACE loga těchto webových stránek a všech dalších náležitostí e-mailu tak, že je k nerozpoznání od toho pravého. V těchto e-mailech č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 e-maily 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 80 000 uživatelů se stane obětí phishingu a poskytne své citlivé informace [20]. Phishingové e-maily 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]. E-mailová autentizace se snaží řešit právě tento problém a slouží k ověření a případnému zablokování podvodných e-mailů. 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 e-mail může být doručen. Naopak pokud je e-mail autentizován, je velmi pravděpodobné, že jej ISP zablokuje a nebude doručen do schránky příjemce. Například Google blokuje 100% e-mailů, které nejsou autentizovány pomocí DKIM [21]. Nutno podoktnout, že to, zda e-mail 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 e-mailových zpráv lze rozdělit na dvě základní kategorie: Autentizace IP adres a Kryptografická autentizace. 19

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 e-mail 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 e-mailu 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. 3.2.1 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

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 e-mailové 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]. 3.3.1 Prvky DKIM popisuje dvě skupiny prvků. Ti, kteří e-mail 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í e-mailové 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 e-mailové/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

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. 3.3.2 Princip DKIM je kompatibilní se současným e-mailovým systémem a nevyžaduje žádné podstatné změny v infrastruktuře. V e-mailové zprávě se DKIM projevuje pouze přidáním nového pole DKIM-Signature do hlavičky e-mailu. 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é e-mailové 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 e-mailové 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 e-mailová 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í e-mailový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

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 e-mailu [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

3. AUTENTIZACE Po ověření autentizace bude do hlavičky e-mailu 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 208.64.202.37 as permitted sender) smtp.mail=noreply@steampowered.com; dkim=pass header.i=@steampowered.com 3.3.3 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 e-mailových zpráv od určité domény (za předpokladu, že bude ISP filtrovat příchozí e-maily a ověřovat autentizaci), příjemce ví odkud e-mailová 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 e-mailová 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 e-mailů (takové e-maily 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

3. AUTENTIZACE změny v obsahu nebo hlavičky podepsané e-mailové 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é e-mailové 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 e-mailové zprávy je validní a nejde o spam. Pouze říká, odkud byl e-mail odeslán a nepředepisuje, co by se mělo s e-mailovou 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 e-mailového klienta. 3.3.4 Shrnutí V dnešní době, kdy velkou část e-mailový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é e-mailový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 e-mailů 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 e-mailu, 25

3. AUTENTIZACE nemožnost delegovat podepisování na vnější subjekty a neexistující timeout podpora pro verifikaci DNS záznamů. 3.4.1 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 e-mailový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]. 3.5.1 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 e-mailové zprávy za danou doménu. Příjemci e-mailové 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 e-mailovou 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

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 (http://mxtoolbox.com/spf.aspx) nebo Kitterman (http://www.kitterman.com/spf/validate.html). MxToolBox poskytuje grafický a přehledný výstup spolu s popisem jednotlivých částí SPF záznamu pro jeho snadnější interpretaci. 3.5.2 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 e-mailový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

3. AUTENTIZACE Obrázek 3.3: Rozhraní aplikace MxToolBox zdroj: http://mxtoolbox.com/ Příklad pravidla, které říká, že doména neposílá žádné e-maily, a proto by všechny e-maily odesílané z této domény měly být odmítnuty. v=spf1 -all Pravidlo, které povoluje odesílat e-mailové zprávy z jakékoliv adresy pouze v rozmezí 192.168.0.1 192.168.255.255. Všechny e-maily 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:192.168.0.1/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]. 3.5.3 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

3. AUTENTIZACE a nevaliduje From: v hlavičce e-mailu z důvodu komplexnosti, kterou by to přineslo [32]. V praxi to znamená, že e-mail, 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 e-mailů 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ý e-mail není spam. Smyslem SPF ale není garance nezávadnosti e-mailové 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 e-mailových adres v hlavičce e-mailu (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 e-mailové zprávy. 3.6.1 Shrnutí V tabulce zobrazující používané techniky poskytovatelů e-mailový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

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

4 Filtrování podle obsahu E-mailová autentizace a reputace IP adres nejsou jediné způsoby, podle kterých se určuje, zda je příchozí e-mail 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í e-mailový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 e-mailový 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 e-mailovým klientem. Tento typ filtru je možné použít jen v případě, kdy máme přístup k e-mailovému serveru [4]. Typy e-mailových filtrů jsou podrobněji rozebrány v kapitole 5. Chtěl bych upozornit na rozdíl mezi obecným filtrováním e-mailů, filtrováním obsahu e-mailů a e-mailovými filtry, protože tyto pojmy lze snadno zaměňovat. E-mailové filtry označují programy, které vykonávají e-mailové filtrování. E-mailové 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 e-mailu Samotnému obsahu e-mailu vždy předchází tzv. hlavička e-mailu, která identifikuje a popisuje daný e-mail. 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

4. FILTROVÁNÍ PODLE OBSAHU Obrázek 4.1: Filtrovaní e-mailů zdroj: vlastní Spammeři odesílají velké množství e-mailů a využívají k tomu často praktiky, které již v hlavičce e-mailu 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í e-mailové adresy, použití stejné e-mailové 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

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 e-mailu 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ý e-mailový filtr může využívat odlišná pravidla. 4.2 Analýza těla e-mailu Tělo e-mailu (označováno jako body ) je to, co vidí uživatel, když otevře e-mail. Testování probíhá stejně jako v případě analýzy hlavičky. Největší charakteristiky spamu jsou v případě těla e-mailu: e-maily obsahující pouze HTML verzi (e-mail 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 e-mailu 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

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 e-mailu, 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 e-mailu rovná spamu. Na rozdíl od jednoduchých obsahových filtrů, které mohou zkoumat pouze jednotlivá slova nebo fráze obsažené v e-mailu, se Bayesův filtr postupně automaticky učí z legitimních e-mailů a spamů. Bayesův spam filtr dokáže rozeznat dobrý e-mail 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 e-mailu (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% e-mailech, 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 e-mailech, je mu přiřazeno skóre nízké. Pokud e-mail obsahuje oboje slova, není jasné, zda se jedná o spam nebo legitimní e-mail. Výsledné skóre pak bude záviset na dalších slovech a frázích obsažených v e-mailu, které budou zkoumány stejným způsobem. Vždy se zkoumá obsah celého e-mailu 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é e-maily. To, co pro jednoho uživatele je spam, může pro jiného být všední a legitimní e-mail. 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

4. FILTROVÁNÍ PODLE OBSAHU extra dat do e-mailu, 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 e-mailech. Pokud je e-mail 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

5 Existující e-mailové filtry E-mailové filtry lze označit za množinu programů, které zajišt ují samotné filtrování e-mailů (lze filtrovat příchozí i odchozí e-mailové zprávy), tzn., rozhodují o tom, zda bude e-mail přijat, pozměněn, přeposlán nebo zahozen. Pro vyhodnocení e-mailové 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 e-maily 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 e-mailů. Zmiňuji to zejména z toho důvodu, že neexistuje sada jednoznačných pravidel, která zajistí, že e-mail 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 e-mail, 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í e-mailu se soustředit na tyto principy tak, aby riziko nepřijetí e-mailu bylo co nejmenší. 5.1 Typy e-mailových filtrů E-mailové filtry lze rozdělit na dvě základní kategorie: serverové filtry a lokální filtry. 36

5. EXISTUJÍCÍ E-MAILOVÉ FILTRY 5.1.1 Serverové filtry Serverové filtry jsou programy, které jak jejich název napovídá, provádějí filtrování e-mailů na straně serveru při jejich přijetí. Filtrovat e-maily na serveru bude zcela jistě každý solidní poskytovatel e-mailových služeb (Gmail, Seznam.cz, Centrum.cz apod.). E-maily, 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 e-mailů, ale je třeba dávat pozor i na tzv. false positives, kdy dojde k vyfiltrování legitimních e-mailů. 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. 5.1.1.1 SpamAssassin SpamAssassin je nejznámější open-source program určený pro filtrování e-mailový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 e-mail 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í e-mailové zprávy, jsou následující [47]: analýza hlavičky e-mailu, analýza těla e-mailu, Bayesovo filtrování, automatická kontrola adres z blacklistů a whitelistů, 37

5. EXISTUJÍCÍ E-MAILOVÉ 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]. 5.1.1.2 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 e-mailu a další. 5.1.2 Lokální filtry Lokální filtry označují programy, které jsou schopny filtrovat e-maily lokálně u uživatele. Tyto programy umožňují zpravidla nastavit jednoduchá pravidla pro filtrování příchozích e-mailů 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 e-mailu, kterou přidává SpamAssassin po vyhodnocení 38

5. EXISTUJÍCÍ E-MAILOVÉ FILTRY e-mailu [44], nebo i přímá integrace, kdy e-mailový klient použije tento program. V takovém případě musí e-mailový 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í e-mailů. Existuje velké množství různých e-mailových klientů. Mezi nejznámější patří zejména Thunderbird a Outlook. 5.1.2.1 Thunderbird Thunderbird je e-mailový 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 e-mailovým filtrováním poskytuje Thundebird možnost vytváření vlastních filtrů, které na základě vlastnosti e-mailové zprávy (jako je odesílatel, tělo e-mailu, nadpis apod.) a jednoduchého pravidla (obsahuje, neobsahuje, začíná na apod.) může uskutečnit nějakou akci (dát e-mail do jiné složky, smazat e-mail, 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]. 5.1.2.2 Outlook Outlook je produkt společnosti Microsoft a kromě e-mailové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

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

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í e-mailů 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 e-mailový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 e-maily (phishing, spoofing), které mohou poškodit reputaci značky a snížit důvěru uživatele číst a dále pracovat s e-maily. Cíle, ke kterým by měly firmy, dle mého názoru, směrovat, jsou především: odesílání e-mailů, o které uživatelé mají zájem, faktické doručení e-mailů do schránky příjemců, zabezpečení e-mailů 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í e-mailů. Tyto zahrnují [1]: získávání odběratelů, udržování seznamu odběratelů, kontrola HTML, 41

6. ZLEPŠOVÁNÍ DORUČITELNOSTI NA STRANĚ APLIKACE kontrola verzí e-mailu, 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 e-mailů. Pokud například zašleme e-mail uživatelům, jejichž e-mail 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 e-maily 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 e-maily. Existují 4 základní typy seznamu odběratelů: opt-out, opt-in, confirmed opt-in a double opt-in. 6.2.1 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 e-mailů na jejich e-mailovou adresu. Na webové stránce je zpravidla napsáno, že provedením této akce dávají souhlas k zasílání e-mailů. 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 e-maily ignorovat, nebo je v horším případě nahlásí jako 42

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. 6.2.2 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í e-mailovou adresu. V nejhorším případě pak dojde e-mail někomu, kdo o nás nikdy neslyšel a e-mail označí za spam. 6.2.3 Confirmed opt-in Confirmed opt-in je podobný listu typu opt-in. Rozdíl je, že uživateli je zaslán tzv. děkovací e-mail, ve kterém je odkaz, který umožní uživateli odhlášení z odběru. Pokud tedy e-mail 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 e-mailovou 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 e-mailů. Uživatelé, kterým náš e-mail 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 e-maily 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

6. ZLEPŠOVÁNÍ DORUČITELNOSTI NA STRANĚ APLIKACE 6.2.4 Double opt-in Double opt-in je metoda, ve které uživatelům pro přihlášení k odběru zašleme e-mail 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 e-maily. 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 e-maily. 6.2.5 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í e-mailový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ů E-mailové 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í e-mailové adresy, odstraňovat neaktivní odběratele, umožnit odběrateli změnit frekvenci odesílání e-mailů a umožnit odběrateli zvolit typy e-mailů, 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

6. ZLEPŠOVÁNÍ DORUČITELNOSTI NA STRANĚ APLIKACE e-mailů, větší aktivitě za strany odběratelů, menšímu počtu nedoručených e-mailů a nakonec ve větší celkové doručitelnosti všech e- mailů. 6.3.1 Odstraňování neexistujících e-mailových adres Aplikace by měla automaticky sledovat bounce e-maily a přiřazovat je ke konkrétním příjemcům. V případě výskytu Hard bounce, která značí nenalezenou e-mailovou adresu, by mělo dojít k okamžitému zastavení odesílání veškerých e-mailů na tuto adresu. Soft bounce značí pouze dočasnou nemožnost doručit e-mail a v takovém případě bych doporučil odstranit odběratele po 2-3 bounce e-mailů v jednom měsíci. 6.3.2 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 e-maily a přestanou je číst. Aplikace by měla sledovat otevření e-mailů uživatelem a ukládat tyto informace pro pozdější zpracování. Problémem je, že nelze se stoprocentní jistotou zjistit přečtení e-mailu uživatelem. U HTML e-mailů lze otevření e-mailu sledovat pomocí vloženého obrázku s identifikací příjemce v jeho URL. Při otevření e-mailu se tento obrázek stáhne z našeho serveru a my můžeme na základě URL zjistit, kdo e-mail otevřel. HTML obrázku může vypadat například takhle: <img alt="hi" src="http://www.mydomain.com/img/ tracking_image.png?source=richard@email.com"> Identitu odběratele, který otevřel e-mail, 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

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 e-mailovém klientu nastaveno blokování obrázků nebo čtou e-maily pouze v plain text verzi, která nemůže obsahovat HTML. Takoví uživatelé mohou číst naše e-maily, ale my je nebudeme moct rozlišit. Pro pokrytí těchto případů doporučuji využít tzv. angažovací e-mail. Angažovací e-mail bychom poslali odběratelům, od kterých jsme například 12 měsíců nezaznamenali žádnou aktivitu. Obsahem e-mailu je text, který se dotazuje odběratele, zda chce nadále dostávat e-maily 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ů. 6.3.3 Frekvence odesílání e-mailů Každý odběratel by měl mít možnost změnit frekvenci, s jakou mu budou zasílány e-maily. To je důležité zejména pro odesílatele, kteří často zasílají e-maily. Někteří lidé mohou být velmi brzy frustrovaní z toho, jak často jim jsou zasílány e-maily 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 e-mail např. každý týden, měsíc nebo jen při výjimečných událostech apod. Dnes je na e-mail 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. 6.3.4 Preference uživatelů a typy e-mailů Kromě nastavení frekvence odesílání e-mailů 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 e-maily. 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 e-maily o zahradním nářadí, protože nemá zahradu, a e-maily, 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

6. ZLEPŠOVÁNÍ DORUČITELNOSTI NA STRANĚ APLIKACE Obrázek 6.1: Nastavení frekvence odesílání e-mailů u Bonobos zdroj: http://blog.marketo.com/wp-content/uploads/2013/09/bonobosopt-down.png 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í e-maily 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 e-mailu udělí. Před odesláním e-mailů by proto měla aplikace umožnit kontrolu validity e-mailu a upozornit odesílatele na případné problémy. Pro validace je možné použít SOAP API přímo od W3C dostupné na http://validator.w3.org/docs/api.html. E-mailové 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 e-mailu používat fráze a slova vysky- 47

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 e-mailu 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í e-mailu V sekci 4.2 jsem psal, že spamové filtry negativně postihují e-maily, 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 e-mail 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 e-mail působit nejen na spam filtry. V neposlední řadě lze implementovat i způsob, kdy se textová verze e-mailu 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é e-maily bývají ale často plné obrázků, které nahrazují text. V takových případech je důležité, aby tvůrce e-mailu věnoval textové verzi zvýšenou pozornost. Není výjimkou, že HTML verze marketingových e-mailů se skládá pouze z obrázků. Takový e-mail 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

6.6 Workflow 6. ZLEPŠOVÁNÍ DORUČITELNOSTI NA STRANĚ APLIKACE Tvorbu marketingových e-mailů mohou mít na starosti především grafici, marketéři a kodéři. V případě, že bude výsledný e-mail 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 e-mailů 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 e-mailu tak může vytvořit e-mail, 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 e-maily pouze určitým skupinám uživatelů. Workflow nemá přímý vliv na doručitelnost e-mailů, 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í e-mail. Tento e-mail 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 e-mailů. Kromě poškozené reputace firmy dojde také ke snížení IP reputace a problémům s doručitelností e-mailů. 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 e-mailů, je velmi důležité odesílat relevantní obsah, který příjemce zajímá. V případě, že nevíme, jak jsou naše e-maily 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 e-maily. Měřit a vyhodnocovat lze zejména otevření e-mailů (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 e-mailu, 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-email apod.), 49

6. ZLEPŠOVÁNÍ DORUČITELNOSTI NA STRANĚ APLIKACE utm_medium - název zdroje (e-mail, 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 e-mailech 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í: www.mydomain.com/products?utm_source=new_products& utm_medium=email&utm_content=image_link& utm_campaign=summer_sale 6.8 Naplnění práva Obchodní e-maily 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 e-mailů. Každý komerční e-mail musí například odběrateli umožňovat jednoduše a zdarma se odhlásit z odběru těchto e-mailů 2. Odběratel nejspíše označí e-mail za spam, pokud v e-mailu 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 e-mailů. Na odběratele může působit nevěrohodně, pokud se e-mail odlišuje od jiných obchodních e-mailů a neobsahuje například identifikaci odesílatele, platnou 2. Zpravidla se jedná o tzv. unsubscribe link 50

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í e-mail obsahuje potřebné náležitosti (ty, které lze kontrolovat) a neumožnit e-mail 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. 6.8.1 Č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ý e-mail obsahuje jasnou a zřetelnou možnost odhlášení z odběru e-mailů, e-mail je jasně označen jako obchodní sdělení, e-mail neukrývá totožnost odesílatele a e-mail 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í e-maily. 6.8.2 USA V USA od roku 2003 existuje CAN-SPAM zákon, který se zabývá problematikou odesílání obchodních e-mailů. Hlavní požadavky tohoto zákona jsou: uvedení pravdivých informací v hlavičce e-mailu ( From, To a Reply-To ), předmět e-mailu musí korespondovat s obsahem, označení e-mailu za obchodní sdělení/reklamu, uvedení vlastní fyzické adresy, 51

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 e-mailů 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 e-mailů. 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é e-maily budou správné, vždy bude v konečném důsledku záležet na člověku samotném. 52

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 e-mailovou 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 e-mailový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 e-maily a kontakty. Primárním cílem je pomoci zákazníkům dosáhnout co nejvyšší doručitelnost e-mailů a pomoci jim vyhodnocovat e-mailové 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

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 e-mailech 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

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

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í 7.4.1 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í e-mailu, bounce, zahození e-mailu, označení e-mailu za spam jeho příjemcem apod. Modul umožňuje uživateli přímo z Kentico CMS nastavit monitorování: bounce e-mailů, zahozených e-mailů a označení za spam (viz. 2.1.1). 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

7. IMPLEMENTACE MODULU V KENTICO CMS Obrázek 7.3: Ukázka desynchronizovaného nastavení zdroj: vlastní U bounce 3 e-mailů lze také nastavit jejich limit, než bude odběratel odhlášen. Dále je také možné nastavit e-mailovou 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 e-mailů 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 e-mailové š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 e-mailových šablonách lze nalézt v dokumentaci [56] Kentico CMS. Ukázku takové šablony je vidět na 3. Bounce e-maily v tomhle kontextu značí pouze soft bounce, hard bounce je zařazen do kategorie zahozených e-mailů 57

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

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

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