http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3109
------- Additional Comments From [EMAIL PROTECTED] 2006-03-23 22:49 -------
(In reply to comment #21)
> > first, I really don't like the override score idea. I don't think
> > there's a real point in doing it, and it's going to cause confusion by
> > people who add up the rules and see it's nowhere near the rule score
> > sum.
>
> -1
> I think it provides a better, more familiar UI for users. Compare
> (assuming we fix the "something in x-spam-status" issue below):
>
> X-Spam-Status: Yes, score=1.9 required=5.0
> tests=BAYES_50,HTML_IMAGE_ONLY_28,
> HTML_MESSAGE,MIME_HTML_ONLY,SC_TEST shortcircuit=spam
> autolearn=no version=3.2.0-r372567
>
> eh? "Yes, score=1.9 required=5.0", wtf?
> that's less intuitive, and more likely to cause confusion, than
>
> X-Spam-Status: Yes, score=15.0 required=5.0
> tests=BAYES_50,HTML_IMAGE_ONLY_28,
> HTML_MESSAGE,MIME_HTML_ONLY,SC_TEST shortcircuit=spam
> autolearn=no version=3.2.0-r372567
>
> it really makes less sense in my opinion for the mail to be marked as spam
> with a low score, than for the tests not to add up. ;)
While it may make more sense to have a score greater than the required score,
neither make complete sense. :)
I think that either tests that are going to cause short circuit should either
have a score alone that will cause a sensible spam score; or where that may not
be possible (say, decision trees in a future check() plugin) score should be
undefined:
X-Spam-Level: ****************************************** (max # of stars we use)
X-Spam-Status: Yes, score= required= tests=BAYES_50,
HTML_IMAGE_ONLY_28,HTML_MESSAGE,MIME_HTML_ONLY,SC_TEST
shortcircuit=spam autolearn=no version=3.2.0-r372567
(or maybe 0.0 for both score and required)
> > fourth, what about autolearn? it's likely autolearn won't happen by
> > default (too few hits, etc,) but it could also potentially learn the
> > wrong way depending on what rules hit. I'd like to get a consensus on
> > what should happen here (IMO, autolearn is skipped for SC).
>
> -1
> I don't think this needs to block autolearning necessarily. It can be
> driven by the rules that caused the shortcircuiting. For example, let's
> say USER_IN_WHITELIST is the rule that shortcircuited -- that rule already
> mandates "noautolearn", so there's no need for the act of shortcircuiting
> to do so, too.
Agreed with jm here.
> > seventh, and this is tricky, do we want to try moving the priorities
> > around automatically when SC is enabled? I was thinking of having code
> > that sets default priorities, similar to default score, that goes
> > through the SC rule listing and bumps the priority so they run first
> > (including meta dependencies) unless the rule has a priority
> > specifically set by config. Then another loop which sets the default to
> > priority 0.
I'd say yes, but it can wait.
> > eighth, should the SC decision code be in a plugin?
>
> -1
> No. There are a lot of issues around pluginizing parts of check(), and
> they're being discussed in 2 other bugs simultaneously iirc! Let's not
> confuse matters even more by making it 3! :(
>
> This patch, in contrast, is pretty simple and small, and can be easily
> refactored into a plugin *later* if desired, once the other pluginization
> discussions are concluded with an agreement.
Agreed with jm.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
