You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Marcin Krol <mr...@gmail.com> on 2008/12/18 18:37:12 UTC
sa-update damages existing SA installation
Hello everyone,
When I run sa-update -D --gpgkey 6C6191E3 --channel
sought.rules.yerp.org, it damages my SA installation!
After the update, I get:
orchidea 192.168.1.1 ~/tmp % spamassassin --lint
[15235] warn: config: warning: score set for non-existent rule URIBL_SBL
[15235] warn: config: warning: score set for non-existent rule URIBL_GREY
[15235] warn: config: warning: score set for non-existent rule URIBL_BLACK
[15235] warn: config: warning: score set for non-existent rule
ENV_AND_HDR_DKIM_MATCH
[15235] warn: config: warning: score set for non-existent rule
USER_IN_DKIM_WHITELIST
[15235] warn: config: warning: score set for non-existent rule
STOCK_IMG_HTML
[15235] warn: config: warning: score set for non-existent rule
STOCK_IMG_CTYPE
...
And my SA doesn't score any mails anymore! I have to purge the existing
SA (dpkg -P spamassassin), reinstall it from scratch, restore conf files
from backups and then it works.
WTF! Does anybody know what goes wrong?
Platform: Debian Etch.
Regards,
Marcin Krol
Re: sa-update damages existing SA installation
Posted by Bill Landry <bi...@inetmsg.com>.
Rosenbaum, Larry M. wrote:
>> From: Daryl C. W. O'Shea [mailto:spamassassin@dostech.ca]
>> Sent: Saturday, December 20, 2008 2:48 AM
>>
>> On 19/12/2008 5:40 AM, Marcin Krol wrote:
>>> Daryl C. W. O'Shea wrote:
>>>> do it all at once. See my SARE sa-update page for details:
>>>> http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt
>>> Are SARE rules still being updated a bit at least / are they still
>> working?
>>
>> The only one really being updated is 90_2tld.cf:
>
> What do I need to put in my sa-update channel file to get updates for 90_2tld.cf?
>
> (I can't get to the "howto" web page above.)
Add: 90_2tld.cf.sare.sa-update.dostech.net
Bill
Re: sa-update damages existing SA installation
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 22/12/2008 12:11 PM, Rosenbaum, Larry M. wrote:
>> From: Daryl C. W. O'Shea [mailto:spamassassin@dostech.ca]
>> Sent: Saturday, December 20, 2008 2:48 AM
>>
>> On 19/12/2008 5:40 AM, Marcin Krol wrote:
>>> Daryl C. W. O'Shea wrote:
>>>> do it all at once. See my SARE sa-update page for details:
>>>> http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt
>>> Are SARE rules still being updated a bit at least / are they still
>> working?
>>
>> The only one really being updated is 90_2tld.cf:
>
> What do I need to put in my sa-update channel file to get updates for 90_2tld.cf?
>
> (I can't get to the "howto" web page above.)
Should be fine now... had a "little" load issue there for a while.
Daryl
RE: sa-update damages existing SA installation
Posted by "Rosenbaum, Larry M." <ro...@ornl.gov>.
> From: Daryl C. W. O'Shea [mailto:spamassassin@dostech.ca]
> Sent: Saturday, December 20, 2008 2:48 AM
>
> On 19/12/2008 5:40 AM, Marcin Krol wrote:
> > Daryl C. W. O'Shea wrote:
> >> do it all at once. See my SARE sa-update page for details:
> >
> >> http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt
> >
> > Are SARE rules still being updated a bit at least / are they still
> working?
>
> The only one really being updated is 90_2tld.cf:
What do I need to put in my sa-update channel file to get updates for 90_2tld.cf?
(I can't get to the "howto" web page above.)
Re: sa-update damages existing SA installation
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 19/12/2008 5:40 AM, Marcin Krol wrote:
> Daryl C. W. O'Shea wrote:
>> do it all at once. See my SARE sa-update page for details:
>
>> http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt
>
> Are SARE rules still being updated a bit at least / are they still working?
The only one really being updated is 90_2tld.cf:
[dos@wally channels]$ pwd ; ls -l | grep -v 2006
/home/dos/sare-sa-updates/channels
total 428
drwxr-xr-x 2 dos dos 4096 Apr 6 2007 00_FVGT_File001.cf
drwxrwxr-x 2 dos dos 4096 Nov 11 2007 70_sare_adult.cf
drwxrwxr-x 2 dos dos 4096 Oct 27 07:14 70_sare_header.cf
drwxrwxr-x 2 dos dos 4096 Oct 27 07:14 70_sare_header3.cf
drwxrwxr-x 2 dos dos 4096 Jun 5 2007 70_sare_obfu.cf
drwxrwxr-x 2 dos dos 4096 Jun 4 2007 70_sare_obfu0.cf
drwxrwxr-x 2 dos dos 4096 Jun 4 2007 70_sare_obfu1.cf
drwxrwxr-x 2 dos dos 4096 Jan 15 2007 70_sare_spoof.cf
drwxrwxr-x 2 dos dos 4096 Aug 18 2007 70_sare_stocks.cf
drwxrwxr-x 2 dos dos 16384 Jan 18 2008 70_sc_top200.cf
drwxrwxr-x 2 dos dos 4096 May 21 2007 72_sare_bml_post25x.cf
drwxrwxr-x 2 dos dos 4096 Jan 2 2007 88_FVGT_headers.cf
drwxr-xr-x 2 dos dos 4096 Dec 13 11:14 90_2tld.cf
-rw-r--r-- 1 dos dos 1687 Nov 22 2007 sare-sa-update-howto.txt
[dos@wally channels]$
Daryl
Re: sa-update damages existing SA installation
Posted by Marcin Krol <mr...@gmail.com>.
Daryl C. W. O'Shea wrote:
> do it all at once. See my SARE sa-update page for details:
> http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt
Are SARE rules still being updated a bit at least / are they still working?
The home page bears warning "IMPORTANT: Due to Ninjas being busy with
lives, wives & hockey matches, SARE rules aren't being updated."
>> Is there a way to *sensibly* combine JM's rules with those from Debian
>> package?
> Is there some reason you don't want to use the updated rules from the
> SpamAssassin project itself? They're essentially from the same people
> with a tiny bit more QA than Justin's sought rules.
No, I just originally did not update default SA rules (added JM_SOUGHT
rules only via sa-update) and then freaked out when spamassassin --lint
showed that BAYES and URIBL rules were not there anymore. :-) I have
tested now that all of my local.cf settings seem to work with updated
default SA rules, so it should be fine.
Regards,
Marcin
Re: sa-update damages existing SA installation
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 18/12/2008 1:00 PM, Marcin Krol wrote:
> Jeff Mincy wrote:
>> Try doing sa-update of the normal rules before you use sa-update of
>> additional rule sets.
>
> Hmm, how do I do that? sa-update -–channel updates.spamassassin.org ?
Sure, or just run sa-update without a channel parameter or so create a
channel file (or use --channel on the command line more than once) and
do it all at once. See my SARE sa-update page for details:
http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt
> Is there a way to *sensibly* combine JM's rules with those from Debian
> package?
Is there some reason you don't want to use the updated rules from the
SpamAssassin project itself? They're essentially from the same people
with a tiny bit more QA than Justin's sought rules.
> Sure, I can do sa-update ... and then move those files
> elsewhere, rename them etc. But is that a right thing to do?
IMO, it's not.
Daryl
Re: sa-update damages existing SA installation
Posted by mouss <mo...@netoyen.net>.
Gene Heskett a écrit :
> On Friday 19 December 2008, mouss wrote:
>> Gene Heskett a écrit :
>>> OTOH, if I run it as root, then the clients have no perms. Tell me a way
>>> around that please.
>> I run it as root, like almost everybody. the "clients" only need read
>> access to the directory, which should be the case by default, unless you
>> played with the root umask.
>>
> I haven't that I recall since reinstalling F8. However, I note that the spamd
> children are running as the user gene. Not root.
>
I was not talking about spamd. I was talking about sa-update. sa-update
is like your package manager (yum, apt, ...), which I'm sure you run as
root.
>>>> the user who scans incoming mail should be used to train (his) bayes.
>
> Mmm, lemme check my script, but I believe that is the case now. Yes, if I
> read correctly what I wrote nearly a year ago.
>
If you store Bayes in sql, you can configure SA so that it "forces" a
single user.
bayes_store_module Mail::SpamAssassin::BayesStore::SQL
bayes_sql_dsn DBI:mysql:spamassassin:127.0.0.1:3306
bayes_sql_override_username spamassassin
bayes_sql_username yoursqluser
bayes_sql_password yoursqlpassword
Re: sa-update damages existing SA installation
Posted by Gene Heskett <ge...@verizon.net>.
On Friday 19 December 2008, mouss wrote:
>Gene Heskett a écrit :
>> OTOH, if I run it as root, then the clients have no perms. Tell me a way
>> around that please.
>
>I run it as root, like almost everybody. the "clients" only need read
>access to the directory, which should be the case by default, unless you
>played with the root umask.
>
I haven't that I recall since reinstalling F8. However, I note that the spamd
children are running as the user gene. Not root.
>>> This is ugly. use a subdirectory. for example
>>> /var/lib/spamassassin/keys, and make this directory only accessible to
>>> the sa-update user (mode 600).
>>
>> Humm, and spec that in the --gpghomedir argument I assume?
>
>yes.
Done, it seems to work. Many thanks Mouss.
[...]
>>> the user who scans incoming mail should be used to train (his) bayes.
Mmm, lemme check my script, but I believe that is the case now. Yes, if I
read correctly what I wrote nearly a year ago.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
"There is no statute of limitations on stupidity."
-- Randomly produced by a computer program called Markov3.
Re: sa-update damages existing SA installation
Posted by mouss <mo...@netoyen.net>.
Gene Heskett a écrit :
> OTOH, if I run it as root, then the clients have no perms. Tell me a way
> around that please.
>
I run it as root, like almost everybody. the "clients" only need read
access to the directory, which should be the case by default, unless you
played with the root umask.
>> This is ugly. use a subdirectory. for example
>> /var/lib/spamassassin/keys, and make this directory only accessible to
>> the sa-update user (mode 600).
>
> Humm, and spec that in the --gpghomedir argument I assume?
>
yes.
>> the user who runs sa-update does so to update the rules. not to scan
>> mail, update Bayes, ... etc. do not use it for that.
>>
>> the user who scans incoming mail should be used to train (his) bayes.
>
> As is being done now.
>>> Thanks for any more guidance, I feel like I need a white cane at this
>>> point. :)
>> as long as you are not a turkey, there aren't much risks these days :)
>
> Nah, just an old fart trying to keep busy. I may eat some turkey though. :)
>
> Thanks everybody.
>
Re: sa-update damages existing SA installation
Posted by Gene Heskett <ge...@verizon.net>.
On Friday 19 December 2008, mouss wrote:
>Gene Heskett a écrit :
>> Stumbling around in the dark, I created that user, and chowned
>> the /var/lib/spamassassin directory to that user:mail, made saupdate a
>> member of group mail.
>
>Why? if you do random mixing of owners and groups, you'll end up making
>your system more vulnerable than it would be if you run sa-update as root.
>
OTOH, if I run it as root, then the clients have no perms. Tell me a way
around that please.
>> The key import complained about unsafe perms
>> of /var/lib/spamassassin, but did import the keys I think:
>> /var/lib/spamassassin:
>> total 40
>> drwxr-xr-x 2 saupdate mail 4096 2008-12-19 08:26 .
>> drwxr-xr-x 39 root root 4096 2008-12-19 00:22 ..
>> -rw------- 1 saupdate saupdate 2783 2008-12-19 08:26 pubring.gpg
>> -rw------- 1 saupdate saupdate 0 2008-12-19 08:26 pubring.gpg~
>> -rw------- 1 saupdate saupdate 0 2008-12-19 08:26 secring.gpg
>> -rw------- 1 saupdate saupdate 1200 2008-12-19 08:26 trustdb.gpg
>
>This is ugly. use a subdirectory. for example
>/var/lib/spamassassin/keys, and make this directory only accessible to
>the sa-update user (mode 600).
Humm, and spec that in the --gpghomedir argument I assume?
>> But now 'su saupdate -c "sa-update --gpghomedir /var/lib/spamassassin"
>> returns:
>> [root@coyote saupdate]# su
>> saupdate -c "sa-update --gpghomedir /var/lib/spamassassin"
>> gpg: WARNING: unsafe permissions on homedir `/var/lib/spamassassin'
>>
>> However, it did seem to do it, and do it nearly instantly as I now have
>> the full menu of cf files present in that /var/lib/spamassassin directory.
>> All dated today.
>>
>> I just checked /usr/share/spamassassin, and root:root owns all of those
>> .cf files, which doesn't seem correct to me, is that correct/ok?
>
>yes, it is correct. files that should not be changed by "anybody" should
>belong to root.
>
>> Now it looks like I have 2 more questions:
>>
>> 1. How do I fix the permissions that gpg is fussing about?
>
>see above (create a subdir...).
>
>> 2. And what do I do to my /etc/init.d/spamassassin script so it will use
>> the newly fetched .cf files instead of the ones in
>> /usr/share/spamassassin?
>
>once you successfully run sa-update, it should be ok. you can verify
>that by runnin spamassassin -D.
>
>> FWIW the user who runs fetchnail/procmail is also a member of group
>> 'mail'.
>>
>> Running spamassassin -D --lint as this new user gets a higher score for
>> the test message than I get when running it as the current user does.
>>
>> As the user saupdate:
>> [...]
>> [12840] dbg: check: is spam? score=4.205 required=5
>> [12840] dbg: check:
>> tests=MISSING_DATE,MISSING_HEADERS,MISSING_SUBJECT,NO_RECEIVED,NO_RELAYS
>> [12840] dbg: check:
>> subtests=__HAS_MSGID,__MISSING_REF,__MSGID_OK_DIGITS,__MSGID_OK_HOST,__MSO
>>E_MID_WRONG_CASE,__NONEMPTY_BODY,__SANE_MSGID,__TVD_BODY,__UNUSABLE_MSGID
>>
>> As the user gene:
>> [12861] dbg: check: is spam? score=3.79 required=5
>> [12861] dbg: check:
>> tests=BAYES_40,MISSING_DATE,MISSING_HEADERS,MISSING_SUBJECT,NO_RECEIVED,NO
>>_RELAYS [12861] dbg: check:
>> subtests=__HAS_MSGID,__MISSING_REF,__MSGID_OK_DIGITS,__MSGID_OK_HOST,__MSO
>>E_MID_WRONG_CASE,__NONEMPTY_BODY,__SANE_MSGID,__TVD_BODY,__UNUSABLE_MSGID
>>
>> The diff being BAYES_40 apparently.
>
>the user who runs sa-update does so to update the rules. not to scan
>mail, update Bayes, ... etc. do not use it for that.
>
>the user who scans incoming mail should be used to train (his) bayes.
As is being done now.
>
>> Thanks for any more guidance, I feel like I need a white cane at this
>> point. :)
>
>as long as you are not a turkey, there aren't much risks these days :)
Nah, just an old fart trying to keep busy. I may eat some turkey though. :)
Thanks everybody.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
"I'm not a god, I was misquoted."
-- Lister, Red Dwarf
Re: sa-update damages existing SA installation
Posted by Gene Heskett <ge...@verizon.net>.
On Friday 19 December 2008, Kai Schaetzl wrote:
>Gene Heskett wrote on Fri, 19 Dec 2008 09:43:13 -0500:
>> Anything else, like setting up a weekly update run in that new users
>> crontab?
>
>sure. I think most people do it daily. If you use sa-compile adds this to
> the script as well.
>
>Kai
I didn't want to abuse the server. sa-compile? I'll check that out, thanks.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
"I'm not a god, I was misquoted."
-- Lister, Red Dwarf
Re: sa-update damages existing SA installation
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 23/12/2008 11:18 AM, Mike Bird wrote:
> Karsten Bräckelmann-2 wrote:
>> Daily is fine, cause it means a single DNS request only most of the
>> time. Updates of the stock rules however usually are less frequent than
>> once a week.
>
> DNS seems to have been reporting 709395 as current for about eight weeks
> now, and a lot of very obvious spam is getting through. Have the stock rule
> updates ceased?
Rule updates are largely dependent on both the amount of time the core
developers have and the amount of spam they are receiving. I for one
seem to have been largely whitelisted as of late and probably wouldn't
have the time to push updates anyway.
Justin's sought rules work good, so try those if you're not already. If
you've got any good rules to contribute send them our way and we'll try
them out for you.
Daryl
Re: sa-update damages existing SA installation
Posted by ji...@jidanni.org.
HK> If SVN does not ring a bell,
Oh, you mean like the example on
http://svn.savannah.gnu.org/viewvc/trunk/grub2/docs/grub.texi?root=grub&view=log
$ svn co svn://svn.sv.gnu.org/grub/trunk/grub2/docs/grub.texi
svn: URL 'svn://svn.sv.gnu.org/grub/trunk/grub2/docs/grub.texi' refers to a file, not a directory
HK> then better stick with the official version. :)
Re: sa-update damages existing SA installation
Posted by Henrik K <he...@hege.li>.
On Sat, Dec 27, 2008 at 04:31:48AM +0800, jidanni@jidanni.org wrote:
> >> DNS seems to have been reporting 709395 as current for about eight weeks
>
> HK> If you want more up-to-date protection, use latest SVN (3.3). That's where
> HK> the development happens. It's been working fine here for a long time.
>
> All I know is I have
> $ crontab -l
> 33 3 * * * PATH=$HOME/bin:$PATH sa-update
> What should I now put there instead?
If SVN does not ring a bell, then better stick with the official version. :)
Nothing you can do if no one pushes updates.
Re: sa-update damages existing SA installation
Posted by ji...@jidanni.org.
>> DNS seems to have been reporting 709395 as current for about eight weeks
HK> If you want more up-to-date protection, use latest SVN (3.3). That's where
HK> the development happens. It's been working fine here for a long time.
All I know is I have
$ crontab -l
33 3 * * * PATH=$HOME/bin:$PATH sa-update
What should I now put there instead?
Re: sa-update damages existing SA installation
Posted by Henrik K <he...@hege.li>.
On Tue, Dec 23, 2008 at 08:18:50AM -0800, Mike Bird wrote:
>
> Karsten Bräckelmann-2 wrote:
> > Daily is fine, cause it means a single DNS request only most of the
> > time. Updates of the stock rules however usually are less frequent than
> > once a week.
>
> DNS seems to have been reporting 709395 as current for about eight weeks
> now, and a lot of very obvious spam is getting through. Have the stock rule
> updates ceased?
If you want more up-to-date protection, use latest SVN (3.3). That's where
the development happens. It's been working fine here for a long time.
Re: sa-update damages existing SA installation
Posted by Mike Bird <mg...@yosemite.net>.
Karsten Bräckelmann-2 wrote:
> Daily is fine, cause it means a single DNS request only most of the
> time. Updates of the stock rules however usually are less frequent than
> once a week.
DNS seems to have been reporting 709395 as current for about eight weeks
now, and a lot of very obvious spam is getting through. Have the stock rule
updates ceased?
--Mike Bird
--
View this message in context: http://www.nabble.com/sa-update-damages-existing-SA-installation-tp21077491p21147137.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: sa-update damages existing SA installation
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Fri, 2008-12-19 at 16:31 +0100, Kai Schaetzl wrote:
> Gene Heskett wrote on Fri, 19 Dec 2008 09:43:13 -0500:
>
> > Anything else, like setting up a weekly update run in that new users crontab?
>
> sure. I think most people do it daily. If you use sa-compile adds this to the
> script as well.
Daily is fine, cause it means a single DNS request only most of the
time. Updates of the stock rules however usually are less frequent than
once a week.
Keep in mind that your dedicated sa-update user now can update your
rules. You still need to restart your spamd though, which only root can
do.
guenther
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: sa-update damages existing SA installation
Posted by Kai Schaetzl <ma...@conactive.com>.
Gene Heskett wrote on Fri, 19 Dec 2008 09:43:13 -0500:
> Anything else, like setting up a weekly update run in that new users crontab?
sure. I think most people do it daily. If you use sa-compile adds this to the
script as well.
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
Re: sa-update damages existing SA installation
Posted by Gene Heskett <ge...@verizon.net>.
On Friday 19 December 2008, Kai Schaetzl wrote:
>Gene Heskett wrote on Fri, 19 Dec 2008 09:04:52 -0500:
>> 2. And what do I do to my /etc/init.d/spamassassin script so it will use
>> the newly fetched .cf files instead of the ones in
>> /usr/share/spamassassin?
>
>is that spamd or what? Reload it.
>
>Kai
Done, thanks Kai.
Anything else, like setting up a weekly update run in that new users crontab?
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Many Myths are based on truth
-- Spock, "The Way to Eden", stardate 5832.3
Re: sa-update damages existing SA installation
Posted by Kai Schaetzl <ma...@conactive.com>.
Gene Heskett wrote on Fri, 19 Dec 2008 09:04:52 -0500:
> 2. And what do I do to my /etc/init.d/spamassassin script so it will use the
> newly fetched .cf files instead of the ones in /usr/share/spamassassin?
is that spamd or what? Reload it.
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
Re: sa-update damages existing SA installation
Posted by mouss <mo...@netoyen.net>.
Gene Heskett a écrit :
> Stumbling around in the dark, I created that user, and chowned
> the /var/lib/spamassassin directory to that user:mail, made saupdate a member
> of group mail.
Why? if you do random mixing of owners and groups, you'll end up making
your system more vulnerable than it would be if you run sa-update as root.
> The key import complained about unsafe perms
> of /var/lib/spamassassin, but did import the keys I think:
> /var/lib/spamassassin:
> total 40
> drwxr-xr-x 2 saupdate mail 4096 2008-12-19 08:26 .
> drwxr-xr-x 39 root root 4096 2008-12-19 00:22 ..
> -rw------- 1 saupdate saupdate 2783 2008-12-19 08:26 pubring.gpg
> -rw------- 1 saupdate saupdate 0 2008-12-19 08:26 pubring.gpg~
> -rw------- 1 saupdate saupdate 0 2008-12-19 08:26 secring.gpg
> -rw------- 1 saupdate saupdate 1200 2008-12-19 08:26 trustdb.gpg
>
This is ugly. use a subdirectory. for example
/var/lib/spamassassin/keys, and make this directory only accessible to
the sa-update user (mode 600).
> But now 'su saupdate -c "sa-update --gpghomedir /var/lib/spamassassin"
> returns:
> [root@coyote saupdate]# su
> saupdate -c "sa-update --gpghomedir /var/lib/spamassassin"
> gpg: WARNING: unsafe permissions on homedir `/var/lib/spamassassin'
>
> However, it did seem to do it, and do it nearly instantly as I now have the
> full menu of cf files present in that /var/lib/spamassassin directory. All
> dated today.
>
> I just checked /usr/share/spamassassin, and root:root owns all of those .cf
> files, which doesn't seem correct to me, is that correct/ok?
>
yes, it is correct. files that should not be changed by "anybody" should
belong to root.
> Now it looks like I have 2 more questions:
>
> 1. How do I fix the permissions that gpg is fussing about?
see above (create a subdir...).
>
> 2. And what do I do to my /etc/init.d/spamassassin script so it will use the
> newly fetched .cf files instead of the ones in /usr/share/spamassassin?
>
once you successfully run sa-update, it should be ok. you can verify
that by runnin spamassassin -D.
> FWIW the user who runs fetchnail/procmail is also a member of group 'mail'.
>
> Running spamassassin -D --lint as this new user gets a higher score for the
> test message than I get when running it as the current user does.
>
> As the user saupdate:
> [...]
> [12840] dbg: check: is spam? score=4.205 required=5
> [12840] dbg: check:
> tests=MISSING_DATE,MISSING_HEADERS,MISSING_SUBJECT,NO_RECEIVED,NO_RELAYS
> [12840] dbg: check:
> subtests=__HAS_MSGID,__MISSING_REF,__MSGID_OK_DIGITS,__MSGID_OK_HOST,__MSOE_MID_WRONG_CASE,__NONEMPTY_BODY,__SANE_MSGID,__TVD_BODY,__UNUSABLE_MSGID
>
> As the user gene:
> [12861] dbg: check: is spam? score=3.79 required=5
> [12861] dbg: check:
> tests=BAYES_40,MISSING_DATE,MISSING_HEADERS,MISSING_SUBJECT,NO_RECEIVED,NO_RELAYS
> [12861] dbg: check:
> subtests=__HAS_MSGID,__MISSING_REF,__MSGID_OK_DIGITS,__MSGID_OK_HOST,__MSOE_MID_WRONG_CASE,__NONEMPTY_BODY,__SANE_MSGID,__TVD_BODY,__UNUSABLE_MSGID
>
> The diff being BAYES_40 apparently.
>
the user who runs sa-update does so to update the rules. not to scan
mail, update Bayes, ... etc. do not use it for that.
the user who scans incoming mail should be used to train (his) bayes.
> Thanks for any more guidance, I feel like I need a white cane at this
> point. :)
as long as you are not a turkey, there aren't much risks these days :)
Re: sa-update damages existing SA installation
Posted by Gene Heskett <ge...@verizon.net>.
On Friday 19 December 2008, mouss wrote:
>Gene Heskett a écrit :
>> On Thursday 18 December 2008, Kai Schaetzl wrote:
>>> Gene Heskett wrote on Thu, 18 Dec 2008 15:13:28 -0500:
>>>> Following the above tut, step 2 fails as root owns the /etc/mail tree,
>>>> and the user running SA has no perms. What should the owner/group
>>>> actually be for that? I changed it to $user:mail and that seemed to fix
>>>> it.
>>>
>>> I assume your are not using sendmail then?
>>
>> Yes, AFAIK I am.
>>
>>> As you import this key only once I'd rather do that step as root. Then
>>> requires root for changing it as well - which I think is good.
>>>
>>>> Now however, I find other spamassassin trees (like
>>>> /usr/share/spamassassin where all these .cf files live) are also owned
>>>> by root, can I just chown them to that user:mail too?
>>>
>>> sa-update does not write to this directory, so you can ignore that. But
>>> you will see problems with writing to /var/lib/spamassassin I suppose.
>>> I'm running sa- update as root, don't know what others are doing.
>>
>> All well and good I presume, but that is also conflicting advice re
>> security. I do ALL my mail fetching and spamassassin stuff as an
>> unpriviledged user clear up to dumping it into a mailfile in
>> /var/mail/$user.
>
>if you run sa-update as the user which scans mail, then any
>vulnerability in SA will allow an attacker to modify your rules and/or
>keys (remember that SA parses mail received from the untrusted network).
>
>if you want to run sa-update as an unprivileged user, then create a
>specific account (say "saupdate") and make it own /var/lib/spamassassin
>and the keys directory. you can make the latter a sub directory of
>/var/lib/spamassassin using --gpghomedir.
>
>> Then as root, I suck that $user file into kmail and sort it to the
>> appropriate folders. Which is why, when I do an sa-learn session, I first
>> pickup the stuff I as root have dropped in the spam directory, copy it to
>> that users scratchpad, chown it to that user, run sa-learn against that,
>> so that there are no clashes in ownership. Once sa-learn is finished with
>> it, it gets nuked till the next days crontab launched repeat.
>>
>> You mentioned /var/lib/spamassassin. It is currently owned by root and
>> empty. Maybe that explains why I feed this viagra crap 20 x a day to
>> sa-learn and it doesn't seem to? What should I do to populate that if its
>> needed after I chown it to $user:mail?
>
>/var/lib/spamassassin is used for rules that you get via sa-update. it
>is not used by sa-learn.
Stumbling around in the dark, I created that user, and chowned
the /var/lib/spamassassin directory to that user:mail, made saupdate a member
of group mail. The key import complained about unsafe perms
of /var/lib/spamassassin, but did import the keys I think:
/var/lib/spamassassin:
total 40
drwxr-xr-x 2 saupdate mail 4096 2008-12-19 08:26 .
drwxr-xr-x 39 root root 4096 2008-12-19 00:22 ..
-rw------- 1 saupdate saupdate 2783 2008-12-19 08:26 pubring.gpg
-rw------- 1 saupdate saupdate 0 2008-12-19 08:26 pubring.gpg~
-rw------- 1 saupdate saupdate 0 2008-12-19 08:26 secring.gpg
-rw------- 1 saupdate saupdate 1200 2008-12-19 08:26 trustdb.gpg
But now 'su saupdate -c "sa-update --gpghomedir /var/lib/spamassassin"
returns:
[root@coyote saupdate]# su
saupdate -c "sa-update --gpghomedir /var/lib/spamassassin"
gpg: WARNING: unsafe permissions on homedir `/var/lib/spamassassin'
However, it did seem to do it, and do it nearly instantly as I now have the
full menu of cf files present in that /var/lib/spamassassin directory. All
dated today.
I just checked /usr/share/spamassassin, and root:root owns all of those .cf
files, which doesn't seem correct to me, is that correct/ok?
Now it looks like I have 2 more questions:
1. How do I fix the permissions that gpg is fussing about?
2. And what do I do to my /etc/init.d/spamassassin script so it will use the
newly fetched .cf files instead of the ones in /usr/share/spamassassin?
FWIW the user who runs fetchnail/procmail is also a member of group 'mail'.
Running spamassassin -D --lint as this new user gets a higher score for the
test message than I get when running it as the current user does.
As the user saupdate:
[...]
[12840] dbg: check: is spam? score=4.205 required=5
[12840] dbg: check:
tests=MISSING_DATE,MISSING_HEADERS,MISSING_SUBJECT,NO_RECEIVED,NO_RELAYS
[12840] dbg: check:
subtests=__HAS_MSGID,__MISSING_REF,__MSGID_OK_DIGITS,__MSGID_OK_HOST,__MSOE_MID_WRONG_CASE,__NONEMPTY_BODY,__SANE_MSGID,__TVD_BODY,__UNUSABLE_MSGID
As the user gene:
[12861] dbg: check: is spam? score=3.79 required=5
[12861] dbg: check:
tests=BAYES_40,MISSING_DATE,MISSING_HEADERS,MISSING_SUBJECT,NO_RECEIVED,NO_RELAYS
[12861] dbg: check:
subtests=__HAS_MSGID,__MISSING_REF,__MSGID_OK_DIGITS,__MSGID_OK_HOST,__MSOE_MID_WRONG_CASE,__NONEMPTY_BODY,__SANE_MSGID,__TVD_BODY,__UNUSABLE_MSGID
The diff being BAYES_40 apparently.
Thanks for any more guidance, I feel like I need a white cane at this
point. :)
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
It doesn't matter what you do, it only matters what you say you've
done and what you're going to do.
Re: sa-update damages existing SA installation
Posted by mouss <mo...@netoyen.net>.
Gene Heskett a écrit :
> On Thursday 18 December 2008, Kai Schaetzl wrote:
>> Gene Heskett wrote on Thu, 18 Dec 2008 15:13:28 -0500:
>>> Following the above tut, step 2 fails as root owns the /etc/mail tree, and
>>> the user running SA has no perms. What should the owner/group actually be
>>> for that? I changed it to $user:mail and that seemed to fix it.
>> I assume your are not using sendmail then?
>
> Yes, AFAIK I am.
>
>> As you import this key only once I'd rather do that step as root. Then
>> requires root for changing it as well - which I think is good.
>>
>>> Now however, I find other spamassassin trees (like /usr/share/spamassassin
>>> where all these .cf files live) are also owned by root, can I just chown
>>> them to that user:mail too?
>> sa-update does not write to this directory, so you can ignore that. But you
>> will see problems with writing to /var/lib/spamassassin I suppose. I'm
>> running sa- update as root, don't know what others are doing.
>
> All well and good I presume, but that is also conflicting advice re security.
> I do ALL my mail fetching and spamassassin stuff as an unpriviledged user
> clear up to dumping it into a mailfile in /var/mail/$user.
>
if you run sa-update as the user which scans mail, then any
vulnerability in SA will allow an attacker to modify your rules and/or
keys (remember that SA parses mail received from the untrusted network).
if you want to run sa-update as an unprivileged user, then create a
specific account (say "saupdate") and make it own /var/lib/spamassassin
and the keys directory. you can make the latter a sub directory of
/var/lib/spamassassin using --gpghomedir.
> Then as root, I suck that $user file into kmail and sort it to the appropriate
> folders. Which is why, when I do an sa-learn session, I first pickup the
> stuff I as root have dropped in the spam directory, copy it to that users
> scratchpad, chown it to that user, run sa-learn against that, so that there
> are no clashes in ownership. Once sa-learn is finished with it, it gets
> nuked till the next days crontab launched repeat.
>
> You mentioned /var/lib/spamassassin. It is currently owned by root and empty.
> Maybe that explains why I feed this viagra crap 20 x a day to sa-learn and it
> doesn't seem to? What should I do to populate that if its needed after I
> chown it to $user:mail?
>
/var/lib/spamassassin is used for rules that you get via sa-update. it
is not used by sa-learn.
Re: sa-update damages existing SA installation
Posted by Gene Heskett <ge...@verizon.net>.
On Thursday 18 December 2008, Kai Schaetzl wrote:
>Gene Heskett wrote on Thu, 18 Dec 2008 15:13:28 -0500:
>> Following the above tut, step 2 fails as root owns the /etc/mail tree, and
>> the user running SA has no perms. What should the owner/group actually be
>> for that? I changed it to $user:mail and that seemed to fix it.
>
>I assume your are not using sendmail then?
Yes, AFAIK I am.
>As you import this key only once I'd rather do that step as root. Then
> requires root for changing it as well - which I think is good.
>
>> Now however, I find other spamassassin trees (like /usr/share/spamassassin
>> where all these .cf files live) are also owned by root, can I just chown
>> them to that user:mail too?
>
>sa-update does not write to this directory, so you can ignore that. But you
> will see problems with writing to /var/lib/spamassassin I suppose. I'm
> running sa- update as root, don't know what others are doing.
All well and good I presume, but that is also conflicting advice re security.
I do ALL my mail fetching and spamassassin stuff as an unpriviledged user
clear up to dumping it into a mailfile in /var/mail/$user.
Then as root, I suck that $user file into kmail and sort it to the appropriate
folders. Which is why, when I do an sa-learn session, I first pickup the
stuff I as root have dropped in the spam directory, copy it to that users
scratchpad, chown it to that user, run sa-learn against that, so that there
are no clashes in ownership. Once sa-learn is finished with it, it gets
nuked till the next days crontab launched repeat.
You mentioned /var/lib/spamassassin. It is currently owned by root and empty.
Maybe that explains why I feed this viagra crap 20 x a day to sa-learn and it
doesn't seem to? What should I do to populate that if its needed after I
chown it to $user:mail?
Thanks Kai.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Operative: "Do you know what your sin is?"
--"Serenity"
Re: sa-update damages existing SA installation
Posted by Kai Schaetzl <ma...@conactive.com>.
Gene Heskett wrote on Thu, 18 Dec 2008 15:13:28 -0500:
> Following the above tut, step 2 fails as root owns the /etc/mail tree, and the
> user running SA has no perms. What should the owner/group actually be for
> that? I changed it to $user:mail and that seemed to fix it.
I assume your are not using sendmail then?
As you import this key only once I'd rather do that step as root. Then requires
root for changing it as well - which I think is good.
> Now however, I find other spamassassin trees (like /usr/share/spamassassin
> where all these .cf files live) are also owned by root, can I just chown them
> to that user:mail too?
sa-update does not write to this directory, so you can ignore that. But you will
see problems with writing to /var/lib/spamassassin I suppose. I'm running sa-
update as root, don't know what others are doing.
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
Re: sa-update damages existing SA installation
Posted by Gene Heskett <ge...@verizon.net>.
On Thursday 18 December 2008, Kai Schaetzl wrote:
>Marcin Krol wrote on Thu, 18 Dec 2008 19:00:55 +0100:
>> Hmm, how do I do that? sa-update -channel updates.spamassassin.org ?
>
>just sa-update. If you want to add other channels you either do it like
>Daryl explains in the link below or one by one.
>
>> Is there a way to *sensibly* combine JM's rules with those from Debian
>> package? Sure, I can do sa-update ... and then move those files
>> elsewhere, rename them etc. But is that a right thing to do?
>
>The "rules from Debian package" should be those rules that were shipped
>with that SA version (3.2.5?). You do *not* want to combine these with the
>updated SA rules. What you want is
>
>- update the "stock" SA rules
>- add/update any rules like sought per your liking
>
>Did you already read "man sa-update" and the available documentation on
>wiki.spamassassin.org?
>-> http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt
Following the above tut, step 2 fails as root owns the /etc/mail tree, and the
user running SA has no perms. What should the owner/group actually be for
that? I changed it to $user:mail and that seemed to fix it.
Now however, I find other spamassassin trees (like /usr/share/spamassassin
where all these .cf files live) are also owned by root, can I just chown them
to that user:mail too?
>-> http://wiki.apache.org/spamassassin/?
>action=fullsearch&context=180&value=sa-update
>
>Kai
Thanks.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Executive ability is prominent in your make-up.
Re: sa-update damages existing SA installation
Posted by Kai Schaetzl <ma...@conactive.com>.
Marcin Krol wrote on Thu, 18 Dec 2008 19:00:55 +0100:
> Hmm, how do I do that? sa-update -channel updates.spamassassin.org ?
just sa-update. If you want to add other channels you either do it like
Daryl explains in the link below or one by one.
>
> Is there a way to *sensibly* combine JM's rules with those from Debian
> package? Sure, I can do sa-update ... and then move those files
> elsewhere, rename them etc. But is that a right thing to do?
The "rules from Debian package" should be those rules that were shipped
with that SA version (3.2.5?). You do *not* want to combine these with the
updated SA rules. What you want is
- update the "stock" SA rules
- add/update any rules like sought per your liking
Did you already read "man sa-update" and the available documentation on
wiki.spamassassin.org?
-> http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt
-> http://wiki.apache.org/spamassassin/?
action=fullsearch&context=180&value=sa-update
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
Re: sa-update damages existing SA installation
Posted by Marcin Krol <mr...@gmail.com>.
Jeff Mincy wrote:
> sa-update puts rules in /var/lib/spamassassin/<VER> Once this directory
> exists all site rules are expected to come from this directory.
I found out that...
>The
> previous installation directory (eg /usr/local/share/spamassassin) is
> ignored.
..but not that. Now it makes sense, thanks!
>
> Try doing sa-update of the normal rules before you use sa-update of
> additional rule sets.
Hmm, how do I do that? sa-update -–channel updates.spamassassin.org ?
Is there a way to *sensibly* combine JM's rules with those from Debian
package? Sure, I can do sa-update ... and then move those files
elsewhere, rename them etc. But is that a right thing to do?
Regards,
Marcin Krol
Re: sa-update damages existing SA installation
Posted by Jeff Mincy <je...@delphioutpost.com>.
From: Marcin Krol <mr...@gmail.com>
Date: Thu, 18 Dec 2008 18:37:12 +0100
Hello everyone,
When I run sa-update -D --gpgkey 6C6191E3 --channel
sought.rules.yerp.org, it damages my SA installation!
sa-update puts rules in /var/lib/spamassassin/<VER> Once this directory
exists all site rules are expected to come from this directory. The
previous installation directory (eg /usr/local/share/spamassassin) is
ignored.
Try doing sa-update of the normal rules before you use sa-update of
additional rule sets.
...
And my SA doesn't score any mails anymore! I have to purge the existing
SA (dpkg -P spamassassin), reinstall it from scratch, restore conf files
from backups and then it works.
WTF! Does anybody know what goes wrong?
Use -D to print see which config files is being read by spamassassin:
% spamassassin --lint -D 2>&1 | fgrep 'config: using'
[31869] dbg: config: using "/etc/mail/spamassassin" for site rules pre files
[31869] dbg: config: using "/var/lib/spamassassin/3.001007" for sys rules pre files
[31869] dbg: config: using "/var/lib/spamassassin/3.001007" for default rules dir
[31869] dbg: config: using "/etc/mail/spamassassin" for site rules dir
[31869] dbg: config: using "/home/jeff/.spamassassin/user_prefs" for user prefs file
[31869] dbg: config: using "/var/lib/spamassassin/3.001007/updates_spamassassin_org/empty.pre" for included file
[31869] dbg: config: using "/var/lib/spamassassin/3.001007/updates_spamassassin_org/10_misc.cf" for included file
[31869] dbg: config: using "/var/lib/spamassassin/3.001007/updates_spamassassin_org/20_advance_fee.cf" for included file
-jeff