exim + spamassassin subject rewriting on symbiosis

One customer of mine has an Bytemark Symbiosis based exim mailserver which uses SpamAssassin. It works pretty well – however the :

rewrite_header Subject *****SPAM*****

directive in spamassassin (/etc/spamassassin/local.cf) seemed to be being ignored – and the only effect of the mail being classified as spam is/was a couple of additional headers added (X-Spam-Status: spam). For the customer in question this wasn’t of much use – as they’re reasonably non-technical and probably couldn’t create a client side mail filter. And they also thought the spamfiltering wasn’t working.

I found adding the following to /etc/exim4/system_filter results in the subject being appropriately modified :

if $h_X-Spam-Status: contains "spam"
then
    headers add "Old-Subject: $h_subject"
    headers remove "Subject"
    headers add "Subject: *** SPAM *** $h_old-subject"
    headers remove "Old-Subject"
endif

And if you want to tag virus-ey emails … add this in as well :

# X-Anti-Virus: infected
if $h_X-Anti-Virus: contains "infected"
then
    headers add "Old-Subject: $h_subject"
    headers remove "Subject"
    headers add "Subject: *** VIRUS *** $h_old-subject"
    headers remove "Old-Subject"
endif

Seeing as how that took about 2 hours to figure out – hopefully this will be of use to others.

I started looking at SpamAssassin and wondering why IT wasn’t doing it… I still don’t know why – but assume it’s an Exim ‘feature’.

netstat –tcp -lp output not showing a process id

I often use ‘netstat –tcp -lpn’ to display a list of open ports on a server – so i can check things aren’t listening where they shouldn’t be (e.g. MySQL accepting connections from the world) and so on. Obviously I firewall boxes; but I like to have a reasonable default incase the firewall decides to flush itself randomly or whatever.

Anyway, I ran ‘netstat –tcp -lpn’ and saw something like the following :

tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      3355/mysqld     
tcp        0      0 0.0.0.0:54283           0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      1940/portmap

Now ‘mysqld’ looks OK – and portmap does (well, I need it on this box). But what on earth was listening on port 54283, and why is there no process name/pid attached to it?

After lots of rummaging, and paranoia where I thought perhaps the box had been rooted, I discovered it was from an NFS mount (which explains the lack of a pid, as it’s kernel based).

lsof -i tcp:54283

Didn’t help either. Unmounting the NFS filesystem did identify the problem – and the entry went away.

Checking varnish configuration syntax

If you’ve updated your varnish server’s configuration, there doesn’t seem to be an equivalent of ‘apachectl configtest’ for it, but you can do :

varnishd -C -f /etc/varnish/default.vcl

If everything is correct, varnish will then dump out the generated configuration. Otherwise you’ll get an error message pointing you to a specific line number.

yum changelog (Want to know what you’re about to upgrade on CentOS/RHEL?)

Want to see what changes you’re about to apply when doing a ‘yum update’ ? Similar-ish to how ‘apt-listchanges’ works…

On CentOS 5.6, try :

  • yum install yum-changelog python-dateutil

Note, python-dateutil seems to be an unmarked dependency – i.e. you get an error message like : “Dateutil module not available, so can’t parse dates” when trying to run ‘yum changelog all updates’.

Note, /etc/yum/pluginconf.d/changelog.conf (but this didn’t seem to need changing to me).

Now you can do :

  • yum changelog all updates
  • yum changelog all mysql-server (or whatever package you’re interested in).

 

Useful settings for history recording in bash (/etc/profile or ~/.bashrc)

shopt -s histappend
shopt -s checkwinsize
export HISTCONTROL=ignoredps:ignorespace
export HISTTIMEFORMAT='%Y-%m-%d %H:%M:%S  '
export EDITOR=vim

histappend: don’t overwrite .bash_history files on each logout; then when someone logs into the server, and messes something up, there’s a vague chance you’ll see what they did. Your history file will obviously grow to be quite big – but suppression of duplicates helps. Mine’s only 900kb after 7 months.

checkwinsize: check the window size after each command, might help some braindead programs cope with you resizing their windows, I guess.

HISTCONTROL: suppress duplicates, ignore spaces

HISTTIMEFORMAT: record a timestamp against each history entry; run ‘history’ to see an example of it’s output…

EDITOR: why would you not use vim?