Odchozí pošta padá do spamu

[Vietnanka]

... IP adresa přeložená na záznam...  Nebo ho přeloží zpět na IP adresu a zkoumá, zda mezi přeloženými IP adresami je i ta původní IP adresa klienta.

To mi nedává smysl, z logiky věci by  reverzní doménové jméno  se mělo přeložit vždy na tu stejnou IP, jako pro kterou bylo reverzní doménové jméno vyhledané. (Jsou ale IP adresy, které reverzní jméno nemají, tam ale chybí už první krok)

(Pokud ses neuklepl a nemyslel to jeden krok posunutě / záměna IP a jména: přeložení doménového jména na ip adresu a té reverzně na reverzní jméno.)

A nebo může ověřovat, zda doména z toho reverzního záznamu se objeví v EHLO hlavičce, kterou klient pošle. Asi protože pro spammera je hrozně obtížné zjistit si reverzí DNS záznam počítače, odkud zkouší spam odeslat – musel by udělat jeden DNS dotaz navíc…

Čili kvůli tomuhle ty SMTP provádějí ty nestandardní filtrace na výskyt čísel s pomlčkami? (V kombinaci s tou kontrolou rovnosti, jinak by tam rovnou mohl napsat HELO domena.com)

Ten dotaz původně mířil na to, jestli je přípustné mít v HELO hlavičce například mailer.firma.cz, když její zpětné přeložené jméno (mailer.firma.cz -> IP -> reverzní jméno) je třeba s1.firma.cz nebo rovnou outbound.mailgun.net nebo outlook.com. Což podle mě ale je legitimní, když někdo posílá  maily outsourcovaně.

[Reklama]

[Vietnanka]

Našel jsem tedy jeden příklad:
{85.207.4.158+85.207.59.62} -PTR-> cnc2-smtp1.cncenter.cz -A-> 85.207.59.62 (-PTR-> cnc2-smtp1.cncenter.cz )

Takovéhle "smyčky" jsou povolené?  (že víc IP má stejné reverzní jméno, smyčka to není, ale trychtýř)? Zajímá mě to na víc úrovních (například nikdo nebrání providerovi v Brazílii nastavit stejné doménové jméno jeho zákazníkovi jako má zákazník v hostingu v japonsku). To ale není tento případ očividně, když se shodují na /16,/15,/14.... (a ostatně  v ASN blok je pro /16)

A nebo je tam chyba, že to vrací jen jednu IP adresu, ale mělo by (aspoň obě)?

Nebo je to situace naprosto v pořádku? Nebo může tato podivnost  pramenit, že neexistuje na světě jen RR typu A?

[Filip Jirsák]

Našel jsem tedy jeden příklad:
{85.207.4.158+85.207.59.62} -PTR-> cnc2-smtp1.cncenter.cz -A-> 85.207.59.62 (-PTR-> cnc2-smtp1.cncenter.cz )

Takovéhle "smyčky" jsou povolené?  (že víc IP má stejné reverzní jméno, smyčka to není, ale trychtýř)? Zajímá mě to na víc úrovních (například nikdo nebrání providerovi v Brazílii nastavit stejné doménové jméno jeho zákazníkovi jako má zákazník v hostingu v japonsku). To ale není tento případ očividně, když se shodují na /16,/15,/14.... (a ostatně  v ASN blok je pro /16)

A nebo je tam chyba, že to vrací jen jednu IP adresu, ale mělo by (aspoň obě)?

Nebo je to situace naprosto v pořádku? Nebo může tato podivnost  pramenit, že neexistuje na světě jen RR typu A?

Je to trochu divné, popírá to smysl PTR – PTR by mělo ukazovat na jméno zařízení, které by z principu věci mělo být unikátní. Ale ničemu to nevadí – prostě A záznam vede na víc IP adres, tak se to jméno použilo i pro reverzní záznam. To, že by dva ISP v různých částech světa nastavili stejné doménové jméno do PTR ničemu nevadí.

