Találtam egy site-ot, ahol videokat lehet készíteni. Gyorsan össze is dobtam pár clapf promo videot. Lesz még több is, szebb is. Kattints rá a lejátszáshoz!

Még tavaly volt, hogy a Korubo kft. a Vodafone megbízásából megszórta a netet az “én családom” nevű akcióval. Sajnos az én címemre is jutott, amire persze bánatos lettem, és ahogy kell, felnyomtam őket az NHH-nál.

Hosszan húzódott az ügy, mert új eljárást kellett indítani, de végül meglett az eredmény, és az NHH elmarasztalta mind a Vodafone-t (=hirdető), mind pedig a Korubo Kft-t (=elektronikus hirdetési szolgáltató). A hatóság felszólította őket, hogy egyrészt töröljék az email címem, másrészt jó lenne, ha tartózkodnának a jogellenes magatartás folytatásától.

A megismételt eljárásban Korubo csatolta az email címemet tartalmazó nyilvántartását. Ez azárt volt pikáns, mert az email címem mellett a “web_erdeklodo” megjegyzés volt. Na igen, gondolom, a Korubo címgyűjtő robotja ha valahol lát egy email címet, akkor azt hitte, hogy az biztos érdeklődő. Az NHH megállapította, hogy sem a Kérelmező (ez én vagyok) feliratkozásának körülményeit, sem a Kérelmező egyéb, az Ekertv. 6. paragrafusában meghatározott személyes adatot nem tartalmazott a Korubo nyilvántartása, ezért a hozzájárulás meglétének bizonyítására nem alkalmas.

Tehát sem a Vodafone, sem a Korubo nem tudta bizonyítani, hogy kértem volna spamet tőlük. Ugyanis az előzetes engedély megadását nekik kell hitelt érdemlő módon bizonyítani. Nyilván nem tudták.

Azt nehéz eldönteni, hogy a címlistát végül is ki állította össze. Vagy a Vodafone adta a Korubonak, hogy itt egy halom cím, küldjetek rá reklámot, avagy a Vodafone csak annyit mondott, hogy itt a reklám, küldjétek szét [...]. De akárhogy is, ez a kettejük közös balhéja volt, amiért szégyellje magát mind a Vodafone, mind pedig a Korubo.

A “Raid5″ fantázianevű formáció Végső búcsú a megbízhatatlan SPAM szűrőktől! akciós cikkében olvastam érdekeseket a spamszűrő szolgáltatás(uk)ról.

Már az első mondat megdobogtatta a kicsi szívemet:

“Talán már azt is megtapasztalta, hogy az ingyenes spam szűrő rendszerek egyike sem véd megbízhatóan a kéretlen levelek ellen.”

Hasonló csúsztatásokkal találkoztunk már, és nyilván a Raid5 számára is világos a cél: ráhangolni az olvasót a Symantec Mail Security megvásárlására, ugyanis ez a cég az említett termékre építi a saját dobozát.

Azt is megtudjuk, hogy “a kéretlen leveleket késő akkor kiszűrni, amikor azokat a levelező szerverünk már letöltötte, kézbesítette! Hiszen így a kár nagy részét óhatatlanul elszenvedjük:

• felesleges terhelést és lassulást okozunk a levelezőszerveren,
• a vírusokat és kémprogramokat is átengedjük a vállalati kommunikációs rendszeren, egészen a végfelhasználók számítógépéig,
• minden kéretlen email annyi példányban tárolódik az asztali számítógépek karanténjaiban, ahány számítógépen a spam szűrő telepítve van,
• a gépek számával megszokszorozott többlet adattárolási és adattovábbítási költséget is állnunk kell.

Ezekben van igazság, azonban ezeket a számokat pl. a spam miatti költségek kalkulátoraiban hajlamosak eltúlozni a kereskedelmi megoldások szállítói, akik nyilván abban érdekeltek, hogy egy jó nagy összeg jöjjön ki a spam miatti károkra.

A múlt havi jó leveleim mérete ~29 MB volt, míg a spam mappa ~11 MB. Ha ehhez hozzáveszem a csapda email címre érkezett ~27 MB levelet (ami egy “normális” felhasználó esetén nincs), csak akkor lesz nagyobb a spamek összmérete. Ha a kéretlen leveleket az asztali PC-ken szűrjük, akkor a fenti kifogások (pl. többlet adattárolás) nem valódiak, hiszen manapság (több) száz GB-os diszkekkel érkeznek a PC-k(, ill. a felismert spamet nem kell a központi gépeken archiválni). Egy átlag felhasználónak ~7.5 év kell ahhoz, hogy 1 GB spamet kapjon, és még akkor is csak a merevlemez 1%-t foglalják el a kéretlen levelek. A spam okozta probléma máshol van.

