Email Authentication

V rámci SMTP protokolu je jednoduché podvrhnout většinu údajů v poštovní zprávě. Proto se vymýšlí metody, které by ověřili autentičnost. Jednou metodou je elektronický podpis, ale tam je složité získávání a práce s certifikáty (jsou kladeny velké nároky na koncového uživatele). Takže se řeší metody, které fungují na straně serverů.

Obecně se pro metody ověřování původu poštovních zpráv používá termín Email Authentication. Cílem je zamezit možnosti podvržení identity zprávy (Email Spoofing), tedy Phishingu a případně SPAMu. Ověřuje se, že email pochází od adresy, která je uvedena jako odesílatel, alespoň na úrovni domény. Částečně se dá říci, že se kontrolují poštovní servery (Message Transfer Agents - MTA), které se účastní odeslání a přenosu emailu.

Protože poštovní zpráva běžně obsahuje více adres odesílatele, tak je důležité, jaká adresa se ukazuje uživateli a jaká se kontroluje. Otázku adres v SMTP protokolu jsme si popsali v článku Protokol SMTP a adresy v elektronické poště.

Pro ověření původu zpráv se dnes převážně využívá technik SPF (Sender Policy Framework) a DKIM (DomainKeys Identified Mail), případně rozšíření DMARC (Domain-based Message Authentication, Reporting and Conformance).Tyto metody jsou definovány v internetových standardech RFC (a v nich nalezneme nejvíce detailních informací). Techniky SPF a DKIM se spíše doplňují, než by se nahrazovaly. Každá ověřuje trochu něco jiného.

Nutno poznamenat, že všechny tyto techniky fungují pouze mezi organizacemi, které je používají. Musí být provedeno nastavení pro odesílání zpráv. A při příjmu zpráv prováděna kontrola (pokud byla některá z technik použita).

SPF - Sender Policy Framework

Jednou z hodně rozšířených metod je Sender Policy Framework (SPF) popsané v RFC 7208 (navržený standard). Používají se termíny jako SPF Verification či SPF Authentication. Jeho využití je velmi jednoduché, ale funguje pouze pro strany, které jej používají. Pro své domény vytvoříme DNS záznamy a na příjmu zapneme SPF ochranu (naše poštovní brána musí SPF podporovat).

SPF ověřuje doménu použitou v adrese Envelope Sender (doporučeno je kontrolovat MAIL FROM i HELO), že poštovní zpráva byla odeslána korektním (povoleným) poštovním serverem pro tuto doménu. Dá se říci, že SPF svazuje doménu odesílatele s IP adresami serverů, které mohou email odeslat. Ověření může proběhnout již při přijetí prvních STMP příkazů (ve stejné chvíli, kdy se kontroluje existence adresy příjemce), nemusí se přijímat celá zpráva.

Princip SPF

SPF umožňuje vlastníkovi domény specifikovat, které poštovní servery jsou povoleny (autorizovány) k odesílání emailů za danou doménu. Nastavení se provádí pomocí textového (TXT) DNS záznamu se specifickým formátem.

• Když poštovní server přijímá zprávu, tak se podívá na doménu v Envelope Sender, bere se doména z příkazu HELO a MAIL FROM (některé implementace používájí pouze MAIL FROM).
• Pro tuto doménu se hledá SPF záznam (SPF Record) v DNS.
• Pokud záznam existuje, tak se podle něj ověří (Checking Authorization) IP adresa poštovního serveru, odkud zpráva přišla.
• Vyhodnocení (Evaluation) je definováno funkcí check_host() a jsou dány možné výsledky SPF testu (Results of Evaluation).
• RFC také popisuje doporučené chování k různým výsledkům (Result Handling), ale reálné chování si standardně určujeme sami.

Výsledky SPF kontroly (Results of Evaluation)

Níže jsou možné výsledky vyhodnocení SPF ověření. Stručný popis i doporučené chování (manipulace) se zprávou podle výsledku.

• None - neexistuje SPF záznam, přijmout zprávu
• Neutral ? - záznam určuje, že o platnosti nelze rozhodnout, přijmout zprávu
• Pass + - server je autorizován k odeslání zprávy, přijmout zprávu
• Fail - - server není autorizován k odeslání zprávy, odmítnout zprávu
• Softfail ~ - server pravděpodobně není autorizován k odeslání zprávy (ale nechceme odmítat), přijmout a označit zprávu
• Temperror - při ověření SPF došlo k přechodné chybě (obvykle DNS)
• Permerror - došlo k trvalé chybě (chybný SPF záznam)

SPF záznam v DNS

Formát SPF záznamu, a další požadavky na DNS záznamy, jsou specifikovány v RFC 7208. Čitelnější popis najdeme v článku SPF Record Syntax. Na internetu jsou také různé nástroje pro kontroly SPF záznamů SPF Record Check - Lookup SPF Records, či jejich generování SPF Record Generator.

