Was vroeger postbank.nl populair om bij gebruikers naar gegevens te hengelen, maar sinds de definitieve uitfasering in 2010 van het merk Postbank is de plaats ingenomen door ING. Heel toepasselijk waar alle klanten en diensten in zijn opgegaan en waar vroeger alleen postbank.nl een SPF-record in DNS had is dat nu ook zo voor oa ing.nl. En gelukkig worden veel berichten automatisch al als spam-gemarkeerd, maar niet alles helaas.
Om de laatste paar phishing e-mails voor ING als spam te laten markeren zijn voorlopig wat custom regels nodig voor SpamAssassin. Gelukkig is dat redelijk goed te doen met behulp van SPF en na al die jaren wordt toch langzaam duidelijk waar SPF en DKIM goed voor zijn. Wat wel opvallend is dat andere Nederlandse banken geen SPF-records publiceren in DNS zover te achter halen is. Dit terwijl de belastingdienst dit wel doet heel toepasselijk.
Na meer dan een jaar na het op de automatische piloot zetten van een bayesian filtering oplossing voor alle inkomende e-mail begint het langzaam aan tijd te worden om de balans op te maken. Dus eerst even wat grafiekjes en eerste laat de hoeveelheid tokens in de database.
De tweede grafiek laat het aantal geleerde berichten zien en dit zijn zowel berichten die via spamtraps en hamtraps binnen zijn gekomen.
Hier komt ook gelijk het opvallende punt. Het aantal berichten blijft gelijkmatig oplopen op de kleine sprong in april na, want toen waren de spamtraps als test niet voorzien van DNSBL-filtering. Voorlopig lijkt hiermee opzet redelijk stabiel te zijn en met een plugin voor Roundcube kunnen gebruikers nu ook fouten netjes zelf melden en worden die verwerkt in de database.
Over de effectiviteit zijn op dit moment geen harde cijfers en de vraag is dan ook hoe die te meten zijn. Dus wat is er nog te verbeteren aan de opstelling? Op dit moment worden performance gegevens over hoeveelheid berichten die worden geweigerd of aangenomen nog niet verwerkt, maar ook niet hoeveel berichten als spam worden gemarkeerd en wat de gemiddelde doorloop tijd is om een bericht te verwerken. Binnenkort dus maar eens een blik werpen op een aantal logfiles om te kijken of dit mogelijk is om zo beter inzicht te krijgen.
Al geruime tijd gebruik ik een Bayesian-filter om e-mail te beoordelen of het ham of spam is, maar wat is de stand nu na enkele maanden? Gelukkig loopt rrdtool mee te bepalen wat de vullingsgraad van de database is. Op de maandgrafiek lijkt niet echt mis en dat terwijl het langzaam lijkt af te nemen.
Als we naar de jaargrafiek kijken dan ziet het er iets heftiger uit, maar na de eerste dip in mei is de database aangepast om nog maar 500.000 tokens te bewaren maximaal. Dit omdat het verschil tussen de top en de bodem te groot was. Deze nieuwe top is dan ook zeker te zien bij de twee pieken erna, maar hierna lijkt de database zoveel spreiding in tokens van verschillende data te hebben dat er eens stabiele vullingsgraad komt.
Als we naar de huidige afname kijken dan zou die nooit onder de 375.000 moeten komen, want dat is de magische grens van 75 procent van 500.000 die in de database zou moeten blijven zitten bij een opschoning. Mocht dat wel gebeuren dan komen er niet snel genoeg verse tokens bij, maar dat zal duidelijk moeten worden in de komende maanden. Voorlopig lijkt de stroom van spam en ham berichten stabiel genoeg om dit voor elkaar te krijgen, maar het is even afwachten.
Soms moet je een databaseschema verplaatsen van de ene machine naar de andere. In veel gevallen is een export en import de meest slimme oplossingen, maar waar zou je het de applicatie niet laten doen. Zo ook met SpamAssassin waarbij alle voorzieningen in de applicatie zitten en wat wel zo veilig is als je dit op een draaiende omgeving wilt doen.
De eerste stap is om een data te exporteren en dan te verplaatsen naar de juiste machine:
$ sa-learn --backup > sa-learn.dump
Op de nieuwe machine is het lege schema al geladen en kan een import worden gedaan:
$ sa-learn --restore sa-learn.dump
$ sa-learn --force-expire
Als laatste stap wordt ook door SpamAssassin gekeken of en wanneer er een expire moet plaats vinden. Dit zorgt ervoor dat als je auto-expire aan hebt staan je database niet bij de eerste e-mail al direct wordt gecontroleerd. De kans op vertraging wordt hiermee beperkt en het is duidelijk dat SpamAssassin met de nieuwe dataset goed kan werken.
Nu SpamAssassin op automatische piloot staat en op versie 3.3 zit werd het tijd voor grafiekjes. Zeker om het gedrag te kunnen monitoren en een van de eerste onderdelen is was het Bayesian-filter. Met wat Perl-code en rrdtool kom je al redelijk vlot tot grafiekjes en hoef je alleen nog maar tijd te hebben.
Gelukkig hebben de grafiekjes voldoende tijd gehad, want recentelijk besloot de software dat de maximale vulgraad was bereikt en werd er opgeschoond, maar of dit nu geheel wenselijk was. Met bayes_expiry_max_db_size verhoogt naar 1.000.000 tokens zou de database even vooruit moeten en de performance bleek ook goed te zijn, maar waarom dan die grote afname in tokens? Zeker omdat het doel is om 75% van bayes_expiry_max_db_size te behouden of minimaal 100.000 tokens.
Een ander onderdeel van de expire is de leeftijd van de tokens en hoe vaak er een daadwerkelijke expire wordt uitgevoerd. Hieruit vallen twee dingen te herleiden. De daadwerkelijke opruimactie op de database wordt niet vaak genoeg getriggerd en hiervoor moet of de omvang van de database omlaag of moeten we sneller nieuwe tokens de database in. Een tweede wat te herleiden is dat er wel genoeg nieuwe tokens de database inkomen om oudere tokens op te ruimen.
Wat de oplossing gaat zijn ben ik nog niet geheel uit, maar wat wel interessant is om te zien of er een relatie is tussen de vulgraad van de database en de scores die worden uitgedeeld. Een ander feit is of de extra spam van week 10 invloed heeft gehad, maar dit zal moeten blijken met de volgende iteratie. Het is dus nog even wachten of dit eenmalig was of niet, want voorlopig blijkt het Bayesian-filter wel goed te werken.
Recent Comments