Neshoda reverzních záznamů u odesílajícího SMTP

Neshoda reverzních záznamů u odesílajícího SMTP
« kdy: 23. 11. 2022, 22:29:55 »
Je problém, když (poslední)SMTP server, má jiné
Kód: [Vybrat]
formát typu mxe1.seznam.cz (mxe2.seznam.cz [SS.S5.76.34])
echo "$rpc" | grep -Evi --color 'from ([^ ]+) \(\1'

Vypíše)
mxe1.seznam.cz (mxe2.seznam.cz xxx.75.76.34])
mxe2.seznam.cz (mxe1.seznam.cz xxx.75.78.34])
smtp.github.com (out-17.smtp.github.com xxx.30.252.200])
smtp.github.com (out-18.smtp.github.com xxx.30.252.201])
smtp.github.com (out-21.smtp.github.com xxx.30.252.204])
smtp.github.com (out-22.smtp.github.com xxx.30.252.205])
smtp.github.com (out-25.smtp.github.com xxx.30.252.208])
smtpx012.webglobe.com (smtpx012-2.webglobe.com xxx.109.150.178])
Ostatních 50 je OK čili tak z vzorku 60. Pozor, je to po sort -u, takže nezohledňuje četnost zpráv od daného seerveru




1 Zajímá mě praxe, jestli to  není chyba, nebo třeba jen flag pro nižší skóre. Vím, že jde nakonfigurovat třeba že se to musí rovnat(uvedený v HELO a zjištěný , případně že nesmí být ve tvaru dynamické IP a taky že třeba zpětný záznam musí existovat  ...

2 A z druhé strany, jestli je nutné aby se HELO řetězec musí rovnat  zpětnému doménovému jménu adresy počítače. TO znamená že mám nějaké ptr název daného počítače, ale v HELO chci uvádět jiné jméno. Samozřejmě obě vedou na tutéž IP

3 Hint: tak se z druhé strany (tedy v případě naslouchání příchozí pošty) odhalí spameři: posílají poštu adresátovi ptrjmeno.domena.cz místo  domena.cz. kupodivu na mx.domena.cz neposílají vůbec


4 Například mxe{1,2} neexistují (může jít ale o historická DNSdata, protože to bylo resolvováno Teď, ale data jsou historická až pár měsíců)... Ono když si vyzkoušíte ty adresy ze seznamu, jsou to unikátní situace, dostanete se do různých grafů., částečně tím, že jak A, tak/nebo PTR záznamy jsou vícepoložkové. Než když je to siutace, kdy to souhlasí přesně 1:1. (což právě ve výpisu nemám, díky parametru -v grepu)
« Poslední změna: 23. 11. 2022, 22:53:46 od Petr Krčmář »


Není jasné, čeho je to výpis, co je jiné. (Ano, vidím, že je rozdíl smtpx012.webglobe.com a smtpx012-2.webglobe.com, ale nenapsal jste, kde jste ty názvy vzal.) Když zkusím přeložit smtpx012.webglobe.com, dostávám 62.109.150.11 a 2001:1ab0:7e1e:151::91, obojí vede zase zpět na smtpx012.webglobe.com. (Je vtipné „začerňovat“ IP adresy, když stejně uvádíte doménová jména.) smtpx012-2.webglobe.com se mi překládá na 62.109.150.178 a to zase zpět na smtpx012-2.webglobe.com.

Pro antispam neexistují žádná pravidla, každý si dělá, co chce. Takže na otázku, jestli je nutné, vám nikdo neodpoví – podle RFC má být za EHLO doménové jméno počítače nebo IP adresa, ale někdo to kontrolovat může, někdo nemusí.

Podobné je to s IP adresou odesílajícího počítače. Podle obecných pravidel by pro ni měl existovat reverzní záznam vedoucí na nějaké jméno, a to jméno by se zase mělo překládat zpět i na uvedenou IP adresu. Ve standardech je should a že by na to nikdo neměl spoléhat, ale spousta e-mailových serverů to kontroluje.

Re:Neshoda reverzních záznamů u odesílajícího SMTP
« Odpověď #2 kdy: 24. 11. 2022, 00:17:38 »
Je to log přijatých. Je to standardní syntaxe v těle zprávy hlavičky Received   -v tomto případě poslední chronologicky,(kromě nějakého LMTP případně vnitřních zpracování). Tedy hlavička která už neprošla odesilatelovou stranou. Snad je to pochopitelné, prostě "ta důležitá" hlavička Received.
a formát je  Received from:  <EHLO> (PTR [IP])

Proto možná proč se podivujete, že to souhlasí, je že zkoumáš  špatné páry. v HELO je verze bez pomlčky (podobně jako u github "smtp."), ale PTR adresy vede na verzi s pomlčkou. Což by nevadilo za předpokladu, že budou propojené tím způsobem, že buď se upraví  EHLO a nebo se upraví PTR) .... A nebo ještě nějak propleteněji, protože "A" I "PTR" umí vícenásobné záznamy

