spamdrop, avagy egy fejlesztő kalandjai
Tovább pofozgattam a spamszűrőmet. A clapf-ban kikapcsoltam az antispam modult, így most csak vírusellenőrzést végez. A spam ellen pedig a spamdrop nevű komponens véd, amely egy LDA (pl. maildrop) segítségével használható. Ennek az az előnye az SMTP szinten működő clapf ellenében, hogy sokkal egyszerűbb azt megoldani, hogy minden felhasználó a saját token adatbázisát használja, amely a uid=0 globális adatbázissal való on-the-fly összegyúrással áll elő.
A maildrop konfigom (~/.mailfilter) így néz ki (leegyszerűsítve):
xfilter "/usr/local/bin/spamdrop -c /home/sj/.clapf.conf -p" if(/csapda@email.cim/:h) { to "|/usr/local/bin/black.pl" } if(/^X-Clapf-spamicity: Yes/:h) { to "mail/junk" } to "Mailbox"
Az 1. sor hatására a maildrop átzavarja a levelet a spamdrop programon, amely megnézi, hogy vajon spam-e a levél vagy sem, majd a levél fejlécébe írja a saját dolgait. A 2. blokk a csapda email címet definiálja, minden erre a címre érkező levél automatikusan a kukába kerül. A következő rész arra szolgál, hogy a spamként megjelölt levelek a junk folderbe kerüljenek. Ha pedig egy levél ezt az akadályt is vette, akkor a postafiókomban landolhat.
Arra is lehetőség van, hogy ne kelljen minden egyes felhasználó esetén egy .mailfilter nevű fájlt írogatni, ebben az esetben a /etc/maildroprc használható az alábbi módon:
if($LOGNAME =~ /^spam$/) { `/usr/local/bin/spam-fwd-train` exit } if($LOGNAME =~ /^ham$/) { `/usr/local/bin/ham-fwd-train` exit } else { xfilter "/usr/local/bin/spamdrop -p" to "Mailbox" }
Az
első 2 blokk a spam ill. a ham levelekkel való tanítást állítja be. Ha a spam+felhasznalo@aaaa.hu címre továbbít egy levelet mellékletként a felhasználó, akkor valójában a token adatbázist tanította. A 3. rész ugyanaz, mint az előbb: a levelet átküldjük a spamdrop-on, majd irány a postaláda (Mailbox). A spam és a hasznos levelek szétválogatást pedig a felhasználó oldja meg (nyilván automatikusan), amikor letölti a leveleit POP3, IMAP4 vagy más módon.
Ja igen, a kaland meg az izgalom ott volt, amikor átálltam a spamdrop-ra. tail -f /var/log/maillog-gal, figyeltem, hogy mikor jön levél. Várok, várok, majd eszembe jut, hogy a spamdrop-ot nem másoltam a /usr/local/bin alá. Gyorsan su, mount, cp, megint mount, és nézem a naplót, levél még sehol. Aztán az is eszembe jut, hogy a konfigot nem másoltam a helyére. Gyorsan cp, vi, majd újra log nézés. Szerencsére semmi nem jött ez idő alatt.
Aztán jött egy spammer a csapda email címre, de hibátlanul felismerte a spamszűrő.
spamdrop[399]: written temporary file: b2be73a643afe47ddde823a415140a
spamdrop[399]: b2be73a643afe47ddde823a415140a: parsing
spamdrop[399]: b2be73a643afe47ddde823a415140a: TUM training 51 tokens for uid: 1000 11 [ms]
Qcache[2808]: cache hit rate: (403 of 500) 80.60% in 81187 [us]
spamdrop[399]: update metadata result: 1
spamdrop[399]: b2be73a643afe47ddde823a415140a: 1.0000 5706 in 102 [ms]
A spamdrop az üzenethez rendelt egy azonosítót, 51 tokennel tanította az adatbázist. Az egész a (még) experimentál Query cache-n keresztül történt. A levelet betolta MySQL adatbázisba, majd a néhány statisztikai adat: a levél 100% spam, 5,7 kB és ~100 ms alatt végzett az egésszel.
A spam nem statikus, nem marad ugyanaz mindig, hanem lassan változik, evolválódik. A csapda email cím segítségével azonban úgy képes a szűrő megtanulni a legújabb spam trendeket, hogy nekem nem kell azokkal találkoznom egy fals negatív élményben – hogy aztán kézzel tanítani kelljen a szűrőt, hanem a spammerek vannak olyan szívesek, és bemutatják a legújabb trükkjeiket, hogy a szűrő megtanulja.
Leave a Reply