SPF FAIL -> SPAM

 ( Proci85 | 2019. április 17., szerda - 12:19 )

Sziasztok

A spamassassin egy ideje keményen észreveszi az SPF hibákat, aminek örülök. Viszont hetente jelentik a munkatársak, hogy fontos levelek komoly feladótól a spam mappában ladolnak.
Ezek általában SPF FAIL hiba miatt.
Múlthetéen az OTP küldött SPF hibás levelet, nem engedélyezett smtp-ről ment, ráadásul az SPF rekordja végén -all határozottan.
Ma a publications.europa.eu -val kapcsolatban szóltak, ami még rosszabb. Pedig itt valami közbeszerezési eljárásokat kezelnek.

$ host -t txt publications.europa.eu
publications.europa.eu descriptive text "v=spf1 include:_spf.tech.ec.europa.eu -all"
publications.europa.eu descriptive text "MS=ms23806379"

Ennyire nem értenek hozzá? Még jó, hogy nem hardosan dobom el az SPF hard fail leveleket.

A spamassassin aranyosan aranyosan a segítségemre siet még egy kis magyarázattal: [SPF failed: Please see http://www.openspf.org/Why?s=mfrom;id=no_reply%40publications.europa.eu;ip=158.167.3.13
De sajnos a domain nem szolgál ki kéréseket.
Mi a túró van itt? Így kicsit komolytalan az egész, pedig hasznos ellenőrzési pontnak tűnik. Vagy nálam van valami furcsa gixer, ami azért fura, mert heti sok száz levélből 1-2 akad fent ilyen hibával.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

nem, nem nálad van a hiba, és ez tényleg hasznos ellenőrzési pont :)

csak ezek néha annyira komplex és szétterült rendszerek, hogy nincs aki átlássa az egészet, vagy éppen nincs meghatározott globális minimum policy, hogy minek kell ezeknek megfelelnie. illetve sokszor úgy lesznek telepítve ehhez új rész(egység)ek, szolgáltatások, hogy nem is gondolják végig azt, hogy pl. a levelezéssel ilyen szinten törődni is kéne. jobb esetben valami teszt levél az initial fázisban megérkezik, aztán csókolom, elkönyvelik késznek. rossz esetben teszt sem igazán van.
vagy ennél is rosszabb esetben az adott cég deploymentet végző része nem tudja, hogy kihez kell fordulni pl. egy DNS rekord módosítása okán, vagy rosszabb esetben nem is izgatja egyik felet sem, hogy ezt up-to-date tartsa, még rosszabb esetben azt se tudják, hogy az spf-et eszik-e vagy isszák :)

Az SPF hibától önmagában nem kéne a Spam mappában landolnia semminek, érdemes lenne a pontos SA hiteket és pontokat átnézned ezeknél.

Ami fontos, azt pedig az SA-val vagy még előtte érdemes whitelistelni.

Nálunk is volt/van hasonló gond. Lassan nem a spam szűrés a probléma, hanem a legális levelek nem kiszűrése. És ez nem a túl szigorú szabályok miatt, hanem egyszerűen úgy jönnek levelek nagy cégektől, hogy hibás a fejléc, dkim, spf probléma, feketelistákon vannak,... Utóbbi időben elég sok ilyenbe futottunk bele. Mondjuk egy része a "hozzáértő" szaki miatt van, akik otthon beállítják a UPC,... smtp-t céges levélküldéshez.

hát ja, manapság már a spamek technikailag kifogástalan levelek.

Egyébként a spf -all esetén miért nem kéne spam mappába landolnia?

Mert az esetek nagy részében rosszul van beállítva a policy, összevissza továbbítgatnak és jön a fail, jön az isp... stb. Nem tudsz szigorú lenni, hiába lenne jó. Egyszerűen nem lehet szapporttal győzni és sosem megy át, hogy te igazából nagyon patent módon kezelsz mindent (SPF, dnsbl-ek, akármi), de pont a rohadtul hipernagy partnertől a túloldal baromsága miatt nem jött át a mail.

Ha esetleg eljut nagytúloldal szapportig, akkor jó eséllyel le is pattan róluk "nálunk mindenjóval" és a juzerek szentírásnak fogják venni, aztán megint ott vagy ahol a part szakad.

Az különösen elképesztő, hogy mennyire nem látják át és mennyire csapatnak összevissza a levelezéssel. Ha jelzed jó szándékkal, akkor egy felfoghatatlanul pökhendi válasz jön. Ebbe nem egyszer egyébként "DevOps" környezetes jóemberek futnak bele sajnos.

Javasolni szoktam a kuldonek, hogy tesztelje le itt: mail-tester.com.
Es intezkedjen ha ugy erzi sok a hiba. Meg szoktak koszonni, es kenytelenek elismerni a hibakat.
De talalkoztam mar olyan esettel is, amit irsz.

Par honapja a sajat o365 fiokommal is szivtam spf gond miatt. Fel napig spamba mentek, vagy visszapattantak a leveleim.

1-2 ilyen talán volt, de jellezően pont a nagyobb (tehát multicégek) helyeken vannak a bajok és jön a falba ütközés. A felhasználóknak van fehérlistázásra lehetősége, így azt szoktam javasolni.

+++

És mennyi ilyen van, te jó ég... Viszont ha valamit mindenképpen meg kell oldani, javaslom a multik esetén a jogi út felemlegetését. Ekkor adott esetben a supporton belül (kötelezően) átveszi másik csoport vagy épp a support leadje a problémát, ami után egy fokkal gördülékenyebbé válik az ügyintézés.

Nemrég esett meg velem, hogy 43 napig tartott amíg (nem levelezést érintően) egy hasonló ügyet felgöngyölítettem. Konkrétan 33 nap volt amíg a Cloudflare support queue-ján végigvertem (végül egy második ticketben, cca. 25(!!!) oda-vissza válasz után, mert végül előjöttem a "legal authorities" varázsszóval), hogy bizony ők a hibásak. Pontosabban kiderült, hogy mind a Cloudflare, mind pedig az általuk használt Project Honey Pot rendszerében hiba van, ami miatt adott esetben nem lehet lekerülni a CF egyik banlistájáról.

Volt nem kis örömködés, amikor kiderült, hogy értek mégis a szakmámhoz, csak ilyen mega cégekkel szemben az ember hajlamos már idejekorán feladni, mert még ő is elhiszi, hogy ott csak zsenik dolgoznak (ami igaz, de ők is hibáznak).