From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.7.3) Gecko/20041020 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): spamassassin-3.0.1-0.FC3 How reproducible: Always 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: /home/jr/.spamassassin/bayes_journal Expected Results: no change of ownership Additional info: 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 stripcr pass8bits user 'jrodary' there with password '********' is 'jr' here options stripcr pass8bits user 'lucechauliac' there with password '********'is 'jr' here options stripcr pass8bits poll srvgim.iu2t.univ-paris8.fr with proto POP3 user 'rodary' there with password '********' is 'jr' here options keep pass8bits
Thanks. 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/ total 8032 -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 fedora-list 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 change. Please let other users know.