Az valóban reális aggodalom, hogy ne engedjük a vírusokat, kémprogramokat a felhasználó gépéig. Azonban egy működőnek nevezhető levelező infrastruktúra már a szervereken biztosít vírusvédelmet, amit jól kiegészíthet a PC-ken futó, másik gyártó antivírus szoftvere.

“Egy olyan megoldást ajánlunk, melynek spam szűrő motorja már több mint százezer email postafiók spam és vírus védelmét látja el magyarországon.”

Fúúú, de jó! Bár az ilyen számok kapcsán mindig kissé olyan érzésem van, mint a Jézus keresztjéből származó fadarabokkal. Ha azokat mind összeraknánk, nem hogy egy kereszt, de Kolumbusz teljes flottája kitelne. Hasonlóan: az egyik termék ennyi millió postafiókot véd, a másik annyit. Még százezer itt, még százezer ott, és kiderül, hogy annyi email cím nincs is Magyarországon.

Még szerencse, hogy itt van nekünk a RAID 500 ANTISPAM+ANTIVIRUS SERVER, amely több mint 20 féle levélszemét-szűrési technológiát kombinál.

• több mint 97 százalékos találati arányt nyújt a spam levelek felismerésében, de ami még fontosabb:
• Kevesebb mint 1 : 1000000 alatti a hamis riasztások aránya. Azaz kevesebb mint egy a millióhoz azoknak az emailek-nek a száma, amelyek tévesen spam-nek minősítve a karanténba vagy törlésre kerülnek.
• A levélszemét-felismerés szabályai automatikusan, minden 5-10 percben frissülnek, nem igényelnek adminisztrálást, és biztosítják, hogy mindig az új fenyegetések elleni leghatékonyabb védelmet élvezze.
• A szűrés még azelőtt megtörténik, hogy a spam és vírus gyanús levelek elérnék a vállalati levelezőszervert.

Tehát arról van szó, hogy a RAID 500 fantázianevű dobozt leteszik a cégednél. A rendszergazdád ráirányítja az Internet felől érkező leveleket, az pedig a jó email-eket továbbadja az Exchange-nek (vagy amit használtok). Van azonban néhány apróság, ami mellett ne menjünk el szó nélkül.

Ahhoz képest, hogy a termék 20 féle technológiát kombinál, meglehetősen közepes (hogy ne a gyenge/karesz/… szavakat kelljen használnom) spam felismerést biztosít. Ez egy kissé távol van attól, hogy “ha örökre megszabadulna a kéretlen levelektől,”. Bár az is lehet, hogy ez csak egy költői merengés volt, hogy ‘az jó lenne, ha?’, de sajnos, mi sem tudjuk, hogyan. Úgy tűnik, hogy hiába az 5-10 percenkénti frissítés, ez sem elég egy 99% feletti spam felismeréshez. Ez alatt nem tartok megfelelőnek egyetlen antispam megoldást sem.

A rendkívül impozáns fals pozitív arány semmitmondó, és jó, ha a szokásos PR-cikkek adatainak megfelelően kezeljük. Egy bizonyos kereskedelmi termék hasonló adatokat reklámozott, de ehhez képest néhány jó levelet is spamként értékelt. Mondanom sem kell, meg se közelítette a gyakorlati érték a hirdetett 1:1000000-t.

Végül hiába történik meg a szűrés a vállalati levelezőszerver előtt, a spamek már lejöttek a cég bérelt vonalán. Ebben a tekintetben a ‘RAID 500′ nem jobb az asztali szűrőprogramoknál. De mondom, egy cég számára elsősorban nem a spamek letöltéséhez szükséges extra sávszélességigény okoz problémát.

Értékelés

Nem állítom, hogy a Symantec termékre épített RAID 500 nevű doboz teljességgel megbízhatatlan lenne, de azt igen, hogy az a brigád, akik a heurisztikus szűrőket egy kalapba teszik a statisztikai szűrőkkel, és kijelentik, hogy “A vállalati szférában az ingyenes termékek használata nem jelenthet megoldást.“, nos azok egyszerűen nem kompetensek a témában.

Több teszt eredményem alapján ki merem jelenteni, hogy egy jó statisztikai spamszűrő bármelyik kereskedelmi termékkel felveszi a versenyt teljesítmény és pontosság terén is. A Raid 500 akciós áránál sokkal kevesebb pénzből (legyen mondjuk a fele) egy olyan rendszert építek neked, ami lazán alázza az említett terméket.