Ono při přemýšlení o tom  se dá dojít až k "6 proměnným" :
1. Prvotní informace: zdrojová srcIP (nelze "zfalšovat") +  EHLO(lze vepsa cokoliv)
Obojí jde "ždímat"  kaskádou ?PTR->?A->?PTR->?A   (Dle mě u IP adresy má smysl jen kolečko [srcIP]->PTR->A->A, u [EHLO] má smysl [EHLO]->A->PTR , přičemž škrtnutě jsou vyznačené údaje, které už nemá cenu zkoumat, pokud se předchozí/jiné liší, ale mohou dát jiný zajímavý výsledek)

Samozřejmě v růžovém světě, kde PTR srcIP je shodný s EHLO je situace jasná a není potřeba {dva,tři,n}krát resolvovat to samé.

Logicky se musí EHLO->A rovnat srcIP (bez nadstandardních kontrol ), o tom není třeba vést diskuzi.
Pak je tu  EHLO a srcIP->PTR, což je to na co tady poukazuju. Pokud vím, tak tahle kontrola je volitelná, není to ani nějaký hard fail.


Potud to ještě ale není žádný mechanismus proti zombie spamerským počítačům (+ nulové složitosti zaregistrovat si doménu,abych si mohl obstarat validní EHLO)

Z toho vyplývá, že kontrola src-IP->PTR se musí dělat vždy (s ohledem na praxi proti boje s zombie , ne s nutností ze strany RFC)


Jsou 2 možnosti-:
PTR se rovná EHLO (což je ten růžový příklad), vše je OK.
PTR je odlišné (na to se ptám), je potřeba udělat o jednu kontrolu navíc : PTR->A'. A to už se musí přeci rovnat, další kolečko už se mi zdá nesmysl.

Je to takhle popsané dobře? Tažkže pro EHLO jedna dopředný překlad a pro srcIP minimálně jeden zpětný a možná navíc   jeden dopředný toho zpětného.



Jo a mimochodem, jenom tak  pod čarou, "nad tou hlavičkou" Received se mi ukazuje hlavička fcrDNS: <PTR>



Kód: [Vybrat]
Received-SPF: Pass/None (mx-in.vvv.vn: domain of (smtp.)github.com
  does (not )designate 192.30.252.204 as permitted sender)
  receiver=mx-in.vvv.vn; identity=mail-from/helo;
  client-ip=192.30.252.204 helo=smtp.github.com;
  envelope-from=<noreply@github.com>
X-fcrDNS: out-21.smtp.github.com
Received: from smtp.github.com (out-21.smtp.github.com [192.30.252.204])
...
From: notifications@github.com(fun fact)
« Poslední změna: 24. 11. 2022, 00:26:53 od Ħαℓ₸℮ℵ ␏⫢ ⦚ »

Re:Neshoda reverzních záznamů u odesílajícího SMTP
« Odpověď #3 kdy: 24. 11. 2022, 18:18:22 »
Proto možná proč se podivujete, že to souhlasí, je že zkoumáš  špatné páry.
Ne, neporovnávám špatné páry. Vzal jsem normálně vámi uvedené doménové jméno, přeložil jsem ho na IP adresy, a takto získané IP adresy jsem reverzním záznamem přeložil na doménové jméno.

