2008.05.30.
Kalandok a Cloudmark-kal
Böngészem a netet, vagy éppen egy SpamAssassin lista egyik levele került elém, és mit látok? A Cloudmark elérhetővé tette a szolgáltatását – Cloudmark Authority Engine (CMAE) – az elterjedt SpamAssassinhoz. Mi a CMAE? Egy 2 csomagból álló alkalmazás, amellyel a SpamAssassinba integrálható a Cloudmark kollaboratív vírus/spamszűrője. Az egyik része egy démon, ami a 2703/tcp porton várja a leveleket, a másik pedig egy SA plugin.
Én meg amilyen kísérletező kedvű vagyok, megnéztem a kliens részét, amihez nyilván van egy C library + header fájlok. Mázli, hogy a cmae_client.h
korrekt módon dokumentált, így írni tudtam egy rövid 2 soros C függvényt, ami fog egy levelet, és kideríti, hogy az vírus, spam vagy tiszta levél.
A megoldás egyébként úgy működik, hogy a kliens base64 kódolva elküldi a levelet a démonnak, az pedig az adatbázisa alapján eldönti, hogy az jó levél vagy sem. Mivel a Cloudmark képes valósidőben (real time) detektálni a vírus/spamkitöréseket, ezért nagyon fontos, hogy az adatbázisa up-to-date legyen. Ezt úgy oldja meg, hogy ún. microupdate-ekkel tartja percre frissen az adatbázisát, és csak egy licence kulcs kell hozzá.
A kliens program kb. ennyi:
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <fcntl.h>
#include <cmae_client.h>
int main(int argc, char **argv){
int ret, fd;
unsigned int ScoreOut=0;
char *msg=NULL;
struct stat st;
CMAE_Client_Session SessionOut;
if(argc < 2){
printf("usage: %s <messagefile>\n", argv[0]);
return 1;
}
if(CMAE_Client_Open(&SessionOut, "127.0.0.1", 0, 0, 0)){
printf("CMAE_Client_Open()\n");
return 1;
}
if(stat(argv[1], &st)){
printf("cannot stat: %s\n", argv[1]);
return 1;
}
fd = open(argv[1], O_RDONLY);
if(fd == -1){
printf("cannot open: %s\n", argv[1]);
return 1;
}
msg = mmap(msg, st.st_size, PROT_READ, MAP_SHARED, fd, 0);
close(fd);
if(msg == NULL){
printf("mmap()\n");
return 1;
}
ret = CMAE_Client_Score(SessionOut, NULL, msg,
st.st_size, &ScoreOut, NULL, NULL, NULL, NULL);
munmap(msg, st.st_size);
CMAE_Client_Close(SessionOut);
printf("%s %d\n", argv[1], ScoreOut);
return 1;
}
Az elvégzett tesztben 1313 ham levél szerepelt a májusi levelezésemből, amiből 9-et tévesen spamként azonosított. Ebből kettőt mondhatunk nem kritikusnak (Sun hírlevelek), de a maradék 7 az üzleti levelezésem része, úgyhogy sajna 7 kritikus fals pozitív hibát is vétett. (FP: 9/1313 = 0.68%)
Kétféle spam mintán is leteszteltem: az egyik a junk mappa tartalma, 2182 levél, amiből csak 5 csúszott át, ez 99.77%-os spam felismerés. A másik minta a csapda email címre érkezett 4468 levélből állt, amiből 20 csúszott át, ami 99.55%-os spam felismerés.
A detektálás folyamata egyébként gyors, a 12 ujjlenyomatot gyorsan levette a levelekről, és kidobta az eredményt, hogy szerinte mi az ábra.
Ja igen, a kaland. A poén kedvéért kértem egy ajánlatot a Cloudmark-tól, hogy mégis mennyibe fájna ez nekem, ha a 30 napos trial után komolyra fordulna a dolog? Potom pénz az egész, évente $5,000, amiért akár 2222 mailboxot is megvédhetek.
Azt is kértem, hogy mutassanak már egy demo C-programot, hogyan kell használni az SDK-jukat? Erre jött a kiváncsiskodás, hogy minek az neked, mire akarod használni? Megírtam, hogy építek egy POP3 proxyt, ami bárki használhat regisztráció után egy féléves pilot erejéig. Aztán megjött a válasz, hogy sajna nem fog menni, csak a SpamAssassin plugint tudják adni. Nem akartam ünneprontó lenni, hogy már régen kész van a cucc…
May 31st, 2008 at 2:51:29
Azt hiszem, hogy 99,5% felett mar eleg jonak mondhato a felismeres. Fals pozitiv eseten mi mondhato elfogadhatonak? Nekem soknak tunik, volt valami kozos vonasa ezeknek a leveleknek? (sok $ jel, tipikus token, epp rolex uzlettel leveleztel, ilyesmi)
May 31st, 2008 at 9:51:42
FP-nél a lehető legkisebb arány a cél. A doksiban (http://www.cloudmark.com/releases/docs/ds_authority_sp_10730506.pdf) nagyon taktikusan azt írják, hogy közel nulla a CMAE FP hibája.
Én havi szinten 0.1% alatti FP arányra már azt mondom, hogy szódával elmegy, lehetőleg nulla kritikus FP hibával (pl. ügyfelek levelei).
A tesztben esett kritikus FP levelek a cégen belül egy adott ügyféllel kapcsolatos levelezés volt, semmi különöset nem láttam bennük, amiért 100% score-t érdemeltek volna. Ja, és nem Rolex üzlet volt a partner
June 1st, 2008 at 9:47:50
Az $5000-t elég soknak találom. Bár lehet, hogy más mailbox alapú spam szűrő szolgáltatások árait figyelembe véve megéri. Ha már ilyen nagyszámú felhasználót kell védeni, akkor érdemes lehet valamilyen appliance megoldásba beruházni. Barracude? Azt hiszem az éves szinten valami $1000 körül van.
June 1st, 2008 at 11:42:41
Igen, akárhogy is számoljuk, az bizony 800k HUF/év, és ahhoz nagyon, de nagyon jó eredmények kellenek, hogy ennyi pénzt elköltsek. Ja, meg ennyi pénz is kellene valahonnan…
Jelenleg azonban egy olyan POP3 gateway-ben gondolkodom, ahol a felhasználó kiválaszthatja, hogy milyen anti-spam “motor” szűrje meg a leveleit az alábbi kínálatból: fehérlista, RBL, SURBL, statisztikai szűrő. Ide akartam még tenni egy egy kollaboratív megoldást is.
June 2nd, 2008 at 11:57:23
razor, pyzor?
Nem tudom ezek önmagukban mennyire erősek.
June 2nd, 2008 at 13:33:08
A razor (a pyzor ugyanaz, csak python-ban írva) csak 2 ujjlenyomatot képez, míg a cmae 12-t. Ill. ennek az is gyengéje, hogy egyrészt fork()-olnod kell a razor-t, továbbá az minden egyes levélnél elküldi a fingerprint-eket a cloudmark hálózatába, ami késleltetést okoz. Ez elfogadható 200 levélnél, de 100k-nál már aligha. Szóval ez csak kis levélszámnál járható út.
June 2nd, 2008 at 14:56:32
100k levél naponta? Az nem olyan sok. Nem tudom mekkora egy ilyen ujjlenyomat, de mondjuk 20 byte-al számolva is csak napi 4-5 MB lehet.
Időben ahogy nézem az SA-t 10-12 mp alatt ellenőriz egy levelet. Itt azért már lehetnek gondok. Ha egyszerre sok a bejövő levél, akkor felléphetnek különböző erőforrás problémák (DNS, max SMTP connections, stb).
A razor meg a pyzor projektek már különváltak nem? Tehát külön adatbázisokat használnak!?
Egyébként kíváncsi lennék mit produkál egy razor ugyanazon a spam mintán mint a Cloudmark.
June 2nd, 2008 at 16:10:44
Úgy értem, a SpamAssassin amúgy olyan lassú, ehhez még plusz hozzáadódik a razor válaszideje, mire megérkezik a válasz a cloudmark szervereitől.
A pyzor ügyében igazad van. Ok, telepítek egy razor-t, aztán lefuttatom a tesztet újra a mintával…
June 3rd, 2008 at 10:15:33
A razor teszt eredménye (default beállításokkal) az alábbi módon alakult:
junk mappa: 1925/2254 = 85.40%
csapda email cím: 3823/4612 = 82.89%
ham levelek: 1/1321 = 0.07%
A fals pozitív arány nagyon jó, egy Sun hírlevélre azért megorrolt. A spam felismerése azonban gyengébb, de tegyük hozzá, hogy nem tudjuk, vajon meddig tárolják az egyes ujjlenyomatokat, bár egy alig 1 hónapos spamet azért még illik felismerni.
June 3rd, 2008 at 14:34:57
Ezért kerül a Cloudmark $5000-be
Én egyébként 90% felett vártam volna.
June 5th, 2008 at 15:11:22
Sziasztok!
Az MPP Desktop / Mail Security Desktop pontosan ezt nyújtja, amiről
beszélgettek. Egy saját POP3 proxy + Cloudmark + Commtouch + NOD32 + ClamAV + saját fejlesztésű előfeldolgozás. Több év munkája és tapasztalata van benne, teszteltünk számtalan más ingyenes és fizetős megoldást is, de több okból is a fenti felállás mellett döntöttünk. A licencdíjak miatt pedig mi aggódunk – és komoly piac van rá, de ingyenes a szállítók díjai miatt nem lehet.
Bővebben a http://www.mpp.hu oldalon megtaláltok róla mindent.
June 5th, 2008 at 19:19:12
Helló! Lehet tudni valamit arról, hogy mi volt az a “több ok”, ill. hogy miket próbáltál ki, és miért nem voltak megfelelőek?
June 6th, 2008 at 8:38:43
Persze, gyakorlatilag minden zárt és nyílt forráskódú spamszűrőt kipróbáltunk már az elmúlt 3 évben. Ami számunkra nagyon fontos, az az egyszerű karbantarhatóság, a megbízhatóság több százezer ügyfél esetén is, a sebesség, és ezeknek a kritériumoknak nagyon jól megfelelt a Cloudmark és a NOD32, mindkettő magasan kiemelkedő a saját területén. Később lehetőségünk volt még a Commtouch RPD beépítésére, ami szintén egy innovatív spamszűrő és antivírus és érezhetően javított a statisztikáinkon, a ClamAV-ot pedig mindig alkalmaztuk, mert például rengeteg phishing támadást ismert a többiek mellett.
Gondolom elsősorban arra vagy kiváncsi, hogy mi a gond a clapf és társaival. Természetesen egyértelmű gond nincs velük, hiszen jól működnek, de nagyon sokat kell karbantartani őket, ami pedig lehetetlen egy nagy rendszerben. Nem arra gondolok, hogy magánfelhasználóként leterhelő lenne, de ha egy 10.000 fős cég levelezését kezeled, ahol a szűrés már csak egy sokadik “apróság” (hiszen például smtp védelem nélkül a levelezés sem működne) ott a legkevésbé sincs időd és lehetőséged felügyelni, állítgatni, tanítani egy szűrőmotort. 10ezer dolgozó nem fog karantént olvasni, tanítani, karbantartani, és főleg megérteni, hogy a legújabb spamtrükköt miért nem ismerte fel a szűrő (pl. az új spam módszert pont arra készítették, hogy kikerülje az ingyenes, ezért népszerű szűrőket).
Ezért olyan megoldás kell, ami egyszerűen csak működik, évek óta megbízható és villámgyors – a Cloudmark pedig pont ilyen, még ha megkérik is az árát.
June 6th, 2008 at 20:21:21
Köszönöm az infokat. Néhány dolgot azonban egy kicsit másként látok.
Először is Magyarországon azért nem sok 10k felhasználóval rendelkező cég van. Az a pár ekkora méretű cég pedig aligha fogja a felhasználóinak leveleit egy POP3 proxyn áthajtani, sokkal valószínűbb, hogy “házon” belül oldják meg a saját IT személyzettel, ahol fogadni merek, hogy van, aki főállásban foglalkozik a levelezéssel.
Még az is lehet, hogy megveszik tőled az MPP szerver edition-t, de tuti, hogy nem az MPP Desktop-ot.
Én azonban nem róluk beszélek, a POP3 proxy inkább az otthoni felhasználókat, ill. a pár (1-10) fős kisvállalatokat érdekelheti. Bár, ki tudja? Ha egy hazai “Fortune 500″-beli cég megrendelné a POP3 proxyt, annyi licence árából egy proxy klasztert is építhetnék nekik. Ha az MPP Desktop listaárának a feléért adnám a szolgáltatást, az éves szinten ~25M HUF lenne. Van ebben üzlet, az már egyszer biztos
A statisztikai szűrőkkel kapcsolatban több félreértés is kering a felhasználók (és a szakmabeliek) között, amit a blog bal felső sarkában szereplő könyvben igyekeztem helyre tenni.
Az egyik urban legend pont ez a “nagyon sok karbantartás”. A clapf-ot az elmúlt hónapban 0, azaz nulla spam levéllel kellett tanítani. Volt pár fals pozitív hiba (az okáról egy másik post-ban írtam), de még így sem kellett hetente többet tanítani 1,5-nél. Na hát kb. ennyi az az őrült sok karbantartás.
Egy másik tévhit, hogy bár 1 embernél működhetnek, de nagyobb környezetben – pl. a túlzott mértékű adminisztrációs igényük miatt – nem használhatóak a statisztikai szűrők. Cáfolatként legyen elég annyi, hogy a dspam-et pl. egy 350k felhasználóval rendelkező ISP is használja, és még van legalább 2 db 100k feletti usert kiszolgáló cég/szolgáltató.
De – megnyugtatásképpen – ha a POP3 proxy felállást tekintjük, akkor minden felhasználó úgy tekintheti, hogy a proxy csak az övé: (igény szerint) saját token adatbázis, aminek a tanítgatása – ahogy te is írtad –
“nem leterhelő”.
A félreértés talán abból adódhat, hogy az adatbázist az adminisztrátornak kell tanítania mondjuk 10k felhasználónál (ami, egyetértek, nem piskóta), de a tanítás feladata szét van osztva a felhasználók között, és ezért elhanyagolható a statisztikai szűrők adminisztrációs igénye.
Egy jó (statisztikai) spamszűrő használata olyan egyszerű, hogy – Zdziarski szerint – még a nagymamám is használni tudja. A felhasználó részéről mindössze 2 dologra van szükség: hogy képes legyen a fals +/- hibákat egy megadott címre továbbítani – ha elégedetlen a teljesítménnyel, merthogy még ez sem kötelező.
A következő tévhit, hogy a spammerek legújabb trükkjeit nem tudják felismerni. Cáfolatként hadd mondjam el, hogy havi szinten, jó ha 2-3 spam átcsúszik a ~2000-ből. Pedig Azt pedig büszkén hadd ismételjem meg, hogy májusban az ÖSSZES SPAMET FELISMERTE. Kivétel nélkül, hibátlanul.
Egy jó spamszűrőt nem kell jobban felügyelni, mint egy DNS vagy SMTP szervert. Olyan, mint a vese. Egy egészséges vese esetén az ember azt sem tudja, hogy neki van olyan. Majd szól a nagios, ha baj van. A gépemen futó clapf is csak azért frissül időnként, mert hogy én fejlesztem.
Végső soron azonban evéssel lehet a pudingot legjobban tesztelni, ha elkészül, akkor kiderül, hogy mire képes. Ha tényleg éjjel-nappal reszelgetni kell, hogy működjön, akkor felteszem a kezem, hogy bocs, de tévedtem. Bár erre szerintem kisebb sanszot adnak a bukmékerek, mint az osztrákok EB-győzelmére. Ha egy felhasználó nem elégedett a default token adatbázis biztosította pontossággal, bármikor úgy dönthet, hogy saját kezébe veszi a tanítást. Egyet garantálok: a kezdeti testreszabás után aligha lesz ez a fő foglalatossága.
June 7th, 2008 at 11:32:07
Sajnos teljesen elbeszélünk egymás mellett, ami nem is feltétlenül gond, hiszen teljesen más területeken van tapasztalatunk. Mi teljes szűrőmegoldásokat szállítunk, olyan méretekben amiket biztos nem láttál működni (2000 spamet pár másodpect alatt kell szűrni, nem egy hónap alatt
Azt írtad, hogy egy nagymama is képes karbantartnai egy szűrőt, akkor olvasd el a bejegyzésedet:
Rengeteg dolog van, ami neked természetes, hiszen fejlesztesz ezen a téren és teljesen máshogy állsz a kérdéshez, mint egy rendszergazda vagy cégvezető, akinek kész, működő megoldás kell. Mi nem hibázhatunk, nem mondhatjuk azt hogy “bocsánat, egy picit korrigálni kell és semlegesíteni kell bizonyos tokeneket az adatbázisban” amikor valami balul sül el és több ezer felhasználó nem tud levelezni, ami miatt megbénul egy vállalat adminisztrációja egy napra.
—
Így tehát módosítottam a .mailfilter konfigomat, majd egy sóhajtás után 3 tanítással kezdtem májust (3 angol hírlevél), és vártam, hogy az idő haladtával a korrekciós tanításokkal semlegesített tokenek kihulljanak a token adatbázisból az éjjeli törlések során.
—
Szerinted ilyet csinál egy nagyi?
Tehát kész, kiforrott, megbízható megoldásokra van szükség, a Cloudmark pedig pontosan ilyen. 3 év alatt több milliárd levelet szűrt, és egyszer sem hagyott cserben – ha ezt át tudod gondolni, el tudod képzelni, hogy mennyire lehet megbízható ekkora levéltömegen a clapf és társai, akkor be tudod látni, hogy miért a Cloudmark az egyik legjobb szűrő. Vagy belegondolhatsz, hogy miért használják 100 millióan, bár ezt szintén nem fogható fel hazai szemlélettel. Viszont amíg nem láttál ekkora rendszereket működni, nem ismered a globális helyzetet és trendeket, addig hiába írsz például könyvet erről. Havi 2000 spam alapján nehéz bármilyen következtetésre is jutni, és elhiszem, hogy foglalkoztat a téma, a saját szűrőddel biztosan elégedett vagy hiszen azért fejleszted magadnak, de a világ attól még nem így működik.
June 7th, 2008 at 15:02:40
2000 spamet pár másodperc alatt feldolgozni nagyon korrekt teljesítmény. Csak érdeklődöm, hogy ez a használt szoftver elméleti kapacitása, vagy te saját logjaid összesítése alapján jött az ki, hogy óránként jó 3M levelet dolgozol fel? Ez utóbbi esetén gratulálok, mert némely isp-nél ez egy teljes napi forgalom. De ha ez valóban így van, akkor ez azt jelenti, hogy rengeteg előfizetőd van, aminek örülök. Btw. ezt a mennyiséget (~25M levél / nap) hány géppel szolgálod ki?
Ami a nagymama vs. .mailfilter módosítást illeti, nagyinak továbbra sem kell többet tennie – vagy egyáltalán tudnia – mint a hibásan kategorizált leveleket egy megadott címre továbbítani. Ok, biztos van, akinek magas egy levelet továbbítani, de egy 100-as IQ-val rendelkező felhasználó, és a nagyi, képes erre. Aztán hogy a rendszer mélyén mi zajlik le, az – számára – részletkérdés, nem is kell vele feltétlen untatni.
Az a nyíltan ki nem mondott sugallmazás pedig, hogy a clapf nem megbízható, elég otromba és alaptalan FUD. Hadd mondjam el, hogy több helyen is használják a szűrőt, Texastól Litvániáig, Romániától Indonéziáig, és természetesen Magyarországon is. A clapf tehát már régóta nem csak a saját szórakoztatásomra szolgál, úgyhogy a termék elég stabilnak tekinthető akár vállalati felhasználásra is. Egy százfős hazai cég levelezését (legyen mondjuk havi 500k levél) lazán elviszi egyetlen gépen. Ezt már csak azért merem állítani, mert magam csináltam egy gépet, amin kb. ekkora forgalom megy. Hosszú hónapok óta. Megbízhatóan. Gond nélkül.
A másik otromba FUD-ra (miszerint minden alap nélkül merek spam ügyben felszólalni) meg hadd mondjak annyit, hogy a könyv megírásához alapos kutatómunkát végeztem, nemzetközileg elismert fejlesztők véleményei is elhangzanak a könyvben, és távolról sem havi 2k spam alapján írtam meg a következtetéseimet. Szóval nem is értem, miért nem veszed meg a könyvet, és olvasod el, amit írtam, mielőtt látatlanban lehúzod.
A saját kompetenciám védelmében meg csak halkan jegyzem meg, hogy ki szokták kérni a véleményem a témában, előadásokat tartok, és nem felejtek el sehol sem szólni a statisztikai szűrőkről.
Nem azt mondom, hogy a Cloudmark (vagy az azt is használó MPP) rossz szűrő lenne, bár az a 7-8 fals pozitív hiba májusban elég kiábrándító volt. De azt igen, hogy van alternatíva a kollaboratív megoldások mellett, amelyik legalább olyan jó, sőt jobb felhasználói élményt nyújt.
Végül a világról. Szerencsére a világ nem úgy működik, ahogy azt néhány savanyú jóska megmondja. A helyzet ugyanis az, hogy a statisztikai elvet használó spamszűrők élnek és virulnak. Ha nem is 100 millióan használják – mint a Cloudmark-ot (ami amúgy is egy ellenőrizetlen szám, és legfeljebb a részvényeseknek szól) – de elegen ahhoz, hogy nyugodt lelkiismerettel ki lehessen jelenteni, hogy az elv kiválóan bizonyított a spammerek ellen.
De írj csak bátran egy levelet Paul Grahamnak, Gary Robinsonnak, Jonathan Zdziarskinak, Louis Gregnek, Bill Yerazunisnek, John-Graham Cummingnak, hogy mekkora gagyi a statisztikai elv a spamszűrésben. Persze, csak ha nevetségessé akarod magad tenni, és szakmailag le akarod magad járatni. Ezek az emberek már hosszú évek óta fejlesztenek ilyen spamszűrőket, dolgozták ki a matematikai hátteret, tartottak egy halom előadást a témában.
Olvastam egy manualban – hadd gondolkozzam, melyikben is… – hogy csak az spam, amit nagy tömegben (>1M) küldenek ki. Ez a nevetséges definíció persze teljességgel érthető pl. a Cloudmark szemszögéből, hiszen ő nem képes deketálni a 200 példányban kiküldött magyar spamet, amiből ő mondjuk két példányt lát.
Én azonban azt mondom, majd a felhasználó eldönti, számára mi a spam, és amiben a statisztikai szűrők egyedülállóak: lehetőséget adnak nagyinak, hogy tegyen a spam ellen. Egy MPP Desktop user legfeljebb káromkodik, mert nem tud mit csinálni a kategorizálási hibákkal.
Ehhez csak az kell, hogy legyen valaki, aki elmondja nekik, hogy “Hé, emberek! Tudtok tenni a kategorizálási hibák ellen!”
Persze, mindig akad pár FUD terjesztő, akik félnek a statisztikai szűrőktől, mert a konkurenciát látják benne, vagy szimplán tudatlanok, de legalább hangosak.
Aztán ki tudja? Lehet, hogy az derül ki, hogy használhatatlan lesz a POP3 proxy… vagy az, hogy legalább olyan jó, mint a Cloudmark vagy a Commtouch féltett megoldása. Akárhogy is, mostmár a hiúságomat nem hagyja nyugodni, hogy megnézzem, mire is lesz képes majd a POP3 proxym….
June 8th, 2008 at 20:14:44
Csendesen beleszólok itt a nagyok vitájába. A könyvet olvastam. Elég kritikus vagyok könyvek területén, mivel sok szakkönyvet olvasok, de magyar nyelvű nagyon kevés jó van. Olyan, amit magyar szerző is írt, ritka mint a fehér holló.
A Spamtelenül jó könyv. Nem tökéletes, de jó. A témáról lehetne írni egy háromszor ilyen vastag könyvet is. Gondolom itt a kiadóval kellett egyezségre jutni. Én kicsit keveslem a valódi technikai részt, a konkrétumot. Viszont nagyon örülök annak, hogy ez egy olyan könyv, amit nem csak képzett rendszergazdák olvashatnak végig. kifejezetten fiatalos, érdekes, olvasmányos.
Én személy szerint az egész desktop oldali spam szűrést nem nagyon preferálom. Sajnos az látszik, hogy a spam szűrés olyan irányba megy el mint a vírus szűrés. Oldja meg a kliens oldali levelező. Ezért nem tartom jó ötletnek a POP3 proxy megoldásokat sem.
A spamet már az SMTP DATA fázisban vissza kellene dobni a feladónak.
Aki egy kicsit is utána jár a dolgoknak, az előbb utóbb belátja, hogy jelenleg elméletileg a statisztikai módszerek a legjobbak ezen a területen. Hogy milyen megvalósítások vannak, arról lehet vitatkozni, de biztos vagyok benne, hogy a jövőben az egyik legnagyobb fejlődés ezen a területen fog történni a spam elleni harcban.
June 8th, 2008 at 21:20:36
Valóban az lenne a legjobb, ha a spamet már SMTP szinten eldobhatnánk, de ezt reálisan sajnos nem tehetjük meg a fals pozitív hibák miatt.
Ha lehetőség van rá, akkor persze jobb SMTP szinten lerendezni a dolgot, de abból indultam ki, hogy adott XY otthoni felhasználó, akinek van egy POP3 hozzáférése, és slussz. ő pedig védelmet akar a spam ellen. Van egy yahoo-s címem is, és ha le lehetne tölteni POP3-al a leveleket, az lenne az 1. account (de sajnos nem lehet a free verzióban, pedig annyira azért nem vagyok elégedett a yahoo spamszűrésével).
A POP3 letöltés közbeni ellenőrzésnek is van azért 1-2 előnye. Pl. jellemzően nem a beérkezést követően azonnal töltik le a leveleket, hanem valamekkora késleltetés után. Ez az extra idő alkalmas lehet arra, hogy a feladó IP-címe esetleg “beérjen” egy feketelistán, amin a levél beérkezése idején még nem volt fenn, de időközben mások feltették.
Noha én is a statisztikai szűrőket preferálom, de mégis azt mondom, hogy ‘A’ legjobb megoldás relatív, ill. mindegyiknek meg van a maga jellegzetessége, erőssége ill. gyengéje.
Pl. ha valaki nem hajlandó tanítani a token adatbázisát, akkor a statisztikai szűrők sem lesznek annyira jók (mint amennyire egyébként lehetnének). A kollaboratív szűrők nem (igazán) ismerik fel a kis példányszámú (pl. magyar) vagy polimorf spamet. A feketelista önmagában meglehetősen hajlamos a fals pozitív hibákra. A fehérlista karbantartása időigényes, stb.
Ezért az a legjobb stratégiai, ha mindenki a lehetőségek között legjobb megoldást választja. Számomra nem kérdés, hogy megéri tanítani az extrém pontosság érdekében. Ami, ha az elején megcsináltad a házi feladatot (kezdeti tanítás), akkor aligha egy sűrű elfoglaltság.
Ja, és örülök, hogy a könyv (alapvetően) tetszett. A terjedelemmel nem volt gondja
a kiadónak, elsőre átment a kétszázvalahány oldalas kézirat (legalábbis ami az oldalszámot illeti). Valóban írhattam volna több “konkrétumot”, ebben az első könyvben ennyire futotta. Viszont ha lesznek olvasói vélemények, és valaki elmondja, hogy konkrétan hiányolta/kevesellte azt a részt, amelyik pl. a feketelista DNS kéréseinek lelkivilágáról szól, akkor annak nagyon jó esélye van bekerülni egy (esetleges) 2. (bővített/javított) kiadásba.
Ja, és nem tudom, hogy szerepel-e a könyvben, bele kellene lapoznom
, de a statisztikai szűrők (megfelelő módosítás után) korlátozott mértékben persze, vírusok ill. mutációik felismerésére is alkalmasak.