Választási év van. Ez azt jelenti, hogy a legkülönfélébb politikai formáció igyekszik meggyőzni minket, hogy ők a jövő záloga, az igaz magyarok megmentői, whatever.

És hát ki más is nyitná a sort, mint minden netező legrosszabb rémálma: Seres Mária spammer kompániája. Nem gondolom, hogy minden eddigi Seres spamet ő küldött volna el személyesen. Több seresmária spam végén pl. egyéb nevek szerepelnek.

Íme a legújabb, üres lózungokat durrogtató spam:

**********************************************
Nem gondolom, hogy a rendszerváltás után 20 évvel arra kellene törekedni, hogy egy párt ötven százalékos vagy annál nagyobb többséggel kerüljön hatalomra. Mindegy, hogy melyik pártról beszélünk. Bocsánat, de nem az egypártrendszert akartuk megszüntetni 1990-ben?

Ezért is bízom benne, hogy a Civil Mozgalom által a várakozás és a reménykedés helyett immár a gondolkodás és a cselekvés évei köszöntenek ránk ? mert igazi eredményt csak ez, és az összefogás hozhat.

**********************************************

Először is hadd mondjam el (már sokadik alkalommal): nem szeretem a spamet. Azt sem szeretem, ha valaki törvénytelen módon, az Internetről összevadászott email címekre küld kéretlen levelet. Nem az a gond egy levéllel, ha pirulát hirdet, hanem az, ha azt kéretlenül teszi, ti. ettől lesz spam.

Ha valakit be tud palizni Seres Mária, hogy rájuk adja a szavazatát, hát sok sikert. Csak egyet szeretnék elérni: ne fárassza azokat, akiket nem érdekel Seres Mária, sem a Civil Mozgalom. Mondom, a civilek is elférnek a csalók, hazugok, félkegyelműek és a többi hitvány politikai palettáján, akiknek csak az a céljuk, hogy a húsos fazék mellé kerüljenek, és aztán a saját pecsenyéjüket sütögessék.

Sokan képtelenek megérteni, hogy mi bajom van a Seres Mária / civil mozgalom brigáddal, így megfogalmaztam azt egy korábbi seres spam végén.

A Virus Bulletin: a spamszűrők együtt jobbak, ill. a Hány licence kell neked? írások alapján felbuzdúlva végeztem egy gyors tesztet az MPP-vel ill. egy ‘open source’ spamszűrővel.

Hogy a teszt eredmények valóban összevethetőek legyenek, végül mégsem az MPP VMware appliance-ot használtam, mert abban rengeteg egyéb funkció is megtalálható (pl. karantén, archiválás, …), ami megnehezítené az összehasonlítást.

Ezért letöltöttem az MPP ver. 4.20.0, rc1, Tue Aug 25 13:39:17 EDT 2009 [Linux 2.6.12-1.1381_FC3 i686] verziójú linuxos verzióját, és azt használtam. Nem telepítettem viszont az mppmanager-t, mivel nem volt most szükségem a szolgáltatásaira, és a MySQL szervert sem használta az MPP.

A teszt környezet egy WMware-ben futtatott CentOS 5.4 volt, ami 768 MB RAM-mal gazdálkodhatott. A teszt során összesen 9.6k levelet küldtem a rendszerre 10 szálon (=SMTP kapcsolaton) át, kb. fele-fele arányban jó ill. spam leveleket.

A tesztnek két célja volt. Az első, bizonyítani azt, hogy az MPP esetében nem igaz az a tétel, hogy ha több szűrőmotort használunk, akkor a szűrőmotorok számával egyenes arányban csökkenne az áteresztőképesség, azaz pl. 10 szűrőmotor tizedakkora teljesítményt eredményez. A másik pedig az, hogy képet kapjak a Cloudmark teljesítményéről. Azt is szeretném már az elején megjegyezni, hogy a teszt nem tért ki az egyes spamszűrő megoldások pontosságára.

A leveleket – privacy rulez – minden esetben ssh tunnel-en keresztül küldtem a VMware-ben futó programoknak, és minden levelet – függetlenül attól, hogy spam vagy sem – a /dev/null-ba irányítottam.

Két fajta tesztet végeztem. A TESZT1 során közvetlenül a 127.0.0.1:10025/tcp-re (azaz a spamszűrőre) irányítottam a leveleket, amelyek utána a 127.0.0.1:10026/tcp-n futó postfix példányhoz kerültek, ami a /dev/null-ba írta mindet.

