DMARC: ověření odesilatelovy domény

Jaká je výchozí situace? SPF ověřuje odesílající server a vychází z informací předaných protokolem SMTP. Ty se ovšem nemusí shodovat s tím, co je napsáno v hlavičkách dopisu. Ostatně i v našem článku jsme zmiňovali metodu, jak SPF obejít, pokud si uživatel nechá přeposílat poštu jinam.

DKIM se zabývá obsahem dopisu, ovšem může jej podepsat prakticky kdokoli. Podaří-li se ověřit DKIM podpis, zbývá ještě otázka, zda věříme podepisujícímu. Minule zmiňované ADSP dalo speciální význam DKIM podpisu z domény uvedené v adrese odesilatele a umožnilo určit, jak se k dopisu chovat, pokud jím nedisponuje.

Základní vlastnosti DMARC

DMARC na tuto myšlenku navazuje, poněkud ji zobecňuje a přidává možnosti pro hlášení výsledků při ověřování. Jeho specifikace je velmi mladá – vyšla letos v březnu jako RFC 7489. Přesto je už v současnosti docela populární a najdete je i u velkých poštovních služeb (např. Google, Yahoo, Outlook). Jeho klíčové vlastnosti jsou následující:

• Vychází z adresy odesilatele uvedené v hlavičce From dopisu a snaží se ověřit, jestli dopis byl skutečně odeslán z uvedené domény.
• Využívá SPF a DKIM – pokud bylo splněno SPF odesilatelovy domény nebo dopis nese její ověřený DKIM podpis, považuje ji za důvěryhodnou.
• Definuje politiku pro neúspěšné dopisy – jak se zachovat k těm, které DMARC ověřením neprojdou.
• Umožňuje nastavit zpětnou vazbu – kam a jak posílat zprávy o výsledcích DMARC pro dopisy (údajně) odeslané z dané domény.
• Lze nastavit, že se má uplatňovat jen pro část dopisů a nasazovat je postupně.
• DMARC zveřejňuje držitel odesílající domény a ověřuje příjemce dopisu.

Podstatné je, že DMARC není samostatnou technologií, ale navazuje na existující SPF a DKIM. Jimi si příjemce ověří, zda dopis vyhověl pravidlům pro odesílání z domény podle MAIL FROM z SMTP a ze kterých domén má platné podpisy. Tyto informace se předají DMARC modulu, jenž zkoumá, zda domény ověřené v SPF nebo DKIM mají něco společného s doménou v hlavičce From. Pokud alespoň jedna uspěje, dá se podle DMARC věřit tomu, že dopis byl skutečně odeslán z uvedené domény. Potenciálně lze sortiment nástrojů pro ověření domény dále rozšiřovat, zatím je podporováno SPF a DKIM.

Porovnávání domén

V předchozím odstavci jsem úmyslně použil vágní pojem „domény mají něco společného“, protože jejich porovnání není úplně jednoduché. Podívejme se na ně podrobněji.

Porovnává se vždy doména uvedená za zavináčem v adrese odesilatele (položka From v hlavičkách dopisu) proti doméně ověřené SPF nebo DKIM. V případě SPF slouží k porovnání doména použitá v SMTP příkazu MAIL FROM. U DKIM se jedná o doménu z položky d= úspěšně ověřeného podpisu.

DMARC rozlišuje dva režimy porovnávání. V přísném (strict) režimu musí být obě domény totožné. Ve volném (relaxed) režimu stačí, aby odpovídala doména organizace. Pokud tedy odesilatelem bude kdosi@root.cz a dopis ponese ověřený DKIM podpis s d=dkim.root.cz, doména podpisu vyhovuje odesilatelské ve volném režimu, ale nikoli v přísném.

Režim porovnání si diktuje odesilatel. Součástí jím publikovaného DMARC záznamu mohou být položky aspf a adkim, které odděleně nastavují režim porovnání pro SPF a DKIM. Hodnotou může být r (volný) nebo s (přísný). Implicitní nastavení je aspf=r; adkim=r, tedy volný režim porovnání pro obě technologie.

Zbývá ještě pojem „doména organizace“. V RFC 7489 najdete formalizovaný postup jejího určení, nicméně vaše intuitivní představa je správná: Vezme se veřejná přípona (obvykle doména nejvyšší úrovně) a k ní se přidá jedna doména navíc. Například u dkim.root.cz z našeho příkladu je veřejná přípona cz a doména organizace je tudíž root.cz. Rakouská doména at je členěna tematicky, takže třeba vídeňská univerzita má veřejnou příponu ac.at a doménu organizace univie.ac.at.

