Like many systems, I use SpamAssassin to filter incoming mail and try to guess whether it is spam or not. If it's plausibly spam it goes into the spam folder, and it it looks very likely to be spam then it just gets rejected at SMTP time. Mostly this is fairly effective at dealing with spam.

However the SpamAssassin rules turn out to have a Y2K10 bug, with an assumption that dates should not include 201x or higher, as noted at LWN and some blogs. It adds quite a high "could be spam" score (about half of the "plausibly spam" score all by itself) so has apparently been causing issues with mail that triggers some of the other checks. It seems the issue has been reported since late 2008, and in the middle of last year there was a subversion commit to bump the rule up to 202x or higher. Unfortunately it appears that change didn't get pushed out enough, either via the SpamAssassin rule update channels, or via various distributions (Debian bug #563245, which shows a pending upload to unstable and that they're working on a stable update; see also SpamAssassin forum thread started by one of the blog posters.)

The workaround is to neutralise the rule by adding:

# Neutralise check for non 200x dates, now that we are in 2010
# http://lwn.net/Articles/368396/
score FH_DATE_PAST_20XX 0.0

to /etc/spamassassin/local.cf and restarting SpamAssassin if necessary. (A slightly better fix would be to rewrite the rule to check 202x and higher, as was done in the subversion commit, but that's less easily done in a localised fashion.)

I've just done that on the mail servers that I run. Which means that there was about 35 hours where it was falsely tripping (the joys of being the first country in the world...). I didn't get a lot of mail during that time -- which is probably mostly due to it being a quite time of year, but I guess some mail may have been inadvertently rejected too. Time to clear out the "plausibly spam" folder just in case.

Hopefully in the next 1-5 years someone will come up with a better way of testing "date too far in the future" that is relatively to the current system clock, rather than a hard coded date that will break.

ETA, 2010-01-02: apparently the updated version of the rule is now available via sa-update although it's taking a while to get a non-cached view of the relevant file.

See also jwz's quote about regexes: "now you have two problems".

ETA, 2010-01-07: SpamAssassin Maintainer's blog post on issue and LWN Writeup (restricted to subscribers until 2010-01-14).