A TESZT2 során pedig a szokásos módon a postfix kapta meg a leveleket a 127.0.0.1:25/tcp-n, amelyeket átadott a spamszűrőnek, az pedig visszaadta a postfix-nek, végül ebben az esetben is a /dev/null volt a végállomás.

TESZT1 / MPP:

Két kört is mentem. Először a <scan_engines>cloudmark, clamav</scan_engines> beállítással. Ebben az esetben a teszt időtartama 08:41 perc volt (15:25:40 – 15:34:21). A második körben kihagytam a clamav-ot, és csak a cloudmark eredményére voltam kiváncsi: <scan_engines>cloudmark</scan_engines>. Ebben az esetben rövidebb ideig tartott a teszt: 08:20 percig (16:27:16 – 16:35:36).

TESZT2 / MPP:

Itt már csak a cloudmark-ra koncentráltam, és a 9.6k levél /dev/null-ba továbbításához 09:49 percre (16:05:28 – 16:15:17) volt szükség.

Fontosnak tartom megjegyezni, hogy az mppd.conf konfigurációjában a használt szűrőmotorok felsorolásán kívül semmit nem módosítottam. Az MPP alapesetben debug módban loggolt. Ha ezt lejjebb vettem volna, (valamennyivel) biztosan nőtt volna a teljesítmény.

Az mppd.conf.xml tekerése közben észrevettem, hogy csak 2 szálon dolgozta fel az MPP a leveleket (processing_threads=2). Ezért, ha már itt voltam, ezt felemeltem 10-re, ill. csak a hibákat naplózta az MPP (logging=ERROR). A TESZT2 feladatot ebben az esetben tehát 08:26 perc (22:27:44 – 22:36:10) alatt végezte el az MPP.

A kihívó

Az álruhás versenyző pedig a clapf legutolsó (0.4.3.1) verziója volt az alábbi konfiggal, ill. fordítási paraméretekkel:

clapf_header_field=X-Clapf-spamicity:
clapf_spam_header_field=X-Clapf-spamicity: Yes
group_type=0
hostid=av-engine.localhost
locale=
mysqlsocket=/tmp/mysql.sock
mysqluser=clapf
mysqlpwd=*********
mysqldb=clapf
mysql_connect_timeout=2
penalize_embed_images=1
penalize_images=1
penalize_octet_stream=1
possible_spam_limit=0.8000
possible_spam_subject_prefix=[spam???]
quarantine_dir=/var/lib/clapf/quarantine
spam_overall_limit=0.92
spaminess_oblivion_limit=1.01
store_metadata=0
store_only_spam=0
training_mode=0
update_tokens=0
use_antispam=1
verbosity=1

./configure --localstatedir=/var \
--with-userdb=mysql \
--enable-rbl \
--enable-policy \
--enable-whitelist \
--with-tokendb=mysql \
--enable-static-build \
--with-store=fs \
--enable-lmtp

A clapf nem használta a clamd-t, nem frissítette a tokeneket, és minden adatot MySQL 5.4.3-beta tárolt.

TESZT1 / clapf:

08:02 perc (15:54:00 – 16:02:02) alatt végzett a ~9.6k levéllel.

TESZT2 / clapf:

07:37 percig (16:16:58 – 16:24:35) tartott, amíg elintézte a leveleket.

Az eredmények táblázatban

1. táblázat: Az MPP és a clapf levéláteresztő képessége [levél/sec]

*: processing_threads=2, logging=DEBUG
**: processing_threads=10, logging=ERROR

Következtetések/értékelés/magyarázkodás/….

Az eredmények megcáfolják azt a korábbi kijelentést, miszerint “az MPP-re váltáskor nem ritkán tapasztalunk 10-100x-os teljesítmény (áteresztő képesség) növekedést a korábbi opensource megoldásokhoz képest, a számos szűrőmotor ellenére.”

Noha a TESZT1-ben az MPP/Cloudmark kombó ~25%-ot rávert a clapf-ra, azonban relevánsabb a TESZT2 eredménye (mert a gyakorlatban sosem a spamszűrő fogadja a leveleket, hanem egy MTA), ahol a clapf egy szerényebb 10%-kal ért el nagyobb teljesítményt az MPP/Cloudmark duónál.

Tehát az előbbi állítás helyesen így hangzik: “Ha az MPP csak a Cloudmark szűrőmotort használja, akkor a teljesítménye nem marad el sokkal a clapf-tól”.