Ono při přemýšlení o tom  se dá dojít až k "6 proměnným" :
1. Prvotní informace: zdrojová srcIP (nelze "zfalšovat") +  EHLO(lze vepsa cokoliv)
Obojí jde "ždímat"  kaskádou ?PTR->?A->?PTR->?A   (Dle mě u IP adresy má smysl jen kolečko [srcIP]->PTR->A->A, u [EHLO] má smysl [EHLO]->A->PTR , přičemž škrtnutě jsou vyznačené údaje, které už nemá cenu zkoumat, pokud se předchozí/jiné liší, ale mohou dát jiný zajímavý výsledek)
Když se server představí nějakým jménem (v EHLO), dává smysl kontrolovat, zda se nepředstavil cizím jménem, takže převést uvedené DNS jméno na IP adresu a zkontrolovat, zda se mezi vrácenými IP adresami je zdrojová adresa serveru. Případně můžete kontrolovat i PTR záznam zdrojové adresy, jestli vede i na uvedený název. Žádná další kolečka nemá smysl dělat, protože byste kontroloval pořád dokola to samé.

Pak je tu  EHLO a srcIP->PTR, což je to na co tady poukazuju. Pokud vím, tak tahle kontrola je volitelná, není to ani nějaký hard fail.
Všechny kontroly jsou volitelné a záleží na tom, kdo ty kontroly uplatňuje, jak bude zacházet s výsledkem.

PTR se rovná EHLO (což je ten růžový příklad), vše je OK.
PTR je odlišné (na to se ptám), je potřeba udělat o jednu kontrolu navíc : PTR->A'. A to už se musí přeci rovnat, další kolečko už se mi zdá nesmysl.

Je to takhle popsané dobře? Tažkže pro EHLO jedna dopředný překlad a pro srcIP minimálně jeden zpětný a možná navíc   jeden dopředný toho zpětného.
Není potřeba dělat žádné kontroly, je jenom na vás, jaké kontroly se rozhodnete dělat. Jako první jste popsal kontrolu názvu v EHLO, to nějaký smysl dává. Je na vás, jestli budete akceptovat chybný název nebo ne. Nezávisle na tom můžete kontrolovat vazbu mezi dopředným a zpětným DNS záznamem.

Re:Neshoda reverzních záznamů u odesílajícího SMTP
« Odpověď #4 kdy: 30. 11. 2022, 17:28:56 »
Zkusím to graficky.Srovnávají se řádky, tudíž vstupní údaje nejsou na jednom řádku, ale v poli A1 a B2 jako v šachu
Kód: [Vybrat]

helo *  =alfa=    PTR`
                         
  |       ••        ^ 
  V       ••        | 
                         
  A`    =beta=  #s-ip 
 
