Sa-Exim Greylist teszt

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

Beállítottam exim-hez a spamassassint, hogy szürkelistát is kezeljen. Létre is hozza a tupleteket, olyan, mintha működne, de mégsem tudok kívülről olyan tesztlevelet küldeni, amit ideiglenes hibával visszadobna.A tesztlevél pontszáma -1.0.
Az sa-exim.conf fájlban a SAgreylistraisetempreject értékét -3.0-ra állítottam, a többi alapértelmezettben maradt. A levél header-jébe nem kerül bele, hogy GREYLIST_ISWHITE. Volt olyan levél, ahol beletette, de annak -2.5 volt a pontszáma, és ez meg is fele annak, hogy -1.5 pont alatt teszi fehérlistára. Tehát ez is teljesen olyan, mintha működne.
Próbbálom új és új küldőkkel és feladókkal küldeni a levelet, mégsem tudom elérni, hogy visszautasítsa a teszt levelem.
Van valakinek tapasztalata, mivel tudnám tesztelni, hogy a szürkelista műküdik-e?

  • 2401 megtekintés

( andrej_ v | 2017. 08. 02., sze – 10:31 )

A spamassassin+greylist nem tűnik túl jó ötletnek. Végiggondoltad, hogy pontosan milyen úton megy így a levél?

Nem tudom, miért rossz ötlet a spamassassin saját greylist-je.
Az kimondottan hasznosnak tűnik, hogy a pontozás alapján egyértelműen jó leveleket nem utasítja vissza, ellentétben a többi szürkelistával, amik mind bután minden levelet visszautasítanak, a fehérlistájukon kívül.
Szerinted miért nem jó ezt használni?

Alapvetően három problémát látok, ha jól értem, amit szeretnél elérni. A nagyobbik, hogy minden bejövő SMTP kapcsolatot (és vele a forgalmat) legalább az SMTP DATA végéig meg kell tartanod és második ami ebből következik, hogy minden emailen mazsoláznia kell az SA-nak. A harmadik, hogy átmenetileg visszautasítani egy bármikor spamnek minősült levelet szerintem nem szerencsés, mert az később is spam. A helyzet kevésbé súlyos, hogy ha legalább viszonylag szigorú szabályaid vannak korábbi szakaszokon. A reverse, helo name és tsai ellenőrzésekre gondolok.

Ami MTA üzemeltetés vonalon látok jelenleg, hogy több lépcsőben érdemes szűrni:

1) Mindenféle RFC-k és ajánlások, fehér és feketelisták IP alapon, tapasztalatok szerint alapelvárások szerinti kapcsolat tiltás/továbbengedés (ezekről itt a HUP-on korábbik topikokban értekeztünk már többször)

2) Igény esetén szürkelistázás alapvetően valamilyen szűkített módon, azaz pl: csak a reverzzel nem rendelkezők, vélhetően dinamikus hosztról (ez pont a reverzből dőlhet el) érkezők szűrése.

3) RBL/DNSBL alapú szürke és feketelista. Ebben addig jutottam, hogy ha a küldő nem szerepel RBL/DNSBL-en az jöhet, aki 1-2-n szerepel az szürkelista, aki 3 vagy többön vagy temp reject. Még mindíg csak a RCPT TO szakasznál járunk az általam használt konfigban. Erről is a korábbi topikokban konkrét exim konfigot találsz. (Aki 3+ listán szerepel és aktívan takarítják a küldő szervert és utána lekerül az legfeljebb késéssel szembesül és a fehérlistára tett konkrét feladó is rögtön átjön ezen.)

4) Csak most jön az SMTP DATA. Aki még ezek után megmaradt azoknál vírus (mindenkin, akármilyen listán van) és spamszűrés.

A fenti kombó vagy több eleme több szerveren fut sok száz domainnel összeségében és általában jól vizsgázik. A rendszerre inkább 1-1 átjutó spam jellemző, mint a fals pozitív. (Azt nem tekintem fals pozitívnak, ha egy küldő szerver valid email küldéskor 3+ DNSBL-en van, azért ennyire nehéz hipphopp felkerülni.)

Köszönöm a részletes leírást, és lehet, én nem látom át még rendesen, de a számomra ez összefoglalva annyit jelent, hogy a Spamassassin szürkelistája azért rossz döntés, mert több erőforrást használ el.
Hogy a több erőforrásnak milyen hatékonyság az eredménye, ezt nem tudjuk, de nem látom eleve hibás megközelítésnek.
Amit leírsz, az egy lehetséges szűrése a leveleknek. A Spamassassin szürkelistája meg egy másik lehetőség. Ráadásul ki sem zárják egymást.
Ha a szerver erőforrásai nem túlterheltek, nem látom elsődleges szempontnak az erőforrások kímélését, amennyiben az eredmény egy felhasználóbarát védelmi rendszer.
Ehhez pedig jó lenne tesztelni, milyen hatékonysággal működik a Spamassassin féle szürkelista, amivel én ismét a kezdeti kérdésemhez értem vissza.

Az hogy általában nem terhelt a szerver nem jelenti azt, hogy nem lehetnek hirtelen nagy forgalmak. Szerintem továbbra is kár belekódolnod a rendszerbe egy láthatóan könnyen túlterhelést okozó feature-t.

