I'm now using what I'll call a "mixed" configuration of email accounts.
Some are what I'm calling "normal" accounts, which are for users with
HOME directories; Courier delivers email into the user's $HOME/Maildir
subdirectory. The user and group ownership of Maildir are the same as
the unix ownership of the HOME directory.
The other accounts are what I'm calling "virtual" accounts, which are
for for non-shell users. These all live under /var/vmail, and they are
all owned by a single "vmail" owner and "vmail" group. Each maildrop is
a subdirectory such as this: "/var/vmail/us...@domain.com/Maildir", where
"us...@domain.com" is the recipient's email address, and where
"domain.com" is in "hosteddomains".
This works fine except for one key part of my email delivery software
suite: spamassassin. That program looks in each user's HOME directory
(based on the unix uid and gid of the caller to spamassassin or spamc)
for a .spamassassin subdirectory containing that user's spam filtering
directives. For "normal" accounts, there is no problem, but
spamassassin always looks in /var/vmail/.spamassassin for all of the
"virtual" accounts, which means that for them, I can't maintain
per-account spamassassin configuration.
To solve this problem, someone came up with a patch to spamd called
AuthCourier (see http://da.andaka.org/Doku/courier-spamassassin.html)
which causes it to get its idea of a user's HOME directory from
courier-authlib. If this works as advertised, in my case it would cause
spamassassin to look for the .spamassassin subdirectory under
/var/vmail/us...@domain.com instead of under /var/vmail.
This finally brings me to my questions: has anyone had any experience
with AuthCourier and spamd? If so, does it work well? Are there any
Or perhaps is there another solution to my problem that doesn't
require a spamassassin patch? That would be ideal, because then
I wouldn't have to remember to repatch it every time I upgrade.