Hlavní navigace

SPF a Sender-ID

Michal Kára 10. 11. 2004

Ve svém předešlém článku jsem se věnoval technologii DomainKeys. Dnes bych chtěl váš odborný rozhled doplnit o informace o technologiích SPF a Sender-ID. Ty mají podobný cíl jako DomainKeys, ale řeší jej trochu jiným způsobem: místo aby si údaje pro ověření odesílatele emailu braly z hlavičky, berou jej přímo ze SMTP příkazů.

Začnu technologií SPF, což je zkratka pro Sender Policy Framework. Můžete se s ní setkat i pod starším názvem Sender Permitted From. SPF nevzniklo na zelené louce, hodně těží ze starších návrhů, nicméně jeho autor byl nejhalasnější, a i proto tento standard začalo používat AOL (a mnoho dalších společností).

Stejně jako DomainKeys si SPF klade za cíl omezit možné podvržení odesílatele mailu. Dosahuje toho tak, že doména ve svém TXT záznamu definuje, které servery smí odesílat maily s adresou odesílatele v této doméně. Maily z ostatních serverů jsou potom považovány za možné nebo jisté falzifikáty – podle toho, co záznam o doméně určí.

Standard SPF definuje celý jednoduchý jazyk, jímž je možné tyto servery specifikovat. Můžete zde definovat jednak přímo IP podsítě, ale existují i obecnější pravidla, pomocí nichž lze povolit odeslání všem počítačům, uvedeným jako MX odesílací domény, nebo těm, jejichž IP adresa se resolvuje na jméno v dotyčné doméně.

U pravidla je možno specifikovat prefix, kterým naopak zajistíte, že splnění pravidla bude mít za následek odmítnutí dopisu jako podvrženého. Tím lze dobře udělat různé výjimky.

Například záznam lupa.cz IN TXT "v=spf1 +mx +ptr -all" povoluje odesílání emailů s odesílatelem v doméně lupa.cz strojům sloužícím jako MX pro tuto doménu a dále strojům majícím reverzní záznam v této doméně. Pokud je email odeslán z jiného počítače, má se brát jako podvrh.

Jazyk rovněž obsahuje direktivy pro vložení (include) pravidel z jiné domény, případně rovnou přesměrování na jinou doménu. Tak můžete jednoduše spravovat SPF pro více domén, které mají stejné odesílací servery (například více firemních domén).

Jazyk má i další rozšíření – například makra. Ale v tomto bodě se mi zdá, že už zachází až příliš daleko. Jeho korektní parser nebude jednoduchý, a to je nevýhoda.

Narozdíl od DomainKeys, které počítají s určováním odesílatele pouze z hlavičky mailu (pole Sender: nebo From:), SPF bere jako primární údaje ze SMTP příkazů HELO nebo MAIL FROM: (obálky). I když, podle návrhu standardu, je možné ověřovat i doménu získanou z hlavičky zprávy.

Paralelně k SPF publikoval Microsoft svoji specifikaci CallerID, která fungovala velmi podobně jako SPF. Zásadní rozdíly byly dva. Jednak Microsoft místo jednoduchého jazyka používá specifikaci v XML. To je sice na jednu stranu pěkné a čisté řešení, které navíc silně zjednodušuje parsing SPF specifikace, neboť jej lze svěřit knihovně. Na druhou stranu mi to přijde tak trochu jako kanón na vrabce, nehledě k tomu, že XML reprezentace je o dost delší a nemusela by se vejít do limitu pro DNS záznam, což je na většině používaných serverů 512 bajtů.

Dále Microsoft místo používání SMTP HELO a obálky definoval tzv „Purported Responsible Address“ (PRA) algoritmus na zjištění adresy odesílatele z hlaviček mailu. (Tento algoritmus je podobný tomu, jaký používá Yahoo v DomainKeys).

V rámci standardizační organizace IETF vznikla skupina MARID, která se měla věnovat definici společného standardu. Jejím výsledkem byl návrh označovaný jako SenderID, což je kombinace SPF a CallerID. Ovšem standardizační snahy prozatím neuspěly. Kamenem úrazu je totiž patentování některých částí CallerID/SenderID firmou Microsoft a hlavně licence, která nevylučuje zpoplatnění používání tohoto standardu v budoucnu. To se nelíbilo členům zastupujícím OSS, a jelikož Microsoft odmítl v tomto ohledu udělat jakékoli změny, skupina se rozpadla.

