SPF

Úvod

Sender Policy Framework (SPF) představuje rozšíření SMTP protokolu, které pomáha identifikovat emaily od falešného odesílatele na základě seznamu povolených IP adres v záznamech konkrétní domény.

Princip SPF je založen na dvou předpokladech:

1. Správce domény publikuje na serveru v rámci DNS zóny seznam serverů, které mají právo odesílat zprávy s adresou své domény
2. Mailový server, který obdrží zprávu s názvem domény v její adrese, jí pak oveří pomocí DNS záznamů, kde je přesně specifikováno, zda je daná adresa oprávněna odesílat zprávy z dané IP adresy. V případě, že zpráva příjde s neznámého serveru, považuje se rovnou za falešnou.

Jednoduše shrnuto, SPF tedy umožňuje majitelům internetových domén specifikovat za pomocí DNS záznamů, které počítače jsou autorizvané posílat emaily s adresou, které končí názvem domény v Return-Path (jmeno@domena.cz).

Tento způsob obrany proti Phisingu je tedy logicky zaměřen na pro bežné uživatele emailům, kteří mohou například obdržet automaticky generovanou zprávu se zfalšovanou zpáteční adresou za účelem vymámení důležitých informací např. ohledně bankovního účtu.

SPF definuje primitivní jazyk, ve kterém lze specifikovat DNS záznamy, tedy servery, ze kterých lze posílat maily s danou adresou. Dále celou řadu pravidel včetně možnosti povolit odesílání všem počítačům uvedeným jako MX odesílací domény nebo těm, jejichž IP adresa se resolvuje do dané domény. Jazyk dále umožňuje vkládat do záznamů pravidla z jiné domény nebo přímou přesměrovací direktivu, což umožňuje obsluhu vzdálených domén.

Vlastnosti SPF

Některé nevýhody

• nevýhodou je skutečnost, že spammeři vlastnící účet v doméně se SPF mohou zasílat email právě s úspěšnou verfikací adresy v Return-Path naproti IP adrese.
• některé domény využívá nepřeberné množsví uživatelů, seznam server policy není vždy kompletní
• DNS záznamy fungují prostřednictví formátu TXT, což není moc čisté

K čemu SPF neslouží

• SPF neslouží jako obrana proti příchozím spamům, ale pouze k autentizaci odesílatele
• SPF neověřuje skutečnou identitu odesílajícího

Konfigurace DNS záznamů

DNS záznam může vypadat následovně:

example.net TXT "v=spf1 mx a:pluto.example.net include:gmail.com -all"

kde

Parametr	Popis
v=	verze SPF 1
mx	příchozí emailové servery (MX) dané domény jsou také autorizované posílat maily jako example.net
a:pluto.example.net	počítač pluto.example.net je také autorizovaný
include:gmail.com	vše považováno gmail.com za legitimní je považováno example.net jako legitimní

Syntaxe DNS záznamů

Záznamy DNS může definovat žadný nebo více mechanismů popisují odesílající hosty na dané doméně.

Seznam modifikátorů:

• all: -all vylučuje všechny ostatní než specifikované, +all osamoceně říká že se záznam nebude používat
• a: jestliže je IP klienta koresponduje s IP adresou za parametrem a, pak tento mechanismus splňuje
• mx: definuje splňující mailové servery
• další mechanismy –ptr, -ip4, -ip6, -include a -exists jsou podrobně popsány na stránkách věnovaných syntaxu

Každý z mechanismů může být kombinován s jedním se čtyř kvalifikátorů.

• + pro úspešný výsledek PASS, může být vynecháno
• - pro neúspešný výsledek FAIL; mail by měl být odmítnut
• ? neutrální výsledek NEUTRAL signalizuje žádnou správu nad danou doménou
• ~ SOFTFAIL alternativní výsledek mezi FAIL a NEUTRAL; možnost odstranění nejednoznačnosti

Domény mohou definovat i vlastní modifikátory, ty mohou objevti maximálně jednou-

• redirect: záznam se přesměruje na jiný DNS záznamy
• exp: pomocí tohoto modifikátoru lze příjmeci, který odmíte email, poslat zprávu prostřednictvím jiné domény využívající SPF makro jazyk

Standardy pro autentifikaci emailu

Následující návrhy jsou vytvořeny simlutánně skupinou MARID, která byla založena v roce 2004 s cílem navrhnout standardy pro autentifikaci emailové zprávy. Následující definice jsou vytvořené nezávisle a měly by se dát se aplikovat součaně.

RFC 4405 - SMTP Responsible Submitter Extension

Standard 4406 definuje rozšíření Simple Mail Transfer Protokolu tak, aby umožnil SMTP klientovi specifikovat emailovou adresu zcela původní entity, která uvedla zprávu do řetězu jejího přenosu v Internetu. Toto rozšíření pomáhá serverům, které příjmají maily, efektivně rozhodnout zda daný SMTP klient je oprávněn posílat mail v zastoupení odpovědné domény odesílatele.

Falzifikace identity odesílate zprávy přivedla autory k myšlence vyvinout právě tuto identifikaci osoby odpovědné za odeslání emailu.

Tato specifikace ustanovuje pravidla pro kódování údajně zodpovědné adresy do SMTP protokolu, což umožní příchozím SMTP serverům efektivně rozhodnout, zda je daný SMTP klient autorizován posílat mail z dané domény.

RFC 4407 - Purported Responsible Address in E-Mail Messages

Tento záznam experimentálně popisuje algoritmus, který z příchozího emailu zjistí identitu nejpravděpodobnějšího odesílatele. Tato identita se nazývá Purported Responsible Address (PRA) a měla by se dát vyčits z hlavičky mailu.

