DMARC įrašų tikrinimo įrankis (DMARC Record Checker) sukurtas el. pašto infrastruktūros daliai, kuri skamba abstrakčiai tol, kol realūs laiškai nepradeda dingti, patekti į spam aplanką arba kol jų nepadirbinėja žmonės, kurių jūs į savo prekės ženklą nesikvietėte. Įvedate domeno vardą, tikrintuvas DNS sistemoje ieško TXT įrašo adresu _dmarc.jusudomenas.lt, išanalizuoja politiką ir parodo, ką tas domenas iš tikrųjų liepia laišką priimančioms pašto sistemoms daryti. Tai apima pagrindinę politiką – none, quarantine arba reject, SPF ir DKIM lygiavimo taisykles, ataskaitų adresus žymose rua ir ruf, procentinę žymą pct, ataskaitų siuntimo intervalą ri ir kitas detales, kurias žmonės paprastai atranda tik tada, kai kažkas brangaus jau spėjo nueiti ne ten.
Kam šis terminas girdimas pirmą kartą, raidės yra nuostabiai tiesioginės. DMARC reiškia Domain-based Message Authentication, Reporting, and Conformance (domenu pagrįstas pranešimų autentifikavimas, ataskaitų teikimas ir atitiktis). Šiuos žodžius nerinko poetai, ir tai yra dalis jų žavesio. Domenu pagrįstas reiškia, kad sistema susieta su matomu siuntimo domenu. Pranešimų autentifikavimas reiškia, kad ji priklauso nuo techninių tikrinimų, tokių kaip SPF ir DKIM. Ataskaitų teikimas reiškia, kad gavėjai gali siųsti atsiliepimus apie tai, ką mato. Atitiktis reiškia, kad siuntėjo domenas gali paskelbti politiką, nurodančią, kaip turėtų būti elgiamasi su neautentifikuotu ar nesulygiuotu paštu. Lėtai perskaitius, akronimas yra beveik išsamus vartotojo vadovas, apsivilkęs biurokratiniu paltuku.
Ta matoma domeno dalis yra svarbesnė, nei daugelis suvokia. SPF ir DKIM jau egzistavo prieš DMARC. SPF leidžia domenui skelbti, kurios sistemos turi teisę siųsti jo vardu. DKIM leidžia siuntėjui pridėti kriptografinį parašą, kurį galima patikrinti per viešąjį raktą DNS sistemoje. Naudinga – taip. Pakankama pati savaime – ne visada. Gilesnė problema buvo lygiavimas. Laiškas galėjo praeiniti SPF arba DKIM tikrinimą kažkur vamzdynuose ir vis tiek rodyti skirtingą matomą „From" domeną žmogui, jį skaitančiam. Ta spraga buvo derlingoji dirva klastotėms, fišingui, prekės ženklo piktnaudžiavimui ir bendram techninio dviprasmiškumo karnavalui. DMARC atsirado tam, kad ją susiaurintų. Jis užduoda disciplinuotesnį klausimą: ar autentifikuoti identifikatoriai atitinka domeną, rodomą žmogui gavėjui?
Štai kodėl DMARC nėra tiesiog „dar vienas DNS įrašas". Tai politikos sluoksnis, sėdintis ant SPF ir DKIM. DMARC apžvalgoje jis apibūdinamas kaip mechanizmas, padedantis gavėjams nustatyti, ar laiškas atitinka tai, ką jie žino apie tariamą siuntėją, o jei ne – paskelbta politika nurodo, kaip domeno savininkas norėtų, kad su tokiu paštu būtų elgiamasi. Praktiškai DMARC el. pašto autentifikavimui prideda pasekmių. Domenas gali pradėti atsargiai nuo p=none – stebėjimo režimo. Jis gali pereiti prie quarantine, kur prašo gavėjų su nepraeinančiu paštu elgtis įtariai. Jis gali pereiti prie reject – suaugusiojo versijos pareiškimo: „Jei nepraeis lygiavimo – neprileisti."
Istorija už visa to yra įprastinė interneto istorija: pirmiausia pasitikėk, vėliau taisyk, standartizuok tada, kai žala tampa pakankamai brangi. El. paštas buvo sukurtas eroje, kuri siuntėjų sąžiningumu tikėjo kur kas labiau, nei šiuolaikinė realybė užsipelnė. Klastotės tapo lengvos, fišingas pelningas, o prekės ženklo imitacija – nuoseklia pramonine praktika. SPF ir DKIM kiekvienas išsprendė dalį dėlionės, tačiau organizacijoms vis tiek reikėjo būdo pasakyti vienoje aiškioje politikoje, kaip matomas „From" domenas turėtų būti vertinamas ir kokia grįžtamoji informacija turėtų ateiti. Šis poreikis davė DMARC gyvybę, paskelbtą RFC 7489. Standartų kalba linkusi skambėti suvaržytai, tačiau motyvas yra akivaizdus: jei internetas atkakliai reikalauja leisti globalų pranešimų mainus absurdišku mastu, turi egzistuoti būdas pasakyti, kas iš tikrųjų stovi už žinutės ir kas turėtų nutikti, kai tas teiginys žlunga.
DNS serverio pavadinime slepiasi mažutė administracinė komedija. DMARC įrašai skelbiami po _dmarc. Ne prie pagrindinio domeno, ne kažkokiame mistiškame „saugumo nustatymų" debesyje, ne emociniuose prisimininimuose paskutinio sistemos administratoriaus, kuris prisiekė, kad konfigūravo tai prieš kelerius metus. Politika turės būti konkrečiame adrese, pvz., _dmarc.example.com. Toks fiksuotas išdėstymas egzistuoja, nes standartų kūrėjai teikia pirmenybę atkuriamiems sistemoms, o ne lobių paieškai. Laišką priimantis serveris neturėtų reikalingi intuicijos, pranašystės ar prieigos prie jūsų komandos pokalbių, kad surastų jūsų politikos įrašą.
Įrašo gramatika taip pat yra mažiau atlaidžios nei atsitiktinės kopijavimo-įklijavimo kultūra norėtų. RFC 7489 reikalauja, kad įrašas prasidėtų v=DMARC1, o p žyma yra privaloma ir privalo eiti iškart po versijos žymos. Jei toje pačioje vietoje paskelbiami keli DMARC įrašai, rezultatas nėra „papildomas saugumas". Tai nesėkmė. RFC sako, kad pašto gavėjas turi nepaisant atrastos politikos, jei toje vietoje pasirodo daugiau nei vienas DMARC įrašas. Tai viena iš tų retų sričių, kur protokolas į kūrybingą persikonfigūravimą reaguoja sausa atsisakymo žaisti pozicija.
Tuomet ateina žymos, su kuriomis žmonės nuolatos susiduria DNS valdymo pultuose ir apsimeta suprantantys iš raumenų atminties. p yra pagrindinė politika. sp gali apibrėžti atskirą subdomeno politiką. adkim ir aspf valdo DKIM ir SPF lygiavimo griežtumą. Atsipalaidavęs lygiavimas yra atlaidesnis. Griežtas lygiavimas yra tikslesnis. pct leidžia domenui taikyti politiką tik procentinei daliai nepraeinančio pašto – tai naudinga laipsniškam diegimui ir taip pat nepaprastai naudinga neapibrėžtam delsimui. ri siūlo, kaip dažnai turėtų būti siunčiamos suvestinės ataskaitos. rua laiko suvestinių ataskaitų paskirties adresus. ruf laiko klaidų ataskaitų paskirties adresus. fo patikslina, kada prašoma klaidų ataskaitų. rf pavadina klaidų ataskaitų formatus. Nieko iš to nėra dekoratyvinio. Kiekviena žyma egzistuoja todėl, kad kažkas kažkur sudegė pakankamai skaudžiai nuo dviprasmiškumo, kad pareikalautų lauko tam reikalui.
Ataskaitų teikimas – tai vieta, kur DMARC tampa kur kas daugiau nei patvirtinimo arba atmetimo žyma. Suvestinės ataskaitos, paprastai siunčiamos adresais, nurodytas rua žymoje, leidžia domeno savininkui matyti, kas visame internete siunčia paštą naudodamas tą domeną ir kaip gavėjai tai vertina. DMARC projektai ir apžvalgos aiškina, kad ataskaitų teikimas yra pagrindinis diegimo elementas, nes leidžia domeno savininkui atrasti tiek neteisėtą naudojimą, tiek teisėtus pašto srautus, kuriems vis dar reikia tinkamo autentifikavimo. Paprastai tariant, ataskaitos pasako, ar jūsų domeno pašto ekologija yra sveika, ar pusė jūsų „teisėto" pašto vaikšto nepasirašyta, nesulygiuota arba paleista pamiršta trečiųjų šalių platforma, kurią visi manė, kad kažkas kitas dokumentavo.
Ta paskutinė kategorija nusipelno savo muziejaus sparno. Daugelis organizacijų įsivaizduoja, kad DMARC yra vienas jungiklis. Paskelbk įrašą. Jauskis saugiai. Dėk „el. paštas apsaugotas" ant skaidrės. Realus diegimas paprastai yra netvarkingesnis. Rinkodaros platforma pasirašo vienu DKIM domenu. CRM naudoja kitą kelią. Bilietų sistema siunčia iš subdomeno, kurio niekas neprisimena. Finansinės sąskaitos eina per tarpinį serverį, kurį valdo tiekėjas, kurio sąrankos vadovas buvo parašytas pavojingo pasitikėjimo tonu. Kažkas prideda p=none matomumui, žada laipsnišką perėjimą prie vykdymo, o tada politika ten sėdi aštuoniolika mėnesių kaip diplomatinė nota, kurią niekas neketina vykdyti. Tuo tarpu organizacija toliau kalba apie „stiprią el. pašto saugumo poziciją" su iškilmingu tikrumu, paprastai rezervuotu misijos pareiškimams ir blogai pasirinktam biuro menui.
Štai kodėl tikras DMARC tikrintuvas neturėtų sustoti ties „įrašas rastas." Įrašo radimas yra trivialus. Rimti klausimai yra aštresni. Ar yra tiksliai vienas DMARC įrašas? Ar sintaksė galiojanti? Ar politika prasminga? Ar domenas amžinai užstrigo stebėjimo režime? Ar suvestinės ataskaitos sukonfigūruotos? Ar klaidų ataskaitos sukonfigūruotos protingai? Ar griežtų lygiavimo nustatymų pasirinkimas yra tyčinis ar atsitiktinis? Ar išoriniai ataskaitų adresai tikrai autoritetingi? RFC 7489 apima išorinio paskirties patvirtinimo mechanizmą, naudojant specialų DNS įrašą po _report._dmarc, nes priešingu atveju domenai galėtų nurodyti gavėjams siųsti ataskaitas trečiosioms šalims be sutikimo. Tas mažas projektavimo sprendimas pasako viską apie internetą: net ataskaitų adresui reikia leidimų struktūros, nes kažkas kažkur tikrai piktnaudžiautų paprastesne versija.
Atskleistiniausia DMARC dalis gali būti žodis atitiktis. Jis skamba standžiai, beveik bažnytiškai, bet sako kažką svarbaus. DMARC nėra tiesiog tapatybės artefaktų skelbimas. Tai sprendimas, ar laiškas atitinka domeno savininko deklaruotus autentifikavimo lūkesčius. Tai yra stipresnis teiginys nei „mes turime SPF kažkur" arba „DKIM parašas egzistuoja kokioje nors antraščių dalyje". Atitiktis klausia, ar laiškas tikrai atitinka gavėjui matomą domeną. Ji paverčia išsibarsčiusius techninius patikrinimus politiniu sprendimu. Štai kodėl DMARC yra svarbus fišingo gynybai ir prekės ženklo apsaugai, ir taip pat kodėl silpni diegimai sukuria klaidingą teisingumo jausmą, nesuteikiant daug realios atsparumo.
Taigi, ko turėtų mokyti rimtas DMARC įrašų tikrintuvas? Turėtų mokyti, kad domeno vardas yra matoma tapatybė, DNS yra skelbimo sluoksnis, SPF ir DKIM yra autentifikavimo ingredientai, o DMARC yra politikos sistema, kuri verčia tuos ingredientus atsakyti matomam siuntėjo identitetui. Turėtų mokyti, kad p=none nėra vykdymas, kad besidubliuojantys DMARC įrašai nėra „papildomas kruopštumas", kad ataskaitų adresai yra svarbūs, kad lygiavimo nustatymai keičia elgesį ir kad el. pašto autentifikavimas yra viena iš tų suaugusiųjų techninių disciplinų, kur maži DNS eilutės fragmentai gali tyliai nulemti, ar sąskaitos, slaptažodžių atstatymai, teisiniai pranešimai ir vadovų laiškai bus pristatyti, sulaikyti karantine ar išmesti.
Štai kodėl DMARC verta patikrinti kruopščiai. Tai viena iš nedaugelio vietų, kur trumpas DNS įrašas gali išreikšti korporatyvinį rimtumą sąžiningiau nei politinės retorikos puslapis. Arba domenas skelbia nuoseklią autentifikavimo politiką su vykdomais ataskaitų teikimu ir pagrįstu lygiavimą – arba ne. DNS yra nuostabiai nesentimental tuo atžvilgiu. Jis nevertina pagal ketinimą. Jam nerūpi, kiek kartų komanda sakė „kitą ketvirtį tikrai sugriežtinsime el. pašto saugumą." Jis tik atkuria egzistuojantį įrašą.