Klady a zápory SPF bych, s přihlédnutím k tomu, co jsem napsal o DomainKeys, hodnotil asi takto:

  • – 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é.
  • + Jednodušší na zavedení autorizace než DomainKeys – stačí vytvořit záznamy v DNS.
  • + Dovoluje zahodit zprávu už po specifikování Mail From, nemusí se celá přenést.
  • + Méně náročné na CPU.
  • – Celkově (kvůli více DNS lookupům) asi bude pomalejší.

Petr Souček dal (v diskusi ke článku o DomainKeys) dohromady tento seznam odkazů na návrhy standardů:

Našli jste v článku chybu?

18. 11. 2004 20:41

Dan Lukes (neregistrovaný)
To uz tu jednou bylo a jedeme dokola, takze jen velice strucne. Elektronicky podpis musite take jednou zavest. A klice muzete vydavat na sto let, budete-li chtit. Nevim, kolik klientskych softwaru tuto technilogii nepodporuje - z tech, co vitam ve svem okoli kazdy - takze i tento argument je, zrejme, umely. Nastaveni v souvislosti s prichody a odchody zamestnancu musite delat tak jako tak - preci jim nenechavate pristup na firemni servery a do firemnich schranek. Pridat do CRL jedno seriove cisl…

18. 11. 2004 19:50

Michal Kára (neregistrovaný)
Presne tohle jsme uz resili u DomainKeys... Ano, osobni elektronicky podpis je kanon na vrabce. DomainKeys i SPF se proste jednou zavedou (u SPF dokonce staci jen pridat radek do DNS), kdezto u klicu je problem s vhodnym klientskym SW a musi se o to porad nekdo starat (prichazeji/odchazeji zamestnanci), zatimco SPF se meni jen kdyz provadim nejake vyznamnejsi zmeny v siti.
Měšec.cz: Air Bank zruší TOP3 garanci a zdražuje kurzy

Air Bank zruší TOP3 garanci a zdražuje kurzy

Měšec.cz: Vklad na cizí účet je draze zpoplatněn (přehled)

Vklad na cizí účet je draze zpoplatněn (přehled)

Měšec.cz: Kdy vám stát dá na stěhování 50 000 Kč?

Kdy vám stát dá na stěhování 50 000 Kč?

Lupa.cz: Levný tarif pro Brno nebude. Radní: je to kartel

Levný tarif pro Brno nebude. Radní: je to kartel

Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

Vitalia.cz: Dáte si jahody s plísní?

Dáte si jahody s plísní?

Root.cz: Vypadl Google a rozbilo se toho hodně

Vypadl Google a rozbilo se toho hodně

Podnikatel.cz: 3, 2, 1..EET startuje. Na co nezapomenout?

3, 2, 1..EET startuje. Na co nezapomenout?

DigiZone.cz: Rádio Šlágr má licenci pro digi vysílání

Rádio Šlágr má licenci pro digi vysílání

Měšec.cz: Platby do zahraničí: pozor na tučné poplatky

Platby do zahraničí: pozor na tučné poplatky

Měšec.cz: Za palivo zaplatíte mobilem (TEST)

Za palivo zaplatíte mobilem (TEST)

DigiZone.cz: ČT má dalšího zástupce v EBU

ČT má dalšího zástupce v EBU

Měšec.cz: Golfové pojištění: kde si jej můžete sjednat?

Golfové pojištění: kde si jej můžete sjednat?

120na80.cz: Rovnátka, která nejsou vidět

Rovnátka, která nejsou vidět

Měšec.cz: Finančním poradcům hrozí vracení provizí

Finančním poradcům hrozí vracení provizí

Podnikatel.cz: Zavře krám u #EET Malá pokladna a Teeta?

Zavře krám u #EET Malá pokladna a Teeta?

120na80.cz: Co všechno ovlivňuje ženskou plodnost?

Co všechno ovlivňuje ženskou plodnost?

DigiZone.cz: Milan Kruml: procházka TV historií

Milan Kruml: procházka TV historií

Podnikatel.cz: Udávání kvůli EET začalo

Udávání kvůli EET začalo

Vitalia.cz: Jsou čajové sáčky toxické?

Jsou čajové sáčky toxické?