The Sky is Falling: First Y2010 bug discovered

Well for everyone with apocalyptic fears that aren't being satisfied by climate change or asteroids, we have a real life Y2010 computer bug. This Earth shattering bug affects the widely used spam filtering system, SpamAssassin. Even if you have never heard of this, there is a very good chance that your email provider uses SpamAssassin as part of its arsenal in limiting the spam that lands in your inbox.

Spammers want to have their messages to you seen, so they would like to have their messages at the top (or bottom, depending on how you view your mail) of your inbox. That is, they would like their messages to be viewed as the most recent message in your inbox. Many mail programs will sort the messages in your mailbox by (apparent) send date. Personally, I prefer to have my mail sorted by arrival time which I trust my system to know instead of using unreliable values in the sender created Date field of the message header.

But there are programs and people who do display messages by the easily faked sender date. And so for a time, spammers produced spam sending software that gave dates in the future so that these messages would listed in your inbox where you look for most recent messages. Naturally, spam filtering tools, like SpamAssassin, added rules that tried to detect message with dates that were far in the future. At the time that some of these filtering rules were put in place, 2010 was, in fact, far in the future. But the future is now, and messages with perfectly honest and legitimate Date information are being incorrectly flagged as spam.

The filtering rule in question in the default SpamAssassin distribution is in the file 72_active.cf and reads

##{ FH_DATE_PAST_20XX
header   FH_DATE_PAST_20XX      Date =~ /20[1-9][0-9]/ [if-unset: 2006]
describe FH_DATE_PAST_20XX      The date is grossly in the future.
##} FH_DATE_PAST_20XX

Solutions

Fortunately these rules are designed to be easily modified by system administrators (but not by end users). There are three option that I can see.

The first option is to tell your system to not use this rule. That is, tell your system to assign zero points for a hit against that rule. This can be done in your local configuration file, typically local.cf in the SpamAssassin configuration directory, with something like
score FH_DATE_PAST_20XX 0

The second solution is the modify or replace the rule with something that looks further into the future. That is change the regular expression in the rule from matching /20[1-9][0-9]/ to matching /20[2-9][0-9]/. This way the rule is safe for another 10 years, after which you may hope that it becomes Somebody Else's Problem.

Of course an ideal solution would be to have the system look at the current date. Unfortunately this undermines some of the effectiveness of SpamAssassin which is to have lots of rules that are quick and easy to check. Of the top of my head, I can see a number of approaches to this, but I haven't yet joined the discussion among the SpamAssassin community. My recommendation for email administrators is to use the first fix (disable the rule) until we work out a robust solution.

Ordinary users

If you find that a bunch of non-spam is suddenly being treated as spam by your email system, please report the problem to your email provider immediately with a link to either this posting or some of the ones I've linked to.

Credit

Thanks to Paul Haldane of Information Systems and Services, Newcastle University (England) who posted on a mailing list I read a link and summery of Mike Cardwell's post on this issue.