SPF záznam musí být publikován jako DNS TXT (type 16) Resource Record (RR) přímo na dané doméně. Jeho formát začíná určením, že jde o SPF záznam v=spf1. Následuje seznam direktiv oddělených mezerou, ty jsou vyhodnocovány v zadaném pořadí. Případně obsahuje modifikátory.

Direktiva se skládá z kvalifikátoru a mechanismu. Kvalifikátor určuje chování (vyhodnocení) k danému mechanismu, což je zjednodušeně odesílající adresa. Pokud se adresa shoduje, tak se dle kvalifikátoru určí vyhodnocení. Kvalifikátor se nemusí zapisovat, pak je výchozí Pass. Možnosti jsou

• + Pass
• - Fail
• ~ Softfail
• ? Neutral

Mechanismy jsou například ip4:<ip4-address>, kde se určuje porovnávaná IP adresa, a:<domain>, kde se zadává A záznam v DNS pro porovnání. Speciální mechanismus je include:<domain>, kdy použije SPF záznam zadané domény. A all, který vždy odpovídá (určuje všechny adresy), standardně se používá na konci záznamu.

Jednoduchý SPF záznam, pro FQDN firma.cz (na této doméně se TXT záznam vytváří), může vypadat následně:

"v=spf1 ip4:1.2.3.4 mx -all"

Pokud přijde mail z IP adresy 1.2.3.4 nebo IP adresy, která je přiřazena k MX záznamu, tak je výsledek Pass. Pro všechny ostatní případy je Fail.

SPF HELO

Standardně se při SPF kontrole ověřuje doména v MAIL FROM (tedy doménová část adresy odesílatele - Envelope Sender). Například pro adresu bouska@firma.cz vychází doména firma.cz. RFC 7208 doporučuje, aby se ověřovala také doména v HELO/EHLO příkazu. V HELO/EHLO je doporučeno uvádět jméno serveru (hostname - FQDN), což je například mail.firma.cz (viděl jsem použitu i emailovou adresu).

Myslel jsem, že ze jména se vezme pouze doména (ač to není nikde popsané), ale patrně ne. Různé testovací služby pro kontrolu SPF, ověřují nejen MAIL FROM (mfrom), ale také HELO (helo), a vrací, že SPF záznam pro doménu mail.firma.cz nebyl nalezen. Zkusil jsem tedy přidat TXT DNS záznam i pro subdoménu a testy najednou vychází jako Pass. Také brána Cisco Email Security umožňuje při kontrole SPF/SIDF volitelně zapnout HELO Test. Pak přidává do hlaviček zpráv druhou (třetí, pokud máme i PRA) položku Received-SPF, kde je výsledek testu HELO domény.

Zkusil jsem hledat pro mnoho známých domén, ale u nikoho jsem nenalezl, že by měl SPF záznam pro HELO doménu. Takže se to v praxi asi nepoužívá.

Problém SPF

S technologií SPF je jeden problém, a to při přeposílání emailů (Forward) na jinou emailovou adresu. Pokud se použije standardní přeposlání, jaké nabízí běžný poštovní klient pod funkcí Forward, tak problém není. Tehdy se vytvoří nová zpráva, kde je odesílatelem daný uživatel (je vidět, že jsem zprávu přeposlal já). Chování je stejné, jako při odpovědi (Reply), jen se nevyplní adresa příjemce a do předmětu se vloží (něco jako) FW:.

Problém způsobuje operace, která se označuje jako přesměrování emailu (Redirect). Přesměrování se v běžných poštovních klientech (například MS Outlook) nedá provést ručně, ale můžeme vytvořit automatizované pravidlo (Rule), které tuto funkci podporuje. Při přesměrování se zpráva nemění a vypadá, jako kdyby přišla od originálního odesílatele. Pokud na ni příjemce odpoví, tak odpovídá originálnímu odesílateli a ne tomu, kdo přesměrování provedl. Problém je, že zprávu odesílá poštovní server toho, kdo přesměrování provádí, a používá adresu originálního odesílatele. Čili prakticky jde o podvržení odesílatele. A pokud je originální odesílatel a přeposílatel na jiné doméně, tak příjemcův server, při použití SPF, zprávu detekuje jako podvrženou.

Praktický dopad (s kterým jsem se dříve setkával velmi často, ale možná se situace zlepšuje) popisuje následující příklad. Odešlu email (ja@firma.cz) příjemci v jiné firmě (prijemce@nekde.cz). Tato osoba má nastavené pravidlo, aby se všechny zprávy přeposlaly na její adresu prijemce@seznam.cz (a v horším případě, aby se neuložila jejich kopie). Seznam přijímá email, kde je odesílatel z domény firma.cz, ale odeslal jej poštovní server domény nekde.cz. Pro naši doménu firma.cz máme SPF záznam, kde je autorizovaný pouze náš poštovní server. Seznam kontroluje SPF a toto považuje za podvržený email, takže jej odmítne. Zajímavé je, že chyba se nedostane k osobě, která má nastaveno přesměrování. Ale NDR se odešle nám (je to jediná adresa v hlavičce).

