On 02/18/2014 11:57 PM, Adam Katz wrote:
The real question (which I should admittedly know the answer to) is
whether it is safe to unleash this. I've been hosting it on my own
sa-update channel for all that time merely because SA rules updates
aren't prompt enough to host directly. Is that still the case?
I do not think these rules are unsafe to run in production (the CIDR8
rules are unsafe in theory and I wouldn't want those scored directly
even though it has been safe in practice). I've got some (safer)
downstream remixes of these rules that I'll push up if the main
updates.spamassassin.org mechanism is safe.
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 preoblematic 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 made
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
Thanks
Axb
On 02/18/2014 01:19 AM, Axb wrote:
Could we PLEASE loose this rules file?
/trunk/rulesrc/sandbox/khopesh/20_khop_sc_bug_6114.cf
We've been masschecking it for 4 years and it's tflags nopublish and
pretty dangerous to use in production if you have more than a "man &
his dog" setup.
I see no reason to throw cycles/resources to masscheck such rules for
years.
Thx
