Re: sare channels
jdow wrote:
There is one rule, Ted. If you modify a rule and break it, you get to
keep the pieces.
:-)
Unfortunately, there's too many out there who modify a rule and break it
and then don't realize it.
Ted
{^_-}
- Original Message - From: Ted Mittelstaedt t...@ipinc.net
Sent: Thursday, 2009/August/20 17:25
Dave wrote:
Hi,
Thanks. If the sare rules work great, is it standard practice to use
them and they catch what they catch or look elsewhere?
Pretty much yes. you can also modify them. You can also modify the
stock spamassassin rules.
There's only one rule to follow in spamassassin rules: there are no
rules. Use what works. The more you can customize it to your site the
better it will work. And watch out for doing stuff that will burn your
own house down.
Ted
Thanks.
Dave.
-Original Message-
From: Ted Mittelstaedt [mailto:t...@ipinc.net] Sent: Thursday, August
20, 2009 2:29 PM
Gary Smith wrote:
Read the top of the rulesemporium site:
http://www.rulesemporium.com/
SARE rules aren't being updated. Hence, sa-updating them is pointless.
Is it still recommended to run the SARE rules?
Try them and if they work, great.
Ted
RE: sare channels
On Thu, 2009-08-20 at 17:35 -0700, Gary Smith wrote:
Thanks. I used them years ago back before rulesemporium actually
existed, and I know they had value at the time. I just didn't know if
the rules were migrated into the mainline or something like that.
It's been years since I really had to configure an SA box.
Some are. The rulesemporium site tells you which rule-sets are suitable
for which SA versions, and whether they have been merged upstream.
--
char *t=\10pse\0r\0dtu...@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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: sare channels
Gary Smith a écrit : Read the top of the rulesemporium site: http://www.rulesemporium.com/ SARE rules aren't being updated. Hence, sa-updating them is pointless. Is it still recommended to run the SARE rules? you should use 90_2tld_cf_sare_sa-update_dostech_net to avoid querying uribl for domains that will never be listed. other than that, I have stopped using the other rules after noticing that they bring nothing to my setup. now, my mail flow isn't yours and vice versa. so check for yourself.
Re: sare channels
There is one rule, Ted. If you modify a rule and break it, you get to
keep the pieces.
{^_-}
- Original Message -
From: Ted Mittelstaedt t...@ipinc.net
Sent: Thursday, 2009/August/20 17:25
Dave wrote:
Hi,
Thanks. If the sare rules work great, is it standard practice to use
them and they catch what they catch or look elsewhere?
Pretty much yes. you can also modify them. You can also modify the
stock spamassassin rules.
There's only one rule to follow in spamassassin rules: there are no
rules. Use what works. The more you can customize it to your site the
better it will work. And watch out for doing stuff that will burn your
own house down.
Ted
Thanks.
Dave.
-Original Message-
From: Ted Mittelstaedt [mailto:t...@ipinc.net]
Sent: Thursday, August 20, 2009 2:29 PM
Gary Smith wrote:
Read the top of the rulesemporium site:
http://www.rulesemporium.com/
SARE rules aren't being updated. Hence, sa-updating them is pointless.
Is it still recommended to run the SARE rules?
Try them and if they work, great.
Ted
Re: sare channels
Dave wrote: Hello, I'm trying to add additional sa rules and wanted to use the sare channels referenced by the wiki. I'm using sa 3.2.5 and when i atempted to get updates from saupdates.openprotect.com the channel didn't exist. Has it moved? Thanks. Dave. Read the top of the rulesemporium site: http://www.rulesemporium.com/ SARE rules aren't being updated. Hence, sa-updating them is pointless.
RE: sare channels
Read the top of the rulesemporium site: http://www.rulesemporium.com/ SARE rules aren't being updated. Hence, sa-updating them is pointless. Is it still recommended to run the SARE rules?
Re: sare channels
Gary Smith wrote: Read the top of the rulesemporium site: http://www.rulesemporium.com/ SARE rules aren't being updated. Hence, sa-updating them is pointless. Is it still recommended to run the SARE rules? Try them and if they work, great. Ted
RE: sare channels
Hi, Thanks. If the sare rules work great, is it standard practice to use them and they catch what they catch or look elsewhere? Thanks. Dave. -Original Message- From: Ted Mittelstaedt [mailto:t...@ipinc.net] Sent: Thursday, August 20, 2009 2:29 PM To: Gary Smith Cc: 'Matt Kettler'; 'dave.meh...@gmail.com'; 'users@spamassassin.apache.org' Subject: Re: sare channels Gary Smith wrote: Read the top of the rulesemporium site: http://www.rulesemporium.com/ SARE rules aren't being updated. Hence, sa-updating them is pointless. Is it still recommended to run the SARE rules? Try them and if they work, great. Ted
Re: sare channels
Dave wrote: Hi, Thanks. If the sare rules work great, is it standard practice to use them and they catch what they catch or look elsewhere? Pretty much yes. you can also modify them. You can also modify the stock spamassassin rules. There's only one rule to follow in spamassassin rules: there are no rules. Use what works. The more you can customize it to your site the better it will work. And watch out for doing stuff that will burn your own house down. Ted Thanks. Dave. -Original Message- From: Ted Mittelstaedt [mailto:t...@ipinc.net] Sent: Thursday, August 20, 2009 2:29 PM To: Gary Smith Cc: 'Matt Kettler'; 'dave.meh...@gmail.com'; 'users@spamassassin.apache.org' Subject: Re: sare channels Gary Smith wrote: Read the top of the rulesemporium site: http://www.rulesemporium.com/ SARE rules aren't being updated. Hence, sa-updating them is pointless. Is it still recommended to run the SARE rules? Try them and if they work, great. Ted
Re: sare channels
Gary Smith wrote: Read the top of the rulesemporium site: http://www.rulesemporium.com/ SARE rules aren't being updated. Hence, sa-updating them is pointless. Is it still recommended to run the SARE rules? There's nothing wrong with running them if you want.. but using sa-update on them regularly is utterly pointless..
RE: sare channels
There's nothing wrong with running them if you want.. but using sa-update on them regularly is utterly pointless.. Matt, Thanks. I used them years ago back before rulesemporium actually existed, and I know they had value at the time. I just didn't know if the rules were migrated into the mainline or something like that. It's been years since I really had to configure an SA box. Anyway, I put a couple of them in there and I can already see some of the rules being hit as expected. Gary
sare channels
Hello, I'm trying to add additional sa rules and wanted to use the sare channels referenced by the wiki. I'm using sa 3.2.5 and when i atempted to get updates from saupdates.openprotect.com the channel didn't exist. Has it moved? Thanks. Dave.
sa-update of SARE channels returns multiple Subroutine ... redefined at ... errors
i've SA 317 installed on OSX 10.4.8. i currently use RDJ to update SARE rules w/o error. i use sa-update w/ channel=updates.spamassassin.org, also w/o error. i'm switching to SARE updates via sa-update DOS's channels. on exec of sa-update + SARE channels, i get multiple errors (warnings?) of kind: Subroutine ... redefined at ... again, i see no such errors with RDJ updates. QUESTION: are these errors, in fact, a problem? if so, what/how needs fixing? thanks. verbose details follow here: after a clean install of SA 317, my DATADIR ((...)/SA/Dist/) contains: 10_misc.cf 23_bayes.cf 30_text_fr.cf 20_advance_fee.cf 25_accessdb.cf 30_text_it.cf 20_anti_ratware.cf 25_antivirus.cf 30_text_nl.cf 20_body_tests.cf 25_body_tests_es.cf 30_text_pl.cf 20_compensate.cf 25_body_tests_pl.cf 30_text_pt_br.cf 20_dnsbl_tests.cf 25_dcc.cf50_scores.cf 20_drugs.cf25_dkim.cf 60_awl.cf 20_fake_helo_tests.cf 25_domainkeys.cf 60_whitelist.cf 20_head_tests.cf 25_hashcash.cf 60_whitelist_dk.cf 20_html_tests.cf 25_pyzor.cf 60_whitelist_dkim.cf 20_meta_tests.cf 25_razor2.cf 60_whitelist_spf.cf 20_net_tests.cf25_replace.cf60_whitelist_subject.cf 20_phrases.cf 25_spf.cflanguages 20_porn.cf 25_textcat.cfsa-update-pubkey.txt 20_ratware.cf 25_uribl.cf triplets.txt 20_uri_tests.cf30_text_de.cfuser_prefs.template i've created/edited a channelfile: (...)/SA/sa-update-channels.txt updates.spamassassin.org 70_sare_obfu.cf.sare.sa-update.dostech.net 72_sare_redirect_post3.0.0.cf.sare.sa-update.dostech.net 70_sare_evilnum0.cf.sare.sa-update.dostech.net 70_sare_evilnum1.cf.sare.sa-update.dostech.net 70_sare_bayes_poison_nxm.cf.sare.sa-update.dostech.net 70_sare_header.cf.sare.sa-update.dostech.net 70_sare_header_eng.cf.sare.sa-update.dostech.net 99_sare_fraud_post25x.cf.sare.sa-update.dostech.net 70_sare_spoof.cf.sare.sa-update.dostech.net 70_sare_random.cf.sare.sa-update.dostech.net 70_sc_top200.cf.sare.sa-update.dostech.net 70_sare_oem.cf.sare.sa-update.dostech.net 70_sare_unsub.cf.sare.sa-update.dostech.net 70_sare_uri.cf.sare.sa-update.dostech.net 70_sare_specific.cf.sare.sa-update.dostech.net 70_sare_oem.cf.sare.sa-update.dostech.net 70_sare_html.cf.sare.sa-update.dostech.net 70_sare_genlsubj.cf.sare.sa-update.dostech.net 70_sare_genlsubj_eng.cf.sare.sa-update.dostech.net 70_sare_adult.cf.sare.sa-update.dostech.net 72_sare_bml_post25x.cf.sare.sa-update.dostech.net 70_sare_stocks.cf.sare.sa-update.dostech.net when i execute: sa-update \ --channelfile (...)/SA/sa-update-channels.txt \ --updatedir (...)/SA/Dist \ --gpgkey 856AA88A i get @ console: Subroutine __HAS_RCVD_head_test redefined at /tmp/.spamassassin11389WRDnhPtmp/200510301100.cf, rule __HAS_RCVD, line 6. Subroutine __THEBAT_MUA_head_test redefined at /tmp/.spamassassin11389WRDnhPtmp/200510301100.cf, rule __THEBAT_MUA, line 6. Subroutine __AOL_FROM_head_test redefined at /tmp/.spamassassin11389WRDnhPtmp/200510301100.cf, rule __AOL_FROM, line 6. Subroutine FROM_BLANK_NAME_head_test redefined at /tmp/.spamassassin11389WRDnhPtmp/200510301100.cf, rule FROM_BLANK_NAME, line 6. Subroutine __MIME_VERSION_head_test redefined at /tmp/.spamassassin11389WRDnhPtmp/200510301100.cf, rule __MIME_VERSION, line 6. Subroutine MSGID_SPAM_ALPHA_NUM_head_test redefined at /tmp/.spamassassin11389WRDnhPtmp/200510301100.cf, rule MSGID_SPAM_ALPHA_NUM, line 6. Subroutine MSGID_SPAM_CAPS_head_test redefined at /tmp/.spamassassin11389WRDnhPtmp/200510301100.cf, rule MSGID_SPAM_CAPS, line 6. Subroutine __FROM_EBAY_head_test redefined at /tmp/.spamassassin11389WRDnhPtmp/200607251600.cf, rule __FROM_EBAY, line 6. Subroutine __TOCC_EXISTS_head_test redefined at /tmp/.spamassassin11389WRDnhPtmp/200606040500.cf, rule __TOCC_EXISTS, line 5. Subroutine __CT_TEXT_PLAIN_head_test redefined at /tmp/.spamassassin11389WRDnhPtmp/200606040500.cf, rule __CT_TEXT_PLAIN, line 6. Subroutine __CTYPE_HTML_head_test redefined at /tmp/.spamassassin11389WRDnhPtmp/200606040500.cf, rule __CTYPE_HTML, line 6. Subroutine __NONEMPTY_BODY_body_test redefined at /tmp/.spamassassin11389WRDnhPtmp/200606040500.cf, rule __NONEMPTY_BODY, line 5. Subroutine SUBJECT_DIET_head_test redefined
Re: sa-update of SARE channels returns multiple Subroutine ... redefined at ... errors
OpenMacNews wrote: i've SA 317 installed on OSX 10.4.8. i currently use RDJ to update SARE rules w/o error. i use sa-update w/ channel=updates.spamassassin.org, also w/o error. i'm switching to SARE updates via sa-update DOS's channels. on exec of sa-update + SARE channels, i get multiple errors (warnings?) of kind: Subroutine ... redefined at ... again, i see no such errors with RDJ updates. QUESTION: are these errors, in fact, a problem? if so, what/how needs fixing? thanks. verbose details follow here: after a clean install of SA 317, my DATADIR ((...)/SA/Dist/) contains: What's this DATADIR? Are you referring to what would normally be something like /var/lib/spamassassin/ ? 10_misc.cf 23_bayes.cf 30_text_fr.cf 20_advance_fee.cf 25_accessdb.cf 30_text_it.cf 20_anti_ratware.cf 25_antivirus.cf 30_text_nl.cf 20_body_tests.cf 25_body_tests_es.cf 30_text_pl.cf 20_compensate.cf 25_body_tests_pl.cf 30_text_pt_br.cf 20_dnsbl_tests.cf 25_dcc.cf50_scores.cf 20_drugs.cf25_dkim.cf 60_awl.cf 20_fake_helo_tests.cf 25_domainkeys.cf 60_whitelist.cf 20_head_tests.cf 25_hashcash.cf 60_whitelist_dk.cf 20_html_tests.cf 25_pyzor.cf 60_whitelist_dkim.cf 20_meta_tests.cf 25_razor2.cf 60_whitelist_spf.cf 20_net_tests.cf25_replace.cf60_whitelist_subject.cf 20_phrases.cf 25_spf.cflanguages 20_porn.cf 25_textcat.cfsa-update-pubkey.txt 20_ratware.cf 25_uribl.cf triplets.txt 20_uri_tests.cf30_text_de.cfuser_prefs.template when i execute: sa-update \ --channelfile (...)/SA/sa-update-channels.txt \ --updatedir (...)/SA/Dist \ --gpgkey 856AA88A i get @ console: Subroutine __HAS_RCVD_head_test redefined at /tmp/.spamassassin11389WRDnhPtmp/200510301100.cf, rule __HAS_RCVD, line 6. Since, for some unknown reason, you're using an --updatedir that already has a bunch of rules in it you've now got two copies of the rulesets in the same directory that you are trying load. Not good. Either don't try to override the --updatedir, or make sure that whatever your DATADIR is (what should be something like /usr/share/spamassassin maybe?) isn't the same as your --updatedir (which would normally be /var/lib/spamassassin). after this update, my DATADIR ((...)/SA/Dist/) contains: 10_misc.cf 20_advance_fee.cf 20_anti_ratware.cf 20_body_tests.cf 20_compensate.cf 20_dnsbl_tests.cf 20_drugs.cf 20_fake_helo_tests.cf 20_head_tests.cf 20_html_tests.cf 20_meta_tests.cf 20_net_tests.cf 20_phrases.cf 20_porn.cf 20_ratware.cf 20_uri_tests.cf 23_bayes.cf 25_accessdb.cf 25_antivirus.cf 25_body_tests_es.cf 25_body_tests_pl.cf 25_dcc.cf 25_dkim.cf 25_domainkeys.cf 25_hashcash.cf 25_pyzor.cf 25_razor2.cf 25_replace.cf 25_spf.cf 25_textcat.cf 25_uribl.cf 30_text_de.cf 30_text_fr.cf 30_text_it.cf 30_text_nl.cf 30_text_pl.cf 30_text_pt_br.cf 50_scores.cf 60_awl.cf 60_whitelist.cf 60_whitelist_dk.cf 60_whitelist_dkim.cf 60_whitelist_spf.cf 60_whitelist_subject.cf 70_sare_adult_cf_sare_sa-update_dostech_net/ 70_sare_adult_cf_sare_sa-update_dostech_net.cf 70_sare_bayes_poison_nxm_cf_sare_sa-update_dostech_net/ 70_sare_bayes_poison_nxm_cf_sare_sa-update_dostech_net.cf 70_sare_evilnum0_cf_sare_sa-update_dostech_net/ 70_sare_evilnum0_cf_sare_sa-update_dostech_net.cf 70_sare_evilnum1_cf_sare_sa-update_dostech_net/ 70_sare_evilnum1_cf_sare_sa-update_dostech_net.cf 70_sare_genlsubj_cf_sare_sa-update_dostech_net/ 70_sare_genlsubj_cf_sare_sa-update_dostech_net.cf 70_sare_genlsubj_eng_cf_sare_sa-update_dostech_net/ 70_sare_genlsubj_eng_cf_sare_sa-update_dostech_net.cf 70_sare_header_cf_sare_sa-update_dostech_net/ 70_sare_header_cf_sare_sa-update_dostech_net.cf 70_sare_header_eng_cf_sare_sa-update_dostech_net/ 70_sare_header_eng_cf_sare_sa-update_dostech_net.cf 70_sare_html_cf_sare_sa-update_dostech_net/ 70_sare_html_cf_sare_sa-update_dostech_net.cf 70_sare_obfu_cf_sare_sa-update_dostech_net/ 70_sare_obfu_cf_sare_sa-update_dostech_net.cf 70_sare_oem_cf_sare_sa-update_dostech_net/ 70_sare_oem_cf_sare_sa-update_dostech_net.cf 70_sare_random_cf_sare_sa-update_dostech_net/ 70_sare_random_cf_sare_sa-update_dostech_net.cf 70_sare_specific_cf_sare_sa-update_dostech_net/ 70_sare_specific_cf_sare_sa-update_dostech_net.cf 70_sare_spoof_cf_sare_sa-update_dostech_net/ 70_sare_spoof_cf_sare_sa-update_dostech_net.cf 70_sare_stocks_cf_sare_sa-update_dostech_net/ 70_sare_stocks_cf_sare_sa-update_dostech_net.cf 70_sare_unsub_cf_sare_sa
Re: sa-update of SARE channels returns multiple Subroutine ... redefined at ... errors
after a clean install of SA 317, my DATADIR ((...)/SA/Dist/) contains: What's this DATADIR? Are you referring to what would normally be something like /var/lib/spamassassin/ ? DATADIR is what i've specified as my DATADIR @ build time. from (distro)/3.1/README: File Locations: SpamAssassin will look in a number of areas to find the default configuration files that are used. The __*__ text are variables whose value you can see by looking at the first several lines of the spamassassin or spamd scripts. They are set on install time and can be overridden with the Makefile.PL command line options DATADIR (for __def_rules_dir__) and CONFDIR (for __local_rules_dir__). If none of these options were given, FHS-compliant locations based on the PREFIX (which becomes __prefix__) are chosen. These are: __prefix____def_rules_dir__ __local_rules_dir__ - /usr /usr/share/spamassassin/etc/mail/spamassassin /usr/local/usr/local/share/spamassassin /etc/mail/spamassassin /opt/$DIR /opt/$DIR/share/spamassassin /etc/opt/mail/spamassassin $DIR $DIR/share/spamassassin $DIR/etc/mail/spamassassin unknown reason, The reason is that that's my understanding of the documentation. til now, with just sa-update of updates.spamassain.org, i've been using: sa-update \ --channel updates.spamassassin.org \ --updatedir /var/SA/Dist i.e., defining --updatedir=$DATADIR, and all's been working fine. It may well be incorrect. It may obvious to all others. Not to me. Hence, I'm asking a question. you're using an --updatedir that already has a bunch of rules in it you've now got two copies of the rulesets in the same directory that you are trying load. Not good. ok. Either don't try to override the --updatedir, or make sure that whatever your DATADIR is (what should be something like /usr/share/spamassassin maybe?) isn't the same as your --updatedir (which would normally be /var/lib/spamassassin). ... No, not at all. There should be no plain ruleset files in the directory that contains all of the channel directories and .cf files. ok. given my build config of: perl Makefile.PL \ PREFIX=/usr/local/spamassassin \ DATADIR=/var/SA/Dist \ CONFDIR=/var/SA/Local \ ENABLE_SSL=yes \ LDDLFLAGS=-L/usr/local/ssl/lib -lssl -lcrypto \ LDFLAGS=-bind_at_load -L/usr/local/ssl/lib -lssl -lcrypto -ldl \ INC=-I/usr/local/ssl/include and that i invoke sa-update with: sa-update \ --channelfile /var/SA/sa-update-channels.txt \ --updatedir /var/SA/Dist \ --gpgkey 856AA88A can you please specifically clarify/suggest, should I: (a) *not* define --updatedir (b) define --updatedir=$DATADIR (c) define --updatedir=$CONFDIR (d) define --updatedir=$somewhereelse in other words, where _should_ the updates now go? /\ \ / ASCII Ribbon Campaign X against HTML email, vCards / \ micro$oft attachments [GPG] OpenMacNews at gmail dot com fingerprint: 50C9 1C46 2F8F DE42 2EDB D460 95F7 DDBD 3671 08C6
Re: sa-update of SARE channels returns multiple Subroutine ... redefined at ... errors
OpenMacNews wrote: after a clean install of SA 317, my DATADIR ((...)/SA/Dist/) contains: What's this DATADIR? Are you referring to what would normally be something like /var/lib/spamassassin/ ? DATADIR is what i've specified as my DATADIR @ build time. Mmm... it's not too often that people report problems that have changed the defaults. from (distro)/3.1/README: File Locations: SpamAssassin will look in a number of areas to find the default configuration files that are used. The __*__ text are variables whose value you can see by looking at the first several lines of the spamassassin or spamd scripts. They are set on install time and can be overridden with the Makefile.PL command line options DATADIR (for __def_rules_dir__) and CONFDIR (for __local_rules_dir__). If none of these options were given, FHS-compliant locations based on the PREFIX (which becomes __prefix__) are chosen. These are: __prefix____def_rules_dir__ __local_rules_dir__ - /usr /usr/share/spamassassin/etc/mail/spamassassin /usr/local/usr/local/share/spamassassin /etc/mail/spamassassin /opt/$DIR /opt/$DIR/share/spamassassin /etc/opt/mail/spamassassin $DIR $DIR/share/spamassassin $DIR/etc/mail/spamassassin Well, the local state dir option doesn't seem to be documented (which is probably a valid bug), but I believe you could set it with LOCALSTATEDIR. unknown reason, The reason is that that's my understanding of the documentation. I'm not entirely sure which documentation you are referring to. The sa-update documentation doesn't seem to suggest that the default --updatedir is the same as the default DATADIR. The how-to for the SARE channels doesn't mention anything about using --updatedir in the example sa-update command either. til now, with just sa-update of updates.spamassain.org, i've been using: sa-update \ --channel updates.spamassassin.org \ --updatedir /var/SA/Dist i.e., defining --updatedir=$DATADIR, and all's been working fine. I'm not sure why it worked for you before. You're now seeing the official rules being loaded twice too, not just the ones from the SARE channels. It may well be incorrect. It may obvious to all others. Not to me. Hence, I'm asking a question. you're using an --updatedir that already has a bunch of rules in it you've now got two copies of the rulesets in the same directory that you are trying load. Not good. ok. Either don't try to override the --updatedir, or make sure that whatever your DATADIR is (what should be something like /usr/share/spamassassin maybe?) isn't the same as your --updatedir (which would normally be /var/lib/spamassassin). ... No, not at all. There should be no plain ruleset files in the directory that contains all of the channel directories and .cf files. ok. given my build config of: perl Makefile.PL \ PREFIX=/usr/local/spamassassin \ DATADIR=/var/SA/Dist \ CONFDIR=/var/SA/Local \ ENABLE_SSL=yes \ LDDLFLAGS=-L/usr/local/ssl/lib -lssl -lcrypto \ LDFLAGS=-bind_at_load -L/usr/local/ssl/lib -lssl -lcrypto -ldl \ INC=-I/usr/local/ssl/include DATADIR isn't really variable... it should only contain the rules that ship with the tarball, and never be updated. I'd stick with the default, which follows FHS, of /usr/share/spamassassin or even use /usr/local/share/spamassassin. and that i invoke sa-update with: sa-update \ --channelfile /var/SA/sa-update-channels.txt \ --updatedir /var/SA/Dist \ --gpgkey 856AA88A can you please specifically clarify/suggest, should I: (a) *not* define --updatedir That'll work. I'd do that. (b) define --updatedir=$DATADIR That's what you're doing now, and won't work. (c) define --updatedir=$CONFDIR That'd probably work, but isn't a good idea. (d) define --updatedir=$somewhereelse That'll work too (as long as $somewhereelse != $DATADIR), but unless you have a problem with the default of /var/lib/spamassassin, I don't see a reason to change it. in other words, where _should_ the updates now go? Well, according to FHS, they should go somewhere in /var. DATADIR should be somewhere in /usr and CONFDIR somewhere in /etc, just like the defaults. Daryl
Re: sa-update of SARE channels returns multiple Subroutine ... redefined at ... errors
following up with actual tests of each of the aforementioned cases: (a) *not* define --updatedir (b) define --updatedir=$DATADIR (c) define --updatedir=$CONFDIR (d) define --updatedir=$somewhereelse for an sa-update run, given my build config of: perl Makefile.PL \ PREFIX=/usr/local/spamassassin \ DATADIR=/var/SA/Dist \ CONFDIR=/var/SA/Local \ ENABLE_SSL=yes \ LDDLFLAGS=-L/usr/local/ssl/lib -lssl -lcrypto \ LDFLAGS=-bind_at_load -L/usr/local/ssl/lib -lssl -lcrypto -ldl \ INC=-I/usr/local/ssl/include and ensuring I clean/remove prior kruft installed in updatedir/ and /tmp/ in each case, results are: CASE: (a) *not* define --updatedir sa-update \ --channelfile /var/SA/sa-update-channels.txt \ --gpgkey 856AA88A Subroutine __HAS_RCVD_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/200510301100.cf, rule __HAS_RCVD, line 6. Subroutine __THEBAT_MUA_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/200510301100.cf, rule __THEBAT_MUA, line 6. Subroutine __AOL_FROM_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/200510301100.cf, rule __AOL_FROM, line 6. Subroutine FROM_BLANK_NAME_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/200510301100.cf, rule FROM_BLANK_NAME, line 6. Subroutine __MIME_VERSION_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/200510301100.cf, rule __MIME_VERSION, line 6. Subroutine MSGID_SPAM_ALPHA_NUM_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/200510301100.cf, rule MSGID_SPAM_ALPHA_NUM, line 6. Subroutine MSGID_SPAM_CAPS_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/200510301100.cf, rule MSGID_SPAM_CAPS, line 6. Subroutine __FROM_EBAY_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/200607251600.cf, rule __FROM_EBAY, line 6. Subroutine __TOCC_EXISTS_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/200606040500.cf, rule __TOCC_EXISTS, line 5. Subroutine __CT_TEXT_PLAIN_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/200606040500.cf, rule __CT_TEXT_PLAIN, line 6. Subroutine __CTYPE_HTML_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/200606040500.cf, rule __CTYPE_HTML, line 6. Subroutine __NONEMPTY_BODY_body_test redefined at /tmp/.spamassassin11590RpRcIytmp/200606040500.cf, rule __NONEMPTY_BODY, line 5. Subroutine __SARE_SUB_OBFU_LQUOT_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/20051227.cf, rule __SARE_SUB_OBFU_LQUOT, line 6. Subroutine __SARE_SUB_OBFU_PERIOD_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/20051227.cf, rule __SARE_SUB_OBFU_PERIOD, line 6. Subroutine __SARE_SUB_OBFU_CARAT_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/20051227.cf, rule __SARE_SUB_OBFU_CARAT, line 6. Subroutine __SARE_SUB_OBFU_SCOLON_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/20051227.cf, rule __SARE_SUB_OBFU_SCOLON, line 6. Subroutine __SARE_SUB_OBFU_ASTER_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/20051227.cf, rule __SARE_SUB_OBFU_ASTER, line 6. Subroutine __SARE_SUB_OBFU_COLON_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/20051227.cf, rule __SARE_SUB_OBFU_COLON, line 6. Subroutine __SARE_SUB_OBFU_PIPE_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/20051227.cf, rule __SARE_SUB_OBFU_PIPE, line 6. Subroutine __SARE_SUB_OBFU_2PER_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/20051227.cf, rule __SARE_SUB_OBFU_2PER, line 6. Subroutine __SARE_SUB_OBFU_COMMA_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/20051227.cf, rule __SARE_SUB_OBFU_COMMA, line 6. Subroutine __SARE_SUB_OBFU_QUOTE_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/20051227.cf, rule __SARE_SUB_OBFU_QUOTE, line 6. Subroutine __SARE_SUB_OBFU_HTTP_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/20051227.cf, rule __SARE_SUB_OBFU_HTTP, line 6. Subroutine __SARE_SUB_OBFU_PLUS_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/20051227.cf, rule __SARE_SUB_OBFU_PLUS, line 6. Subroutine __SARE_SUB_OBFU_USCORE_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/20051227.cf, rule __SARE_SUB_OBFU_USCORE, line 6. Subroutine __SARE_SUB_OBFU_SLASH_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/20051227.cf, rule __SARE_SUB_OBFU_SLASH, line 6. Subroutine __RATWARE_0_TZ_DATE_head_test redefined at /tmp/.spamassassin11590RpRcIytmp/200610182000.cf, rule __RATWARE_0_TZ_DATE, line 6. CASE: (b) define --updatedir=$DATADIR sa-update \ --channelfile /var/SA/sa-update-channels.txt \ --updatedir /var/SA/Dist \ --gpgkey 856AA88A RESULT: SAME AS ABOVE ... CASE: (c) define --updatedir=$CONFDIR sa-update \ --channelfile /var/SA/sa-update-channels.txt \ --updatedir /var/SA/Local \
Re: sa-update of SARE channels returns multiple Subroutine ... redefined at ... errors
If you're seeing subroutine redefined warnings you're loading the same rules more than once, period. Run spamassassin --lint -D and make note of what directories it's loading rules from. Then go and blow away those directories (be careful not to delete things you don't have a copy of... like stuff in your local site directory) and start over. I'd suggest not altering the build defaults, but if you must, don't use the same directory for any two things. Daryl
Re: sa-update of SARE channels returns multiple Subroutine ... redefined at ... errors
starting a clean build where my init dir contains only: % ls -1R /var/SA Local/ rules_du_jour.conf sa-update-channels.txt ./Local: ImageInfo.pm init.pre local.cf local.cf.20061018 razor-agent.log sa-update-keys/ ./Local/sa-update-keys: pubring.gpg secring.gpg trustdb.gpg building a fresh co of SA 317 w/: perl Makefile.PL \ PREFIX=/usr/local/spamassassin \ DATADIR=/var/SA/Dist \ CONFDIR=/var/SA/Local \ ENABLE_SSL=yes \ LDDLFLAGS=-L/usr/local/ssl/lib -lssl -lcrypto \ LDFLAGS=-bind_at_load -L/usr/local/ssl/lib -lssl -lcrypto -ldl \ INC=-I/usr/local/ssl/include ... make install mv /var/SA/Local/v310.pre /var/SA/Local/v310.preORIG mv /var/SA/Local/v312.pre /var/SA/Local/v312.preORIG then checking: % ls -R /var/SA/ /var/SA/: Dist/ Local/ rules_du_jour.conf sa-update-channels.txt /var/SA/Dist: 10_misc.cf 23_bayes.cf 30_text_fr.cf 20_advance_fee.cf 25_accessdb.cf 30_text_it.cf 20_anti_ratware.cf 25_antivirus.cf 30_text_nl.cf 20_body_tests.cf 25_body_tests_es.cf 30_text_pl.cf 20_compensate.cf 25_body_tests_pl.cf 30_text_pt_br.cf 20_dnsbl_tests.cf 25_dcc.cf50_scores.cf 20_drugs.cf25_dkim.cf 60_awl.cf 20_fake_helo_tests.cf 25_domainkeys.cf 60_whitelist.cf 20_head_tests.cf 25_hashcash.cf 60_whitelist_dk.cf 20_html_tests.cf 25_pyzor.cf 60_whitelist_dkim.cf 20_meta_tests.cf 25_razor2.cf 60_whitelist_spf.cf 20_net_tests.cf25_replace.cf 60_whitelist_subject.cf 20_phrases.cf 25_spf.cflanguages 20_porn.cf 25_textcat.cfsa-update-pubkey.txt 20_ratware.cf 25_uribl.cf triplets.txt 20_uri_tests.cf30_text_de.cfuser_prefs.template /var/SA/Local: ImageInfo.pm local.cf razor-agent.log v310.preORIG init.pre local.cf.20061018 sa-update-keys/ v312.preORIG /var/SA/Local/sa-update-keys: pubring.gpg secring.gpg trustdb.gpg running an sa-update, per your instructions without --updatedir defined: sa-update \ --channelfile /var/SA/sa-update-channels.txt \ --gpgkey 856AA88A i get, yet once again, @ shell, the same as before: Subroutine __HAS_RCVD_head_test redefined at /tmp/.spamassassin15766jDBiWjtmp/200510301100.cf, rule __HAS_RCVD, line 6. Subroutine __THEBAT_MUA_head_test redefined at /tmp/.spamassassin15766jDBiWjtmp/200510301100.cf, rule __THEBAT_MUA, line 6. Subroutine __AOL_FROM_head_test redefined at /tmp/.spamassassin15766jDBiWjtmp/200510301100.cf, rule __AOL_FROM, line 6. Subroutine FROM_BLANK_NAME_head_test redefined at /tmp/.spamassassin15766jDBiWjtmp/200510301100.cf, rule FROM_BLANK_NAME, line 6. etc etc ... as LOCALSATEDIR is, apparently, normally derived from $PREFIX: 'LOCALSTATEDIR',# normally determined based on $*PREFIX. , which in my case is: PREFIX=/usr/local/spamassassin in the case above of --updatedir=(undef), i do note that, after sa-update, i have now, as expected: % ls /usr/local/spamassassin/var/spamassassin/3.001007 70_sare_adult_cf_sare_sa-update_dostech_net/ 70_sare_random_cf_sare_sa-update_dostech_net.cf 70_sare_adult_cf_sare_sa-update_dostech_net.cf 70_sare_specific_cf_sare_sa-update_dostech_net/ 70_sare_bayes_poison_nxm_cf_sare_sa-update_dostech_net/ 70_sare_specific_cf_sare_sa-update_dostech_net.cf 70_sare_bayes_poison_nxm_cf_sare_sa-update_dostech_net.cf 70_sare_spoof_cf_sare_sa-update_dostech_net/ 70_sare_evilnum0_cf_sare_sa-update_dostech_net/ 70_sare_spoof_cf_sare_sa-update_dostech_net.cf 70_sare_evilnum0_cf_sare_sa-update_dostech_net.cf 70_sare_stocks_cf_sare_sa-update_dostech_net/ 70_sare_evilnum1_cf_sare_sa-update_dostech_net/ 70_sare_stocks_cf_sare_sa-update_dostech_net.cf 70_sare_evilnum1_cf_sare_sa-update_dostech_net.cf 70_sare_unsub_cf_sare_sa-update_dostech_net/ 70_sare_genlsubj_cf_sare_sa-update_dostech_net/ 70_sare_unsub_cf_sare_sa-update_dostech_net.cf 70_sare_genlsubj_cf_sare_sa-update_dostech_net.cf 70_sare_uri_cf_sare_sa-update_dostech_net/ 70_sare_genlsubj_eng_cf_sare_sa-update_dostech_net/