RFC 4406 - Sender ID: Authenticating E-Mail

Tento dokument popisuje skupinu testovacích analýz, pomocí nichž může SMTP server zjistit, zda adresa uvedená v příchozí zprávě byla použita s povolením správce domény z dané adresy. Testování probíha ve dvou úzce spojených procesech. Jeden ověřuje identitu definovanou níže v dokumentu RFC 4407 jako PRA – Purported Responsible Address, tedy skutečnou identitu odesílatele (adresu) a druhá kontroluje ze zprávy položku MAIL FROM, ta je podrobně popsána v dokumentu RFC 4408 – Sender Policy Framework. Odesílatel přizpůsobený této specifikaci by měl potom vydávat informace právě pro oba zmíněné testy. Stejně tak každý příjemce pracující s touto specifikací by měl provézt aspoň jeden z těchto testů.

Ve skutečnosti Sender ID představuje protokol společnosti Microsoft odovzený od SPF, který validuje jednu z adres v hlavičce mailu HELO a MAIL FROM, které jsou definované v RFC 2822. Který z nich bude valdován rozhodou je právě výše zmínění algoritmus PRA.

SPF 2.0 záznamy – tag pro Sender ID záznamy může být specifikován jako spf2.0/pra, spf2.0/mfrom nebo spf2.0/mfrom,pra, záleží na které z identit MAIL FROM nebo HELO je algoritmus ověřování aplikován. Sender ID však nepředstavují poslední verzi SPF, je to nový a nezávislý protokol. Přesto je synataxe spf2.0 totožná s v=spf1.

V tomto případě jsou SPF 2.0 identifikovany prefixem spf2.0 a slouží k odesílání domén k umožnění přesné specifikace toho, jak mají být záznamy interpretovány.

Kompatibilita SPF1 a SPF2.0 záznamů

Vzhledem ke komaptibilitě záznamů s prefixem spf2.0 a v=spf1, implementace Sender ID by měla podle specifikace RFC 4406 interpretovat verzi v=spf1 jako spf2.0/mfrom,pra. To je však z technického pohledu špatně. Správně by měla považovat v=spf1 jako spf2.0/mfrom. Administrátor, který již publikoval záznamy s prefixem v=spf1 by měl tedy zkontrolovat, zda jsou validní i pro testy PRA.

Vzhledem k tomu, že specidiface Sender ID v RFC 4406 se dokazuje na definice SPF v RFC 4408 a tedy logicky vzhledem delší existenci projektu v=spf1, implementace Sender ID by měly správně respektovat výše zmíněný fakt a RFC 4406 v sekci 3.4 ignorovat.

Rozhodovací model serveru pro příchozí zprávy

Sender ID vyhodnotí příchozí zprávu s IP adresou a určí, zda je SMTP klient autorizován tuto zpávu odesílat.

Odpověd lze rodělit do 3 kroků:

a) Nejprve se ze zprávy extrahuje adresa. To provede buď PRA verifikace definovaná v RFC 4407 nebo se použije původní adresa specifikovaná v RFC 4405. Druhá varianta tohoto testu přes adresu MAIL FROM specifikuje Sender Policy Framework specifikovany jako RFC 4408.. b) Extrahuje se doménová část adresy. c) Zavolá se funkce check_host() definovaná níže v RFC 4408

V případě, že Sender ID v bodě a) nemůže získat ani jednu z uvedených adres, zprávu odmítne s chybouvou zprávou 550.

Výsledek funkce check_host() představuje jeden z následujících klíčových slov: Neutral, Pass, Fail, SoftFail, None, TempError nebo PermError.

RFC 4408 - Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail

Poslední z řady dokumentů skupiny MARID popisuje SPF ve verzi 1, což je obsahem tohoto dokumentu.

Výhody a nevýhody SPF oproti jiným řešením

• + SPF bere jako primární údaje ze SMTP příkazů HELO/EHLO nebo obálky MAIL-FROM, kdežto například DomainKey postupuje pouze z údajů v hlavičce (Sender, From)
• + Zprávu lze odmítnout již po přečtení MAIL-FROM a není třeba jí cekou přenášet
• + Malé nároky na CPU
• + Snadné zavedení autorizace ve formě DNS záznamů
• - Celkově (kvůli více DNS lookupům) asi bude pomalejší.
• - Všichni uživatelé musí pro odesílání používat pouze některý ze oficiálních odesílacích SMTP serverů domény
• - Používá TXT záznamy domény jako takové, což není moc čisté.

Implementace v různých programovacích jazycích

Následující tabulka obsahuje několik základních knihoven implementace SPF

Jazyk	Název knihovny	URL
Perl	Mail::SPF::Query	http://search.cpan.org/dist/Mail-SPF-Query/lib/Mail/SPF/Query.pm
C	libspf	http://www.libspf.org/
C	libspf2	http://www.libspf2.org/support.html
pyspf 1.6	Python	http://www.wayforward.net/spf/
pyspf updates	Python	http://sourceforge.net/projects/pymilte

Některé nástavby nebo patche SPF modulů pro mailové servery jsou uvedeny v následující tabulce

Mailserver	Jméno	URL
Sendmail	libspf/libspf2 spfmilter	http://www.acme.com/software/spfmilter/
Postfix	libspf	http://www.libspf.org/
Exchange	SPF Event Sink	http://sourceforge.net/projects/spf-event-sink/
Courier	native	http://www.courier-mta.org/
Exim	exiscan ACL	http://duncanthrax.net/exiscan-acl/
Qmail	libspf Qmail Patch	http://www.libspf.org/