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).

Nagy lof@szt mar megbocsass. Az ilyen mega cegeknel alul altalaban sima favagok dolgoznak, csak jo esetben van egy par jo architect felul, de azokhoz meg csak a prioritasos dolgok jutnak el, valoszinuleg te ezt erted el a pereles cimu varazsszo hasznalataval :)

pont a napokban teszteltem spf/dkim/dmarc-ot és pl gmail lazán eldobja a levelet ha ezek a rekordok ezt mondják neki. szerintem ezt lehet iparági sztenderdnek tekinteni..

+1000

Belefutottam egy új hibába:

Received: from out.mail.ec.europa.eu (out.mail.ec.europa.eu [147.67.249.5])
    (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits))
    (No client certificate requested)
    by mail.xxx.xx (Postfix) with ESMTPS id 0D90B1200FE
    for ; Mon,  3 Jun 2019 07:15:22 +0200 (CEST)
Received: from S-DC-EMP020-I.net1.cec.eu.int (158.166.6.142) by
 S-DC-EDG009-Q.rcnet.cec.eu.int (147.67.249.5) with Microsoft SMTP Server
 (TLS) id 14.3.439.0; Mon, 3 Jun 2019 07:15:21 +0200
Received: from opvmwsehtx4.publications.win (158.167.96.63) by
 SMTPMAIL.cec.eu.int (158.166.6.142) with Microsoft SMTP Server (TLS) id
 14.3.439.0; Mon, 3 Jun 2019 07:15:21 +0200
Received: from tedmonitor-pk.opoce.cec.eu.int (158.167.99.97) by
 opvmwsehtx4.publications.win (158.167.96.63) with Microsoft SMTP Server id
 14.3.439.0; Mon, 3 Jun 2019 07:15:21 +0200 

A spamassassin kommentje a fejlécben:

X-Spam-Status: Yes, score=5.1 required=5.0 tests=HTML_FONT_LOW_CONTRAST,
    HTML_MESSAGE,MIME_HTML_ONLY,SPF_FAIL,SPF_HELO_NONE,UNPARSEABLE_RELAY,
    URIBL_BLOCKED autolearn=disabled version=3.4.2
X-Spam-Report: *  0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was
    *      blocked.  See
    *      http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
    *      for more information.
    *      [URIs: europa.eu]
    *  3.0 SPF_FAIL SPF: sender does not match SPF record (fail)
    *      [SPF failed: Please see http://www.openspf.org/Why?s=mfrom;id=no_reply%40publications.europa.eu;ip=158.166.6.142;r=xxxx.hu]
    *  0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
    *  0.5 HTML_FONT_LOW_CONTRAST BODY: HTML font color similar or
    *      identical to background
    *  1.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
    *  0.5 HTML_MESSAGE BODY: HTML included in message
    *  0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay
    *      lines
X-Spam-Level: ***** 

A 158.166.6.142 IP-be köt bele. Az nem a legelső és nem a legutolsó szerver.

A domain txt rekordjai:

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

$ host -t TXT _spf.tech.ec.europa.eu
_spf.tech.ec.europa.eu descriptive text "v=spf1 ip4:147.67.11.0/28 ip4:147.67.249.0/28 include:spf-00244802.pphosted.com -all"

$ host -t TXT spf-00244802.pphosted.com
spf-00244802.pphosted.com descriptive text "v=spf1 ip4:185.132.180.112 ip4:185.183.28.74"

A legutolsó szerver, ami elhagyta a netet és bedobta hozzám a levelet a 147.67.249.5, amit engedélyez az első SPF bejegyzés.
A 158.166.6.142 -t nem találom sehol, de a 158.167.99.97 -t sem, ami az első. Miért az utánakövetkezőbe kötött csak bele?

A levél közbenső útja érdekes SPF szempontjából? Mi van, ha belső IP-kel kommunikál (spamszűrő, vírusirtő, egyéb blackboxos megoldás) és végül egy külső MTA. Nem a külső MTA a mérvadó SPF szempontjából?

Nem értem egy ideje a SpamAssassin működését ezen a téren.

Tudom hogy off amit írok most, de nem feltétlen.

"Kadlecsik József: Az e-mail és a DNS" című egy órás előadása ami videómegosztón megtalálható, egészen érdekes dolgokat mesél el magáról a levelezésről.

Ilyen az SPF és a hozzá társuló hibaforrások, hibalehetőségek, olyan is amiről számomra egy élet is kevés lenne, hogy rájöjjek magamtól.
Pedig hosszú évek óta üzemeltetek levelezést, többeknek állítottam már be, évek alatt csak 1-2 alkalommal volt "gondom" spamekkel, "az is csak pár szem eper miatt történt..."

Érdemes megnézni, sőt, kötelező tananyaggá tenném annak aki levelező szerver beállításra, adminra szánja el magát. Bevallom töredelmesen, nekem még évek múltán is igen hasznos volt. Tudott újat mondani, mutatni.

Az `UNPARSEABLE_RELAY` figyelmeztetés arról szól, hogy nem tudta értelmezni az egyik "Received" headert, nyilván az utolsót, itt csúszik félre az egész.

Átfuttattam ezt a rövid headert a sajátomon, nekem jól látja: X-Spam-LastExternalIP: 147.67.249.5.
Át is ment az SPF ellenőrzésen: SPF_HELO_PASS SPF: HELO matches SPF record.
Ugyanúgy 3.4.2-es verzió.

Kérdés, hogy miért hibázik nálad amikor nekem működik (Debian Stretch).

Köszönöm, hogy szántál rá időt és megnézted. Elindultam ebbe az irányba és 2009-től vannak UNPARSEABLE_RELAY + SPF FAIL bejegyzések. spamass-milter bug számlájára írják. Általában nelyben futtatva az SA-t nem hibázik csak, ha spamass-milteren keresztül jön. Nálam sem hibázik, ha "spamassassin -D -t mail.eml" -t futtatok. Gondolom te is igy csináltad és ezért nem kaptál hibát.

spamc-vel ellenőriztem, az éles szűrésem is spamd/spamc párossal működik.

Ha ilyen hibákra hajlamos a milter, akkor le kéne kapcsolnod a relay alapú checkeket, mert sok gond adódhat még belőle.

Ha postfix-szal használod, meg tudod mutatni hogyan integráltad össze?
Korábban egy ilyen volt nálam a posfix/master.cf-ben:

dovecot-spamass   unix - n n - - pipe
  flags=DRhu user=vmail:mail argv=/usr/bin/spamc -u ${recipient} -e /usr/lib/dovecot/deliver -d ${recipient}

Aztán az i-mscp webpanel a spamass-milteres megoldást használta, gondoltam kipróbálom. Azon túl, hogy nem a header közepébe, hanem a végébe teszi a reportot, eddig más különbséget nem vettem észre.

Úgy tűnik, hogy sikerült megoldani. Szerencsére volt a kezem alatt olyan szerver, ahol ez jól működik ugyanilyen spamass-milter megoldással.

A sok-sok összehasonlítás és tesztelés után űgy tűnik ez volt a ludas:

#milter_connect_macros = i j {daemon_name} v {if_name} 
milter_connect_macros = i j {daemon_name} v {if_name} _

subs & thx.
____________________
echo crash > /dev/kmem