728856 - Redesigned user-agent string triggers RATWARE_GECKO_BUILD rule with SpamAssassin, increasing spam score

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[rsx11m]

(Quoting myself from bug 588909 comment #77)
> Given that the revised user-agent string also goes out with e-mails sent
> using Thunderbird and SeaMonkey, mail/news is affected by this change as
> well.
> 
> For SpamAssassin, this now triggers the RATWARE_GECKO_BUILD rule which
> expects a date in a given range, thus increasing the spam score when sent
> from trunk.
> 
> This also applies to Gecko/13.0 and Gecko/13 variants.

Comment 1

[rsx11m]

This applies to trunk builds (Thunderbird 13.0a1 and SeaMonkey 2.10a1), no current release builds are affected, thus target Gecko 13.0 for now. Further changes may follow, specifically removal of the minor version per bug 572659.

Also see https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6305 as reference for the current implementation of this rule.

Comment 2

[Dão Gottwald [:dao]]

We'll need to file a bug on this: https://issues.apache.org/SpamAssassin/enter_bug.cgi?product=Spamassassin&component=Rules

Comment 3

[Gervase Markham [:gerv]]

rsx11m: can you drive this issue? Thanks :-)

Gerv

Comment 4

[rsx11m]

Maybe let's wait for bug 572659 to have a definite pattern what the Gecko 13+ token will look like.

Comment 5

[rsx11m]

Can someone test this with SpamAssassin 3.3.x if it still applies? I found a follow-up https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6323 which apparently removed that rule, thus I may be testing against an older version (which on the other hand implies that those are still in use by providers).

Comment 6

[Dão Gottwald [:dao]]

(In reply to rsx11m from comment #5)
> I found a follow-up https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6323

It says: "RATWARE_GECKO_BUILD is scored 0 on the trunk.  Presumably, this means that it
is not tested despite the entry in http://ruleqa.spamassassin.org"

So is this an issue at all?

Comment 7

[rsx11m]

It's an issue if the server runs SpamAssassin 3.3.1 or earlier, it's not an issue if they run the latest 3.3.2 release with the most recent rules. Thus, updating the spam filter to the current version on the provider's side should resolve the issue.

Do we need further confirmation?

Comment 8

[Gervase Markham [:gerv]]

Whatever happens, we should get this rule removed from all the places we can; SpamAssassin should not be looking for particular values here, because we want the freedom to change them later without having messages classified as spam.

Gerv

Comment 9

[rsx11m]

As far as I can tell from reviewing their activity on SVN, this rule is no longer in current trunk and likely in the 3.3.2 release. I'm just unable to confirm that indeed it's no longer hit in 3.3.2 (as I don't have access to any such server).

Before that, the rule was set to a zero score by default but could be enabled by the provider if so desired (and there was a score before in earlier versions).

Comment 10

[Ben Bucksch (:BenB)]

> (and there was a score before in earlier versions)

Older versions have an update feature, and distros can update as well. Can we get the update in there, too?
Big (and small) servers typically often run old software, so "it's fixed in upstream trunk" probably is not enough.

Comment 11

[Ben Bucksch (:BenB)]

I checked Ubuntu 8.04 Hardy (LTS from 2008) and it already has a score 0 for the rule, so we can probably indeed consider this gone.

header RATWARE_GECKO_BUILD        User-Agent =~ /Gecko\/(?!200\d\d\d\d\d)\d/
score RATWARE_GECKO_BUILD 0 # n=0 n=1 n=2 n=3

Comment 12

[Ben Bucksch (:BenB)]

(And the rule, as it existed, is now broken anyway, because we're past 2009, and that was the reason why it was removed: "I suspect that it will not be worth the Y2K30 issue its present form introduces.")

Comment 13

[rsx11m]

AFAICT the y2010 issue was resolved with 3.3.1 and the rule removed with 3.3.2, where server administrators can assign scores according to their own preferences. Thus, what you are looking at must be a pre-3.3.1 version which apparently already defaulted to a zero score.

(In reply to Ben Bucksch (:BenB) from comment #10)
> Big (and small) servers typically often run old software, so "it's fixed in
> upstream trunk" probably is not enough.

I don't think I understand what your suggestion is. It's hard to find and reach out to anybody who's not running the current version and (as applicable) has assigned a score to it.

Comment 14

[Ben Bucksch (:BenB)]

My suggestion was "Older versions [of SA] have an [built-in] update feature, and distros can update as well". Now, I suggest to do nothing, because these rules were unused by default in 2008, and already broke in 2010 anyway.

I'm saying we don't need to worry about this at all.