https://issues.apache.org/SpamAssassin/show_bug.cgi?id=4900
--- Comment #13 from Adam Katz <[email protected]> 2010-04-15 19:25:23 EDT --- Greg proposed in comment 9: > spamassassin --assign-score [email protected] -5 > > and then there'd be a db entry matching that sender that would add -5 > points. One could use -100 or +100. (But, with forgeable senders, -5 > feels right to me to rescue legit mails that look spammy but not give > a total pass.) > > To implement this the AWL db could store the score in the scorefield > and -1 in the count field, and then AWL would ignore the entry. But, > AWL and persistent scores probably should both operate. I like the idea, but I'm not sure if that's exactly the right approach; that's too much choice in the hand of the user. I'd like either for the AWL plugin to use the old score to calculate what base score is needed to require 100 subsequent emails before reverting to flag/no-flag, or a larger base count (which I think is MUCH simpler and also far more statistically sound). Also, AWL and persistent scores are synonymous :-) As to John's addition in comment 10: > and/or > > spamassassin --assign-score-auth [email protected] -5 Doesn't AWL already keep track of authentication? I guess that's useful for manual training of addresses, but it would be automatic when using --add-to-[white|black]list A lesson I learned when playing with greylisting: The email address is more trouble than it's worth unless you're dealing with a heavyweight like hotmail (we can already recognize the freemailers, which is probably good enough). Otherwise, all that matters is the IP address, which can't be forged. To simplify matters, I'd assume any IP that satisfies SPF should be treated the same. Rethinking the way AWL (and traditional white/blacklisting) deals with authentication is a good exercise, but it is not related to THIS bug. > This could also be reasonable shortcut fodder. If the fixed score has > been set to (for example) -500, it's unlikely any combination of spam > rules will push it back above zero. No dice. Here's what that does: 1 -235.000 2 -102.500 3 -58.333 4 -36.250 5 -23.000 6 -14.167 7 -7.857 8 -3.125 9 0.556 10 3.500 11 5.909 I artificially set the AWL score to -500 (wipe with -R, alter the custom rule to get it to -500, run once, then move the custom rule back to 30 and loop through successive scans as noted in my last post, comment 12). As you can see, this only saves ten messages. How about we set the AWL totscore to -100 and the count to 10 rather than 1? 1 -35.000 2 -29.091 3 -24.167 ... 6 -13.333 9 -6.111 12 -0.952 13 0.455 14 1.739 15 2.917 16 4.000 17 5.000 18 5.926 Not enough in my book. I want to at least affect the first 50, ideally the first hundred or even the first 365. 30 is a high score, but I think it's an admirable start. Here are the results for a base 100x -100 in the AWL before scanning a 30-point email: 1 -35.000 2 -34.356 3 -33.725 ... 10 -29.633 20 -24.622 30 -20.388 40 -16.763 50 -13.624 60 -10.881 70 -8.462 80 -6.313 90 -4.392 100 -2.663 My proposal is a much more "persistent" setting than just cranking the magnitude on the swing. Plus, it should amount to about a single line of code. (In reply to Ian's comment #11) > GTUBE is scored at +1000 points, so AWL whitelist offset should probably be > more. However, we are now drifting outside the scope of this bug. We're not supposed to "protect" against GTUBE. It's scored at 1000 points /specifically/ to bypass things like this. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