To, že ten A záznam vrací jenom jednu IP adresu je proti doporučení pro PTR záznamy – pro ty by mělo (mělo, ale nemusí)  platit, že příslušný A záznam vede zase zpět (i) na původní IP adresu. Pokud by se třeba někdo pokoušel z té IP adresy 85.207.4.158 posílat e-maily, spousta serverů by to vyhodnotila jako spam, protože kontrolují, že je splněné to kolečko IP → PTR → název → A → IP. Ale pro 85.207.59.62 to nijak nevadí – i kdyby někdo zjistil (jako vy) že i pro 85.207.4.158 existuje PTR záznam vedoucí na stejné jméno, nemůže to použít pro žádnou kontrolu. To jméno cnc2-smtp1.cncenter.cz si můžu dát klidně ke své IP adrese jako reverzní záznam a majitel domény cncenter.cz nemá jak mi v tom zabránit.

A samozřejmě ta vámi popsaná situace může být jen dočasná – ať už kvůli probíhajícím změnám v DNS, nebo pro to, že se pro to doménové jméno cnc2-smtp1.cncenter.cz používá nějaké rozvažování a teď zrovna vám server vrátil jenom jednu IP adresu. Což je mimochodem důvod, proč by se neměly míchat technické názvy (které se objevují v PTR záznamech a měly by to být jednoznačné názvy zařízení) a názvy pro lidi. Tj. pro lidi mám www.example.com a to obsluhují čtyři servery alpha.example.com, beta.example.com, gama.example.com a delta.example.com. A reverzní záznamy IP adresy jednotlivých serverů povedou zase zpět na tu alphu až deltu. Na www.example.com nepovede žádný reverzní záznam, protože to není jméno žádného zařízení/serveru, ale jméno služby.

[Vietnanka]

Teď mě to napadlo, hypoteticky, kdyby to byl jeden počítač (stroj, ne služba) co má více IP adres (klidně i na stejném rozhraní), tak by ta asimetrie více IP->jedno jméno asi  dávala smysl (i když to je jen jedna půlka problému-druhá je vrácení jedné IP pro to doménové jméno). "Prostě by měl jedno hostname v /etc/hostname" (velké zjednodušení!)


Jinak moc pěkné vysvětlení, je vidět, že to jde, když chcete

[Filip Jirsák]

Teď mě to napadlo, hypoteticky, kdyby to byl jeden počítač (stroj, ne služba) co má více IP adres (klidně i na stejném rozhraní), tak by ta asimetrie více IP->jedno jméno asi  dávala smysl (i když to je jen jedna půlka problému-druhá je vrácení jedné IP pro to doménové jméno). "Prostě by měl jedno hostname v /etc/hostname" (velké zjednodušení!)

Ano, to je dobrý příklad – třeba router, který má přirozeně víc rozhraní a víc IP adres, přesto chci umět odkazovat jménem na celý router, aniž bych specifikoval, které přesně rozhraní. A pak je dobré mít pojmenovaná i jednotlivá rozhraní, takže tam by ideálně měly pro každou IP adresu existovat 2 PTR záznamy – jeden na jméno rozhraní a druhý na jméno celého routeru. Jména rozhraní by pak měla 1 A záznam vedoucí na IP adresu toho rozhraní, a jméno celého routeru by pak mělo několik A záznamů vedoucích na všechny IP adresy všech rozhraní. Ale to už záleží na politice pojmenovávání v konkrétní síti, zda je někdo hračička a pojmenuje vše takhle pečlivě.

[Reklama]

[Vietnanka]

No tak mě třeba překvapilo, že to vypadá, že seznam absolutně neprovádí žádné kontroly.
1.V hlavičce (v webovém rozhraní zkoušeno jen) jsou jen hlavičky od odesilatele a POUZE "RECEIVED: from+by". Žádné Authentication results, spam-score... (Vím že může prezentovat uživateli e-mail v originální příchozí formě, BFU by tomu stejně nerozuměli)
2. Zároveň projde i mail s porušeným spf, ale platným DKIM (ano vím, že se uvádí, že stačí aby prošlo jedno), nechce se mi to už testovat


Teorie 1(té benevolentnosti, ne absence hlaviček) je, že dokud mail nikdo neoznačí jako spam, tak daná IP/doména se vůbec nedostane do databáze a nedějí na ní žádné kontroly.... Což ale podle mě odporuje denodení realitě, kdy maily jsou posílané z napadených koncových stanic.


