SpamAssassin to blacklist and unblacklist

SpamAssassin has a feature to blacklist and unblacklist certain e-mailaddressen. But recently I noticed something interesting that may need some more investigation. I have all addresses for domain example.org blacklisted, but also unblacklisted certain functional addresses as is shown in the example below.

blacklist_from          *@example.org
unblacklist_from        abuse@*
unblacklist_from        hostmaster@*
unblacklist_from        postmaster@*
unblacklist_from        security@*
unblacklist_from        webmaster@*

Now I expected that webmaster@example.org was going to be unblacklisted, meaning the mail would have both a spamscore of both +100 and -100 making it effective 0 again. This modification resulted in a spamscore of +100 and makes me worry that unblacklisting will demand that the domain part needs to be specified instead of having a wildcard. This will require some more testing in the near future, but for now it may affect other installations.

SpamAssassin regels voor ING phishing

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.

Bayesian database na ruim een jaar

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.

Bayesian database na enkele maanden

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.

SpamAssassin verplaatsen

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.