Lze zjistit DKIM selektor jen podle domény?

[mikesznovu]

Narazil jsem na službu https://dmarc.nu/en, kde mě zaujala jedna věc. po zadání pěti domén (tedy třeba alza.cz) jsem nabyl dojmu, že nevrací správné výsledky. False negatives 

vrátí tyto výsledky (zajímá mě jen 3. boxík DKIM):
alza.cz vrací v pořádku ; selector found: 1 záznam : Office365
kostel.cz vrací v pořádku ; selector found 2 záznamy : Mailjet : mailjet._domainkey Google : google._domainkey
... jiná  ... ; ... 2: mandrill
palermo.it ; fujfuj ; found zero . –– Přesto tato doména selektor má
nebo jakákoli jiná doména o které víte že má DKIM ale kontrola pro něj hlásí not found
... v kontrastu: google.com  nebo jiné spol. používá dynamické selektory typu dkim-2022-10
Mě zajímá jak dochází k těmto selektorům? To jsou nějaká dobře známá jména? Pokud ano, je to nějaký důsledek "nařízení", že si oni diktují hodnotu DKIM selektoru?

Případně si to nějak domýšlí* z TXT záznamu SPF  obsahujících include; nebo různýcch TXT typu site-verification? Toto domýšlení ale nemůže být dokonalé a taky očividně nenajde správný DKIM který zde není uveden



A nebo mě uplně převezli a mají to nějak fikaně? nechají si (jak ) poslat mail z této domény, z nějž na to přijdou?

[Reklama]

[Exceptions]

nelze, provozovatel si může určit sám prefix, který použije pro dkim key, nejsou v tom žádná pevná pravidla, můžeš se pokusit použít výchozí (tak to dělá i dmarc.nu), ale výsledky pro tebe mohou být nespolehlivé. Jediná spolehlivá cesta je mít email s hlavičkou a najít použitý selector.

[_mbily]

Napadají mne dva způsoby, kterými je možné zjistit obsah DNS zóny. A v zóně pak najdete i  DKIM selektory. Oba způsoby jsou založeny na komunikaci se slabě, či chcete-li nevhodně, konfigurovanými autoritativními name servery:

• správce dns serveru omylem či úmyslně povolí libovolnému klientovi tzv. zónový přenos,
• DNSSEC lze provozovat ve variantách NSEC nebo NSEC3. Starší NSEC v sobě skrývá problém v odpovědích informujících o neexistenci nějakého záznamu. Vizte google, klíčová slova dnssec zone walking.

[mikesznovu]

Je nějaký důvod, proč    "MRA" (MAIL RECEIVING AGENT)  stahuje DKIM záznam z hodnoty "d" ( Signing Domain Identifier (SDID)  ? Ta totiž nemusí být žádnou vazbu na adresu odesilatele. 
Tam si přece útočník může napsat co chce (pořídit si nějakou doménu k tomu a na ni vyvěsit x._dkim.dom) a DKIM kontrola krásně  projde , s podvrženou From hlavičkou jakou součástí hlaviček k podpisu hashe   (to že DMARC alignment už ne je druhá věc)


Rozumněl bych tomu, kdyby běžné, strana příjemce by uváděla, tuto hodnotu a  z toho by hned bylo vidět, pro jakou jinou doménu podpis sedí (pokud se neshodují) nebo kdyby výsledkem kontrol


https://www.samuraj-cz.com/clanek/overovani-emailu-pomoci-dkim-domainkeys-identified-mail/

pomocí selektoru (s) a domény (d) se sestaví DNS dotaz a hledá TXT záznam pro s._domainkey.d

Pozn.: Zaráží mne, že se ověřuje doména, která je uvedena v podpisu. Ta vůbec nemusí mít vazbu na domému v adrese odesílatele.

Je nějaký rozmuný důvod, proč tenhle tam vůbec je a nebere se hodnota  pevně odněkud?
Jako jediná mi přichází v úvahu From v těle


( HELO ani MAIL FROM ne, znám maily, kdy se včechny čtyři liší)
From: zadané
HELO sparkpostmail.com
MAIL FROM bounce.ecomailapp.cz
DKIM  xxx._domainkey.ecomailapp.cz


Mimochodem, v čem se liší služby ecomail a sparkpost z hlediska  detailu "oboru"? Obě jsou z emailingu, dělá každéněco v jiné pod-oblasti?

[Filip Jirsák]

Je nějaký rozmuný důvod, proč tenhle tam vůbec je a nebere se hodnota  pevně odněkud?

Protože pro jednu doménu může být víc odesílajících klientů a každý může mít svůj klíč.

[Reklama]

[mikesznovu]

...kontrola (stahování ) veřejného dkim klíče z domény určené d=....

Je nějaký rozumný důvod, proč tenhle tam vůbec je a nebere se hodnota  pevně odněkud?

Protože pro jednu doménu může být víc odesílajících klientů a každý může mít svůj klíč.

Ale víc klíčů  řeší právě "s"elector.
txt : "s"._domainkey."d"
Nerozporuju možnost volby první část " s", ale druhé "d", že není pevná ve tvaru selector._domainkey.domenavzatazFrom:.com,

[Filip Jirsák]

txt : "s"._domainkey."d"
Nerozporuju možnost volby první část " s", ale druhé "d", že není pevná ve tvaru selector._domainkey.domenavzatazFrom:.com,

d je doména toho, kdo e-mail podepisuje. To nemusí být ten, kdo je ve From. Třeba když poštovní konference přeposílá e-mail, ve From je ten, kdo zprávu poslal, ale e-mail musí podepsat provozovatel poštovní konference.