<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
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
From: Ken Jones [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 01, 2005 4:46 PM
Subject: Re: [vchkpw] Spamassin configuration
On Tuesday 01 March 2005 2:27 pm, Charles J. Boening wrote:
> 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
Another idea, we make the compile time spamdirectory a configure option
that could be overriden by this "spammaildir" file.
> 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
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