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
From: Ken Jones [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 02, 2005 7:14 AM
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.
> 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
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.