New Zealand Linux

From : https://secure.grepular.com/blog/index.php/2010/01/01/spamassassin-2010-bug/

I use SpamAssassin to filter the spam out of my incoming email. Last night I noticed that a legitimate email had a particularly high spam score. On further investigation I found that a rule named FH_DATE_PAST_20XX was triggering:

* 3.2 FH_DATE_PAST_20XX The date is grossly in the future

I checked the Date header of the email and it looked totally fine to me. It had just changed from the year 2009 to the year 2010. Could that be a coincidence? A quick look in /usr/share/spamassassin/72_active.cf turned up the rule:

header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006]

Oops. That regex matches on any year between 2010 and 2099. I googled for the rule and came across this:

http://wiki.apache.org/spamassassin/Rules/FH_DATE_PAST_20XX

In the comments it mentioned the problem which I found: “Note: the current rule in 3.2 will start matching legitimate dates from 2010-01-01. See issue #5852.” Looking at issue 5852, the problem was first identified on 2008-Nov-05 and was “fixed” in CVS on 2009-Jun-30. I’m using the standard stable Debian package which doesn’t contain this fix yet so I had to stick the following in my local.cf file to apply a score of 0 to it:

score FH_DATE_PAST_20XX 0.0

I think a lot of systems will be experiencing false positives on their ham because of this at the moment. It is a particularly high scoring rule considering that the default threshold is 5.0.

As I understand it, rules aren’t distributed with SpamAssassin as of the next version (3.3) so hopefully problems like this wont happen in future. The “fix” which was supplied for this problem five months ago was to update the regex so it matches 2020-2099 instead.

You can read the thread I started about this issue on the SpamAssassin users list here. It’s the one started at “Fri, 01 Jan 2010 00:57:37 GMT” with the subject line “FH_DATE_PAST_20XX”

We had a customer email in after updating to Jaunty recently. They said the following

Hi guys, I upgraded my VPS a little while back to Ubuntu Jaunty (because I was several versions out of date and the apt repositories had gone away.) I never actually rebooted the machine afterwards though because it wasn’t a good time to potentially interrupt email. I finally got around to doing that, and the VPS won’t come back onto the network. Logging in over the console, it looks like there are no network interfaces configured. A few other things don’t feel right (eg, dmesg tells me that the current tls library or perhaps libc isn’t xen-friendly.) but mostly everything *looks* like it’s ok but doesn’t have a network interface.. services that want to resolve hostnames didn’t start up, etc. Trying to dig into the problem, it looks like there are no modules installed for the kernel, but this is where my expertise runs out.. I don’t know enough about Xen to know if everything was just precompiled into the kernel, or if I blew away my kernel modules during upgrade.

I was curious so logged in via the console .

I ran ifup and got the following errors

root@charon ~ # ifup eth0
ifup: failed to open statefile /var/run/network/ifstate: No such file or directory

so i checked and /var/run/network did not exist. I fixed this

root@charon network # mkdir /var/run/network/
root@charon network # ifup eth0
* if-up.d/mountnfs[eth0]: waiting for interface lo before doing NFS mounts
root@charon network # ifconfig
eth0 Link encap:Ethernet HWaddr aa:00:d6:a1:5e:e4
inet addr:72.33.222.111 Bcast:72.29.222.255 Mask:255.255.255.128
inet6 addr: fe80::a800:d6ff:fea1:5ee4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:56 errors:0 dropped:0 overruns:0 frame:0
TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5447 (5.4 KB) TX bytes:1074 (1.0 KB)

The file system on Ubuntu in /var/run is a virtual filesystem on Ubuntu, I googled and came across this post here https://bugs.launchpad.net/ubuntu/+bug/367171 which clearly logs the bug, and a fix.

The fix i applied which was adding the following into /etc/init.d/networking

[ -d /var/run/network ] || mkdir -p /var/run/network

This checks if the dir exists and creates it if it doesn’t.

This does fix the problem but its a bit of a hack. I noticed a link later on down the post which took me to https://bugs.launchpad.net/ubuntu/+bug/377432 . This link had a bit more technical information. They said look for the following files and remove them.

/etc/udev/rules.d/85-ifupdown.rules

/lib/udev/rules.d/85-ifupdown.rules

Virtualmin is a fantastic piece of software which allows the not-so-techy run a full hosting server nicely, however I’ve come accross a bug that seems to happen mostly in Centos 5 when trying to upgrade and you happened to have used the rpm to install

This is how you do it.

Login to Virtualmin. Click on System Settings . Click on “Upgrade to Virtualmin Pro” and enter your serial number etc.

Now if you get the following error

Failed to upgrade to Virtualmin Pro : No Virtualmin GPL repository was found in /etc/yum.repos.d/virtualmin.repo

Put this into /etc/yum.repos.d/virtualmin.repo

[virtualmin]
name=Red Hat Enterprise $releasever - $basearch - Virtualmin
baseurl=http://software.virtualmin.com/gpl/rhel/$releasever/$basearch/
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-virtualmin
gpgcheck=1

[virtualmin-universal]
name=Virtualmin Distribution Neutral
baseurl=http://software.virtualmin.com/gpl/universal/
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-virtualmin
gpgcheck=1

Then try again. It should all go well now for you and be able to update.