SPF

Z Wikipedie, otevřené encyklopedie
Skočit na: Navigace, Hledání

SPF nebo-li 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 SPF záznam (nebo TXT záznam) v DNS (Domain Name System). 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.

Zásady provozu[editovat | editovat zdroj]

SMTP protokol umožňuje odeslat email s libovolnou zdrojovou adresou. 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říjme 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[editovat | editovat zdroj]

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

Publikační politika[editovat | editovat zdroj]

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ů[editovat | editovat zdroj]

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[editovat | editovat zdroj]

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"

„IN=“ definuje použitou verzi SPF. Následují mechanismy, které jsou použity, zda je doména způsobilá k odesílání pošty. „IP4“ a „a“ specifikují povolené systémy k odesílání zpráv pro danou doménu. „-All“ na konci uvádí, že v případě nesouhlasících mechanizmů, by měla být zpráva odmítnuta.

Mechanismy[editovat | editovat zdroj]

Je definováno osm mechanismů:

ALL Vždy odpovídá; použito jako defaultní výsledek jako -all pro všechny IP neodpovídající předchozím mechanizmům.
A Pokud má doménové jméno záznam adresy (A nebo AAAA), které může být vyřešeno adresou odesílatele, bude odpovídat.
IP4 Je-li odesílatel v rozsahu adres IPv4, přijato.
IP6 Je-li odesílatel v rozsahu adres IPv6, přijato.
MX Pokud je doménové jméno v MX záznamu rozlišující adresu odesílatele, bude přijato (tj. mail přichází z jednoho z doménových serverů).
PTR Pokud je název domény (PTR záznam) na klientovu adresu vzhledem k doméně a že doménové jméno se překládá na adresu klienta (FCrDNS), přijato.
EXISTS Určuje jednu nebo více domén, které jsou obvykle vybrány jako výjimky z definic SPF. Dotaz je provedena v zadané doméně, pokud je nalezen výsledek nastane shoda. Toto se používá jen zřídka
INCLUDE Určuje další domény, které jsou oprávněné domény

Kvalifikace[editovat | editovat zdroj]

Každý mechanismus může být kombinován s jednou ze čtyř kvalifikací:

Předpona
+ Pass. Adresa prošla testem.
- Fail. Adresa neprošla testem.
~ Softfail. Adresa neprošla testem, ale výsledek není definitivní.
 ? Neutral. Adresa neprošla testem, nebo došlo k selhání testu.

Modifikátory[editovat | editovat zdroj]

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[editovat | editovat zdroj]

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í[editovat | editovat zdroj]

Interpretace[editovat | editovat zdroj]

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, t.j 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í[editovat | editovat zdroj]

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 [editovat | editovat zdroj]

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 [editovat | editovat zdroj]

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[editovat | editovat zdroj]

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 RFC4407: „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[editovat | editovat zdroj]

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]. . Dostupné online. (anglicky) 
  2. Wong, M., and W. Schlitt. RFC 4408. April 2006 <http://tools.ietf.org/html/rfc4408>
  3. http://www.openspf.org/Tools