I've been following this the last couple days and figured I'd put my $0.02 in.
If you're wanting Spamassassin to be called from vpopmail, how about making it work per domain or per user like simscan does with it's simcontrol file. Then it could be on a per domain basis so you don't have to micromanage. Or if you're hosting multiple domains you could enable or disable on a per domain basis. You could store a vpopcontrol file in the ~vpopmail/domains/<domain> directory. Vdelivermail could read that. Another option would be to just have vpopmail do delivery only. Most of us are either running qmail-scanner or simscan. I recently changed from qmail-scanner to simscan myself. With qmail-scanner or simscan doing Spamassassin, I think all you need is a program to handle the delivery. Currently I have a "stock" mailfilter file called from .qmail for anyone who wants spam filtering. I have a web interface for users to turn it on and off. The web interface just sends an email to a special account who's mailfilter copies the "stock" one and a .qmail file to the user's directory. I saw some discussion the other day about the pw_uid and pw_gid fields in the vpopmail sql tables. I vote to use the unused one (pw_gid IIRC) to store the spam setting. Say relative path to SPAM maildir. If the value is there, then deliver accordingly. If not, deliver to standard delivery location. Also, an environment variable should also be set so maildir/procmail filters can access it as well. On my system, my $HOME looks something like this: . |-- .qmail |-- Maildir | |-- .SPAM | | |-- cur | | |-- maildirfolder | | |-- new | | `-- tmp `-- mailfilter I cut out the irrelevant stuff. For all my users using Spamassassin I filter tagged spam to the .SPAM directory. This shows up right above "Trash" in Squirrelmail. In my mailfilter script I also make sure that the courierimapsubscribed file has the right info so the user can see the directory. The maildir is created the first time the user gets a spam message. Point is that everyone does it different and flexibility is a good thing. IMHO, add the capability to vdelivermail to check the "pw_gid" field or add another data field "pw_spam" and stay away from compiled options. We're doing the database call anyway right? If we're adding Spamassassin support why not add TMDA support as well. :) Call the TMDA script passing it the email, check the return result and decide to deliver or not. If not, then the user isn't authorized via TMDA and a challenge was sent out. Again, this type of thing should be relatively easy to add to vdelivermail. At least the concept is easy. :) Again, we'd have to have a pw_tmda or similar to check and see if we should attempt TMDA delivery. If so, then check for the existence of $HOME/.tmda. If it's not there then create it by calling vadduser-tmda or similar to create the structure and put the right information in the files. Then call tmda-filter and handle delivery based on the return code. I've kind of strayed off the Spamassassin topic but I think something like calling TMDA is more suited to be built into vdelivermail than calling Spamassassin. Let simscan and qmail-scanner take care of calling Spamassassin. Charlie -----Original Message----- From: Bill Wichers [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 01, 2005 11:05 AM To: vchkpw@inter7.com Subject: RE: [vchkpw] Spamassin configuration > 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. -Bill ***************************** Waveform Technology UNIX Systems Administrator
