So specifically, we are talking about:
Commenting the new rules in 50_scores.cf, adding a version block on
20_mailspike.cf in your sandbox, removing the nopublish and then what?
I'll do this later today.
Thanks.
Don't we already have masscheck scoring on the rules or does the nopublish
disable the statistics you want to see?
No, masscheck is not supposed to autoscore anything that is nopublish.
I thought they generated some statistics concerning the scores but
didn't publish them. I know I've seen the rules referenced in all the
data I've been looking through trying to get the mkupdates script
working again.
IIRC, sa-update rulesets were not supposed to change the "base" rules
at all, only auto-promote new rules added since the previous major
release?
Kevin, have time to talk on the phone sometime this week? I think
there is a gap of understanding here that we can clear up on the
phone.
Always happy to talk. Just send me an email off-list to schedule a time.
As for the gap, the behavior of what people think things do and what
they actually do on the infrastructure sometimes differs more than I
like. You and I need to setup a box that replaces zones and zones2 that
is more modern.
In short, what other steps are you proposing in the immediate future on the
MAILSPIKE scores to make them live for trunk/3.4.0?
In general:
* Yes, we include some placeholder rule for now. If my understanding
is correct, if we add it as if it were a "base" rule the
auto-promotion mechanism wont change its score.
If by base rule, you mean defined in 50_scores.cf, than I agree. I
believe that will also auto-promote the rule from sandbox to base.
* BTW, why did you include L2? L2 was *never* tested in masscheck.
The years of top-tier performance were confirmed for only L3-L5. Same
story regarding H2. Please, let's not change things at the last
minute before 3.4?
I've been testing with H2 and L2 for quite some time. I've been working
with Joao on running a public nameserver and testing Mailspike since
March of 2010. To me, this isn't last minute but rather things that
have been languishing for almost 2 years.
* Set the scores to be conservative (see AXB's post) prior to GA
balancing. Let ZBI and L's float in GA rescoring. Then adjust L's to
be linear and increase the H's conservatively after we look at the GA
results and do some quick fp-fn tests across the entire set.
if (version>= 3.400000)
#MAILSPIKE RBL ENABLED FOR SA3.4 and above - BUG 6400
# FLOATING SCORES FOR GA - adjust after GA to make L3 to L5 linear
score RCVD_IN_MSPIKE_ZBI 2.7
score RCVD_IN_MSPIKE_L5 2.5
score RCVD_IN_MSPIKE_L4 1.7
score RCVD_IN_MSPIKE_L3 0.9
# TEMPORARILY FIXED SCORES - adjust these higher after we look at the GA results
# (pending discussion: none of the whitelists should effect the
blacklist balancing as they are orthogonal.)
# I suspect these should be something like H3 = 0.5, H4 = 1.0, H5 =
2.0, alongside big reductions in IADB and DNSWL.
score RCVD_IN_MSPIKE_H3 -0.01
score RCVD_IN_MSPIKE_H4 -0.01
score RCVD_IN_MSPIKE_H5 -0.01
## These are informational rules, useful in statistical comparisons
# FIXED SCORES - leave these scores this way for release
score RCVD_IN_MSPIKE_BL 0.01
score RCVD_IN_MSPIKE_WL -0.01
endif
Your process makes sense and I'll look forward to reviewing the proposed
rule scores as much as the process to determine your score recommendations.
Regards,
KAM
