jdow wrote:
From: "Geoff Soper" <[EMAIL PROTECTED]>

Hi,
I'm getting the following three warning in my procmail log (machine name removed, just in case!), I assume I'm missing some configuration somewhere but don't know where! Can someone advise?

Thanks,
Geoff

[8162] warn: config: cannot write to //.spamassassin/user_prefs: No such file or directory [8162] warn: config: failed to create default user preference file //.spamassassin/user_prefs [8162] warn: auto-whitelist: open of auto-whitelist file failed: locker: safe_lock: cannot create tmp lockfile //.spamassassin/auto-whitelist.lock.<<machine_name>>.8162 for //.spamassassin/auto-whitelist.lock: No such file or directory

Somehow you have spamassassin's user setup to have a home directory
of "/". Fix that and you'll be happier. This may be in procmail since
that seems to be how you call SA.

Are you intending to run as a global Bayes and rules or are you
intending to run individual rules and Bayes? Discussion below
presumes individual rules and Bayes.

You need "DROPPRIVS=yes" somewhere near the front of your .procmailrc.
Then you need to call spamc. The sum total would look like this below.
Be sure to replace <username> with the actual user or a macro that
is defined as the the user id.:
===8<---
DROPPRIVS=yes

# Other procmail rules to preprocess email before SpamAssassin
# go here.

# Then we run SpamAssassin via spamc. I run it this way because I
# sometimes put additional procmail rules inside the braces, I don't
# scan files larger than 500k, and I do not scan files to any of the
# spamassassin mailing lists.
:0
* < 500000
* !^List-Id: .*(spamassassin\.apache.\org)
{
  :0 fw: spamassassin.lock
  | /usr/bin/spamc -t 150 -u <username>
}
===8<---

The spamc part can be reduced to this at it's simplest:
===8<---
:0 fw: spamassassin.lock
| /usr/bin/spamc -t 150 -u <username>
===8<---

I included the version I use for such educational value as it might
have.

{^_^}

and then...

Bart Schaefer wrote:
> On 7/5/06, jdow <[EMAIL PROTECTED]> wrote:
>> You need "DROPPRIVS=yes" somewhere near the front of your .procmailrc.
>
> No, you don't.  By the time the .procmailrc is read, privileges have
> already been dropped.  The only place you need DROPPRIVS=yes is in
> /etc/procmailrc in the event that you want to give up privileges
> before the end of that file has been reached.
>
> You should not have an /etc/procmailrc file at all unless you have
> carefully studied what belongs there.
>

I'm afraid this has left me somewhat confused as to what I should do to solve my problem. Maybe it'll help to give more detail of my setup.

My web server (FC4) runs Plesk and Virtuozzo. Once I've used Plesk to set up a domain (domain.tld for example) and an e-mail address (test, for example) at that domain I have a directory along the lines of /var/qmail/mailnames/domain.tld/test . In this directory I have the following file structure:
drwx------  4 popuser popuser 1024 May 24 22:50 .
drwx------  4 popuser popuser 1024 May 24 22:50 ..
-rw-------  1 popuser popuser   18 May 24 22:50 .qmail
drwx------  2 popuser popuser 1024 May 24 22:50 @attachments
drwx------  9 popuser popuser 1024 Jun  1 22:43 Maildir
-rw-------  1 popuser popuser   55 May 24 22:50 user_prefs

.qmail contains the lines:
| true
./Maildir/

which I've altered to:
| true
| /usr/bin/procmail -m ./.procmailrc

and in that .procmailrc :
DIR="./Maildir/"
LOGFILE="./procmail_log"
...
#
# Pipe the mail through spamassassin (replace 'spamassassin' with 'spamc'
# if you use the spamc/spamd combination)
#
# The condition line ensures that only messages smaller than 250 kB
# (250 * 1024 = 256000 bytes) are processed by SpamAssassin. Most spam
# isn't bigger than a few k and working with big messages can bring
# SpamAssassin to its knees.
#
# The lock file ensures that only 1 spamassassin invocation happens
# at 1 time, to keep the load down.
#
:0fw: spamassassin.lock
* < 256000
| /usr/bin/spamassassin

I've no desire to run different configurations for different users or addresses, the single configuration is fine, I just want to solve these errors I'm seeing in the procmail_log file.

I'm not an expert in this kind of thing so appreciate any advice!

Thanks,
Geoff

Reply via email to