Beta kontroluje shodnost IP, tedy zjednodušeně jestli překlad helo odpovídá IP.
Alfa kontroluje, jestli ip adresa je posvěcená providerem.  S jedním  (potenciálním  a ne vždy) neduhem, že dynamické "adsl" ip adresy typu xx-yy-yy-yy-cust.vodafone.cz toto splní vždy  (obousměrně) . Plus ještě pokud tedy není port 25 blokován
Malými písmeny jsou vstupní hodnoty (#neměnná ip a * zadané ehlo)
S čárkou ` jsou odvozené hodnoty.

A můj dotaz
,  na situaaci. , když alfa kontrola selže.  Zda je to legitimní. Za druhé, je nutné udělat to druhé kolečko (zdaleka ne 6)
Kód: [Vybrat]

helo *  ≠    ≠    PTR` |—————+
                             |
  |                 ^     fcrdns = s-ip ->ptr->a``
  V                 |        |
                             |
  A`    =beta=  #s-ip   <— =gamma=
 
Tedy když kontrola alfa selhala, proběhne kontrola gamma, že se jednou reverzní záznam opět převede na IP a teď už to musí sedět.
« Poslední změna: 30. 11. 2022, 17:34:03 od Ħαℓ₸℮ℵ ␏⫢ ⦚ »


Re:Neshoda reverzních záznamů u odesílajícího SMTP
« Odpověď #5 kdy: 30. 11. 2022, 19:24:38 »
Já bych doporučil místo šachové terminologie použít raději IT terminologii, konkrétně pojmy protokolů SMTP, DNS apod.

Jste v situaci, kdy provozujete SMTP server a někdo se vám pokouší doručit e-mail. Takže znáte jeho IP adresu(ze které se k vám připojil, IP adresa klienta, nazvěme ji třeba A) a text, který předal v EHLO (nazvěme jej třeba T).

Ta vaše beta tedy asi přeloží název poskytnutý v EHLO (T) přes A/AAAA záznam na IP adresu(y) a ověří zda jedna z nich je IP adresou klienta (A).

Co je alfa netuším:

Alfa kontroluje, jestli ip adresa je posvěcená providerem.
Co znamená „posvěcená providerem“? Napište to v IT terminologii.

Plus ještě pokud tedy není port 25 blokován
Tím myslíte „pokud není na straně klienta blokována odchozí TCP komunikace na port 25“, pak to nemusíte řešit, protože kdyby ta komunikace blokována byla, klient se k vám vůbec nepřipojí. Pokud tím myslíte něco jiného, napište to IP terminologií a přesně.

Zda je to legitimní.
Pokud řešíte reverzní záznamy a dopředné záznamy, na to jsou jenom doporučení, nic závazného.

Za druhé, je nutné udělat to druhé kolečko (zdaleka ne 6)
Nutné není nic. Děláte antispamovou kontrolu, na to nejsou žádná pravidla. Je to vaše rozhodnutí, zda se vám nějaká kombinace líbí nebo nelíbí. Někdo třeba považuje klienta za spammera jenom proto, že v DNS názvu jsou číslice.

Re:Neshoda reverzních záznamů u odesílajícího SMTP
« Odpověď #6 kdy: 30. 11. 2022, 22:54:23 »
Končím, du si dát opium. a až to vyprchá, dám si měsíc přestávku a zkusím to natočit formou youtube videa, udělat tam nějaké vizualizace jako v intru Reporteři ČT.

Posvěcená providerem je novinářská zkratka, že to není zombí počítač (obrazně), tedy že reverzní záznam připojivšíse ip adresy sedí  s HELO řetězcem  , a pokud, ne tak sedí s dopředně-zpětným-záznamem. (což je úhlavní bod dotazu)

Ta blokace portu se netýkal kontroly alfa(kontroly PTR),ale  té "správnosti" F+c+RDNS záznamů u ip providerů koncových uživatelů, že i když tedy ta kontrola by seděla (pak tu jsou ty zmíněné kontroly, co hledají shluk čísel v revezním názvu), tak obvykle bývá odchozí port 25 těchto přípojek blokován.

PS: nádherné a překvapivé (a pro vás důležité), je, že se v těchto příkladech vystačí s unikátními  a rozlišitelnými pojmy:
-HELO řetězec
- - A záznam ( HELO řetězce)
-ip adresa
- - reverzní záznam nebo ptr záznam ( ip adresy)
- - - fcrdns (revezního  záznamu(ip adresy)) - i doslovný překlad dopředně ověřený reverzní překlad sedí, i když to slovo ověřený je zavádějící. Ověřený je jen, když souhlasí s ip adresou

Re:Neshoda reverzních záznamů u odesílajícího SMTP
« Odpověď #7 kdy: 30. 11. 2022, 23:33:49 »
Mohu-li Vám radit, tak z řetězce uvedeného v HELO/EHLO lze jen těžko něco podstatného vyvozovat. Bylo tomu tak vždy, a je tomu tak i dnes. Rovněž tak ze vztahu HELO/EHLO k ip adrese či dns jménu smtp klienta. Vizte tento výběr z pár minut reálného poštovního provozu dnešního dne:

client=mail-vi1eur04on0630.outbound.protection.outlook.com[2a01:111:f400:fe0e::630], helo=<EUR04-VI1-obe.outbound.protection.outlook.com>
client=relay.netic.dk[2a03:dc80:0:f136::218], helo=<mxout02.netic.dk>
client=mailgate.tugraz.at[129.27.2.197], helo=<mxesa1.tugraz.at>
client=budka.sunnysoft.cz[86.49.189.186], helo=<host-22.sunnysoft.cz>

Můžete ty jednotlivé případy analyzovat a hádat, zda jsou to servery s více interfejsy, jestli třeba není ve hře load-balancer, zda ip adresa má omylem více PTR záznamů apod. Bude se tahhle snažit hádat i Váš antispam?

Použil jste pojem něco jako ověřený překlad. I na to pozor. Očekával bych, že v dnešním světě k tomu přidáte nějaké další pojmy. Když se bavíme o smtp, tak třeba smtp spojení zabezpečené pomocí TLS, s platným certifikátem (obou stran?), vydaným respektovanou certifikační autoritou, zabezpečení DNS komunikace na bázi DNSSEC, nad tím kontrola certifikátu podle DANE.
« Poslední změna: 30. 11. 2022, 23:36:18 od _mbily »