I'm very interested in your opinion on this, and want desperately to follow it. You've already put me on the right path of adding to the spamdb and spamdb.helo instead of starting anew and running rebuild spam frequently. That's definitely helped.
Currently we outright reject on DNSBL, URIBL, and Bayesian and score the rest like suspicious helo. I'm not set on these ways. Maybe our corpus isn't good enough, but it always hovers around 1.0, of course that could be with incorrect data. When I reject due to bayesian, it goes to discarded and then I'm manually watching that folder for the time being, adding the confirmed messages to the spam folder. I have bayesian set to reject because there are a lot of messages from hosts that get by greylisting by retrying, come from ip addresses that aren't blacklisted, and don't contain any bad urls. Take messages send from a gmail account (through google's servers), that's just an ad for something with a url that itsn't in the uribl yet. I don't know how I could block a message like that without bayesian rejection. If I'm understanding correctly, the only place it would get a score is bayesian and that wouldn't be enough to reject on its own. I suppose we could have a perfectly crafted bombre, but i don't know how to keep up with the ever changing messages to do that. I'm always afraid of being to strict and having false positives. At the same time, there are lots of administrators who have a conniption fit if a spam message slips through to them. I'm all ears when you h,,ave a moment. THANKS so much for all of your help. You're directly helping hundreds of people here, me especially. I can't imagine email life without you and ASSP. On Sat, Oct 24, 2009 at 10:14 PM, Fritz Borgstedt <[email protected]> wrote: > ASSP development mailing list <[email protected]> > schreibt: >>missed that the new version is out and fixes the issue. > > > By the way: Bayesian blocking and all other scoring is not a > recommended approach for ASSP. I dare to say: to the contrary. > SpamAssassin is working in this way. ASSP should not. > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Assp-test mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/assp-test > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Assp-test mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/assp-test
