SPF įrašų tikrinimo įrankis (SPF Record Checker) sukurtas vienai labai įprastai šių laikų katastrofai: el. laiškas atrodo tikras, atkeliauja iš teisingos įmonės, buvo išsiųstas per teisingą paslaugą, tačiau vis tiek yra traktuojamas kaip įtartinas įsibrovėlis vien dėl to, kad siuntėjo domene paskelbtas atmestinas SPF įrašas. Įvedate domeno vardą, tikrintuvas DNS sistemoje suranda SPF taisyklę, parodo patį įrašą, seka per visas nukreipimų (include ir redirect) grandines, įvertina, kiek DNS užklausų ši taisyklė sukelia, ir išryškina įprastas klaidas: per daug viena į kitą įdėtų nukreipimo grandinių, kelis SPF įrašus viename domene, pavojingą +all, neaiškias pabaigas, kilpas bei paveldėtas nesąmones, kurių niekas neperžiūrėjo nuo kokių nors seniai pamirštų migracijos laikų.
Norint suprasti, kodėl tai svarbu, verta trumpam sulėtinti tempą ir paaiškinti visas judančias dalis paprasta žmonių kalba. A domenas yra viešas vardas, pavyzdžiui, pvz.lt. DNS (Domain Name System – domenų vardų sistema) yra pasaulinė paieškos sistema, kuri nurodo internetui, kokie techniniai įrašai priklauso tam vardui. Vienas įrašas nukreipia svetainę į IP adresą. Kitas nurodo, kurie pašto serveriai priima ateinančius laiškus. SPF yra dar viena DNS sistemoje paskelbta taisyklė. Ji nurodo laiškus priimančioms pašto sistemoms, kuriems serveriams leidžiama siųsti el. laiškus to domeno vardu. Paprastai tariant, SPF yra domeno savininko paliktas raštelis DNS sistemoje, kuriame parašyta: „Jei el. laiškas teigia esąs iš manęs, patikrinkite, ar siuntėjas yra mano patvirtintame sąraše.“ Stebėtinai daug organizacijų vis dar nesugeba atlikti šio pagrindinio saviidentifikacijos veiksmo, o vėliau jaučiasi giliai įžeistos, kai spam filtrai atsako joms tuo pačiu.
Verta žinoti ir istorinį kontekstą, nes SPF atsirado ne dėl mados ar korporacinių užgaidų. El. paštas buvo sukurtas kur kas labiau pasitikinčiais laikais, kai internetas buvo mažesnis, o žmonės dar nebuvo industrializavę apgaulės planetiniu mastu. Klasikiniame SMTP protokole, naudojamame laiškų siuntimui, buvo skausmingai lengva suklastoti siuntėjo tapatybę. Tai puikiai pasitarnavo nusikaltėliams, spameriams, fišingo meistrams ir visai pasaulinei įkyruolių sąjungai. Augant piktnaudžiavimui, el. pašto pasauliui prireikė praktiškų būdų deklaruoti, kam leidžiama siųsti laiškus konkretaus domeno vardu. SPF tapo vienu iš atsakymų. Vėliau jis buvo standartizuotas RFC 7208 dokumente, kuriame numatyta, kad ši politika DNS sistemoje skelbiama kaip TXT įrašas, prasidedantis v=spf1. Elegantiška, paprasta ir visiškai per lengva žmonėms viską pernelyg komplikuoti.
SPF įrašas yra tik tekstas, tačiau šis tekstas neša griežtą politiką. Jame galima tiesiogiai išvardyti IP adresus naudojant ip4 arba ip6. Jis gali autorizuoti paties domeno A arba MX įrašų serverius. Jis gali įtraukti kitas taisykles naudojant include:. Jis gali perduoti vertinimą kitam domenui su redirect=. Ir dažniausiai jis baigiasi tokiais simboliais kaip -all, ~all, ?all arba katastrofišku mažu klounų vežimėliu, žinomu kaip +all. Šios pabaigos yra labai svarbios. -all yra griežta: jei siuntėjas neatitinka sąrašo – atmetimas. ~all yra švelnesnė ir labai paplitusi. ?all yra gūžtelėjimas pečiais, apsimetantis politika. O +all iš esmės yra viešas pareiškimas, kad bet kas pasaulyje gali siųsti laiškus jūsų vardu – tai yra ne autorizacijos taisyklė, o veikiau oficiali kapituliacija.
SPF žmones klaidina todėl, kad jis gyvena DNS sistemoje, tačiau el. pašto pristatymas vyksta visiškai kitoje vietoje, o pašto dėžutėje matomas adresas gali būti susijęs su dar kitais domenais. Todėl žmonės užduoda klausimus visiškai neteisinga tvarka. Jie galvoja: „Mano svetainė veikia, vadinasi, mano pašto nustatymai yra tvarkingi.“ Tikrai ne. Svetainė gali veikti tobulai, kol jūsų pašto autentifikavimas yra tikras šiukšlynas. Jie galvoja: „Mano domenas egzistuoja, todėl visos juo besinaudojančios paslaugos turi būti automatiškai patikimos.“ Vėlgi – ne. Laiškus priimantis serveris tikrina techninius įrašus, kelius, IP adresus bei atitikimo logiką, o ne jūsų jausmus. Internetas turi daug trūkumų, tačiau jis yra nuostabiai abejingas jūsų pažeistai savigarbai.
Viena svarbiausių SPF realijų yra DNS užklausų limitas. RFC 7208 nurodo, kad SPF vertinimo metu DNS užklausas atliekančių mechanizmų ir modifikatorių skaičius negali viršyti dešimties. Šis limitas atsirado ne todėl, kad standartų kūrėjai mėgtų žiaurumą. Jis egzistuoja todėl, kad kitaip SPF gali sukelti tokias DNS užklausų grandines, kurios tampa brangios, lėtos ir lengvai piktnaudžiaujamos. Kiekvienas include, kai kurie a, mx, ptr, exists ir redirect naudojimo atvejai gali sudeginti po vieną DNS užklausą. Žmonės dažnai sukuria įrašą klijuodami tiekėjų fragmentus kaip magnetukus ant šaldytuvo: Google Workspace, rinkodaros platforma, CRM, bilietų sistema, naujienlaiškių įrankis, transakcinių laiškų siuntėjas, paslaptingas serveris, paveldėtas iš buvusio administratoriaus, ir dar viena paslauga, kurios niekas nedrįsta pašalinti, nes „gali nustoti veikti paštas“. O tada stebisi, kodėl SPF neveikia. Jis neveikia todėl, kad egzistuoja aritmetika.
Būtent todėl tikras SPF tikrinimo įrankis yra toks naudingas. Dažnai neužtenka tiesiog pažiūrėti į matomą TXT eilutę. Iš pirmo žvilgsnio SPF įrašas gali atrodyti tvarkingas, tačiau išsiskleisti į tikrą DNS lobių ieškojimą, kai tik pradedame plėsti include: grandines. Vienas tiekėjas įtraukia kitą. Tas kitas įtraukia dar du. Kažkas prideda nukreipimą (redirect). Kita komanda migracijos metu prideda dar vieną include. Staiga jūsų pašto kelias pradeda priklausyti nuo rusiškos matrioškos tipo nuotolinių taisyklių, kurias prižiūri visiškai svetimi žmonės, ir jūsų domeną nuo limito viršijimo skiria tik vienas entuziastingas tiekėjas. Vėliau, pasirodžius autentifikavimo klaidai, visi pradeda kaltinti Microsoft, Google, mėnulio fazę arba „DNS plitimą“, tarsi pats standartas būtų asmeniškai juos įžeidęs.
SPF taip pat moko vienos labai senos pamokos apie infrastruktūrą: kiekviena sistema, kuri prasideda paprastai, ilgainiui pritraukia žmonių kūrybiškumą, o žmonių kūrybiškumas veikiančioje DNS sistemoje dažnai yra visiškai neatskiriamas nuo sabotažo. Pradinė idėja buvo kukli – tiesiog paskelbti patvirtintų siuntėjų sąrašą. Praktinė realybė virsta archeologiniais kasinėjimais po išorines pašto paslaugas, pamirštus subdomenus, pasikartojančius TXT įrašus, prieštaringas ištraukas iš pagalbos puslapių ir vieno konsultanto „laikiną“ nukreipimą, kuris išgyveno šešis prekės ženklo keitimus ir dvi įmonių jungtis. El. pašto autentifikavimas yra ta vieta, kur dokumentacija keliauja tam, kad būtų ignoruojama tol, kol laiškų pristatymas tampa toks skausmingas, jog priverčia jį gerbti.
Yra dar vienas svarbus momentas, kurį daugelis paviršutiniškų gidų linkę nutylėti. SPF negarantuoja, kad vartotojai pamatys „From“ (Nuo) adresą tiksliai tokį, kokio tikisi, ir iškart juo patikės. SPF tikrina tik pašto voką (envelope) ir siuntėjo infrastruktūros kelią, o moderniose pašto ekosistemose jis veikia kartu su DKIM ir DMARC. Tai reiškia, kad SPF yra svarbus, kartais net lemiamas, bet vis tiek yra tik viena didesnės autentifikavimo istorijos dalis. Sveikam pašto nustatymui paprastai reikia, kad visi šie trys elementai sugyventų santykinėje taikoje. Kiekvienas, kuris bando parduoti SPF kaip visišką vaistą nuo tapatybės klastojimo (anti-spoofing), demonstruoja tokį pasitikėjimą savimi, kokį galima rasti tik pigiuose vadovėliuose ir pernelyg entuziastingose valdymo skydų vizualizacijose.
Techninis SPF grožis yra tas, kad perpratus gramatiką jis yra brutaliai įskaitomas. Praktinis bjaurumas yra tas, kad šis įskaitomumas vilioja redaguoti žmones, kurie žino pakankamai, kad taptų pavojingi. Pridėkite vieną include. Pridėkite dar vieną. Pakeiskite -all į ~all, nes taip buvo parašyta tiekėjo pagalbos straipsnyje. Nukopijuokite fragmentą iš instrukcijos, sukurtos visai kitai platformai. Pamirškite, kad senasis paslaugų teikėjas vis dar siunčia sąskaitas-faktūras kartą per savaitę. Paskelbkite du SPF įrašus, nes viena sistema „reikalavo savo nuosavo“. O tada mėgaukitės periodinių nesėkmių skaitmeniniu šou. Tokio tipo klaidos yra dažnos būtent todėl, kad SPF DNS sistemoje gyvena kaip paprastas tekstas. Žmonės mato tekstą ir mano, kad pasekmės bus mažos. Tačiau tekstas DNS sistemoje tyliai sprendžia, ar svarbus laiškas pasieks adresatą, nusileis spam aplanke, ar pradings biurokratiniame užkaboryje.
Štai kodėl tikrintuvas turėtų daryti daugiau nei tiesiog paskelbti: „įrašas rastas“. Rasti įrašą yra darželio lygis. Tikroji vertė yra atsakyti į klausimus, ar ši politika yra nuosekli, vienintelė, baigtinė ir sveiko proto ribose. Ar domenas skelbia tiksliai vieną SPF įrašą? Ar jis baigiasi prasminga politika? Ar jame nėra pasenusių paslaugų teikėjų? Ar jame nesiremiama nebemendujamais mechanizmais, tokiais kaip ptr? Or jis neperžengia dešimties DNS užklausų lubų, kai išplečiami visi include ir redirect? Ar jis nenaudoja +all, kas el. pašto autentifikavimo pasaulyje prilygsta lauko durų užrakinimui ir rakto pakabinimui išorėje su draugišku rašteliu lankytojams?
Žmogui, kuris niekada anksčiau tuo nesirūpino, praktinė pamoka yra nuostabiai paprasta. Jei jūsų įmonė siunčia laiškus iš domeno, tas domenas DNS sistemoje privalo turėti teisingą SPF įrašą. Šis įrašas turi nurodyti legalius siuntimo kelius, neviršyti užklausų limitų, vengti prieštaravimų ir būti peržiūrimas kaskart, kai keičiasi siuntimo paslaugos. El. pašto problemos dažnai atrodo paslaptingos tik todėl, kad neveikianti politika yra užkasta DNS tekste, o ne pakabinta ant biuro sienos. Kai tinkamai patikrinate įrašą, paslaptis dažniausiai sugriūva į paprastą aplaidumą, apsirengusį techniniais drabužiais.
Kitaip tariant, SPF yra vienas iš tų interneto mechanizmų, kurie atskleidžia didesnę tiesą. Tinklas sugenda ne todėl, kad sumanymai būtų neįmanomi. Jis sugenda todėl, kad organizacijos nuolat sluoksniuoja įrankius, tiekėjus, išimtis ir laikinus sprendimus ant to, kas turėjo likti aišku ir švaru. Geras SPF įrašas yra pakankamai trumpas, kad jį suprastumėte, pakankamai griežtas, kad turėtų prasmę, ir pakankamai tikslus, kad atspindėtų realius laiškų srautus. Blogas įrašas skaitomas kaip institucinės kaltės serialas, paskelbtas DNS sistemoje. Štai kodėl rimtas SPF įrašų tikrintuvas priklauso tikram įrankių rinkiniui: ne tam, kad pieštų dekoratyvines žalias varneles, o tam, kad atskleistų, ar domeno pašto politika yra iš tiesų apgynžiama, ar tiesiog vis dar laikosi dėl gryno administracinio atsitiktinumo.