Using the domainlimits file isn't a bad idea. It doesn't really address scanning on a per user basis. My thoughts on that are if a user doesn't want the spam filtering they can set their score to say 99.
How would we address users who want the spam tagging but want to handle the filtering on their end? On the environment variable option. Is there a way we can set variables for vpopmail? Charlie -----Original Message----- From: Ken Jones [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 02, 2005 7:14 AM To: vchkpw@inter7.com Subject: Re: [vchkpw] Spamassin configuration On Wednesday 02 March 2005 12:22 am, Charles J. Boening wrote: > <slaps forehead> I guess the pw_gid/pw_uid fields are numeric. Yeah. bit flags. > Saving a file open/read/close is a good idea if possible. That's why > I was thinking if the current vpasswd/database structure could be > modified it wouldn't be too bad. I think it's worth trying to not have those operations if possible. Efficency! > I still don't know if I'd be sold on a compile time option. I just > don't think it's as flexible. Which begs the question does it need to > be that flexible. I guess by reading options from a database it makes > it easier when you go to upgrade. One less option to remember while > compiling. :) yeah, we do have a huge number of config options. > Would another option be to pass the spam directory as an option to > vdelivermail in the .qmail-default file for a domain? Granted it > wouldn't address making the spam folder settable on a per user basis > but then again I guess it doesn't really need to be. Check the > pw_gid/pw_uid to see if it's enabled. If so, put spam in the place > specified when vdelivermail was called. > > How about making it an environment variable that could be set via > tcpserver? Checking an environment variable sure is low cost. I think we should definitly check for a variable. I thought of something last night. We could add it to the domain limits structure. That file gets parsed anyway and adding one more option to parse should have almost no processing impact. <snip> Ken Jones
