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

Reply via email to