DMARC záznam

Politiku pro DMARC zveřejňuje držitel odesilatelské domény v podobě tak zvaného DMARC záznamu. Jedná se o záznam typu TXT s pevně daným jménem, které vznikne připojením domény, pro niž se pravidla nastavují, k předponě _dmarc. Například Google Mail má svůj DMARC záznam pod jménem _dmarc.gmail.com.

Záznam smí pro danou doménu existovat jen jeden. Pokud by DNS obsahovalo několik DMARC záznamů pro stejnou doménu, ověření se neprovede.

Jeho obsah je strukturován do dvojic položka=hodnota, oddělovaných navzájem středníky. Přehled položek poskytuje následující tabulka. Povinné jsou jen dvě: Záznam musí začínat v=DMARC1, aby byl považován za platný DMARC záznam. Kromě toho musí být vždy přítomna položka p definující politiku.

Politiky jsou k dispozici tři: none nevyžaduje žádnou konkrétní akci. Hodnotou quarantine držitel domény požaduje, aby se na dopisy, které mají tuto doménu v adrese odesilatele, ale neprošly DMARC ověřením, pohlíželo jako na podezřelé. Nejtvrdší je reject, která požaduje, aby takové dopisy byly odmítnuty.

Samostatnou politiku lze nastavit vlastní doméně (položka p) a jejím poddoménám (položka sp). Pokud DMARC záznam neobsahuje sp, poddomény zdědí politiku určenou v  p.

K uplatnění politiky pro poddomény dochází v situaci, kdy nemají své vlastní DMARC záznamy. Přijímající poštovní server totiž vezme doménu z odesilatelské adresy a nejprve hledá v DNS její DMARC záznam. Jestliže neuspěje (tedy buď takový záznam neexistuje, nebo nezačíná v=DMARC1,tedy není korektní), zkusí ještě získat DMARC záznam pro příslušnou doménu organizace. Přichází-li například dopis z adresy kdosi@kdysi.kdesi.root.cz, bude nejprve shánět TXT záznam jménem _dmarc.kdysi.kdesi.root.cz a v případě neúspěchu ještě _dmarc.root.cz.

Chování příjemce

Tím se dostáváme k chování poštovního serveru přijímajícího dopis. Pokud podporuje DMARC, provede nejprve SPF a DKIM ověření a jejich výsledky předá DMARC modulu. Ten obstará z DNS DMARC záznam. Pokud neexistuje (nebo jich naopak získal více), DMARC pro tuto doménu nelze použít a jeho ověření končí.

Má-li použitelný záznam, pokusí se srovnat odesilatelskou doménu s některou z domén ověřených pomocí SPF nebo DKIM. Když uspěje, dopis úspěšně prošel DMARC. V opačném případě dopis neuspěl a bude s ním naloženo podle politiky definované v DMARC záznamu.

Ještě před srovnáváním domén ale přijde ke slovu případné omezení počtu ověřovaných dopisů. Pokud DMARC záznam obsahuje položku pct s hodnotou jinou než 100, příjemce vygeneruje náhodné číslo od 0 do 99 a pokračuje s ověřováním DMARC jen v případě, že je menší než hodnota  pct.

Mezi povinnosti příjemce patří i zpětná vazba, čili zasílání hlášení. K němu dochází ve dvou situacích: při neúspěchu ověření a pravidelné agregované hlášení shrnující výsledky DMARC pro danou doménu za určité období.

Agregované zprávy se posílají pravidelně v intervalech daných položkou ri (implicitně jednou denně) na adresy určené položkou rua. Obsahují souhrnné údaje o úspěších i neúspěších při ověřování DMARC dopisů odesílaných (údajně) z dané domény. Typicky se posílají v komprimovaném formátu XML, jeho schéma najdete v příloze C RFC 7489, popis u Cherie Ansari a příklad na dmarc.org.

Adres (přesněji URI) může být v rua  uvedeno několik. V tom případě se oddělují čárkami a příjemce by měl rozeslat informaci všem. Agregované zprávy mohou být dlouhé, proto lze k adresám připojit i maximální akceptovanou velikost zprávy. Odděluje se vykřičníkem, takže například

