> Guilty, I have thousands of accounts, mostly commercial, and mail
> constantly 24 hours a day. While there are some nice programs out
> to replace qmail-queue or to drop inside a dot qmail file, I really
> to avoid running the perl interpreter (once sometimes twice) for each
> message. I can make better use of system resources elswhere.
> If I understand what Ken is proposing correctly, you could make
> without the spamassassin switch to return to the normal delivery
> continuing to call spamassassin/spamc/procmail/maildrop as before.
> DAve
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
maildrop isn't significant based on the little bit of testing I did.
Besides which, for load there are other improvements to vpopmail which
should be made (such as dynamic linking of vpopmail binaries).
I'm merely asking that the ability to have a message checked be
decoupled from the ability to have it delivered into a SPAM folder, so
that we can pick and choose the features we need.

Reply via email to