Program pro verifikaci DKIM

[Vietnanka]

Znáte nějaký program, skript, či webovou stránku snad (sic!) v offline režimu , kam se jako vstup zadá tělo e-mailu a ono to vyplivne, zda souhlasí DKIM podpis? Hledal jsem na internetu, ale všechny výsledky jsou povrchní - pouze validují syntaxi veřejného záznamu _domainkey "v=DKIM1...." A to ani v nejmenším není to ,co hledám

[Reklama]

[_Tomáš_]

online např. https://mxtoolbox.com/EmailHeaders.aspx, ač je to stabilní a věrohodná služba (za mě), tak tam neposílej důvěrné informace a nic, co bys nechtěl, aby s zveřejnilo.

Kód pro validaci často najdeš u projektů, které implementují nějaké self-hosted email řešení (např. https://github.com/haraka/Haraka), koukám, že třeba historicky používám knihovnu https://github.com/hudeany/dkim pro dkim validaci.

V produkci dnes už každý používá nějaké hostované email řešení a tam se informace o validaci dkim dostávají buď do speciálních hlaviček nebo jsou k dispozici jako logy, takže nutnost dělat něco vlastního už moc nemám.

[jjrsk]

...

Addon do tb ... https://github.com/lieser/dkim_verifier

Ale nesmis ten mail protahovat treba pres exchange, ten maily zmrvi.

[Vietnanka]

Nemám, to k samotnému  podepisování nebo  implementaci validování do flow mailserveru, ale k odhalování jednotlivých problémů "out of band" - v DMARC reportu mi přistálo, že  jednou z 100 nesouhlasil DKIM podpis, který vždy  jindy souhlasil. Tak teď chci vzít zprávy (jsou 4 kandidáti) a  ručně to u nich ověřit.Kdyby šlo se  podívat za rameny příjemců, tak je to rychlejší, ale půlka z nich netuší o existenci Zobrazit Hlavičky natož DKIM.

pro jjrsk: šlo to přímo na seznam.

Chtěl jsem ještě přidat požadavek: jak si předsavuji, přidanou hodnotu tohoto nástroje
A aby to vypsalo v případě nesouhlasu, zda nesouhlasí, bh, b nebo obojí. A jako bonus , takovou třešničku na dortu, pokud  opět nesouhlasí hashe, tak to nějak se pokusilo odhadnout, kde se stala chyba(snažit se nějak dojít k správnému hashi tak, že to vyzkouší případné možné varianty (záměna CRLF-LF, přidání-odebrání posledního prázdného řádku, kanolizace a pak to řekne, tahle varianta souhlasila)

[Vietnanka]

A jako udělat hash těla  (bh) není problém : echo -ne "Začátek.Konec" |sha256sum | cut -f1 -d \  | xxd -r -ps  |base64
zas*aný xxd vyžaduje parametr -ps  osamoceně- takže -rps nefunguje . A --ps mě napadlo až ted, ale kdyby to bylo v man, tak je to jasné hned. A je to -ps a ne jenom -p

podpis hlavičky (copypaste od začátku po "...;b=") bude vyžadovat nějakou magii s openssl  pubutil nebo tak

[Reklama]

[Vietnanka]

což je mimochodem tady
https://forum.directadmin.com/threads/dkim-signature-did-not-verify.59305/
openssl dgst -sha256 -sign private.key -out sha1.sign head1.txt
(přidat    asi i--binary a následně |base64)

[McFly]

Možná to bude overkill, ale spamassassin. Z příkazové řádky spustit:

Kód: [Vybrat]

spamassassin -t -D dkim < mail.msg

[Vietnanka]

Tak je totakto: ... Ovšem musí se to použít na kanonikalizovaný výstup což je něco jako:

Kód: [Vybrat]

date:Thu, 9 May 2024 18:19:09 +0200
to:Jana.VELKA
mime-version:1.0
content-type:text/plain; charset=utf-8
dkim-signature:v=1; d...9; c=relaxed/simple; h=D....pe; bh=6K8=; b=(poslední řádek je dlouhý) - následující skript-ohejbák přidá LF (zajistí převod na CR+LF) a zároveň odebere  poslední LF (rovnák)

head -c -1 <(sed -E 's/$/\r/g')| openssl dgst -sha256 -sign ../dkimp.pem |base64 # hlavička
+
echo -ne "Začátek.Konec" |sha256sum | cut -f1 -d \  | xxd -r -ps  |base64 # body
# - ovšem hash body se musí udělat jako první

[Filip Jirsák]

Offline to určitě nepůjde, protože potřebujete z DNS stáhnout klíče, proti kterým se má podpis ověřit.

[_Tomáš_]

Offline to určitě nepůjde, protože potřebujete z DNS stáhnout klíče, proti kterým se má podpis ověřit.

Jak se to vezme, ideálně je potřeba mít klíče, které v DNS byly v době poslání toho emailu, takže vlastně si je cachovat doma a pak to dělat kompletně offline je asi nejlepší.

Ručně to počítat a parsovat jsem ani nechtěl zmiňovat, hele, je tam strašný problém v normalizaci, na konkrétní implemetaci to napíš pokus omyl, dělat to univerzálně je opravdu pěkný oříšek, už jsem to kdysi zkoušel, ale proč by ne, pohraj si s tím.

[Vietnanka]

offline

To je pravda. Myslel jsem offline tak,že nebudu někam to tramtárie posílat znění mailu a že i ten veřejný selektor z DNS si dopředu stáhnu  (a poplatný té době) taky předám offline algoritmu.
kanonizace=kanolizace=normalizace

(v tom  odkazovaném linku byl problém v něčem jiném, že  v závěru hlavičky DKIM-Signature byl středník na konci "...bh=MM8hb=; b=i8B6fC=); a v tom konkrétně nevidím problém

[Vietnanka]

offline

To je pravda. Myslel jsem offline tak,že nebudu někam to tramtárie posílat znění mailu a že veřejný (a poplatný té době)selektor z DNS taky předám offline algoritmu.
kanonizace=kanolizace=normalizace=Kanonikalizace

(v tom  odkazovaném linku byl problém v něčem jiném, že  v závěru hlavičky DKIM-Signature byl středník na konci "...bh=MM8hb=; b=i8B6fC=); a v tom konkrétně nevidím problém

[Filip Jirsák]

Jak se to vezme, ideálně je potřeba mít klíče, které v DNS byly v době poslání toho emailu

Každý rozumný správce musí počítat s tím, že doručení e-mailu nějakou dobu trvá, takže ponechá klíče v DNS i nějakou dobu (minimálně v řádu dnů) po té, co je přestane používat pro podepisování e-mailů.

[_Tomáš_]

Jak se to vezme, ideálně je potřeba mít klíče, které v DNS byly v době poslání toho emailu

Každý rozumný správce musí počítat s tím, že doručení e-mailu nějakou dobu trvá, takže ponechá klíče v DNS i nějakou dobu (minimálně v řádu dnů) po té, co je přestane používat pro podepisování e-mailů.

kdyby byl každý správce rozumný, tak tady tazatel asi nemusí tenhle problém řešit, ne?

[Filip Jirsák]

kdyby byl každý správce rozumný, tak tady tazatel asi nemusí tenhle problém řešit, ne?

Tazatel přece řeší nevalidní DKIM podpisy. Důvodů, proč jsou nevalidní, může být spousta. Kdyby byl problém v tom, že příslušný klíč není v DNS, asi už by to tazatel dávno zjistil a nepotřeboval by kvůli tomu DKIM validátor.