From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.7.3)
Description of problem:
Each time I run sa-learn on a new mail, fetched with fetchmail, I
get the message "bayes: bad permissions on journal, can't read:
/home/jr/.spamassassin/bayes_journal". This file and sometimes
bayes.lock files in same directory have owner and group changed from
jr:mail to root:mail.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.change permissions of .spamassassin/* to jr:mail
2.fetch mail with fetchmail (as a cron job)
3.launch "sa-learn --spam" on a spam not flaged as such
Actual Results: bayes: bad permissions on journal, can't read:
Expected Results: no change of ownership
Should I rather suspect fetchmail, or cron ?
I tried today to launch fetchmail, not as a cron job. and the owner
of /home/jr/.spamassassin/bayes_journal changed to root:mail. So Ifeel
it's a fetchmail bug.
No news, and it still doesn't work.
Can you please attach the fetchmail config file used when fetchmail is
started from cron?
Make sure you have replaced all passwords by a placeholder text.
here it is:
set postmaster "jr"
set no bouncemail
set no spambounce
set properties ""
poll pop.free.fr with proto POP3
user 'jrwallai' there with password '********' is 'jr' here options
user 'jrodary' there with password '********' is 'jr' here options
user 'lucechauliac' there with password '********'is 'jr' here options
poll srvgim.iu2t.univ-paris8.fr with proto POP3
user 'rodary' there with password '********' is 'jr' here options keep
This confirms that fetchmail just passes the mail to your SMTP
daemon and it is not directly involved with spamassassin at all.
My best guess is that you have incorrectly set up spamassassin
to run from the MTA for all users, perhaps by setting it up in /etc/procmailrc
without using DROPPRIVS; that's just a guess though.
It seems OK with DROPPRIVS=yes in /etc/procmailrc.
I forgot the most important: many thanks.
I spoke too fast, it sill doesn't work,neither with fetchmail lauched manuallyn
nor with a cron job:
[jr@ns ~]$ ll .spamassassin/
-rw------- 1 jr mail 2613248 jun 8 19:21 auto-whitelist
-rw------- 1 jr mail 60 fÃ©v 2 10:07 auto-whitelist.lock.ns.jrodary.org.4927
-rw------- 1 root mail 28104 jun 8 19:21 bayes_journal
-rw------- 1 jr mail 140 nov 11 2004 bayes.lock.ns.jrodary.org.3649
-rw------- 1 jr mail 60 nov 11 2004 bayes.lock.ns.jrodary.org.4388
-rw------- 1 jr mail 60 fÃ©v 2 10:07 bayes.lock.ns.jrodary.org.4943
-rw------- 1 jr mail 160 fÃ©v 2 10:07 bayes.lock.ns.jrodary.org.4947
-rw-rw---- 1 jr mail 1368064 jun 8 17:51 bayes_seen
-rw------- 1 jr mail 5447680 jun 8 17:51 bayes_toks
-rw------- 1 jr mail 589824 jan 26 03:55 bayes_toks.expire950
-rw-rw---- 1 jr mail 1165 fÃ©v 3 2004 user_prefs
You would get exactly the same behavior after submitting a test e-mail
by connecting to port 25 and using SMTP, without fetchmail in the path.
Bugzilla is not a support forum, please consider asking for help configuring
your smtp server at firstname.lastname@example.org or http://fedoraforum.org/.
If you still think this is a Fedora Core bug, please reopen this bug report
against the specific SMTP server you use and provide the configuration
necessary to reproduce the behavior
One and a half year and two fedora releases later, it seems the issue is with
procmail not creating a $HOME/.procmailrc. As soon as I copyed /etc/procmailrc
as $HOME/.procmailrc (with DROPPRIVS=yes), permissions on bayes_journal didn't
Please let other users know.