FS#17731 - [spamassassin] Y2K10 Rule Bug
Attached to Project:
Arch Linux
Opened by Andreas Wagner (awagner) - Thursday, 07 January 2010, 09:02 GMT
Last edited by Paul Mattal (paul) - Saturday, 06 March 2010, 22:58 GMT
Opened by Andreas Wagner (awagner) - Thursday, 07 January 2010, 09:02 GMT
Last edited by Paul Mattal (paul) - Saturday, 06 March 2010, 22:58 GMT
|
Details
Description:
[Quote From the spamassassin homepage (http://spamassassin.apache.org/):] Versions of the FH_DATE_PAST_20XX rule released with versions of Apache SpamAssassin 3.2.0 thru 3.2.5 will trigger on most mail with a Date header that includes the year 2010 or later. The rule will add a score of up to 3.6 towards the spam classification of all email. You should take corrective action immediately; there are two easy ways to correct the problem: If your system is configured to use sa-update run sa-update now. An update is available that will correct the rule. No further action is necessary (other than restarting spamd or any service that uses SpamAssassin directly). Add "score FH_DATE_PAST_20XX 0" without the quotes to the end of your local.cf file to disable the rule.[/quote] The scores go from 2 to 3.6, which is not negligible. Also, it duplicates DATE_IN_FUTURE_96_XX, which triggers if "Date:" is more than 96 hours ahead of "Received:". It would be best to replace the regex in /usr/share/spamassassin/72_active.cf, line 543 either with "Date =~ /20[2-9][0-9]/ [if-unset: 2006]" or with "eval:check_for_shifted_date('8760', 'undef')", if you want to keep combining both rules or to drop FH_DATE_PAST_20XX altogether. The approach taken with the official ruleset (via sa-update) is to match >2020... Additional info: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269 and https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5852 * package version(s) 3.2.5-2 * config and/or log files etc. /usr/share/spamassassin/72_active.cf at ca. line 542, /usr/share/spamassassin/50_scores.cf at line 168 |
This task depends upon
Closed by Paul Mattal (paul)
Saturday, 06 March 2010, 22:58 GMT
Reason for closing: Fixed
Additional comments about closing: Implemented in 3.3.0-2 in extra for both arches.
Saturday, 06 March 2010, 22:58 GMT
Reason for closing: Fixed
Additional comments about closing: Implemented in 3.3.0-2 in extra for both arches.
What do folks think -- is it worth hacking this fix in ourselves? I feel like if spamassassin isn't issuing a new version, the answer is no, but gobs of first-time Spamassassin installers are tripping over this, I'd like to hear from them, and we'll do something.
Get your complaints in by 1/15.
- if the user ever used sa-update, there's outdated updated rules that override the fixed package, post_upgrade should run sa-update in that case
- if the user ever used sa-compile, the post_upgrade should also run sa-compile
Both are detectable and should be performed after each update of spamassassin actually, not just with these bugfixed default rules.
As for people not running sa-update: they'll probably have other issues also. This issue is just one of them, though it hurts functionality a lot by flagging on a way too low score.
I'm trying to decide whether upgrading the rules behind the user's back is too automatic-y.
This occurs with other packages, like clamav for example, and I don't believe we generally automate this fully, rather we notice the user so he's aware and can take what action he wants.
For example, a user may want to stay on a particular version of the rules, even though he may have upgraded the code or uninstalled/reinstalled spamassassin.
So I am not planning to implement automatic sa-update and sa-compile detection for 3.3.0-1, but we may continue the discussion here, if you like. I have already written the code, and it is straightforward, but it doesn't seem like the Arch way to do it.
- /etc/cron.daily/spamassassin
- /etc/default/spamassassin
If CRON is set to something else than 0 in /etc/default/spamassassin, the cronjob executes. The cronjob calculates a delay to avoid spanking update channels at the same time and runs sa-update. After retrieving updates, it detects if the user ever used sa-compile, and if so, it will compile.
So far, there's nothing special here. It's still the user who enables the cronjob, and it's still the user who compiles his rules for the first time. In case of package upgrades, sa-compile is also run, but AFAIK there's no call to sa-update.
As of version 3.3.0, rules are distributed standalone. The reasoning behind this is that you want newer rulesets far more often than a new spamassassin, and it's no use installing a spamfilter with 2 year old rulesets.
This approach sounds good, and I'll plan to do something very much like it in the next update.