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? 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
