Posílání mailů, to je brnkačka, na to máme přece helper

K něčemu se vám přiznám. Ještě tak zhruba před dvěma měsíci jsem si myslel, že to takhle fakt je. Co je na poslání mailu těžkého? Do odhadu dáme hodinu na helper, hodinu na šablonu a je to. SMTP na těch serverech přece je a o zbytek se postarají admini.

Blažená nevědomost.

Poslat mail je sice trivka, ale bohužel se taky klidně může stát, že nikdy nikomu nedojde. Od té doby, co se v Activate věnuju naplno e-mailingu, jsem objevil spoustu překážek, které stojí mezi odesilatelem a adresátem.

Budete mi věřit, když vám řeknu, že průměrně kolem 20% e-mailů nikdy nedorazí do cíle? Potvrzení registrace, potvrzení objednávek, výzvy k vyzvednutí na prodejnách, zapomenutá hesla - a hromada dalších. Když k tomu přidáte další průměr 10% blbě vyplněných e-mailových adres, tak máme celkem slušný odpad. Na Správném kroku bych vám mohl vyprávět, kolik se toho vrací nebo kolik lidí se denně ozývá, že jim potvrzení registrace nedošlo.

Ale nebojte, světlo na konci tunelu svítí... :-)

Tou černou dírou, kde ty e-maily mizí, jsou totiž opatření ESP (Email Service Provider, např. Seznam nebo Gmail) proti spammerům, popř. phisherům. ESP implementují celou řadu ochranných prvků na to, aby dokázali odlišit poctivého odesilatele od záškodnických živlů.

Problematika to je hodně rozsáhlá a ještě jsem do ní nepronikl do takové hloubky, abych dokázal zodpovědět všechny otázky. Dneska se tedy alespoň podíváme na tři základní prvky ochrany proti SPAMu. Všechny jsou na straně odesilatele.

Sender Policy Framework (SPF)

SPF je, zjednodušeně řečeno, mechanizmus, jak říct přijímací straně, který mailserver může odesílat mojí poštu. Každému z vás se určitě stalo, že vaším jménem někdo posílal SPAM (a vám se pak vracely jen zprávy o nedoručitelnosti). SPF je jednou z cest, jak tomu zabránit. Pokud totiž víte, že e-maily z domény @etnetera.cz může odesílat jen Google (nebo dřív to byla Sponka), tak pomocí SPF tohle řeknete. Funguje to jednoduše:

  1. do DNS záznamu etnetera.cz se přidá SPF záznam, který vypadá plus mínus takhle:
  2. spravnykrok.cz. 1800 IN TXT "v=spf1 a mx ip4:90.183.53.0/24 -all"

    (tenhle říká, že pro doménu spravnykrok.cz jsou povolené jako odesílací servery jen ty, které splňují daná pravidla, všechno ostatní je zakázané). Pozn. typ TXT se používá z historických důvodů (než se standardizoval SPF záznam, suploval to speciální případ TXT záznamu), nově je v RFC už standardizovaný typ SPF.

  3. přijímací strana se podívá do DNS, jestli tam SPF záznam existuje
  4. pokud ano, porovná MAIL FROM z obálky e-mailu (pozor, nezaměňovat s From: z hlavičky e-mailu, to je něco jiného) s tím, co je povolené v SPF záznamu
  5. když se údaje neshodují, e-mail vrátí odesilateli jako nedoručitelný, pokud se shodují, postupuje e-mail do dalšího kola (ale ještě není vyhráno, těch kol je totiž celá řada)

Tenhle mechanismus je fajn, ale má drobné "ale". Neporadí si to s automatickým forwardem - pokud si např. na jedné doméně nastavíte forward na jinou doménu, tak se pochopitelně změní odesílací server a cílový ESP přeposlanou zprávu odmítne, protože nevyhovuje SPF. Vám se pak ale jako odesilateli začnou vracet nepochopitelné zprávy od lidí, kterým jste nic neposílali (akorát měl původní adresát nastavený forward jinam). Lze sice nastavit tzv. SoftFail, což je varianta, že cílový server nemá zprávu rovnou zahodit, ale má ji jen označit jako podezřelou, ale to taky není zrovna ideální řešení. Druhým řešením je z pohledu ESP využívat tzv. Sender Rewriting Scheme, ale to ne všichni podporují (např. se Seznamem to právě řešíme, momentálně ho nepodporuje a tím pádem se forwardované e-maily vrací jako nedoručitelné z důvodu porušení SPF).

Druhým problémem je to, když byste chtěli posílat poštu z dané domény např. z domova, popř. mobilu - pokud tam totiž budete mít nastavené jiný SMTP server, než ten, který je povolený v SPF záznamu (např. SMTP provozovatele připojení), neprojde to.

V neposlední řadě bych dodal, že to samozřejmě nebrání spammerům si do jejich DNS záznamů přidat validní SPF - ten největší háček je totiž ten, že SPF kontroluje MAIL FROM z obálky, nikoliv From: z hlavičky.

DomainKeys Identified Mail (DKIM)

Zjednodušeně řečeno se jedná o mechanizmus podepisování hlaviček odchozích zpráv, aby příjemce mohl ověřit, že cestou nedošlo k jejich změně.

