Sender Policy Framework

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]

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.

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 <[email protected]>
• 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.

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)

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

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.

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).

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ů.

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.

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 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.“