Figyelemre méltó, hogy amíg az MPP teljesítménye csökken, ha a levelet a postfix fogadja (és nem az MPP), addig a clapf esetében jobban jártunk. Utóbbinak az a magyarázata, hogy a clapf a TESZT1 esetén minden levél esetén fork()-olt egyet. Viszont a postfix, ha nő a terhelés, akkor ugyanazt az s/lmtp kapcsolatot a tartalomszűrő felé több levél esetében is fel tudja használni. Így amit veszítünk a 25/tcp-n hallgató postfix beiktatásával, azt bőven megnyerjük a clapf kevesebb fork()-olásával. Az MPP viszont nem használja a postfix lmtp connection cache-t – az MPP telepítője egészen konkrétan kikapcsolja.

A TESZT2 során egy érdekes jelenségre is felfigyeltem. A működés során a postfix fogadja a leveleket SMTP protokollon, elkezdi gyűjteni a queue-jába, majd érzés szerint tovább adja a tartalomszűrőnek. Az MPP esetében a postfix rövidebb idő átvette a leveleket az SMTP klienstől, viszont amikor elment az utolsó levél is a kliensről, azaz a postfix nem vett át több levelet a hálózatról, akkor a queue mérete ~4k levél volt. A clapf esetén tovább tartott, amíg a 9.6k levelet átvette, viszont a queue mérete nem ment 100 levél fölé, és összességében rövidebb idő alatt elért az utolsó levél is a /dev/null-ba.

A történeti hűség kedvéért meg kell jegyezni, hogy a load magasabb volt, amikor a clapf vizsgálta a leveleket, ill. amikor 10 MPP szál végezte a feldolgozást, akkor a queue mérete kb. akkora volt (n*10), mint a clapf esetében, viszont az MPP esetében is megnőtt a load.

A legfontosabb viszont még csak most jön. Az MPP tesztben mindössze egyetlen szűrőmotort használtam. Az MPP viszont használni képes még sok más szűrőmotort is, pl. Commtouch, mailshell, … és a jó öreg SpamAssassin démon változatát (spamd) is. Az admin felületen be lehet állítani, hogy milyen vírus-, ill. spamszűrő modulokat használjon az MPP, és azt is, hogy milyen sorrendben. A működés a következő. Ha az első spamszűrő modul spamként azonosítja a levelet, akkor készen vagyunk. Ha nem, akkor átadja a sorban következőnek. Ha az spamként azonosítja, akkor készen vagyunk, ha nem, akkor megyünk a következő spamszűrő motorra, és így tovább. Az antivírus szoftverek esetében hasonlóképpen jár el az MPP. Tehát az egyes motorok sorban egymás után következnek, ami a logfile-ból is látható, és nem párhuzamosan egyszerre kapják meg a levelet.

Ez azért lényeges, mert a korábbi, az MPP ‘majdnem olyan gyors, mint a clapf’, következtetésünk csak akkor igaz, ha csak gyors spamszűrő motorokat használunk, és ha a levelek zöme spam, amelyek nagy részét már az első helyen álló spamszűrő is felismeri.

Azonban a spam ill. a jó levelek aránya manapság kb. fele-fele, és ez azzal jár, hogy a levelek ~50%-a esetében az összes spamszűrőn végigmegy a levél. Ha az ingyenesen elérhető SpamAssassin is a spamszűrő motorok között van, akkor ez katasztrofális hatással lesz a teljesítményre, vö. az Általában amavis/maia/spamassassin kombinációkra gondolok open source alatt. állítással, ill. az fentebb említett ezekhez képest 10-100x teljesítmény növekedéssel.

A végső konklúzió

Az nem vitás, hogy az MPP magasan veri a SpamAssassin-t (hacsak nincs bekapcsolva az SpamAssassin az MPP-ben), de a végső konklúzió mégis az, amit Zdziarski is mond:

“they [commercial products] are certainly not more scalable than what’s freely available. Many open source projects have been deployed on systems with several hundred thousand users – there’s no justification to suggest that a commercial application could do any better”.

Azaz: a kereskedelmi spamszűrők biztosan nem skálázódnak jobban az open source termékeknél. Sok nyílt forrású termék szolgál ki több százezenyi felhasználóval rendelkező rendszereket – semmi sem támasztja alá, hogy egy kereskedelmi termék jobban teljesítene.

A SpamAssassin 3.2.0 – 3.2.5 verzióiban egy bug van, amely minden – amúgy legitim – 2010 01.01-jétől íródott levélhez egy durva a 3.6 pontot ad. Ez a spamek esetében ugyan nem probléma, de a jó levelek egy részét megharaphatja.

Ezért ajánlott azonnal upgrade-elni, vagy a local.cf fájlba az alábbi szabályt beleírni:

score FH_DATE_PAST_20XX 0