https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7016
Bug ID: 7016
Summary: third party auto generated rules in sandboxes
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: RuleQA
Assignee: [email protected]
Reporter: [email protected]
This concerns 20_khop_sc_bug_6114.cf and possinby other thir party generated
rules vegetating in sandboxes.
>From dev list traffic as per KAM request
On 2/19/2014 2:19 AM, Axb wrote:
there's several reasons why I consider these rules as dangerous and should not
be included in the default SA ruleset.
1.- rules are created outside the the project's infrastructure and SA devs have
no way to quickly control/modify output in case something goes bad.
2.- Spamcop is riddled with FPs and creating static rules based on it's output
is either adding dangerous overlap or next to pointless due to low score. I'm
positive this could initiate a whole separate discussion outside this thread.
4.- If your autocreating routine goes MIA, ppl are left with stale data - SA
project has no control over that data.
5.- masscheck results are a VERY small snapshot of global traffic and static
IP/CIDR lists should be avoided - stuff changes too fast and a delayed daily
update of a rule file is fine in a separate sa-update channel (yours, in this
case) but should not be part of the SA framework.
A good example of "auto generated problems" are the SOUGHT rules, one of them
being empty for many months and as things are now we have no immediate way to
fix whatever is required so it's good for them to be in an optional channel
outside the default SA scope. Admins have a choice to drop a third party
channel and the SA dev group cannot be held responsible for any issues outside
their control.
Last but not least, SA should deliver a basic ruleset which should work
globally, as static as possible and auto generated stuff should not affect the
framework's results.
Even autopromoted stuff has it's caveats and there are big plans to work on
this to make SA leaner and avoid surprises.
Personally, I don't consider it fair and questionable that you make use of the
volunteered masschecker resources to do QA for your personal channel for years
yet don't run a masschecker yourself.
For these reason I ask you to remove the 20_khop_sc_bug_6114.cf file from the
sandbox
KAM Replied:
I've been thinking about this issue for a day or so.
My job as chair is to help guide problems like this to an amicable end. So I
will reiterate something I say a lot which is that you both have 1 vote and in
the end, you have to agree to disagree without being disagreeable. It's a
quote from MLK, Jr. and a great one for many things in like. I like it in
business like this because you state your position passionately, you make a
vote, and then you SUPPORT THE OUTCOME no matter if it was your vote or note.
So continuing my discussion as chair, Alex, please open a bugzilla item and
record this as a vote there. Adam, please weigh in on the issue and vote.
Now, switching back to my normal role in the project, here are some technical
thoughts:
The issues with SOUGHT do lead to learned experience that this should be a
separate channel. I think the project needs the ability to have different
channels and publish them.
Adam, it would also be nice if we could get you as a masschecker. Rules for
years in sandbox isn't really the intent.
Look forward to more discussion on this.
regards,
KAM
--
You are receiving this mail because:
You are the assignee for the bug.
