Created attachment 4659 [details]
Patch to defer bug for three decades

On second thought, push this back until sometime after I retire.

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Thunderbird/3.0.1

My Thunderbird doesn't appear to be triggering this rule.

(In reply to comment #2)
> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7)
> Gecko/20100120 Fedora/3.0.1-1.fc12 Thunderbird/3.0.1
> 
> My Thunderbird doesn't appear to be triggering this rule.

Agreed.  I have SA 3.2.5 and Thunderbird 3.0.1 that also does not match ... despite that a raw run of perl matches it...

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100121 Lightning/1.0b1 Icedove/3.0.1

No mention of it in the debug output either, and I definitely have that rule.
http://ruleqa.spamassassin.org/?rule=RATWARE_GECKO_BUILD
Also doesn't hit the masscheck, either due to a bug or the fact that nobody forges this with a future date.  I suspect both.

Mine does seem to trigger it (running from XP anyway, possibly also from Mac):

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1
X-Spam-Report: 1.7 RATWARE_GECKO_BUILD    Bulk email fingerprint (Gecko faked) found

Incidentally, this is with 3.2.4. Is there any temporary fix for this issue? It could be a bit of a problem as my whole office use Thunderbird.

(In reply to comment #4)
> Mine does seem to trigger it (running from XP anyway, possibly also from Mac):
> 
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.7)
> Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1
> X-Spam-Report: 1.7 RATWARE_GECKO_BUILD    Bulk email fingerprint (Gecko faked)
> found

Same for Mac, running OS X 10.5:

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-GB; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1

X-Spam-Report: 1.7 RATWARE_GECKO_BUILD    Bulk email fingerprint (Gecko faked) found

Alex

This bug is twofold:

1.  The important part:  Fix the regex!
    This is easy and has a patch.
    +1 do it now.

2.  The tougher part:  figure out why this doesn't fire all the time.

Since it IS firing some of the time, let's knock out #1 ASAP and then deal with #2.

(In reply to comment #7)
> This bug is twofold:
> 
> 1.  The important part:  Fix the regex!
>     This is easy and has a patch.
>     +1 do it now.
> 
> 2.  The tougher part:  figure out why this doesn't fire all the time.
> 
> Since it IS firing some of the time, let's knock out #1 ASAP and then deal with
> #2.


I'm +1 on the very small fix and keeping the ticket open.

I suspect that it is not differences in their t-bird user-agent causing some people to not see the rule triggered, but differences in the perl they are running. I'm seeing the rule not being triggered to and I did the following experiment.

I created a test message with the following line both in the headers and again in the body:

User-Agent: Gecko/20100111 Lightning

I then added the following to local.cf:

header TEST_GB1 User-Agent =~ /Gecko\/(?!200\d\d\d\d\d)\d/
describe TEST_GB1       Test header 1
score TEST_GB1 1.0

header TEST_GB2 User-Agent =~ /Gecko\/(?!200\d\d\d\d\d)[0-9]/
describe TEST_GB2       Test header 2
score TEST_GB2 1.0

header TEST_GB3 User-Agent =~ /Gecko\/(?!200\d\d\d\d\d)(\d)/
describe TEST_GB3       Test header 3
score TEST_GB3 1.0

rawbody TEST_GB4        /User-Agent: Gecko\/(?!200\d\d\d\d\d)\d/
describe TEST_GB4       Test rawbody
score TEST_GB4 1.0

body TEST_GB5   /User-Agent: Gecko\/(?!200\d\d\d\d\d)\d/
describe TEST_GB5       Test body
score TEST_GB5 1.0

I then ran spamassassin -t -L on the message and the result was that TEST_GB1 did not hit and all the others did.

I can't explain the results, but notice that the problem only occurs in a header rule and that it goes away if you change the final \d into either [0-9] or into (\d)

Any ideas about how this can be true? BTW, I'm running perl 5.8.9 from MacPorts under Mac OS 10.6.2

After all sorts of debugging I finally tracked down the reason while the rule did not fire with the pattern /Gecko\/(?!200\d\d\d\d\d)\d/ on my machine.

First of all, my local.cf test rule TEST_GB1 was removed by duplicate rule detection

[35591] dbg: rules: RATWARE_GECKO_BUILD merged duplicates: TEST_GB1

So I was still only looking at RATWARE_GECKO_BUILD

Second, notice this line in 3.003000/updates_spamassassin_org/50_scores.cf

score RATWARE_GECKO_BUILD 0 # n=0 n=1 n=2 n=3

That seems to explain it :) When I set the score to 1 in local.cf the rule fires fine. I think we can put that problem to bed.

+1 on the proposed fix

(In reply to comment #10)
> After all sorts of debugging I finally tracked down the reason while the rule
> did not fire with the pattern /Gecko\/(?!200\d\d\d\d\d)\d/ on my machine.
> 
> First of all, my local.cf test rule TEST_GB1 was removed by duplicate rule
> detection
> 
> [35591] dbg: rules: RATWARE_GECKO_BUILD merged duplicates: TEST_GB1
> 
> So I was still only looking at RATWARE_GECKO_BUILD
> 
> Second, notice this line in 3.003000/updates_spamassassin_org/50_scores.cf
> 
> score RATWARE_GECKO_BUILD 0 # n=0 n=1 n=2 n=3
> 
> That seems to explain it :) When I set the score to 1 in local.cf the rule
> fires fine. I think we can put that problem to bed.
> 
> +1 on the proposed fix

The proposed patch doesn't fix the score issue.  Are you proposing a patch to a score of 1 AND the attached gecko.diff?  If so, I'm +1.

(in reply to comment #11)

I just assumed that somebody pushed a score 0 out to updates while we dealt with the false positives that this y2k10 bug was generating. If that didn't happen, why is the rule there with a score of 0? What score is it supposed to be set at?

(In reply to comment #12)
> (in reply to comment #11)
> 
> I just assumed that somebody pushed a score 0 out to updates while we dealt
> with the false positives that this y2k10 bug was generating. If that didn't
> happen, why is the rule there with a score of 0? What score is it supposed to
> be set at?

fwiw, it's zeroed in trunk:

: 41...; ./spamassassin -Lt < tst | grep -C2 X-Spam-Status
        jmason.ubuntu.amazon.com
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=T_FSL_HELO_NON_FQDN_2,
        T_KHOP_NEWSLETTER,T_KHOP_PGP_INLINE,T_RP_MATCHES_RCVD autolearn=unavailable
        version=3.4.0-r904526

+1 on the second rule patch

Committed revision 906263.

Leaving bug open in case someone else wants to deal with the score issue.

Actually, the score issue is an entirely separate bug.  Resolving this bug.