Princip je následující:

  1. vlastník domény přidá do DNS svůj veřejný podepisovací klíč, např.
  2. spop1024._domainkey.news.bata.eu. IN TXT "k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCvFJAzpJ9v2qrtH0EKTBnuXR9zE1xMCCr0sNx8e4PhDkixTGOsO+b3HZJq3tsDYQ3ohqHLt278xSDsp1jNWWHUXzbfPZgJTKUmRGCEZGQ8wpjYPsn6cMT6N5Wvw6QGyKj90QIzCobyM9T15SQr3+biu+GdIZuznCxJNI6d0ZmsIwIDAQAB"

  3. Odesílací mail server na základě nastavení podepíše tajným klíčem vybrané údaje z hlavičky (viz "h" parametr v následujícím příkladu) a přidá podpis do hlavičky odesílaného e-mailu. Vypadá to např. takhle:
  4. DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=spop1024; d=news.bata.eu; h=Date:From:Reply-To:To:Message-ID:Subject:MIME-Version:Content-Type:List-Unsubscribe; i=fr-ch@news.bata.eu; bh=UNy+HOsygr6cM16oiqsn60tTc4I=;

    b=qZXdx9vHWT+43w0EAW83DTrRx2otNXFH16GWlycQtQgXZCH58uPe2kHpdCmlemrRzmHgiKd5xOFSUwpZpgqfmTYCKCl2Ya5R/XcqtSVOxLuISbBCfUY0cVY3X1ixmYLXQEtQtImO80gjAEcRew5hcKKp643GWFinI0Z0f2LCBdc=

  5. Přijímací server stáhne z DNS veřejný klíč a ověří, jestli podpis odpovídá - pokud ne, může zprávu odmítnout

Opět má tahle technika svá ale. Prvním z nich je vyšší nárok na výkon na obou stranách - prostě se musí na výstupu podepsat a na vstupu ověřit.

Druhým problémem je, že DKIM (na rozdíl od SPF) nepodepisuje údaje z SMTP obálky (Return-path), ale údaje z hlavičky (From, To, apod.) - tím pádem lze podvrhnout skutečného odesilatele (na druhou stranu, díky tomu toto přežije forwardování e-mailu a lze to ověřit kdekoliv po cestě). Nicméně toho můžou opět zneužít spammeři/phishers - stačí zachytit jakoukoliv podepsanou zprávu, přidat na konec jejího obsahu svůj vlastní text a dál ji šířit (přičemž se bude tvářit jako skutečně odeslaná zpráva).

Třetím problémem jsou "automaticky" přidávané patičky - např. od antivirů nebo mailerů, které přidávají trackovací kódy. Pokud se např. podepisuje i obsah zprávy (resp. jeho významná část), tak to může způsobit problém.

Domain-based Message Authentication, Reporting and Conformance (DMARC)

Obě výše zmíněné techniky byly jen a pouze orientační a záleží na přijímací straně, co s e-mailem skutečně udělá (tj. odesilatel nemohl vyžadovat, aby přijímací ESP nějak reagoval - to je čistě na implementaci).

DMARC tyto dvě technologie kombinuje a navíc přidává dvě věci:

  1. říká, co se má stát, když něco není splněno
  2. přidává informaci o zpětné vazbě - aby se odesilatel dozvěděl o zjištěných problémech

Opět je to změna v DNS záznamech. Vlastník domény přidá něco takového (jedná se o TXT záznam pro speciální subdoménu _dmarc):

_dmarc.returnpath.net. TXT IN 600 7ms "v=DMARC1; p=none; rua=mailto:dmarc_agg@auth.returnpath.net; ruf=mailto:dmarc_afrf@auth.returnpath.net; rf=afrf; pct=100"

V tom nastavení může říct, jaké domény chrání (včetně např. subdomén), jak je chrání (SPF/DKIM) a co se má stát v případě, když některá z ochran není splněna. Důležité taky je, kam má přijímací strana poslat zprávu o nesplnění (reporting).

Nastavit DMARC určitě zvládneme za 15 minut :-), výhodou je, že poskytuje několik úrovní “ochrany”:

  • Monitoring - tím je doporučeno začít, protože tím získáte zpětnou vazbu o tom, jak ESP přijímají vaše e-maily, aniž by je jakkoliv řešili
  • Karanténa - poté, co se rozkoukáte, co se s e-maily děje můžete přejít ke karanténě - ta už zajistí, že e-mail, který nesplňuje nastavená pravidla skončí ve SPAMu
  • Odmítnutí - finální stádium - nic, co nesplňuje vaše pravidla nebude vůbec doručeno a vrátí se jako nedoručitelné

Tak co, nastavíme si DMARC i u nás? :-) A kolik z našich klientů, pro které denně rozesíláme tisíce transakčních e-mailů to má nastavené správně?

Závěr?

Každopádně objevuju nový svět. Problematika doručitelnosti e-mailů je hodně rozsáhlá - to jsem např. vůbec nezmínil reputaci IP adresy (nebo celých rozsahů / bloků), blacklisty / whitelisty / greylisty, obsahové SPAM detektory, HTML validátory, antiviry a další záležitosti, které ovlivňují to, jestli váš e-mail skončí nakonec v inboxu adresáta nebo v propadlišti internetových dějin.

A navíc, pokud výše uvedeným způsobům (DNS záznamům) máte věřit, tak do hry ještě vstupuje DNSSEC, ale to už je na jiné povídání.

Mezi spammery/phishery a ESP zuří nelítostný boj, a bohužel se dotýká i legitimních rozesílek, navíc se musí všechno vyhodnocovat skoro v reálném čase.

Nicméně dobrá zpráva je, že pokud chcete pro vaše klienty zajistit lepší doručitelnost e-mailů (hlavně těch transakčních), tak cesta, jak to zařídit, existuje. Ozvěte se a probereme to.

Článek obsahuje 2 komentáře

  • Michal

    1
    Položka MAILl FROM neobsahuje IP adresu odesílajícího serveru.
  • Pavel Pola

    2
    Dobrý den, samozřejmě neobsahuje, ono to tak někde z toho článku vyznělo? To bych nerad. :-)