Níže je příklad chyby, která je uvedene v NDR při odmítnutí zprávy. Je vidět, že jsem sice psal adrese na doméně nekde.cz, ale odpověď je od serveru seznam.cz pro jinou adresu.

prijemce@seznam.cz
mx1.seznam.cz #<mx1.seznam.cz #5.7.1 smtp; 550 5.7.1 Sender Policy Framework of `firma.cz' domain denied your IP address.> #SMTP#

Ve většině případů, kdy vytváříme automatické pravidlo na přeposílání příchozích zpráv, můžeme volit jednu ze tří možností. Buď klasické přeposlání (to bychom měli preferovat) nebo přeposlání jako přílohu, poslední možnost je právě přesměrování (nechat zprávu nezměněnou).

Pozn.: DKIM, který si popíšeme dále, s přesměrováním problém nemá, protože funguje na úplně jiném principu.

Sender Rewriting Scheme - SRS

Řešení výše popsaného problému, zmínil v komentářích Martin, a já se na něj podíval až spolu s DMARCem. Jde o SRS (Sender Rewriting Scheme), které jednoduše přepisuje adresu odesílatele při přesměrování (Redirect). Přepisuje se adresa Envelope Sender, tedy v SMTP příkazu MAIL FROM, adresa From v hlavičce zůstává původní. Takže SPF kontrola by měla projít, ale uživatel pořád vidí původního odesílatele. Nutno říci, že DMARC kontrola neprojde, protože je jiná doména v MAIL FROM a From. Toto používá například seznam.cz.

SRS definuje způsob přepisu adresy, například odesílám zprávu z adresy bouska@firma.cz, přesměrování provádí server seznam.cz (kde je schránka s pravidlem na přesměrování), tak změní adresu odesílatele na SRS0=QQIi=32=firma.cz=bouska@seznam.cz (QQli je hash, 32 je timestamp). Jde o variantu Variable Envelope Return Path (VERP).

Sender ID, Sender ID Framework (SIDF)

Sender ID, popsané v RFC 4406, je založené na SPF a je mu značně podobné, i když má určité rozšíření. Patrně se dnes příliš nepoužívá. Microsoft implementoval Sender ID jako Sender ID Framework (SIDF). Umožňuje kontrolovat doménu z Envelope Sender, klíčové slovo mfrom. Ale také Purported Responsible Address (PRA), což je adresa určená různými pravidly, uvažuje se také Header Sender.

Textový DNS záznam pro SPF začíná v=spf1. Pro Sender ID je to nějaká varianta typu spf2.0/mfrom, spf2.0/pra,mfrom, apod.

Praktické nasazení SPF

Zapnutí SPF

Pokud chceme, aby pro naši doménu mohli příjemci provádět SPF kontrolu, tak stačí na doméně vytvořit DNS záznam, jak jsme si popsali výše.

Například pro odesílání z adres, jako je bouska@firma.cz, vytváříme TXT záznam na doméně firma.cz. Hodnota záznamu může být:

"v=spf1 ip4:10.20.30.40 -all"

Případně můžeme vytvořit stejný záznam i pro HELO jméno serveru, například mail.firma.cz.

Prohlédnout záznam můžeme jednoduše, třeba řádkovým příkazem na Windows.

nslookup

> set type=txt
> firma.cz
Server: ns.firma.cz
Address: 192.168.0.10

Non-authoritative answer:
firma.cz   text =
	"v=spf1 ip4:10.20.30.40 -all"

> mail.firma.cz
mail.firma.cz   text =
	"v=spf1 ip4:10.20.30.40 -all"

Ověřování SPF

Potřebujeme poštovní bránu (server), která podporuje SPF. Zapnutí ověřování je pak většinou jednoduché. Musíme se rozhodnout, jak naložíme se zprávami, které kontrolou neprojdou (třeba označíme v předmětu). Příkladem brány s podporou SPF je Cisco Email Security. Velmi stručně jsem zapnutí SPF kontroly popsal v článku Cisco Email Security - konfigurace AntiSpam řešení.

SPF podporuje i přímo Exchange Server, musíme ale nainstalovat AntiSpam agenty pro Transport service Enable antispam functionality on Mailbox servers.

Online kontrola SPF

Na internetu nalezneme řadu nástrojů, které pro zadanou doménu naleznou SPF DNS záznam a ověří jeho syntaxi. Případně porovnají i zadanou odesílající IP adresu, zda odpovídá záznamu. Jedním příkladem je SPF Record Check - Lookup SPF Records. Další služby fungují tak, že na jejich emailovou adresu odešleme zprávu a vrátí se nám report.