http://bugzilla.spamassassin.org/show_bug.cgi?id=3109
------- Additional Comments From [EMAIL PROTECTED] 2005-10-04 19:19 -------
Subject: Re: RFE: really simple "this is ham" shortcircuiting
On Tue, Oct 04, 2005 at 06:37:30PM -0700, [EMAIL PROTECTED] wrote:
> I've just realised, btw, that we don't need separate "shortcircuit-ham" and
> "shortcircuit-spam" keywords -- we can set the ham/spam status using the
> rule's
> score. Just set the score to -100 or +100, and shortcircuit.
You can figure out the ham/spam via score, but the relative score
value doesn't matter imo. I'd base ham/spam on "tflags nice" versus
not personally. I had previously sent some thoughts to the dev list
about short circuiting, but I'll put them here as well so I can find it
easier next time:
- set certain rules as SC if hit
USER_IN_WHITELIST, USER_IN_BLACKLIST (not DEF)
*BSP*
HABEAS*
- allow SC on ham score (ie: < #)
- allow SC on spam score (ie: > #)
- should autolearn skip SC msgs? should we always do autolearn in the
appropriate direction?
- AWL should be skipped during SC
- SC rules should have a negative priority so they run first
- do *not* do score check per rule, do it either per priority or rule
type (header, body, etc.)
- SC will require is_spam SC as score + required_hits will be at odds
- add SC header macro (get_tag)
- SC for S/O 1.000 rules? how about S/O near 1? BAYES_99, etc.
Some form of order/priority rearrangement:
Blacklist short
Whitelist user/admin wants it
BSP/Habeas reputable, non-forgable
Other SC Rules as early as possible
Other Local Rules lightweight
Bayes don't do it unless we have to
Network large latency, try to avoid
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