rua=mailto:dmarc-report@root.cz!20m

znamená, že agregované zprávy se mají posílat poštou na adresu dmarc-report@root.cz a jejich velikost nesmí překročit 20 MB. Příliš velkou zprávu lze rozdělit do několika menších.

Položka rua je nepovinná a nemá implicitní hodnotu. Pokud není uvedena, agregované zprávy se prostě neposílají.

Zpráva o neúspěchu se obvykle posílá ihned po neúspěšném ověření DMARC každého dopisu. Pokud by ovšem frekvence byla příliš vysoká, může přijímající server i zde sáhnout k určité agregaci. Adresu se dozví z položky ruf v DMARC záznamu. Opět lze uvést několik adres a hlášení se posílá všem, opět nemá implicitní hodnotu a pokud chybí, nic se neposílá.

Hlášení o chybách se zdá být spíše papírovou možností, kterou současné implementace spíše nepodporují. Doporučujeme je zatím nepoužívat a případně sledovat vývoj, pokud vás lákají.

Smyslem ohlašovací části DMARC je poskytnout správcům poštovního systému zpětnou vazbu, jaké jsou výsledky ověřování dopisů odesílaných jejich uživateli. Bez ní se o případných problémech dozvídají často s velkým zpožděním, protože uživatelé, jak známo, trpí mlčky a obvykle pasivně čekají, až se problém sám spraví.

Zároveň se jedná o mechanismus zcela dobrovolný. Jestliže správci o zpětnou vazbu nestojí, jednoduše do DMARC záznamu nevloží rua ani ruf a žádná hlášení přicházet nebudou.

Pokud je zapne, musí být příslušné adresy připraveny na příjem odpovídajícího počtu hlášení. A bude jednodušší, budou-li pocházet ze stejné domény. Je sice možné, aby adresy pro příjem hlášení byly jinde (například u externího poskytovatele poštovních služeb). V tom případě ale jejich doména musí v DNS zveřejnit speciální záznamy, jimiž potvrdí, že se svou rolí souhlasí. Vše je popsáno v části 7.1 RFC 7489.

Nasazení

DMARC je sice papírově velice mladou technologií, o nasazení ale není nouze. Specifikace samozřejmě nespadla z nebe, takže už během vývoje vznikla řada implementací a leckterá doména již obsahuje DMARC záznam. Proslavilo se například yahoo.com svou drsnou politikou reject  – záznam _dmarc.yahoo.com obsahuje:

v=DMARC1; p=reject; sp=none; pct=100; rua=mailto:dmarc-yahoo-rua@yahoo-inc.com, mailto:dmarc_y_rua@yahoo.com;

Vidíte, že politika reject platí jen pro vlastní doménu yahoo.com, zatímco na poddomény se vztahuje none. Kontrolují se všechny dopisy a agregovaná hlášení o výsledcích se mají posílat na dvě uvedené poštovní adresy.

Pokud uvažujete o implementaci, určitě navštivte stránku zdrojů na dmarc.org, kde najdete odkazy na implementace, podpůrné nástroje i návody. A nezapomeňte, že musíte začít u SPF a DKIM, bez nichž nemá DMARC smysl.

Doporučuje se začít zlehka a postupně utužovat disciplínu. Nejprve nasaďte politiku none a nízké procento ověřovaných dopisů. Pokud nezaznamenáte nebo vyřešíte problémy, postupně je zvyšujte až ke stovce. Pak můžete zpřísnit na quarantine a zopakovat navyšování procenta dopisů. A nakonec ještě jednou pro politiku reject, pokud je vaším cílem.

DMARC samozřejmě není univerzální řešení všech problémů se spamem bez jediné chybičky. Ve skutečnosti vůbec neřeší, jestli dopis obsahuje neřádstvo nebo užitečné informace. Zabývá se jen tím, zda se dá alespoň trochu věřit, že jej odeslal ten, kdo je uveden v hlavičce  From.

A není bez chyby. Problémy mu působí především různé varianty předávání dopisů, jako jsou poštovní konference či automatické přeposílání příchozí korespondence na uživatelův účet u jiné poštovní služby. Jejich analýza a návrh protiopatření se připravuje, zatím se nachází ve stavu pracovního návrhu (draft-ietf-dmarc-interoperability). Rozhodně se jedná o živý standard, na jehož budoucnost je dnes pohlíženo dost optimisticky.