Sender Policy Framework

SPF neboli Sender Policy Framework je e-mailový validační systém sloužící jako obrana proti spamu. Jeho princip spočívá v tom, že ověřuje IP adresu odesílatele. SPF umožňuje administrátorům určit, které počítače mohou odesílat poštu z dané domény. Administrátor musí vytvořit v DNS TXT záznam ve formátu SPF. SMTP server pomocí DNS záznamu rozhodne, zda je pošta odeslaná z příslušné adresy pro danou doménu schválena.[1]

SPF je definován IETF standardem RFC 4408. SPF spolupracuje s DMARC.

Zásady provozu

SMTP protokol umožňuje odeslat email s libovolnou adresou odesilatele. To využívají spammeři, kteří často používají falešné adresy. Je potom obtížné vysledovat zprávu zpět k odesílateli a tak je skryta identita spammera. Tato technika se také používá u phishingu, kdy se útočník snaží ze své oběti vylákat osobní údaje. Toho docílí odesláním emailu, který se tváří jako pošta např. od banky.

SPF umožňuje majiteli internetové domény určit, které počítače mohou odesílat poštu s adresou odesílatele této domény. Používají se na to speciální DNS záznamy (SPF, typ 99). Příjemce může ověřit záznam SPF a odmítnout zprávu od neautorizovaného zdroje ještě před tím, než přijme tělo zprávy.[2]

To znamená, že je tento systém v principu podobný jako DNSBL (Domain Name System Blacklist). Dřívější implementace používala TXT záznamy, ale dnes už se používají záznamy, které jsou k dispozici v DNS. Záznam typu TXT byl vytvořen pouze jako přechodný mechanismus.

Adresa odesílatele je přenesena na začátku SMTP dialogu. Pokud server odmítne poslat email z nějaké adresy, odesílatel obdrží upozornění. SPF však nezabrání padělání adres tím, že spammer vloží do záhlaví zprávy pole Return-Path, které se neshoduje se zdrojovou adresou.

Spammer může odeslat e-maily, které projdou přes SPF tím, že si založí účet v dané doméně. Tím ale zároveň lze vystopovat jeho identitu.

Nevýhodou je, že vlastníci adres, které jsou falešně použity v hlavičce Return-Path, dostávají velké množství chybových zpráv. Tomu lze zabránit, pokud použijeme SPF, kde zadáme legitimní zdrojové IP adresy. Tím částečně eliminujeme množství chybových zpráv.

Implementace

Implementace SPF se skládá ze tří základních částí:

Publikační politika

Doména a host identifikují počítač, který je oprávněn rozesílat e-mail jejich jménem. Dělá se to tak, že se přidá další záznam do DNS. Každá doména nebo host, který má záznam typu A nebo MX, by měl mít také záznam SPF. Ta určuje politiku, která je pro danou adresu určena nebo je zde uveden argument HELO/EHLO. I počítače, které neodesílají žádné zprávy, by měly mít SPF záznamy. To se důrazně doporučuje, aby bylo možné použití nástrojů, které testují validitu SPF záznamů. Ty jsou k dispozici na internetové stránce SPF projektu.[3]

Kontrola a použití SPF záznamů

Servery používají DNS dotazy, které jsou obvykle uloženy v mezipaměti kvůli zvýšení výkonu. DNS záznamy tak mohou být zkreslené a mohou mít vliv na výsledek SPF.

Revize přeposílané pošty

SPF zakazuje prosté přeposílání poštovních zpráv. Alternativy jsou:

  • nahrazení původního odesílatele jedním, který patří do lokální domény
  • odpověď 551 User not local; prosím zkuste <uzivatel@priklad.cz>
  • whitelist na cílovém serveru, takže neodmítne předání zprávy
  • Sender Rewriting Scheme, složitější mechanismus, který zpracovává oznámení o nedoručení původnímu odesílateli

To znamená, že klíčové je v SPF specifikovat informace pro nově nastavené DNS domény a přijímače. Záznam níže je uveden v typické DNS syntaxi: 

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

„v=“ definuje použitou verzi SPF. Následuje seznam pravidel pro rozhodnutí, zda odesílající může posílat zprávy z dané domény (v tomto případě „example.com“). První dvě pravidla (začínající „ip4:“) značí, že pokud má odesílající danou IPv4 adresu, zprávy zasílat může. Pravidlo „a“ značí, že pokud daná doména má DNS A záznam odkazující na odesílajícího, zprávu lze poslat. Konečně poslední pravidlo „-all“ značí, že pokud odesílající nevyhověl žádnému z předchozích pravidel, zprávu z dané domény odesílat nemůže.

Pravidla

