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

Ondřej Caletka 9. 4. 2015

Sender Policy Framework je jedno z opatření, jak zvýšit důvěryhodnost e-mailové komunikace pomocí speciálních autorizačních DNS záznamů. Za určitých okolností ale může SPF způsobit nefunkčnost přeposílané pošty. V prvním díle nového seriálu o e-mailových reputačních systémech se podíváme, jak SPF funguje.

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:

znak název význam
+ pass daný rozsah adres vyhovouje politice (výchozí)
? neutral pro daný rozsah adres politika neexistuje
- fail daný rozsah adres nevyhovouje politice
~ softfail daný rozsah adres spíše nevyhovouje politice

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 BC. 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á.

widgety

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!

Našli jste v článku chybu?
Lupa.cz: Patička e-mailu závazná jako vlastnoruční podpis?

Patička e-mailu závazná jako vlastnoruční podpis?

Podnikatel.cz: Nemá dluhy? Zjistíte to na poště

Nemá dluhy? Zjistíte to na poště

DigiZone.cz: Slovensko: startuje sportovní TV 213

Slovensko: startuje sportovní TV 213

DigiZone.cz: Digi2GO: výborný základ, ale...

Digi2GO: výborný základ, ale...

Vitalia.cz: dTest odhalil ten nejlepší kečup

dTest odhalil ten nejlepší kečup

DigiZone.cz: Wimbledon na Nova Sport až do 2019

Wimbledon na Nova Sport až do 2019

Podnikatel.cz: Tyto pojmy k #EET byste měli znát

Tyto pojmy k #EET byste měli znát

120na80.cz: Nejsilnější alergeny jsou pryč

Nejsilnější alergeny jsou pryč

120na80.cz: Co je padesátkrát sladší než cukr?

Co je padesátkrát sladší než cukr?

Vitalia.cz: Muž, který miluje příliš. Ženám neimponuje

Muž, který miluje příliš. Ženám neimponuje

Vitalia.cz: Tohle jsou nejlepší česká piva podle odborníků

Tohle jsou nejlepší česká piva podle odborníků

Vitalia.cz: Tradiční čínská medicína a rakovina

Tradiční čínská medicína a rakovina

Podnikatel.cz: Byla finanční manažerka, teď cvičí jógu

Byla finanční manažerka, teď cvičí jógu

DigiZone.cz: Technisat připravuje trojici DAB

Technisat připravuje trojici DAB

DigiZone.cz: Digi Slovakia zařazuje stanice SPI

Digi Slovakia zařazuje stanice SPI

Lupa.cz: Jak se prodává firma za miliardu?

Jak se prodává firma za miliardu?

DigiZone.cz: Světový pohár v přímém přenosu na ČT

Světový pohár v přímém přenosu na ČT

DigiZone.cz: Na jaká videa se vlastně díváme

Na jaká videa se vlastně díváme

Lupa.cz: Cimrman má hry na YouTube i vlastní doodle

Cimrman má hry na YouTube i vlastní doodle

120na80.cz: Galerie: Čínští policisté testují českou minerálku

Galerie: Čínští policisté testují českou minerálku