Brian J. Murrell wrote: > On Thu, 2008-12-04 at 18:35 -0500, Matt Kettler wrote: > >> ie: you >> can't tell sa-learn a message is spam and have it apply that information >> in any way to the AWL. I guess that's really what my point was, and I >> expressed it poorly. >> > > I guess as the OP of this thread, my point was that why shouldn't > sa-learn skew up the (existing) scores in the AWL when it is given a > spam to learn? IOW, if an entry in the AWL doesn't already exist, don't > add one but if there is a matching entry, skew it's scoring to ensure > that the next time it's used for this sender, it adds to the spamminess > score, not subtracts from it. > > I have come to understand via this thread that the > "--add-addr-to-blacklist" (or is it more correctly > "--add-to-blacklist"?) argument effectively does that, adding a "fake" > entry to the AWL representing a spam scored at 100 points. > > My proposal would be to roll up this "--add-to-blacklist" spamassassin > argument into sa-learn --ham with the exception of only modifying an > existing entry, not creating new ones. > Well, part of the point of having sa-learn is to keep it lightweight. Adding the AWL code doesn't really follow along with that.
That said, why add code to sa-learn when spamassassin can already do something even more complete. Try feeding the message "spamassassin -r --add-to-blacklist". Provided you haven't disabled bayes_learn_during_report, the -r will cause bayes learning as spam. As a bonus it will also report the message to spamcop and razor, pyzor, etc if you have them installed.