On Wed, Apr 28, 2004 at 03:18:57AM -0400, George Georgalis wrote: > On Wed, Apr 28, 2004 at 02:59:12PM +1000, Daniel Pittman wrote: > >On Tue, 27 Apr 2004, Dan Christensen wrote: > >> Daniel Pittman <[EMAIL PROTECTED]> writes: > >>> On Mon, 26 Apr 2004, George Georgalis wrote: > >>>> On Mon, Apr 26, 2004 at 06:44:35PM +0200, LeVA wrote: > >>>>>So when I'm getting a large amount of messages there is approx. > >>>>>15-20 spamc/spamd running. I want to limit this to ~5. > >>>> I suspect if spamc invokes spamd but spamd reached its max-children > >>>> then spamc will act as if spamd timed out, or report ham. > >>> That depends on the options you pass to spamc; I pass -x which says > >>> "report a temp failure in that case", and advise that for general > >>> use. > >> I'm not sure if this is helpful to the original poster, but I invoke > >> spamc from within procmail, and use a lockfile to limit it to one > >> invocation at a time. > >> Does anyone see a problem with this setup? (I use exim as my MTA.) > >No, no problem. This is a pretty high overhead solution, though, and > >the original question was about limiting that overhead. :) > yep. SA is high overhead. the annoying thing is that besides all the > > SA seems the only real choice for an OSS spam filter, but I find the > api, poor, and looking at the code tells me resource efficiency was never > a consideration either. > > I'm wanting to write a program that process mail through SA modules, > but more efficiently. I'm surprised I've not found one out there already. > Maybe scrubber is the answer? http://projects.gasperino.org/scrubber/ > (don't know yet...)
I've had good success with MailScanner which uses SpamAssassin as a perl library. It does not use spamc or spamd. If I understand correctly this approach has far less overhead than the procmail/spamc/spamd approach. http://mailscanner.info -Eric Rz.
