On Tuesday 01 March 2005 1:05 pm, Bill Wichers wrote: > > 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 > > [snip] > > 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 > mailboxes.
Looks like we are on the same page Bill. On a high volume system like yours we could just check for spamassassin headers to see if it is marked as spam. That should not add too much extra processing since we already read through the email. For a small systems where the load is lower (ours is like this) we could continue to run spamc/spamd in vdelivermail then check the spam headers like above. Of course, both of these would be configurable options. Probably it would be best to have them disabled by default. Ken Jones
