<slaps forehead> I guess the pw_gid/pw_uid fields are numeric. 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 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. :) 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? Charlie -----Original Message----- From: Ken Jones [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 01, 2005 4:46 PM To: vchkpw@inter7.com Subject: Re: [vchkpw] Spamassin configuration On Tuesday 01 March 2005 2:27 pm, Charles J. Boening wrote: <snip> > > 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. We could use one of the pw_gid or pw_uid fields to enable/disable putting the email into a spam folder. We already have a field for enable/disable spamc processing. Since we need a character array for storing a directory location for spam placement, the uid/gid fields would not work. I'd rather not add this space to the vpasswd structure since there is a lot of code that would need to be checked. I'd recommend either a default location compiled into the source or a file in the Maildir directory that only contains the path, like perhaps "spammaildir" Another idea, we make the compile time spamdirectory a configure option that could be overriden by this "spammaildir" file. like: --enable-spam-maildir=".Spam" > > On my system, my $HOME looks something like this: > > . > > |-- .qmail > |-- Maildir > | > | |-- .SPAM > | | > | | |-- cur > | | |-- maildirfolder > | | |-- new > | | > | | `-- tmp > > `-- mailfilter So in this case if we used a "spammaildir" file it could contain ".SPAM" or use --enable-spam-maildir=".SPAM" and forget about having to create a spammaildir file. I wonder if there would be much of an efficency advantage to not looking for a spammaildir file and only using a configure option. It would save a file open/read/close operation. > 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. Good point about auto-creation of the maildir. We should do that! > > 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? We sure could get the pw_gid field to decide to do the spam directory processing from the database lookup. If set we would need to read the spammaildir file. <snip> Ken Jones