Každé pravidlo je buď pozitivní (povoluje odesílání), neutrální (pravidlo ani nepovoluje, ani nezakazuje), slabě negativní (pravidlo zakazuje jen pokud žádné jiné pravidlo nepovoluje) nebo negativní (zakazuje odesílání bez ohledu na následující pravidla). Negativní pravidla začínají znakem „-“, slabě negativní znakem „~“, neutrální znakem „?“. Pozitivní pravidla mohou (ale nemusí) začínat znakem „+“. Každé pravidlo určuje, na které odesílatele se vztahuje. Při zjišťování, zda odesílající může odesílat poštu z aktuální domény, se použije první pozitivní či negativní pravidlo, které se na něj vztahuje. Pokud se na něj žádné takové pravidlo nevztahuje, ale vztahuje se na něj nějaké slabě negativní pravidlo, odesílajícímu je typicky povoleno poštu odeslat, ale jeho pošta je označena (např. se přidá informace o slabém zákazu do hlavičky mailu). Pokud je například prvním pravidlem „all“, které se vztahuje na všechny, znamená to, bez ohledu na jakákoliv další pravidla, že poštu může odesílat kdokoliv. Naopak pokud je prvním pravidlem „-all“ znamená to, že poštu nesmí posílat nikdo (opět bez ohledu na jakákoliv další pravidla). Pravidla se dále dělí podle způsobu, kterým určují, na koho se vztahují (v následující tabulce je v prvním sloupci název pravidla a v druhém sloupci popis, na koho se pravidlo vztahuje)

ALL Pravidlo se vztahuje na všechny odesílatele.
A Vztahuje se na odesílatele mající IP adresu, která odpovídá adrese uvedené v DNS A (či AAAA) záznamu domény.
IP4 Vztahuje se na odesílatele mající IPv4 adresu v rozsahu zadaném za dvojtečkou.
IP6 Vztahuje se na odesílatele mající IPv6 adresu v rozsahu zadaném za dvojtečkou.
MX Vztahuje se na odesílatele mající IP adresu, která odpovídá některému MX záznamu domény (tj. vztahuje se na servery, které pro tuto doménu přijímají poštu).
PTR Vztahuje se na odesílatele, jejichž adresa (dle PTR záznamu) je v doméně uvedené za dvojtečkou a zároveň je shodná s adresou této domény (tj. nejprve se provede reverzní DNS dotaz na adresu odesílatele a následně se zkontroluje, že výsledné doménové jméno odkazuje zpět na adresu odesílatele). Toto pravidlo je zastaralé a nemělo by se dále používat.[4]
EXISTS Vztahuje se na libovolného odesílatele, jehož adresa odpovídá nějaké doméně. Toto pravidlo se používá velmi zřídka.
INCLUDE Toto je speciální pravidlo, které odkazuje na pravidla pro doménu uvedenou za dvojtečkou. Pokud odesílatel může odesílat z uvedené domény, může odesílat i z aktuální domény. Pokud ale z uvedené domény odesílat nemůže, pokračuje se k dalším pravidlům (tzv. softfail).

Modifikátory

Modifikátory umožňují budoucí rozšíření rámce. K dnešnímu dni jsou pouze dva modifikátory definované v RFC 4408, byly zavedeny v širokém měřítku:

  • exp – Nastaví vysvětlení v SPF záznamu. Je-li dotaz SPF fail (selhání), vysvětlující řetězec poskytuje více informací neodpovídajícímu uživateli. Vysvětlení je obvykle umístěn v protokolu SPF.
  • redirect – Odešle dotaz na jinou doménu. Příklad: redirect = exampleredirect.com

Zpracování chyb

Jakmile SPF implementace odhalí syntaktické chyby v politice odesílatele, musí přerušit ohodnocení s výsledkem PERMERROR. Přeskakování chybných mechanismů nemůže fungovat podle očekávání a proto: bad.example and redirect=bad.example může také způsobit PERMERROR.

Další pojistkou je maximálně deset mechanizmů dotazování na DNS, tj. jakýkoli mechanismus s výjimkou z -IP4, -IP6 a -all. Implementace může přerušit hodnocení s výsledkem SOFTERROR, když to trvá příliš dlouho, nebo když DNS dotaz vypršel, ale musí se vrátit PERMERROR, pokud politika potřebuje přímo či nepřímo více než deset dotazů na mechanismy.

Upozornění

Interpretace

Politika SPF FAIL může být účinná, ale problematická. Typickým příkladem je uživatel, který pošle mail z vlastního PC nebo mobilního telefonu: uživatel používá firemní mailovou adresu, ale může použít jiný odchozí SMTP server, který není uveden v SPF záznamu. Pokud je firemní doména zabezpečena, tak že blokuje veškerou poštu, která nepochází z její domény, může omezit některé uživatele.

SPF PASS je užitečné k ověřování domény pro použití jako parametr pro klasifikaci spamu. To znamená, že doménu na adrese odesílatele můžeme považovat za autentickou, pokud původní IP vrací SPF PASS.

