LWN: Comments on "Happy New Year from SpamAssassin"

Happy New Year from SpamAssassin

ajross — 2010-01-05T17:17:04+00:00

Right. So the fix just introduces a 2020 bug. Sigh...

Happy New Year from SpamAssassin

drag — 2010-01-03T10:34:53+00:00

I think that the point was that some software sucks so badly that it's been
broken for 10 years and has not been fixed yet!

Happy New Year from SpamAssassin

cventers — 2010-01-03T09:22:47+00:00

> BTW, to all Perl programmers out there: Happy new year, 19110!

Ah, but you see, any Perl program that erroneously string-concatenates the
year would have already been rendered broken at the turn of the
millennium (19100).

Or perhaps my sarcasm detector is broken :p

Happy New Year from SpamAssassin

JoeBuck — 2010-01-03T05:33:17+00:00

Exactly. Y2K wasn't a problem because billions were spent fixing all of the software systems before it happened. Without those fixes (and many of the bugs that were fixed would have been catastrophic), the software simply wouldn't have worked, and we would have had a huge mess.

Also, if it weren't for all of this investment, the dot-com bubble would have exploded a couple of years earlier. Thanks to all that dot-com spending, we didn't see a tech collapse until spring of 2000.

Happy New Year from SpamAssassin

rahvin — 2010-01-03T04:14:42+00:00

It could be argued that the only reason Y2K didn't cause a computer metldown is so many people ran around screaming that it was going to cause a meltdown along with all the people who tried to capitalize on those people by selling guns, food, generators and other "end of civilization" products. It's interesting to consider that had there not been so much publicity and the end of the world crowd not gotten involved that the y2k bug would have resulted in serious problems although certainly not the end of the world.

Happy New Year from SpamAssassin

ejr — 2010-01-03T03:07:52+00:00

Indeed, thank you! This explains recent false positives at my ISP, and now I can point them at the reason directly.

Happy New Year from SpamAssassin

jordanb — 2010-01-03T02:05:09+00:00

Considering that we ended up having very few problems with Y2K, it seems like the 1980s assessment was correct. The Y2K problem was successfully dealt with in the 1990s and caused no major disruptions.

Although it did show just how crappy many perl programs are.

BTW, to all Perl programmers out there: Happy new year, 19110!

Happy New Year from SpamAssassin

Cyberax — 2010-01-03T01:47:51+00:00

Ha! That's what they though about Y2K in 80-s.

Happy New Year from SpamAssassin

jengelh — 2010-01-02T04:59:51+00:00

That is why I use Sort By Arrival in the re-alpine MUA. Well, I use it not because of the spammers, but because of course people from all timezones can send me mail, and I rather prefer that new items get tacked onto the inbox list at the end rather than somewhere in the middle (a little prone to oversee it when you have lots).

Happy New Year from SpamAssassin

frazier — 2010-01-02T04:24:00+00:00

Although I'm not a Sysadmin, this is why part of why I subscribe to LWN. Thanks for making these sorts of things more known.

Happy New Year from SpamAssassin

dom — 2010-01-01T23:10:34+00:00

I think everyone agrees :) The fix pushed out today was a minimal fix for the immediate problem; they have another decade to push out a proper one :)

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6271

Happy New Year from SpamAssassin

csamuel — 2010-01-01T22:57:58+00:00

Seems to be available via sa-update now:

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

Happy New Year from SpamAssassin

iabervon — 2010-01-01T19:47:36+00:00

That depends on what relative dates are relative to. Generally the top "Received" date is trustworthy, since it's provided by the user's own mail server, and it's what ought to be close to the "Date" date. It doesn't matter when the mail is scanned, of course.

Happy New Year from SpamAssassin

rbuchmann — 2010-01-01T19:31:50+00:00

Some spammers try to have their spam always on top in the mailbox by using dates in the future.

Happy New Year from SpamAssassin

dark — 2010-01-01T18:57:26+00:00

The problem with such time-dependent rules is that it is hard to measure their effectiveness. Their evaluation of existing archives (of preclassified mail) is going to change with time, usually for the worse.

And it does need to be measured. There's no obvious reason why spam would be more likely to have bad date headers than ham. I've been using Debian long enough to remember when the alpha port had system clock issues; I have a lot of ham from 2020 in my mail folders :)

Happy New Year from SpamAssassin

PO8 — 2010-01-01T18:49:22+00:00

I would argue that the right fix for this problem is to enhance the pattern language so that it can match relative dates. Then you could have a rule that flags messages that are more than a year in the past or a year in the future, without worrying that the rule will go stale. It looks like this would be doable with the eval: construct in spamassassin, but I haven't the energy to try it right now, so I did some dumb kludge that will fail in 2050. :-)

Happy New Year from SpamAssassin

joey — 2010-01-01T17:55:03+00:00

But no release, and sa-update even seems to be pulling down the old broken
rule rather than a fixed one.

Happy New Year from SpamAssassin

mbanck — 2010-01-01T17:46:31+00:00

This has hit two major german ISPs already. I wonder whether this Y2K10 bug will make more damage on GNU/Linux systems (or to users who get served by them) than the Y2K issues.

Happy New Year from SpamAssassin

seveas — 2010-01-01T17:17:19+00:00

The bugreport as filed in 2010: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269

Happy New Year from SpamAssassin

edwill — 2010-01-01T17:04:15+00:00

fuhchee - This issue was first identified over a year ago, and a fix constructed about half a year ago. See "SpamAssassin 2010 Bug" for information on how it went down.

Happy New Year from SpamAssassin

fuhchee — 2010-01-01T16:55:30+00:00

Love the typo. FH_*_20XX should have been named FH_*_200X,
in which case the Y2010 bug would have been obvious earlier.