<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


-----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:
> 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. 
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.


Ken Jones

Reply via email to