SPF: proti spamu i přeposílání pošty

Principem SPF (původně zkratka znamenala Sender Permitted From) je dát možnost vlastníkovi DNS domény deklarovat, které servery jsou oprávněny odesílat e-mailové zprávy jménem domény. Příjemce pošty pak může validovat, zda poštu od dané domény dostává z autorizovaného serveru a podle toho zohlednit další nakládání se zprávou.

Majitel domény example.com může například specifikovat politiku, že poštu z adres @example.com mohou předávat pouze servery z adresního rozsahu 192.0.2.0/24 takto:

example.com   IN  TXT  "v=spf1 ip4:192.0.2.0/24 -all" 

Pass, neutral, fail, softfail

Obsah TXT záznamu obsahuje vždy povinné záhlaví v=spf1 následované mezerou oddělenými slovy, která definují povolené, nebo naopak zakázané rozsahy adres. Každé slovo může být uvozeno kvalifikátorem, jejichž význam shrnuje následující tabulka:

Jako rozsah adres pak mohou být kromě výše uvedeného příkladu se slovy all pro všechny adresy a ip4  pro daný rozsah adres také klíčová slova a a mx, která doplní IP adresu získanou DNS dotazem na příslušný typ doménového záznamu. Nejlepší současná praxe ale doporučuje se takovýmto zřetězením vyhnout za účelem snížení počtu DNS dotazů, které musí validátor vykonat.

Pravidla se při validaci vyhodnocují v pořadí, v jakém jsou zapsána, po nalezení první shody se další nezkoumají. Neexistující politika vrací stav neutral, je tedy ekvivalentní existenci záznamu

example.com   IN  TXT  "v=spf1 ?all" 

Příjemce pošty, který SPF záznam validuje, tak činí ideálně ještě v průběhu SMTP komunikace. Nejprve by měl pomocí SPF validovat jméno hostitele, kterým se představí klient v příkazu HELO/EHLO, následně validuje adresu domény, uvedenou v příkazu MAIL FROM. Pokud na základě vyhodnocení SPF rozhodnuto o nepřijetí zprávy, měla by být odmítnuta již během SMTP komunikace.

TXT nebo SPF?

SPF je jedním z protokolů, jehož vývoj probíhal ve spěchu a tak trochu mimo půdu IETF. Jedním z důsledků kvapného zavádění je způsob, jakým protokol SPF přikládá speciální význam TXT záznamům v DNS. Ty byly původně určeny pro nestrukturované textové informace. SPF těmto informacím přikládá speciální význam a dopouští se tak klasické chyby známé ve světě databází jako metadata v datech.

Na půdě IETF proto kdysi vznikla snaha situaci napravit zavedením nového typu DNS záznamu SPF, který bude mít stejnou sémantiku jako TXT záznam, bude však určen jen pro potřebu SPF. Tato snaha ovšem dopadla fiaskem; než se podpora pro nový typ DNS záznamu dostala do DNS serverů a jejich uživatelských rozhraní, bylo SPF již velmi rozvinuto. Validátory tak musely kontrolovat dva různé DNS záznamy a řešit případně rozpory. Přítrž tomu učinil nejnovější standard RFC 7208, který záznam typu SPF rezervuje pro budoucí revize standardu, zatímco pro aktuální verzi 1 nařizuje – v souladu se současnou praxí – použití záznamu typu  TXT.

Problém s přeposíláním pošty

Mnohem zásadnější je ale koncepční problém s přeposíláním pošty na straně příjemce. Mějme příklad se třemi entitami:

• A publikuje SPF politiku, obsahující tvrdé selhání pro nepovolené adresy
• B nemá s SPF nic společného, jen provozuje e-mailové schránky a nabízí svým uživatelům přesměrování pošty na jinou adresu
• C validuje SPF politiku a poštu, u které SPF selhává, tvrdě odmítá

Problém nastane ve chvíli, kdy uživatel schránky u B nastaví přesměrování všech nebo vybraných zpráv od A na adresu u C. K C se totiž v okamžiku přeposílání připojí server entity B a bude se snažit doručit zprávu která bude v SMTP komunikaci MAIL FROM označena jako přicházející od A. To C vyhodnotí jako porušení politiky a zprávu odmítne.

Zpráva se tedy nedoručí a není to ničí vina. Každá z entit však může nějakým způsobem proces ovlivnit s cílem snížit riziko takového nedoručení. Entita A má možnost použít kvalifikátor softfail namísto fail (tedy zakončit definici politiky ~all namísto -all). Dává tím najevo, že si sice nepřeje, aby jiné adresy odesílaly poštu jejím jménem, ale nepřeje si tvrdé odmítnutí takových zpráv. Stejně tak entita C může nastavit svůj systém tak, aby i zprávy, jejichž SPF kontrola selže, podrobila pouze důkladnější kontrole, ale neodmítala. Standard definující SPF totiž záměrně nechává volnost v tom, co se má se zprávou na základě výsledku kontroly stát.

