> Putting the spamc->spamd calls inside vpopmail makes sense to me.
> However then putting the logic that decides where to deliver the mail,
> and tying those to irrevocably together is what I'm asking not be done.
> I'm in the same load situation as you, my systems do a couple hundred
> thousand local deliveries a day, and invoking spamassassin rather than
> spamc is unthinkable. However the overhead to fork and exec procmail or

No one has suggested non-modifiable behavior. I suggested maybe a
compile-time directive to either do or not-do the filtering, and others
suggested some kind of config file to hold the options (and presumably
configuration info for the options too). All the discussion about the name
of the maildir to use has implied a *default* of "spam", but even worst
case you could always just change that in the source.

Running spamc/spamd directly from vpopmail seems very, very scary to me.
We handle well over 1 million messages/day here and have several beefy
machines front-ending for our mail system that do all the filtering
(ClamAV and Spamassassin). Running Spamassassin on the vpopmail mailstore
box simply does not work from us (nowhere near enough CPU/RAM resources on
the one server). Spamassassin really *is* seperate from vpopmail. The
filtering function could be efficiently implemented in vdelivermail since
that process is already involved in the message delivery, and it would be
nice to not have to involve shell or perl scripts to filter messages into


Waveform Technology
UNIX Systems Administrator

Reply via email to