You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Geoff Soper <ge...@alphaworks.co.uk> on 2006/07/05 14:19:57 UTC

Warnings in procmail log

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



Re: Warnings in procmail log

Posted by Bart Schaefer <ba...@gmail.com>.
On 7/5/06, jdow <jd...@earthlink.net> 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.

Re: Warnings in procmail log

Posted by Bart Schaefer <ba...@gmail.com>.
On 7/9/06, Geoff Soper <ge...@alphaworks.co.uk> wrote:
> Apologies, I've little idea of what is traditional and didn't realise my
> situation was unusual!

I didn't say it was unusual ... it's just not the assumed default
state of affairs.

> I mean all users should have the same rules and spam threshold, subject
> rewriting setting etc.

Including sharing a bayes database (if you're using bayes)?

In that case all you have to do is make sure that the user who is
running spamassassin is not root and has a writable home directory.
If your conjecture that procmail is running as the user "popuser" is
correct, make sure that "popuser" does not have its home directory set
to "/".

Re: Warnings in procmail log

Posted by Geoff Soper <ge...@alphaworks.co.uk>.
Bart Schaefer wrote:
> On 7/8/06, Geoff Soper <ge...@alphaworks.co.uk> wrote:
>> Bart Schaefer wrote:
>> I think I need to specify the .procmailrc as the .procmailrc file is per
>> e-mail address, not per user or even system-wide
>
> I think we've just uncovered a crucial bit of missing information.
>
> You're apparently running procmail in some kind of virtual-user
> environment, where there is no user login name corresponding to the
> email address being processed.  You need to explain these sorts of
> things up front.  All the answers so far have assumed you have a
> traditional unix/linux type environment where mail is delivered to
> individual user accounts that have /etc/passwd file entries, separate
> home directories, etc.
>
> So, forget everything that's been said, and let's start over.
Apologies, I've little idea of what is traditional and didn't realise my 
situation was unusual!

>> > Where is this "./.procmailrc" file that you are trying to read with
>> > the -m option?  That is, what do you expect the current directory
>> > (./) to be at the time procmail runs?
>>
>> the .procmailrc file is in /var/qmail/mailnames/domain.tld/test
>> alongside the .qmail file and the Maildir directory
>
> In that case you need to tell spamassassin to look for its
> configuration files in that location.
I don't want to have a per address/user configuration file, one 
configuration file per system is more than enough.

> There may be a way to finagle the options to "spamassassin" itself to
> make this work, but the easiest approach is to run spamd:
>
>  spamd --create-prefs --virtual-config-dir=/var/qmail/mailnames/%d/%u
>
> (see "man spamd" for other options you might want to pass, such as
> "-m" to limit the number
> of simultaneous processes, etc.).  This is a daemon that needs to run
> as a system service; you may already have an
> /etc/rc.d/init.d/spamassassin or similar script for managing this
> service.  It depends on your OS and whether you built SA yourself or
> installed it with some kind of package management tool (other than
> CPAN).
>
> Then in each appropriate .procmailrc file,
>
> :0fw
> * < 256000
> | /usr/bin/spamc -u test@domain.tld
>
> where you'll need to get the equivalent of "test@domain.tld" for each
> virtual address from somewhere; I don't know enough about qmail to
> tell you how, but if it's not in an environment variable, perhaps you
> can add it to the procmail command line after the ./.procmailrc and
> then refer to it here as $1.
>
>> Just to confirm, the .procmailrc file isn't common to all users but the
>> SA setup is.
>
> I'm no longer sure I understand what you consider to be "the SA setup."
>
I mean all users should have the same rules and spam threshold, subject 
rewriting setting etc.

Re: Warnings in procmail log

Posted by Bart Schaefer <ba...@gmail.com>.
On 7/8/06, Geoff Soper <ge...@alphaworks.co.uk> wrote:
> Bart Schaefer wrote:
> I think I need to specify the .procmailrc as the .procmailrc file is per
> e-mail address, not per user or even system-wide

I think we've just uncovered a crucial bit of missing information.

You're apparently running procmail in some kind of virtual-user
environment, where there is no user login name corresponding to the
email address being processed.  You need to explain these sorts of
things up front.  All the answers so far have assumed you have a
traditional unix/linux type environment where mail is delivered to
individual user accounts that have /etc/passwd file entries, separate
home directories, etc.

So, forget everything that's been said, and let's start over.

> > Where is this "./.procmailrc" file that you are trying to read with
> > the -m option?  That is, what do you expect the current directory
> > (./) to be at the time procmail runs?
>
> the .procmailrc file is in /var/qmail/mailnames/domain.tld/test
> alongside the .qmail file and the Maildir directory

In that case you need to tell spamassassin to look for its
configuration files in that location.

There may be a way to finagle the options to "spamassassin" itself to
make this work, but the easiest approach is to run spamd:

  spamd --create-prefs --virtual-config-dir=/var/qmail/mailnames/%d/%u

(see "man spamd" for other options you might want to pass, such as
"-m" to limit the number
of simultaneous processes, etc.).  This is a daemon that needs to run
as a system service; you may already have an
/etc/rc.d/init.d/spamassassin or similar script for managing this
service.  It depends on your OS and whether you built SA yourself or
installed it with some kind of package management tool (other than
CPAN).

Then in each appropriate .procmailrc file,

:0fw
* < 256000
| /usr/bin/spamc -u test@domain.tld

where you'll need to get the equivalent of "test@domain.tld" for each
virtual address from somewhere; I don't know enough about qmail to
tell you how, but if it's not in an environment variable, perhaps you
can add it to the procmail command line after the ./.procmailrc and
then refer to it here as $1.

> Just to confirm, the .procmailrc file isn't common to all users but the
> SA setup is.

I'm no longer sure I understand what you consider to be "the SA setup."

Re: Warnings in procmail log

Posted by Geoff Soper <ge...@alphaworks.co.uk>.
jdow wrote:
> From: "Geoff Soper" <ge...@alphaworks.co.uk>
>
>> Bart Schaefer wrote:
>>> On 7/8/06, Geoff Soper <ge...@alphaworks.co.uk> wrote:
>>>>
>>>> .qmail contains the lines: | true ./Maildir/
>>>
>>> Caveat:  I don't use qmail, and don't even particularly like qmail,
>>> so what I'm about to say are really educated guesses rather than 
>>> definitive answers.
>>>
>>>> which I've altered to: | true | /usr/bin/procmail -m ./.procmailrc
>>>
>>> No, don't use the -m option.  Just use
>>>
>>> | /usr/bin/procmail
>>>
>>> and let procmail figure out where the $HOME/.procmailrc file is on
>>> its own.  If you want any options to procmail there at all, you want
>>> the "-d recipient" option (where you'll have to get the value for 
>>> "recipient" from qmail somehow, I don't know how).
>>
>>
>> I think I need to specify the .procmailrc as the .procmailrc file is per
>> e-mail address, not per user or even system-wide
>
> This only works if the number of email addresses is equal to or fewer
> than the number of users. The .procmailrc file must reside in the
> user's home directory as "~/.procmailrc". Now you could bend, fold,
> and mutilate a generic .procmailrc file into a global "/etc/procmailrc"
> file. But you still need a place for Bayes and user_prefs. If you go
> to the extent of having SQL based Bayes and user_prefs database then
> you can, I believe, break free of this restriction. You still need
> the mail spool files for delivery to the individual email addresses.

The setup I have with the .procmailrc in each addresses' 
/var/qmail/mailnames/domain.tld/address directory and referenced by 
/var/qmail/mailnames/domain.tld/address/.qmail seems to work perfectltly 
well, though I realise it might not be conventional.

>>>> and in that .procmailrc : DIR="./Maildir/"
>>>
>>> What exactly do you think that's accomplishing?  If you never refer
>>> to $DIR again anywhere, this is meaningless.  If you want to change 
>>> directories, assign to MAILDIR.  If you are trying to force procmail 
>>> to deliver in maildir format, I think what you want is
I'm using $DIR in the recipes which I haven't quoted for clarity when 
delivering to sub folders or to the main folder. An example recipe is:
:0
* ^X-Spam-Status: Yes
${DIR}.spam/

I don't know if my use of $DIR in this way is correct but it works.

>>> DEFAULT="$HOME/Maildir/"
>>>
>>> I'm not sure about the $HOME part, but DEFAULT should never be a 
>>> relative path (never one starting with "./" or with no directory 
>>> reference at all).
>>
>> The recipes (that I didn't quote) refer to $DIR when delivering to that
>> location or any child folders so I'm happy that this is OK, bear in mind
>> my only known problem is these errors relating to SpamAssassin, the 
>> .procmailrc filtering side of things works just fine. It may not be 
>> the most elegant set up as I'm not totally sure of what I'm doing but 
>> it appears to work.
>
> Out of addled curiosity what does procmail think is the $HOME when
> it is running? Have you ever figured that out?
>
I'll get back to you on that one! I doubt it's the 
/var/qmail/mailnames/domain.tld/address directory though.
>>>> 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.
>>>
>>> Where is this "./.procmailrc" file that you are trying to read with 
>>> the -m option?  That is, what do you expect the current directory
>>> (./) to be at the time procmail runs?
>>
>> the .procmailrc file is in /var/qmail/mailnames/domain.tld/test 
>> alongside the .qmail file and the Maildir directory
>
> And you REALLY think "./.procmailrc" points to that file? Off
> hand I don't THINK so.
>
Seriously, it works almost perfectly, the various recipes in the 
.procmail work very well in moving messages around.

>>> If you really want exactly this same config for all users, then you 
>>> should move that ./.procmailrc file (wherever it is) to 
>>> /etc/procmailrc (with no dot) and insert DROPPRIVS=yes somewhere 
>>> before the recipe that runs spamassassin, probably at the very top of
>>>  the file (unless you want all users to write to the same log file as
>>>  well).  If you later add things to /etc/procmailrc, you'll need to 
>>> research whether they belong above or below the DROPPRIVS (below will
>>>  usually be safe, but not always correct).
>>
>> Just to confirm, the .procmailrc file isn't common to all users but 
>> the SA setup is.
>
> All I can say is good luck and quit running procmail as root that way.

I don't think I'm running procmail as root, my suspicion from looking at 
the ownership of the files in the 
/var/qmail/mailnames/domain.tld/address directory is that's running as 
popuser. I'll try and confirm my suspicions.

Thanks,
Geoff


Re: Warnings in procmail log

Posted by jdow <jd...@earthlink.net>.
From: "Geoff Soper" <ge...@alphaworks.co.uk>

> Bart Schaefer wrote:
>> On 7/8/06, Geoff Soper <ge...@alphaworks.co.uk> wrote:
>>> 
>>> .qmail contains the lines: | true ./Maildir/
>> 
>> Caveat:  I don't use qmail, and don't even particularly like qmail,
>> so what I'm about to say are really educated guesses rather than 
>> definitive answers.
>> 
>>> which I've altered to: | true | /usr/bin/procmail -m ./.procmailrc
>> 
>> No, don't use the -m option.  Just use
>> 
>> | /usr/bin/procmail
>> 
>> and let procmail figure out where the $HOME/.procmailrc file is on
>> its own.  If you want any options to procmail there at all, you want
>> the "-d recipient" option (where you'll have to get the value for 
>> "recipient" from qmail somehow, I don't know how).
> 
> 
> I think I need to specify the .procmailrc as the .procmailrc file is per
> e-mail address, not per user or even system-wide

This only works if the number of email addresses is equal to or fewer
than the number of users. The .procmailrc file must reside in the
user's home directory as "~/.procmailrc". Now you could bend, fold,
and mutilate a generic .procmailrc file into a global "/etc/procmailrc"
file. But you still need a place for Bayes and user_prefs. If you go
to the extent of having SQL based Bayes and user_prefs database then
you can, I believe, break free of this restriction. You still need
the mail spool files for delivery to the individual email addresses.

>>> and in that .procmailrc : DIR="./Maildir/"
>> 
>> What exactly do you think that's accomplishing?  If you never refer
>> to $DIR again anywhere, this is meaningless.  If you want to change 
>> directories, assign to MAILDIR.  If you are trying to force procmail 
>> to deliver in maildir format, I think what you want is
> 
>> DEFAULT="$HOME/Maildir/"
>> 
>> I'm not sure about the $HOME part, but DEFAULT should never be a 
>> relative path (never one starting with "./" or with no directory 
>> reference at all).
> 
> The recipes (that I didn't quote) refer to $DIR when delivering to that
> location or any child folders so I'm happy that this is OK, bear in mind
> my only known problem is these errors relating to SpamAssassin, the 
> .procmailrc filtering side of things works just fine. It may not be the 
> most elegant set up as I'm not totally sure of what I'm doing but it 
> appears to work.

Out of addled curiosity what does procmail think is the $HOME when
it is running? Have you ever figured that out?

>>> 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.
>> 
>> Where is this "./.procmailrc" file that you are trying to read with 
>> the -m option?  That is, what do you expect the current directory
>> (./) to be at the time procmail runs?
> 
> the .procmailrc file is in /var/qmail/mailnames/domain.tld/test 
> alongside the .qmail file and the Maildir directory

And you REALLY think "./.procmailrc" points to that file? Off
hand I don't THINK so.

>> If you really want exactly this same config for all users, then you 
>> should move that ./.procmailrc file (wherever it is) to 
>> /etc/procmailrc (with no dot) and insert DROPPRIVS=yes somewhere 
>> before the recipe that runs spamassassin, probably at the very top of
>>  the file (unless you want all users to write to the same log file as
>>  well).  If you later add things to /etc/procmailrc, you'll need to 
>> research whether they belong above or below the DROPPRIVS (below will
>>  usually be safe, but not always correct).
> 
> Just to confirm, the .procmailrc file isn't common to all users but the 
> SA setup is.

All I can say is good luck and quit running procmail as root that way.

{^_^}

Re: Warnings in procmail log

Posted by Geoff Soper <ge...@alphaworks.co.uk>.
Bart Schaefer wrote:
> On 7/8/06, Geoff Soper <ge...@alphaworks.co.uk> wrote:
>> 
>> .qmail contains the lines: | true ./Maildir/
> 
> Caveat:  I don't use qmail, and don't even particularly like qmail,
> so what I'm about to say are really educated guesses rather than 
> definitive answers.
> 
>> which I've altered to: | true | /usr/bin/procmail -m ./.procmailrc
> 
> No, don't use the -m option.  Just use
> 
> | /usr/bin/procmail
> 
> and let procmail figure out where the $HOME/.procmailrc file is on
> its own.  If you want any options to procmail there at all, you want
> the "-d recipient" option (where you'll have to get the value for 
> "recipient" from qmail somehow, I don't know how).


I think I need to specify the .procmailrc as the .procmailrc file is per
e-mail address, not per user or even system-wide

> Incidentally, I have no idea what the purpose of that pipe to true
> is, and I suspect you should just remove it.

I'll err on the side of caution and leave it there!

>> and in that .procmailrc : DIR="./Maildir/"
> 
> What exactly do you think that's accomplishing?  If you never refer
> to $DIR again anywhere, this is meaningless.  If you want to change 
> directories, assign to MAILDIR.  If you are trying to force procmail 
> to deliver in maildir format, I think what you want is

> DEFAULT="$HOME/Maildir/"
> 
> I'm not sure about the $HOME part, but DEFAULT should never be a 
> relative path (never one starting with "./" or with no directory 
> reference at all).

The recipes (that I didn't quote) refer to $DIR when delivering to that
location or any child folders so I'm happy that this is OK, bear in mind
my only known problem is these errors relating to SpamAssassin, the 
.procmailrc filtering side of things works just fine. It may not be the 
most elegant set up as I'm not totally sure of what I'm doing but it 
appears to work.

> 
>> 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.
> 
> Where is this "./.procmailrc" file that you are trying to read with 
> the -m option?  That is, what do you expect the current directory
> (./) to be at the time procmail runs?

the .procmailrc file is in /var/qmail/mailnames/domain.tld/test 
alongside the .qmail file and the Maildir directory

> If you really want exactly this same config for all users, then you 
> should move that ./.procmailrc file (wherever it is) to 
> /etc/procmailrc (with no dot) and insert DROPPRIVS=yes somewhere 
> before the recipe that runs spamassassin, probably at the very top of
>  the file (unless you want all users to write to the same log file as
>  well).  If you later add things to /etc/procmailrc, you'll need to 
> research whether they belong above or below the DROPPRIVS (below will
>  usually be safe, but not always correct).

Just to confirm, the .procmailrc file isn't common to all users but the 
SA setup is.

Thanks,
Geoff



Re: Warnings in procmail log

Posted by Bart Schaefer <ba...@gmail.com>.
On 7/8/06, Geoff Soper <ge...@alphaworks.co.uk> wrote:
>
> .qmail contains the lines:
> | true
> ./Maildir/

Caveat:  I don't use qmail, and don't even particularly like qmail, so
what I'm about to say are really educated guesses rather than
definitive answers.

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

No, don't use the -m option.  Just use

| /usr/bin/procmail

and let procmail figure out where the $HOME/.procmailrc file is on its
own.  If you want any options to procmail there at all, you want the
"-d recipient" option (where you'll have to get the value for
"recipient" from qmail somehow, I don't know how).

Incidentally, I have no idea what the purpose of that pipe to true is,
and I suspect you should just remove it.

> and in that .procmailrc :
> DIR="./Maildir/"

What exactly do you think that's accomplishing?  If you never refer to
$DIR again anywhere, this is meaningless.  If you want to change
directories, assign to MAILDIR.  If you are trying to force procmail
to deliver in maildir format, I think what you want is

DEFAULT="$HOME/Maildir/"

I'm not sure about the $HOME part, but DEFAULT should never be a
relative path (never one starting with "./" or with no directory
reference at all).

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

Where is this "./.procmailrc" file that you are trying to read with
the -m option?  That is, what do you expect the current directory (./)
to be at the time procmail runs?

If you really want exactly this same config for all users, then you
should move that ./.procmailrc file (wherever it is) to
/etc/procmailrc (with no dot) and insert DROPPRIVS=yes somewhere
before the recipe that runs spamassassin, probably at the very top of
the file (unless you want all users to write to the same log file as
well).  If you later add things to /etc/procmailrc, you'll need to
research whether they belong above or below the DROPPRIVS (below will
usually be safe, but not always correct).

Re: Warnings in procmail log

Posted by jdow <jd...@earthlink.net>.
From: "Geoff Soper" <ge...@alphaworks.co.uk>

> jdow wrote:
>> From: "Geoff Soper" <ge...@alphaworks.co.uk>
>> 
>>> 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 <jd...@earthlink.net> 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!

As far as I can see you are so far off into left field the right
fielder is complaining about you encroaching on the far right side
of HIS territory. I'm completely lost wrt what you are trying to do
in the first place.

Do you want per user Bayes and rules? Do you want global? What user is
qmail running as when it goes through procmail? Are you running inside
a jail?

If "user_prefs" is supposed to be the spamassassin user_prefs file then
you have it in the wrong place. You need a directory ".spamassassin"
with rwx permissions for the popuser for the user_prefs and Bayes files.
I notice there is no ".procmailrc" file in the popuser list above. So
I suspect these are all off someplace else which you are not showing
us. Maybe somebody else can make heads or tails of what you have done.
I'm sorry; but, I can't.

{o.o}

Re: Warnings in procmail log

Posted by Geoff Soper <ge...@alphaworks.co.uk>.
jdow wrote:
> From: "Geoff Soper" <ge...@alphaworks.co.uk>
> 
>> 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 <jd...@earthlink.net> 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


Re: Warnings in procmail log

Posted by jdow <jd...@earthlink.net>.
From: "Geoff Soper" <ge...@alphaworks.co.uk>

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

{^_^}

Re: Warnings in procmail log

Posted by Matthias Fuhrmann <Ma...@stud.uni-hannover.de>.
On Wed, 5 Jul 2006, Geoff Soper wrote:

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

should look like: /home/$USER/.spamassassin/auto-whitelist.lock

 looks like the users home is missing somehow; would be of great
help to analyze, if u would send your procmailrc.

regards,
Matthias