Information Technology

I want to keep track of the spam scores that show up in my /var/log/mail.log on my Debian Etch machine. My idea was to run a shell script grep’ing the wanted info out of the mail.log right before that file is to be rotated. logrotate provides configuration options for how and when log files should be rotated. This includes a possibility to run a script right before and after the rotation is done. So, I created a configuration /etc/logrotate.d/mail like

sysklogd is Debian’s package containing syslogd and klogd. The syslog itself already cares for rotating the basic log files, and this includes /var/log/mail.{log,info,warn,err}. sysklogd contains the cron-jobs /etc/cron.daily/sysklogd and /etc/cron.weekly/sysklogd, both of which contain logic for rotating the system’s log files. To obtain the list of the log files, the command syslogd-listfiles is issued in both of the scripts—the weekly script uses the option --weekly. When I issue syslogd-listfiles, I only get /var/log/syslog as answer, whereas with --weekly I get:

So I have to use the -s switch to exclude mail.log and mail.info such that logrotate can take care of them. As I also have a separate config for /var/log/messages in /etc/logrotate.d/messages, I modified the call of syslogd-listfiles --weekly in /etc/cron.weekly/sysklogd to

Recently, on the SpamAssassin mailing list, someone was reporting that a newbie spammer seemed to have forgotten to replace variables with values. Someone else noted that the construction

might lead to weird and impossible IP addresses. Now, I really found that in my spam quarantine:

SpamAssassin is doing a good job on my site. It successfully protects my users’ mailboxes for some years now. However, during the last months spamming has increased significantly around the world. Luckily, only few spam is getting through, but a handful of spam mails a day is already too much for the pampered user. So I searched for current enhancements. So far I had only used Debian Etch’s standard spamassassin and amavisd-new packages.

I consider greylisting as a solution for days where I see no other choice. I can imagine my users being confused because they receive an expected mail not immediately. So I installed three enhancements for SpamAssassin:

• FuzzyOCR
• A botnet detector
• Rules against stock spam

The first one is available from Debian ‘unstable’, whereas the other two simply go into /etc/spamassassin. The SpamAssassin Rules Emporium provides a lot of other rules I haven’t tried yet.

The rules are already having some hits adding a lot to the spam score of messages. Here are examples from within 24 hours:

FUZZY_OCR=7.000 (twice), FUZZY_OCR=8.000, FUZZY_OCR=9.000 (5 times), FUZZY_OCR=10.000 (twice), BOTNET_OCNNEJP=5 (3 times), BOTNET_SHAWCABLE=5, SARE_STOCK_MSG_ID2=2.22 (5 times), SARE_GIF_ATTACH=0.75 (16 times), SARE_GIF_STOX=1.66 (6 times), SARE_PROLOSTOCK_SYM3=1.66 (8 times), SARE_MLH_Stock1=1.66 (12 times), SARE_RMML_Stock26=1.12, SARE_MLB_Stock1=1.66 (3 times), SARE_MLB_Stock3=0.794 (7 times), SARE_LWOILCO=0.388 (twice), SARE_LWSYMFMT=1.66, SARE_PROLOSTOCK_SYM4=2.66, SARE_PROLOSTOCK_SYM1=1.66, SARE_LWSHORTT=0.794.

So, it was worth the no effort. For those who wonder why there are only few hits, Postfix is already doing most of the job by rejecting bad connections.