So let me see if I can summarize where this might be going.  A lot has
been talked about on this topic.

Use the pw_uid/pw_gid to check and see if a user wants their mail
filtered.  I'd also suggest setting another bit for delivery.  So we'd
have a bit that says scan for spam and a bit that says deliver to domain
default spam folder (.SPAM or whatever) or not.  This would handle both
the problem of if the user wants their mail scanned and the disposition
of the scanned mail.  The user's only options for tagged spam are to
deliver to inbox so they can filter or deliver to a predetermined spam
container that the domain administrator specifies.

vdelivermail would pull the delivery location for spam from it's command
line or from the domain limits file.  I also think spamc options should
be stored in the same place.  vdelivermail would call spamc.
Personally, I don't think we should offer the ability to call
Spamassassin directly.  It's just not as efficient.  Maybe the spamc
functionality could be compiled right into vdelivermail so no forking is
necessary.  That would be slick!  

Sound about right?  Have I missed anything?


-----Original Message-----
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 
> 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.

Ken Jones

Reply via email to