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