http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3109
------- Additional Comments From [EMAIL PROTECTED] 2006-04-02 01:12 ------- (In reply to comment #27) > undefined score/required? I really don't like that one, to be honest. The > X-Spam-Status is mainly a UI but also an API, and I think it's better to > "degrade gracefully" for apps that won't know about short-circuiting, by > providing them *something* relatively sane in the areas they're looking > at, instead of breaking their expectations like that. Even though it's the most accurate, I don't really like it either -- that's me being used to safety critical systems where we never ever rely on a value that's supposed to be there being there. I'd much prefer that whatever causes the shortcicuit to have fired a rule that will be certain to cause a final score that exceeds the threshold in the appropriate direction, and we use that final score. > option (d), same as (c) but with a higher value for clarity: > > X-Spam-Level: ****************************************** > X-Spam-Status: Yes, score=100.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 > > > me, I like (d), with (c) as a second-best. I'd settle for (d) but with a (default) score outside the range of typical scores. The score should be configurable though, as I believe it is now, so that people using multiple thresholds for tag-accept/reject can still do that. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