SPF výsledky jiné než PASS (používá se v kombinaci s reputačním systémem) a FAIL nelze srozumitelně mapovat na PASS a FAIL. Avšak reputační systém lze snadno sledovat nezávisle na reputaci pro každý výsledek SPF, tj. example.com:PASS a example.com:NEUTRAL, by měl mít jinou reputaci a totéž pro ostatní výsledky. Tento přístup je užitečný i bez prostého předání whitelistingu, protože výsledek FAIL z prostého předávání jednoduše plyne v nezávislou reputaci.

Význam PASS, SOFTFAIL, FAIL je někdy nesprávně interpretován jako „not-spam“, „maybe-spam“ a „spam“. Nicméně SPF nic takového nedělá. SPF pouze nabízí organizovat nejprve prostředky pro roztřídění e-maily na základě názvu jejich domény namísto jejich IP adresy (SPF PASS); a za druhé, způsob k zablokování neoprávněného použití jejich domény (SPF FAIL).

Intra-domain padělání

Naivní implementace SPF nebrání uživateli se stejnou doménou zaslání e-mailu jménem jiného uživatele, protože jen část doménové adresy se používá k vyhledání záznamu SPF. V sofistikovanější implementaci majitel domény může určit různé zásady pro každého uživatele pomocí SPF „makra“, které odkazují na „localpart“ (uživatel) podle definice v RFC 4408, nebo jednoduše vyžaduje všechny poštovní podání pro doménu používat SMTP AUTH (RFC 4954). To se doporučuje z mnoha důvodů.

Kontrolní body 

K provozu na hostitelském počítači potřebuje mít SPF MX záznam přijímací domény. Hostitelské počítače, které jsou přímými příjemci vzdálených TCP připojení, mohou snadno odhalit původní adresu IP z protokolu TCP session. Tyto počítače jsou schopny zablokovat e-mail během SMTP session a vyhnout se nutnosti generovat vracené zprávy, které by mohly být backscatter. (Jak SPF RFC 4408: „generovat oznámení o nedoručení podvrženým identitám, které neprošlo kontrolou autorizace je obecně bráno jako urážlivé a proti výslovnému přání vlastníka identity.“).

Další navazující hostitelé, například v případě předávání mohou provádět pouze SPF kontroly založené na „Received“ hlavičce. Tento postup je těžkopádný a náchylný k chybám. Lepším přístupem je pro MX hostitele zvolit SPF bez blokování žádného e-mailu, a pak přidat „Received-SPF“ do pole hlavičky, jak je uvedeno v dokumentu RFC 4408 nebo novější „Authentication-Results“ hlavička z RFC 7001. Navazující hostitel se pak může podívat na tyto hlavičky a nastavit svou vlastní politiku, zda chcete odmítnout, přijmout nebo poslat do karantény na základě výsledku SPF a dalších faktorech.

Vztah s DKIM 

SPF ověřuje obálky zpráv (SMTP bounce adress), nikoli obsah zprávy (hlavička a těla) – to je rozdíl mezi SMTP (jak je uvedeno v STD 10 nebo RFC 5321) a Internet Message Format (jak je uvedeno v STD 11 nebo RFC 5322). To je ortogonální a komplementární k DomainKeys Identified Mail (DKIM), který podepisuje obsah (včetně hlaviček).

Stručně řečeno, SPF ověřuje MAIL FROM vs. jeho zdrojový server; DKIM ověřuje „FROM:“ zprávu hlavičky a tělo mailu podle kryptografických prostředků.

Sender ID

Sender ID RFC 4406 je paralelním řešením k problému validace zpráv, a definuje dvojici úzce souvisejících testů. Jeden validuje údajně zodpovědné adresy (PRA – Purported Responsible Address), jak je definováno v RFC 4407. Druhý ověřuje zprávy Reverse-Path (také známý jako MAIL-FROM adresa), jak je definováno v dokumentu RFC 4408.

Citace z RFC 4407: „Všimněte si, že odesílatel-ID experimentu může používat DNS záznamy, které mohou být vytvořeny pro aktuální SPF experiment nebo pro staršími verzemi v této sadě experimentů. Což v závislosti na obsahu záznamu, může znamenat, že heuristika odesílatel-ID může být chybně aplikována na zprávu. V závislosti na akcích spojených s příjemcem a těmito heuristikami, může být zpráva doručena, nebo odstraněna z příjmu.“

Reference

V tomto článku byl použit překlad textu z článku Sender Policy Framework na anglické Wikipedii.

  1. ↑ Sender Policy Framework: Introduction [online]. [cit. 2014-02-06]. Dostupné v archivu pořízeném dne 2016-06-17. 
  2. ↑ Wong, M., and W. Schlitt. RFC 4408. April 2006
  3. ↑ Archivovaná kopie. www.openspf.org [online]. [cit. 2014-02-06]. Dostupné v archivu pořízeném dne 2014-02-09. 
  4. ↑ KITTERMAN, S. Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. tools.ietf.org [online]. [cit. 2017-05-11]. Dostupné online. (anglicky) 

Externí odkazy

Strategi Solo vs Squad di Free Fire: Cara Menang Mudah!