k google: (brát s rezervnou ; na základě 1 prošlého a 1 neprošlého mailu)
3. nevím to jistě, ale google mail si hlídá SPF (a zároveň platný DKIM není postačující podmínka). Byl tam ještě třetí faktor- špatné HELO (doména neodpovídala IP).
4. Ale zároveň google nekontroluje PTR kolečko (tedy neexistující PTR), ale bylo splněno MAILFROM+HELO->A


Kromě toho taky google dělá jakousi SPF kontrolu i když  není definovaná. Pozná se to podle "best guess" - pravděpodobně jde o nepsané pravidlo jestli ip adresa domény (v tomto případě třeba bylinkyodsoudruha.cz) se rovná ip adrese  (modulo /24) - skutečně se lišili v posledním bajtu)

Kód: [Vybrat]

spf=pass (google.com: [b]best guess record[/b] for domain of wy1233@he-wd120.wedos.net designates 81.01.0.140 as permitted sender) smtp.mailfrom=wy1233@hc-wd120.wedos.net
Zvláštní praxe :
- (1) proč se uvádí "domain of wy1233@he-wd120.wedos.net" (ta část před @). V received je jen část za @. V return-path je celá adresa wedos.
- From a MAIL FROM se liší. Jako vím, že to je jasný příklad  "outsourcingu posílání mailů/remailingu. Nic proti tomu nemám.  Ale zaprvé proč (2) mě na to neupozorní Desktopový klient a taky proč  (3)se napoužije na mail from: bylinkyodsoudruha.cz

(4) JE snad někde dané, že HELO a doménová část MAIL FROM se mají rovnat? Proč to tak je? Existují protipříklady, že HELO je interní název stroje (typicky mail.hosting.cz nebo ještě lépe název z PTR ) a From : & MAIL FROM jsou shodné  skutečné adresy zákazníka hostingu. Jako jasné, je že HELO má být dohledatelný název stroje (což je ve všech případech splněno), volitelně(!!!) i rovný PTR záznamu.

[Filip Jirsák]

1.V hlavičce (v webovém rozhraní zkoušeno jen) jsou jen hlavičky od odesilatele a POUZE "RECEIVED: from+by". Žádné Authentication results, spam-score... (Vím že může prezentovat uživateli e-mail v originální příchozí formě, BFU by tomu stejně nerozuměli)

Výsledky antispamové kontroly ení nutné zapisovat do původního e-mailu. Klidně mohou být zapsané někde v databázi, nebo se prostě předají aplikaci doručující do schránek jiným způsobem. To, že se ty hlavičky přidávjaí do e-mailu, je spíš obezlička, když se spamové filtry do zpracování filtrů zařazovaly dodatečně a nebyl jiný (a univerzální) způsob, jak hodnocení z antispamu „propašovat“ dál v řetězci zpracování ke službě, která ukládá e-maily do schránky, případně je má zahodit nebo přesunout do složky se spamem.

Rozhodně se z toho, že v e-mailu nevidíte přidané hlavičky antispamu, nedá soudit, že by server kontrolu neprováděl. A třeba kontrola IP adresy a domény se často provádí už v rámci SMTP relace – když kontrola neprojde, je e-mail rovnou odmítnut. Když projde, tak je z tohoto pohledu v pořádku a není důvod o tom dělat nějaký záznam.

- From a MAIL FROM se liší. Jako vím, že to je jasný příklad  "outsourcingu posílání mailů/remailingu. Nic proti tomu nemám.  Ale zaprvé proč (2) mě na to neupozorní Desktopový klient

Protože to MAIL FROM je čistě transportní záležitost serverů. Jako by vás Pošta upozorňovala, že balík nepřivezli přes Brno ale přes Ostravu.

JE snad někde dané, že HELO a doménová část MAIL FROM se mají rovnat?

V žádném případě. To, že se liší, je běžná věc – pokud bych si měl tipnout, řekl bych, že se doručí víc e-mailů, kde se tohle liší, než kde je to stejné. Vlastně správně by to ani stejné být nemělo – v EHLO má být jméno zařízení, v MAIL FROM doména.

[davidb]

obvykle zacinam zjistovanim puvodu spamu, pokud se neodstrani pricina je mazani z blacklistu vcelku k nicemu, ale klidne tenhle krok preskocte