I entita B může přeposílání upravit tak, aby k porušování SPF politiky nedocházelo. Zdaleka nejjednodušší, nikoli však správné řešení, je přeposílání zpráv s prázdnou obálkovou adresou odesílatele. Negativním efektem takového řešení je, že odesílatel původní zprávy A se nedozví o případných problémech s doručením zprávy od B k C. Další spíše teoretickou možností, kterou připouští SPF standard, je odmítnutí zprávy, jejíž přeposlání by porušilo SPF politiku, návratovým kódem 551, User not local spolu s uvedením adresy, na kterou má být zpráva odeslána přímo původním odesílatelem.

Přepisování adresy odesílatele podle SRS

Poslední možností, jak může entita B zabránit porušování SPF politiky, je systematické přepisování obálkové adresy odesílatele během přeposílání tak, aby případné informace o průběhu doručování k C, bylo možné předat zpět odesílateli. Nelze to však udělat jednoduchým přepisem; takové řešení by ze serveru B efektivně vytvářelo open relay, který by mohl být zneužit k rozesílání spamu. Metoda Sender Rewriting Scheme přepisované adresy proti zneužití zabezpečuje buď kryptograficky, nebo použitím databáze.

V prvním případě je pro odesílatele user@A.org, posílajícího zprávu na server B.org tímto serverem při přeposílání vytvořena následující obálková adresa odesílatele:

SRS0=HHH=TT=A.org=user@B.org 

Písmena TT jsou nahrazena časovou značkou, kdy byla přepsaná adresa použita, písmena HHH pak jsou nahrazena částí hashe, na jehož vstupu je adresa odesílatele, časový kód a náhodné tajemství, známé pouze serverům, které generují a validují přepsané adresy.

Protože zpráva ze serveru entity B přichází s obálkovou adresou entity B, nepředstavuje její doručení žádný problém v SPF. Pokud dojde k problému s doručením přeposlané zprávy, je informace o problému poslána na výše uvedenou speciální adresu. Server B ze speciální adresy extrahuje původní adresu user@A.org, ověří, zda souhlasí hash a zda od časové značky neuplynula příliš dlouhá doba, a pokud vše souhlasí, zprávu předá původnímu odesílateli.

Takovýto přepis má jistá úskalí, související především s maximální povolenou délkou uživatelské částí e-mailové adresy, kterou RFC 5321 stanovuje na 64 znaků. Zejména pak v případě, kdy k přeposílání a SRS přepisu dojde víc než jedenkrát. Z toho důvodu je pro takové případy definován zjednodušený formát:

SRS1=KKK=B.org==HHH=TT=A.org=user@B2.org 

Písmena KKK představují nový hash, který vytvoří server B2.org. Při třetím a dalším přeposlání se již formát přepsané adresy nemění – případné zprávy jsou přeposlány přímo serveru, který provedl první přepis a od něj původnímu odesílateli.

Jinou možností přepisu adres je použití databáze. Každá adresa odesílatele se uloží do databáze pod náhodně vygenerovaným klíčem. Adresa se pak přepíše do tvaru:

SRS0=<klíč>@B.org 

Při doručení zprávy na takovou adresu se skutečná identita odesílatele zjistí z databáze. Položky se z databáze se po určité době vyčistí, aby nebylo možné jednou naučenou adresu používat trvale. Výhodou použití databáze je hlavně omezení problémů s délkou uživatelské části e-mailové adresy. Nevýhodou naopak nutnost databázi synchronizovat a sdílet mezi všemi poštovními servery organizace.

Ne úplně povedený standard

S trochou nadsázky to s odstupem času vypadá, že standard SPF řeší zhruba stejné množství problémů, jako sám vytváří. Velcí e-mailoví hráči ho však vzali za svůj, a tak zbytku správců nezbývá než se přizpůsobit. Máte-li v plánu SPF zavést pro svoji doménu, začněte nejdříve průzkumem, kudy uživatelé e-mailových schránek odesílají svou poštu a případně nápravou špatného stavu. Stále totiž existuje nemalé procento lidí, kteří odesílají poštu pochybnými cestami začínajícími obvykle u SMTP serveru internetového poskytovatele. Situace se ale pomalu zlepšuje, i velcí freemailoví poskytovatelé nabízejí autentizované předávání pošty k tomu určenou službou Submission (TCP/587).

Vzhledem k problému s přeposíláním rozhodně nelze doporučit zavádět tvrdé -all a doufat, že problém bude vyřešen na jiné straně spojení. Volba softfail se jeví jako nanejvýš vhodná.

Už z popisu SRS je jasné, že jde o vcelku komplexní službu, která navíc není nativně podporována většinou poštovních serverů. O jejím nasazení se však vyplatí uvažovat zejména u nejrůznějších školních či univerzitních schránek, kde je míra přeposílání pošty velká.

Nasadili jste SPF a/nebo SRS ve své síti? Podělte se s ostatními čtenáři o zkušenosti s použitým softwarem v diskuzi!