SPF softfail

Web, mail, IRC, IM, hálózatok

Szervusztok

Szeretnem tolem jobban hozzaerto(k) segitseget kerni egy SPF softfail esettel kapcsolatban.
Adott egy SPF rekord:
"v=spf1 mx ip4:y.y.y.y ip4:x.x.x.x ip4:z.z.z.z/24 include:spf.protection.outlook.com include:servers.mcsv.net ~all"

Ez igy softfail-t dob egy ellenorzorendszer szerint. Vegig neztem minden szabadon elerheto tesztelo eszkozzel. Egyetlen mondta, hogy softfail, de nem igazan ertem, hogy miert. Csinalhatok belole hardfailt, ha a '~' -t lecserelem '-' -ra. De ezzel nem erzem, hogy kozelebb lennek a megoldashoz.

Valakinek van otlete, hogy mit nezek el vagy mit nem ertek?

Koszonom
lipiqe

  • 1093 megtekintés

( andrej_ v | 2019. 04. 10., sze – 18:49 )

Mi a probléma konkrétan? Mert ez így fentebb tényleg SoftFail -t adó default policy.

( Pene | 2019. 04. 10., sze – 18:52 )

Ez egy teljesen validnak tűnő spf rekord. Egyetlen buktatót látok benne, ha esetleg kiszedtél még belőle pár include-ot, a-t stb., a dns query-k ugyanis maximalizálva vannak. 10 darab felett érvénytelen (és az include is bontható még többre, mint pl. a szokványos google include is igazából többnek számít).

Esetleg még arra tudok gondolni, hogy az egyik space karaktered nem space, hanem valami hasonló, de más. mac-en bashnál volt már hasonlóból gondom.

A https://dmarcian.com/spf-survey/ és a https://www.kitterman.com/spf/validate.html? mondja azt, hogy jó, utána az tuti jó is, random oldal szarul megírt tesztelőivel nem érdemes foglalkozni.

gondolom az, hogy csak _egy_ ellenőrző rendszer mondta azt, hogy ez softfail, miközben mindnek ezt kéne mondani rólaugyebár az "~all" miatt. legalábbis én így értettem, és ezért gyanakszom valami más hibára, ami miatt esetleg nem, vagy rosszul fut le a többin ugyanez a check.

ugye ezeket az ellenőrzőket az rfc szabvány alapján szokták megírni. már itt eltérések lehetnek, ami okozhatja azt, hogy fals negatívakat kapsz, netán hibásnak tüntetnek fel korrekt szintaxisú rekordot.

ezen felül az már teljesen az ellenőrzőt készítő fejlesztőre van bízva, hogy ő mi alapján és hogyan értékel, mivel ilyen nincs is az rfc-ben (csak az, hogy az hibás-e vagy sem). ergo mondhatja azt, hogy minél több dns query-t tartalmaz a rekordod, az annál rosszabb, netán hogy ha nem az "a"-t vagy éppen a legtöbb levelet küldő ip-t teszed legelölre, akkor nem optimális stb. ez rá van bízva, és ezeket érdemes fenntartásokkal kezelni, ezért is írtam fentebb a két példát. azok megbízhatóan, az rfc szabványokat teljesen lekövető módon ellenőriznek. ha ezeken átmegy, nem ölnék bele több energiát a dologba, maximum akkor, ha a gmail is sikoltozna valamiért (de sok kilences eséllyel nem fog).

pár teljesen triviális szabályt érdemes betartani a megfelelő szintaxis mellett, és ennyi (pl. a nem spf, hanem txt rekordként vedd fel ezeket; a ptr-t ne tedd bele az spf-be; lehetőleg a feldolgozási/szerepeltetési sorrend kövesse le a küldésre használt infra/ip-k sorrendjét; rövid spf esetén nyugodtan lehet a rekord flat stb.).

amit még érdemes meglépni, hogy a google postmaster toolsba beregeled a domained, és ha elegendően nagy volumenben küldesz levelet, akkor pár hét után napokra lebontva is szépen láthatod, hogy milyen arányban fogadja el a leveleid spf rekordját validnak a google. ha itt vannak nagy kilengések, akkor érdemes esetleg beavatkozni, de gyakran ezek a hibák is teljesen független rendszerek hibáiból fakadnak (időleges névfeloldásbeli vagy a köztes, 3rd party eszközökön routing problémák például).

( mogorva v | 2019. 04. 11., cs – 21:00 )

Empirikus jótanács.
Ha gmail, outlook.com és egy általad jól összerakottnak tartott mail szerver befogadja a leveleket, akkor jó az spf.