SPF a Sender-ID

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

Tento text je již více než dva měsíce starý. Chcete-li na něj reagovat v diskusi, pravděpodobně vám již nikdo neodpoví. Pro řešení aktuálních problémů doporučujeme využít naše diskusní fórum.