Szerencsére az Exim nagyon nagy konfigurációs szabadságot ad, amit mindenki az ízléséhez és elgondolásaihoz hangolhat.

Ehhez pedig jó lenne tesztelni, milyen hatékonysággal működik a Spamassassin féle szürkelista

sigh. Te erted egyaltalan, miket beszelsz? :-) Kell neked egy feature (=szurkelista). Adott egy (sok) megoldas, ami megcsinalja 5 egyseg koltseggel, meg adott egy masik megoldas, ami ugyanazt megcsinalja 200 egyseg koltseggel. Ha van egy MTA-d, ami az smtp kliensek fele greylistinget mutat (akar beepitve, akar policy demon, akar SA, ... vegezze is el a piszkos melot), akkor az mindig ugyanolyan hatekonysaggal fog dolgozni. Csak a koltsege nem mindegy...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Azért nem fog ugyanolyan hatékonysággal dolgozni, mert a standard greylist minden első levelet visszafordít, az itt ajánlott megoldás RBL-ek alapján válogat, a spamassassin meg levéltartalom alapján válogat.
A hatékonyságot pedig az ügyfelek visszajelzéseiből és az átengedett spamek mennyiségéből fogom látni.
Eddig mindenhol standard szürkelistát használtunk, és mérhetően kevesebb spam érkezik, ha be van kapcsolva. De a felhasználók oldaláról is mérhető az elégedetlenség egy-egy első levél várakoztatásánál. Azt remélem, a spamassassin alapú szürkelistával a végeredmény kedvezőbb lesz felhasználói oldalon, és nem lesz lényegesen rosszabb a bejövő oldalon.

mert a standard greylist minden első levelet visszafordít, az itt ajánlott megoldás RBL-ek alapján válogat, a spamassassin meg levéltartalom alapján válogat.

sigh. Egyreszt a legtobb greylist demon konfiguralhato, mit engedjen be kesleltetes nelkul, igy a leggyakoribb smtp partnereket felveheted, ami erosen csokkenti az elegedetlenseget. Az RBL-ek eredmenyet figyelembe venni a greylisting soran erdekes, de mukodhet. De amit te bedobtal, abban nem latom az ertelem nyomat.

Mert mi tortenik? *Atveszed* a levelet, az SA megcsamcsogja, es kiszamolja, hogy a level spam vagy hogy ham. Namost ha spam, akkor van ertelme visszadobni 450-nel, hogy aztan kesobb meg egyszer megcsamcsogtasd az SA-val, es aztan atvedd? Ha ham, akkor meg van ertelme kesleltetni a levelet?

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Ha már fapados, akkor eximhez inkább a simplegreylist külön bővítmény nélkül, egyszerűen csak szabályokkal. De azért a spamassassinban elég sok embervényi munka és tapasztalat van már benne. Lehet, nem véletlenül olyan a szürkelistájuk, mint amilyen. Szívesen életre lehelném, már csak azért is, hogy okosodjak.

ez a fucked by design minositett esete, mert nem erted, hogy mit csinalsz, hogy mi mire valo. Kb. mint amikor valami draga cuccal olyan melot vegeztetsz, amit egy olcso is meg tudna tenni.

A spamassassin egy eroforras igenyes (resource hog) dolog. A greylisting normalis esetben az mta szintjen valosul meg - olcson.

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

( sj | 2017. 08. 02., sze – 17:46 )

Van valakinek tapasztalata, mivel tudnám tesztelni, hogy a szürkelista műküdik-e?

a telnet parancs pont jo ra...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

ezt irtad: "mivel tudnám tesztelni, hogy a szürkelista műküdik-e?"

erre pedig kivalo a telnet parancs, amivel egy smtp klienst tudsz emulalni. De nem csak azt, hanem az SA tcp portjara is tudsz vele tetszoleges adatokat, IP-cim, email cimek, amit csak egy greylist demon megkaphat...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

( bennyh | 2017. 08. 07., h – 11:50 )

Kisebb cégnek manapság már nem érdemes saját spam szűrővel tökölnie szvsz, évi 100-200ezer alatt már van jó pár felhős szűrő. Persze tudom, akkor már ott a teljesen felhős levelezés, meg ugye a bizalom kérdése, ésatöbbi. Pedig sajnos manapság egy saját levelezőrendszer pont a spamszűrésen bukik el.

(egy atlag) kisebb cegnek eleve nem erdemes sajat mail szolgaltatassal bajlodnia. De ha mar bajlodik, akkor konnyen ossze lehet rakni open source cuccokbol (pl. postfix, postgrey, clamav, spamassassin, ...) egy jo kozepes spamszurot. De legalabb ezt a kombot keveset kell tutujgatni. Ha kidobjuk az SA-t,es valami normalis spamszurot teszunk a helyere, akkor meg egy popec rendszer is lehet belole. Bar ehhez a topiknyitonal lenyegesen nagyobb tudas es tapasztalat szukseges, megis ez az egyszerubb resze.

Ami nehezebb, hogy ezen felul legyen olyan mentesed a mail szerverrol, account-okrol, ... amivel egy disaster eseten hamar vissza tudod allitani a szolgaltatast + archivald a leveleket. De amig a kerdezo ott tart, hogy neki eroforras nem szamit (el-o-el), addig az ugyfelei alighanem nelkulozni fogjak ezeket az 'extrakat'...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...