Apache SpamAssassin Y2K10 Rule Bug - Update Your Rules Now!
I've posted the following note on the Apache SpamAssassin website [1] about an issue with a rule that may cause wanted email to be classified as spam by SpamAssassin. If you're running SpamAssassin 3.2.x you are encouraged to update you rules (updates were released on sa-update around 1900 UTC Jan 1, 2010). Y2K10 Rule Bug - Update Your Rules Now! 2010-01-01: Versions of the FH_DATE_PAST_20XX [2] 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: 1) If your system is configured to use sa-update [3] 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). 2) Add "score FH_DATE_PAST_20XX 0" without the quotes to the end of your local.cf file to disable the rule. If you require help updating your rules to correct this issue you are encouraged to ask for assistance on the Apache SpamAssassin Users' list. Users' mailing list info is here. [4] On behalf of the Apache SpamAssassin project I apologize for this error and the grief it may have caused you. Regards, Daryl C. W. O'Shea VP, Apache SpamAssassin [1] http://spamassassin.apache.org/ [2] http://wiki.apache.org/spamassassin/Rules/FH_DATE_PAST_20XX [3] http://wiki.apache.org/spamassassin/RuleUpdates [4] http://wiki.apache.org/spamassassin/MailingLists
RE: [sa] Re: FH_DATE_PAST_20XX
> > The easiest way to see what is being changed since your last > sa-update is to first sa-update /tmp and diff. The change is > trivial but significant... > snip > > > -jeff > thanks Jeff, umm what we saw was that the first FH_DATE_PAST_20XX update rule push wasnt actually corrected... the second push appears to have fixed that... maybe we are in twilight zone? - rh
Re: Date in the Future
On Fri, 01 Jan 2010 19:08:22 -0500 Jeff Koch wrote: > > Well, now that it's 2010 I'm getting a lot of hits on > > FH_DATE_PAST_20XX The date is grossly in the future > > for emails that have been sent this year and are otherwise OK. > > What's up with that? Our SA is fairly current and we run sa-update > once a week. Has this program bug been corrected yet? You might want to look-up a few threads on the list.
Re: [sa] Re: FH_DATE_PAST_20XX
On Fri, 1 Jan 2010 15:48:13 -0800 "R-Elists" wrote: > what should the new rule look like? > > i mean, i get it, and i think i know, and i even tested it and it was > still failing even after a restarts... > > s... > > seriously, i disabled the rule early AM yet when the update came > through 4 or so hours later, i believe it looks exactly the same as > when i first viewed it early on... > > - rh > /20[1-9][0-9]/ --> /20[2-9][0-9]/
Date in the Future
Well, now that it's 2010 I'm getting a lot of hits on FH_DATE_PAST_20XX The date is grossly in the future for emails that have been sent this year and are otherwise OK. What's up with that? Our SA is fairly current and we run sa-update once a week. Has this program bug been corrected yet? Best Regards, Jeff Koch, Intersessions
RE: [sa] Re: FH_DATE_PAST_20XX
From: "R-Elists"
Date: Fri, 1 Jan 2010 15:48:13 -0800
> Cc: Spamassassin users list
> Subject: Re: [sa] Re: FH_DATE_PAST_20XX
>
> Damn -- mea culpa. When we fixed the bug in SVN trunk in bug
> 5852, I should have immediately backported it to the 3.2.x
> sa-update channel when I commited that patch, but I didn't.
>
> It's now fixed in updates, but that won't help the admins
> who've been paged to deal with high FP rates on a holiday.
> :( Sorry folks...
>
> --j.
what should the new rule look like?
i mean, i get it, and i think i know, and i even tested it and it was still
failing even after a restarts...
s...
seriously, i disabled the rule early AM yet when the update came through 4
or so hours later, i believe it looks exactly the same as when i first
viewed it early on...
The easiest way to see what is being changed since your last sa-update
is to first sa-update /tmp and diff. The change is trivial but significant...
root% sa-update -D --updatedir /tmp/updates
root% diff -r -U 0 /var/lib/spamassassin/3.002005/updates_spamassassin_org
/tmp/updates/updates_spamassassin_org
diff -u -w --minimal -r -U 0
/var/lib/spamassassin/3.002005/updates_spamassassin_org/72_active.cf
/tmp/updates/updates_spamassassin_org/72_active.cf
--- /var/lib/spamassassin/3.002005/updates_spamassassin_org/72_active.cf
2009-07-20 17:01:55.0 -0400
+++ /tmp/updates/updates_spamassassin_org/72_active.cf 2010-01-01
18:51:10.0 -0500
@@ -527,7 +527,7 @@
##{ FH_DATE_PAST_20XX
-header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006]
+header FH_DATE_PAST_20XX Date =~ /20[2-9][0-9]/ [if-unset: 2006]
describe FH_DATE_PAST_20XX The date is grossly in the future.
##} FH_DATE_PAST_20XX
-jeff
RE: [sa] Re: FH_DATE_PAST_20XX
> Cc: Spamassassin users list > Subject: Re: [sa] Re: FH_DATE_PAST_20XX > > Damn -- mea culpa. When we fixed the bug in SVN trunk in bug > 5852, I should have immediately backported it to the 3.2.x > sa-update channel when I commited that patch, but I didn't. > > It's now fixed in updates, but that won't help the admins > who've been paged to deal with high FP rates on a holiday. > :( Sorry folks... > > --j. what should the new rule look like? i mean, i get it, and i think i know, and i even tested it and it was still failing even after a restarts... s... seriously, i disabled the rule early AM yet when the update came through 4 or so hours later, i believe it looks exactly the same as when i first viewed it early on... - rh
Keeping SA up to date
I've had an installation of SpamAssassin which I've been happy with for a number of years, its rulesets have been updated using Rules Du Jour. I've moved to a new server which has less rulesets installed and is catching less spam. The rulesets in this new installation are currently not updated. Not surprisingly, the new installation is catching less spam. I want to get the new installation up to the standard of the old one. Both installations are 3.2.5. This all leaves me with a number of questions: * How do I work out which rulesets are being used by an installation of SA? * What is currently the best way of updating rulesets; I gather sa-update has replaced RulesDu Jour? * Can anyone recommend the best document dealing with sa-update? * A lot of my old rulesets came from the SA Rules Emporium but I see that site is no longer updated, is there anyway to get new versions of these rulesets? I'm finding all this rather confusing as things seem to have moved on somewhat since I last changed anything! Many thanks, Geoff
Keeping SA up to date
I've had an installation of SpamAssassin which I've been happy with for a number of years, its rulesets have been updated using Rules Du Jour. I've moved to a new server which has less rulesets installed and is catching less spam. The rulesets in this new installation are currently not updated. Not surprisingly, the new installation is catching less spam. I want to get the new installation up to the standard of the old one. Both installations are 3.2.5. This all leaves me with a number of questions: * How do I work out which rulesets are being used by an installation of SA? * What is currently the best way of updating rulesets; I gather sa-update has replaced RulesDu Jour? * Can anyone recommend the best document dealing with sa-update? * A lot of my old rulesets came from the SA Rules Emporium but I see that site is no longer updated, is there anyway to get new versions of these rulesets? I'm finding all this rather confusing as things seem to have moved on somewhat since I last changed anything! Many thanks, Geoff
Re: [sa] Re: FH_DATE_PAST_20XX
Damn -- mea culpa. When we fixed the bug in SVN trunk in bug 5852, I should have immediately backported it to the 3.2.x sa-update channel when I commited that patch, but I didn't. It's now fixed in updates, but that won't help the admins who've been paged to deal with high FP rates on a holiday. :( Sorry folks... --j. On Fri, Jan 1, 2010 at 19:01, Martin Gregorie wrote: > On Fri, 2010-01-01 at 10:04 -0500, Thomas Harold wrote: >> On 1/1/2010 9:59 AM, Frank DeChellis DSL wrote: >> > would commenting out FH_DATE_PAST_20XX in 72_active.cf help until it's >> > fixed? >> > >> >> My temporary fix was to override the score and set it to 0.001 in SA's >> local.cf file. >> > Mine was to edit the regex in the latest sa_updates ruleset. I simply > made a 1 character edit to change the 3rd digit pattern to [2-9] from > [1-9]. I tested the change, natch. > >> # Turn down score on broken date testing rule >> score FH_DATE_PAST_20XX 0.001 >> > I deliberately broke the "don't edit the default or sa_update ruleset" > injunction so that my patch will vanish when the official update > arrives. This means that I don't have to remember to undo any temporary > changes. > > Martin > > > -- --j.
Re: FH_DATE_PAST_20XX
> On 12/31/2009 7:57 PM, Mike Cardwell wrote:
>> I just received some HAM with a surprisingly high score. The following
>> rule triggered:
>>
>> * 3.2 FH_DATE_PAST_20XX The date is grossly in the future.
>>
>> Yet the date header looks fine to me:
>>
>> Date: Fri, 1 Jan 2010 00:46:45 GMT
>>
>> In /usr/share/spamassassin/72_active.cf I find:
>>
>> header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006]
>>
>> Doesn't look particularly sane to me... I have given that rule a score
>> of 0 in my local.cf for now.
On 01.01.10 10:14, Thomas Harold wrote:
> My question is: Instead of using a hard-coded acceptable list of years,
> the rule isn't written more in the fashion of DATE_IN_PAST_96_XX which
> calculates the offset?
>
> header Date: is 96 hours or more before Received: date
> DATE_IN_PAST_96_XX 2.952 2.320 1.800 1.690
> eval:check_for_shifted_date('undef', '-96')
>
> header Date: is 96 hours or more after Received: date
> DATE_IN_FUTURE_96_XX 3.899 3.899 2.598 1.439
>
> Then you could replace FH_DATE_PAST_20XX with a set of rules that check
> the date against the current date and score accordingly. I'm guessing
> that intervals of 3 days, 7 days and 30 days before/after would provide
> a suitable set.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5852
it's never been so actual :)
I've overriden the rule to match >=2020 but I'll look if it matches
anything.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I don't have lysdexia. The Dog wouldn't allow that.
Re: [sa] Re: FH_DATE_PAST_20XX
On Fri, 2010-01-01 at 10:04 -0500, Thomas Harold wrote: > On 1/1/2010 9:59 AM, Frank DeChellis DSL wrote: > > would commenting out FH_DATE_PAST_20XX in 72_active.cf help until it's > > fixed? > > > > My temporary fix was to override the score and set it to 0.001 in SA's > local.cf file. > Mine was to edit the regex in the latest sa_updates ruleset. I simply made a 1 character edit to change the 3rd digit pattern to [2-9] from [1-9]. I tested the change, natch. > # Turn down score on broken date testing rule > score FH_DATE_PAST_20XX 0.001 > I deliberately broke the "don't edit the default or sa_update ruleset" injunction so that my patch will vanish when the official update arrives. This means that I don't have to remember to undo any temporary changes. Martin
Re: [SPAM:13.0] Re: [sa] FH_DATE_PAST_20XX
You know - anyone unhappy about this can always ask for a full refund on the purchase price paid for SpamAssassin :-)
Re: [sa] FH_DATE_PAST_20XX
Charles Gregory wrote on Fri, 1 Jan 2010 09:50:24 -0500 (EST): > I speak for the unguessable number of people who have installed a > 'standard' 3.2.x install with their linux variant, and don't monitor > closely, or watch this list. Some of them, we can hope, will have > 'sa-update' running in their nightly cron job. But will that do any good > if this 'patch' is not 'rushed' out as an sa-update for the current > version? This bug is also hitting a good number of mail providers and has made it to the news. Makes for a good measurement for support at those companies. ;-) Where you still see this rule scoring there's obviously nobody paying attention on holidays ... > > You could release 3.3.0 today, but that would not benefit people who don't > know about the upgrade and leave it at 3.2.x. > > And my pity to all those people who don't run sa-update. :( Well, that's their problem. Really. It should be made clear that a well-tuned sa setup will put thru all the ham still as ham. Most of our customer's ham scores even after applying this rule between 1 and 3 and easily makes it thru. If a considerable amount of ham is turned to spam on a certain setup there's likely something wrong with that setup. Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Re: [sa] FH_DATE_PAST_20XX
Thomas Harold wrote on Fri, 01 Jan 2010 10:04:42 -0500: > score FH_DATE_PAST_20XX 0.001 set to 0, there's no reason to have this evaluated at all. Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Re: FH_DATE_PAST_20XX
I think this rule should just be put to rest. According to my stats it hits 100% spam, but there's only very very few of it. Thus it doesn't add any real value over other rules, especially when one takes into account that there are already other rules hitting on time in the (near) future. There is no need to hit double and triple. Kai -- Kai Schätzl, Berlin, Germany Get your web at Conactive Internet Services: http://www.conactive.com
Re: PH_DATE_PAST_20XX
Can we call this the "Y2010" bug? :) I was just thinking back 10 years ago today wondering if there would be a 2010 related date bug. Charles Gregory wrote: Holy !!! I am SO glad that I read my e-mail first thing this morning! THANKS for spotting this! - Charles On Fri, 1 Jan 2010, Mike Cardwell wrote: I just received some HAM with a surprisingly high score. The following rule triggered: * 3.2 FH_DATE_PAST_20XX The date is grossly in the future. Yet the date header looks fine to me: Date: Fri, 1 Jan 2010 00:46:45 GMT In /usr/share/spamassassin/72_active.cf I find: header FH_DATE_PAST_20XXDate =~ /20[1-9][0-9]/ [if-unset: 2006] Doesn't look particularly sane to me... I have given that rule a score of 0 in my local.cf for now. -- Mike Cardwell - IT Consultant and LAMP developer Cardwell IT Ltd. (UK Reg'd Company #06920226) http://cardwellit.com/ Technical Blog: https://secure.grepular.com/blog/
Re: FH_DATE_PAST_20XX
On 12/31/2009 7:57 PM, Mike Cardwell wrote:
I just received some HAM with a surprisingly high score. The following
rule triggered:
* 3.2 FH_DATE_PAST_20XX The date is grossly in the future.
Yet the date header looks fine to me:
Date: Fri, 1 Jan 2010 00:46:45 GMT
In /usr/share/spamassassin/72_active.cf I find:
header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006]
Doesn't look particularly sane to me... I have given that rule a score
of 0 in my local.cf for now.
My question is: Instead of using a hard-coded acceptable list of years,
the rule isn't written more in the fashion of DATE_IN_PAST_96_XX which
calculates the offset?
header Date: is 96 hours or more before Received: date
DATE_IN_PAST_96_XX 2.952 2.320 1.800 1.690
eval:check_for_shifted_date('undef', '-96')
header Date: is 96 hours or more after Received: date
DATE_IN_FUTURE_96_XX 3.899 3.899 2.598 1.439
Then you could replace FH_DATE_PAST_20XX with a set of rules that check
the date against the current date and score accordingly. I'm guessing
that intervals of 3 days, 7 days and 30 days before/after would provide
a suitable set.
Re: [sa] Re: FH_DATE_PAST_20XX
On 1/1/2010 9:59 AM, Frank DeChellis DSL wrote: would commenting out FH_DATE_PAST_20XX in 72_active.cf help until it's fixed? My temporary fix was to override the score and set it to 0.001 in SA's local.cf file. # Turn down score on broken date testing rule score FH_DATE_PAST_20XX 0.001
Re: [sa] Re: FH_DATE_PAST_20XX
would commenting out FH_DATE_PAST_20XX in 72_active.cf help until it's fixed? Thanks Frank On Fri, 1 Jan 2010, Charles Gregory wrote: Date: Fri, 1 Jan 2010 09:50:24 -0500 (EST) From: Charles Gregory To: users@spamassassin.apache.org Subject: Re: [sa] Re: FH_DATE_PAST_20XX On Fri, 1 Jan 2010, Mike Cardwell wrote: On 01/01/2010 10:15, Per Jessen wrote: I just received some HAM with a surprisingly high score. The following rule triggered: * 3.2 FH_DATE_PAST_20XX The date is grossly in the future. Agree, that should probably be [2-9][0-9]. Please open a bug for this, it should be fixed for 3.3.0 https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269 Following that URL you find out that the "bug" was fixed five months ago. I'm using the Debian Lenny package and it doesn't contain that fix. NOW the 'minor' issue I raised before has just become a MAJOR one. I have already fixed my config, so let's skip *that* portion of the argument :) I speak for the unguessable number of people who have installed a 'standard' 3.2.x install with their linux variant, and don't monitor closely, or watch this list. Some of them, we can hope, will have 'sa-update' running in their nightly cron job. But will that do any good if this 'patch' is not 'rushed' out as an sa-update for the current version? You could release 3.3.0 today, but that would not benefit people who don't know about the upgrade and leave it at 3.2.x. And my pity to all those people who don't run sa-update. :( - Charles --- Frank DeChellis Internet Access Worldwide 3 East Main StreetWelland, Ontario, CanadaL3B 3W4 905-714-1400 fax 905-732-0524 www.iaw.com --
Re: [sa] Re: FH_DATE_PAST_20XX
On Fri, 1 Jan 2010, Mike Cardwell wrote: On 01/01/2010 10:15, Per Jessen wrote: I just received some HAM with a surprisingly high score. The following rule triggered: * 3.2 FH_DATE_PAST_20XX The date is grossly in the future. Agree, that should probably be [2-9][0-9]. Please open a bug for this, it should be fixed for 3.3.0 https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269 Following that URL you find out that the "bug" was fixed five months ago. I'm using the Debian Lenny package and it doesn't contain that fix. NOW the 'minor' issue I raised before has just become a MAJOR one. I have already fixed my config, so let's skip *that* portion of the argument :) I speak for the unguessable number of people who have installed a 'standard' 3.2.x install with their linux variant, and don't monitor closely, or watch this list. Some of them, we can hope, will have 'sa-update' running in their nightly cron job. But will that do any good if this 'patch' is not 'rushed' out as an sa-update for the current version? You could release 3.3.0 today, but that would not benefit people who don't know about the upgrade and leave it at 3.2.x. And my pity to all those people who don't run sa-update. :( - Charles
Re: PH_DATE_PAST_20XX
Holy !!! I am SO glad that I read my e-mail first thing this morning! THANKS for spotting this! - Charles On Fri, 1 Jan 2010, Mike Cardwell wrote: I just received some HAM with a surprisingly high score. The following rule triggered: * 3.2 FH_DATE_PAST_20XX The date is grossly in the future. Yet the date header looks fine to me: Date: Fri, 1 Jan 2010 00:46:45 GMT In /usr/share/spamassassin/72_active.cf I find: header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006] Doesn't look particularly sane to me... I have given that rule a score of 0 in my local.cf for now. -- Mike Cardwell - IT Consultant and LAMP developer Cardwell IT Ltd. (UK Reg'd Company #06920226) http://cardwellit.com/ Technical Blog: https://secure.grepular.com/blog/
Re: FH_DATE_PAST_20XX
On Fri, 01 Jan 2010 13:44:27 +
Mike Cardwell wrote:
> Also, the "fix" five months ago was to add 10 years to what is
> classified as "grossly in the future"... That doesn't sound to me as
> though this ruke was based on the results of a mass check...
>
And Happy New Year to you from the development team
{joke -}
Re: FH_DATE_PAST_20XX
Mike Cardwell wrote: > On 01/01/2010 10:15, Per Jessen wrote: > >> >> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269 > > Following that URL you find out that the "bug" was fixed five months > ago. I'm using the Debian Lenny package and it doesn't contain that > fix. Yes, that fix doesn't appear to have made it out with sa-update. > So as I understand it ... everyone using the Debian Lenny package with > the default settings has basically dropped from a spam threshold of > 5.0 to 1.8 over night because of this...? Sounds about right. We need a rule update pushed out asap. /Per Jessen, Zürich
Re: FH_DATE_PAST_20XX
From: "Herbert J. Skuhra"
Sent: Friday, 2010/January/01 01:17
At Thu, 31 Dec 2009 17:53:24 -0800 (PST),
John Hardin wrote:
On Fri, 1 Jan 2010, Mike Cardwell wrote:
> I just received some HAM with a surprisingly high score. The following
> rule triggered:
>
> * 3.2 FH_DATE_PAST_20XX The date is grossly in the future.
>
> Yet the date header looks fine to me:
>
> Date: Fri, 1 Jan 2010 00:46:45 GMT
>
> In /usr/share/spamassassin/72_active.cf I find:
>
> header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006]
>
> Doesn't look particularly sane to me... I have given that rule a score
> of 0 in my local.cf for now.
Agree, that should probably be [2-9][0-9].
What about
header FH_DATE_PAST_20XX Date =~ /(201[1-9])|(20[2-9][0-9])/
and
##{ FH_DATE_IS_200X
header FH_DATE_IS_200XDate =~ /200[0-9]/ [if-unset: 2006]
describe FH_DATE_IS_200XThe date is not 200x.
##} FH_DATE_IS_200X
How about simple arithmetic expressions? Then it will not need yearly
updates. Oh yeah, TPTB don't have arithmetic expressions in SA.
{o.o}
Re: FH_DATE_PAST_20XX
On 01/01/2010 10:15, Per Jessen wrote: >>> I just received some HAM with a surprisingly high score. The >>> following rule triggered: >>> >>> * 3.2 FH_DATE_PAST_20XX The date is grossly in the future. >>> >>> Yet the date header looks fine to me: >>> >>> Date: Fri, 1 Jan 2010 00:46:45 GMT >>> >>> In /usr/share/spamassassin/72_active.cf I find: >>> >>> header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006] >>> >>> Doesn't look particularly sane to me... I have given that rule a >>> score of 0 in my local.cf for now. >> >> Agree, that should probably be [2-9][0-9]. >> >> Please open a bug for this, it should be fixed for 3.3.0 > > https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269 Following that URL you find out that the "bug" was fixed five months ago. I'm using the Debian Lenny package and it doesn't contain that fix. r...@haven:~# spamassassin --version SpamAssassin version 3.2.5 running on Perl version 5.10.0 r...@haven:~# So as I understand it ... everyone using the Debian Lenny package with the default settings has basically dropped from a spam threshold of 5.0 to 1.8 over night because of this...? Also, the "fix" five months ago was to add 10 years to what is classified as "grossly in the future"... That doesn't sound to me as though this ruke was based on the results of a mass check... -- Mike Cardwell - IT Consultant and LAMP developer Cardwell IT Ltd. (UK Reg'd Company #06920226) http://cardwellit.com/ Technical Blog: https://secure.grepular.com/blog/
Re: FH_DATE_PAST_20XX
John Hardin wrote: > On Fri, 1 Jan 2010, Mike Cardwell wrote: > >> I just received some HAM with a surprisingly high score. The >> following rule triggered: >> >> * 3.2 FH_DATE_PAST_20XX The date is grossly in the future. >> >> Yet the date header looks fine to me: >> >> Date: Fri, 1 Jan 2010 00:46:45 GMT >> >> In /usr/share/spamassassin/72_active.cf I find: >> >> header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006] >> >> Doesn't look particularly sane to me... I have given that rule a >> score of 0 in my local.cf for now. > > Agree, that should probably be [2-9][0-9]. > > Please open a bug for this, it should be fixed for 3.3.0 > https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269 /Per Jessen, Zürich
[SPAM:9.4] Re: FH_DATE_PAST_20XX
On Fri, 01 Jan 2010 10:17:57 +0100
"Herbert J. Skuhra" wrote:
> At Thu, 31 Dec 2009 17:53:24 -0800 (PST),
> John Hardin wrote:
> >
> > On Fri, 1 Jan 2010, Mike Cardwell wrote:
> >
> > > I just received some HAM with a surprisingly high score. The
> > > following rule triggered:
> > >
> > > * 3.2 FH_DATE_PAST_20XX The date is grossly in the future.
> > >
> > > Yet the date header looks fine to me:
> > >
> > > Date: Fri, 1 Jan 2010 00:46:45 GMT
> > >
> > > In /usr/share/spamassassin/72_active.cf I find:
> > >
> > > header FH_DATE_PAST_20XXDate =~ /20[1-9][0-9]/
> > > [if-unset: 2006]
> > >
> > > Doesn't look particularly sane to me... I have given that rule a
> > > score of 0 in my local.cf for now.
> >
> > Agree, that should probably be [2-9][0-9].
>
> What about
>
> header FH_DATE_PAST_20XXDate =~ /(201[1-9])|(20[2-9][0-9])/
>
> and
>
> ##{ FH_DATE_IS_200X
> header FH_DATE_IS_200XDate =~ /200[0-9]/ [if-unset: 2006]
> describe FH_DATE_IS_200XThe date is not 200x.
> ##} FH_DATE_IS_200X
>
> -Herbert
Perhaps in a couple of days. There may still be deferred mail sat in
peoples outbound queues with 2009 on it ;-)
Re: FH_DATE_PAST_20XX
At Thu, 31 Dec 2009 17:53:24 -0800 (PST),
John Hardin wrote:
>
> On Fri, 1 Jan 2010, Mike Cardwell wrote:
>
> > I just received some HAM with a surprisingly high score. The following
> > rule triggered:
> >
> > * 3.2 FH_DATE_PAST_20XX The date is grossly in the future.
> >
> > Yet the date header looks fine to me:
> >
> > Date: Fri, 1 Jan 2010 00:46:45 GMT
> >
> > In /usr/share/spamassassin/72_active.cf I find:
> >
> > header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006]
> >
> > Doesn't look particularly sane to me... I have given that rule a score
> > of 0 in my local.cf for now.
>
> Agree, that should probably be [2-9][0-9].
What about
header FH_DATE_PAST_20XX Date =~ /(201[1-9])|(20[2-9][0-9])/
and
##{ FH_DATE_IS_200X
header FH_DATE_IS_200XDate =~ /200[0-9]/ [if-unset: 2006]
describe FH_DATE_IS_200XThe date is not 200x.
##} FH_DATE_IS_200X
-Herbert
