You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Gene Heskett <ge...@verizon.net> on 2007/08/13 04:22:19 UTC
So lets change it to "sa-update doesn't"
On Sunday 12 August 2007, Kai Schaetzl wrote:
>Gene Heskett wrote on Sat, 11 Aug 2007 23:43:38 -0400:
>> 1: sa-update is NOT pulling new PDFInfo.pm or pdfinfo.cf files even when
>> they are available.
>
>of course not!
>
And why not? They've been announced as available, so one would assume a
simple run of sa-update would pull them.
>> 2: spamassassin --lint -D ignores these rules when we install them by
>> hand.
>
>which means you probably haven't installed PDFInfo correctly?
[root@coyote rulesdujour]# ls -l `locate PDFInfo.pm`
-rw-r--r-- 1 root root 23475 Aug 11
05:38 /etc/mail/spamassassin/RulesDuJour/PDFInfo.pm
-rw-r--r-- 1 root root 23475 Aug 11 05:40 /etc/rulesdujour/PDFInfo.pm
-rw-r--r-- 1 root root 23475 Aug 11
05:41 /usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin/Plugin/PDFInfo.pm
[root@coyote rulesdujour]# ls -l `locate pdfinfo.cf`
-rw-r--r-- 1 root root 19863 Aug 11 05:42 /etc/mail/spamassassin/pdfinfo.cf
-rw-r--r-- 1 root root 19863 Aug 11
05:39 /etc/mail/spamassassin/RulesDuJour/pdfinfo.cf
-rw-r--r-- 1 root root 19863 Aug 11 05:41 /etc/rulesdujour/pdfinfo.cf
-rw-r--r-- 1 root root 19863 Aug 11
05:42 /var/lib/spamassassin/3.002001/saupdates_openprotect_com/pdfinfo.cf
>> Now is the question sufficiently illuminated?
>
>Not at all. This is your first posting in this thread. This thread is about
>"rule for empty text + GIF or PDF". Your posting is about "how do I install
> or make use of PDFInfo". So, please go ahead and post a new thread and
> include all the information that is necessary for others to help you. If
> you did that already elsewhere, then please keep going there. But please
> don't hijack threads with completely different topics and pretend it fits.
>
>Kai
I'm not sure, playing this back in my memory, how it got into this thread, so
my apologies. I've made at least 2 other posts about this, both of which
were ignored except for Lorens ack on one of them when I confirmed the --lint
errors someone else had reported.
So what file to we add something to, to enable this, and what do we add to it?
--
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)
You will be awarded the Nobel Peace Prize... posthumously.
Re: So lets change it to "sa-update doesn't"
Posted by Gene Heskett <ge...@verizon.net>.
On Tuesday 14 August 2007, Kai Schaetzl wrote:
>Gene Heskett wrote on Tue, 14 Aug 2007 00:15:24 -0400:
>> Ok, is there a quick & dirty way to determine which .pre file (or
>> local.cf, there are 3 of those too) is actually running the show?
>
>all the files in /etc/mail/spamassassin
>
Ok, I'll start there. I should add that spamc doesn't run as root, but as me.
>> >No, that is something you put yourself there.
>>
>> Sorry Kai, the comment string inserted in front of the loadplugin
>> statements (all of them) specifically said that sa-update had disabled
>> them because the --allowplugins wasn't being passed to sa-update.
>
>Hm. Can just say I don't have it here, never seen it and sa-update is run
> from cron.daily and without any addition to the command line.
>
I wonder if that's a leftover, from the effects of an older version? I've
been running SA here for years.
>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)
Modesty is a vastly overrated virtue.
-- J.K. Galbraith
Re: So lets change it to "sa-update doesn't"
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 8/14/2007 2:18 PM, Gene Heskett wrote:
> On Tuesday 14 August 2007, Daryl C. W. O'Shea wrote:
>> On 8/14/2007 6:31 AM, Kai Schaetzl wrote:
>>> Gene Heskett wrote on Tue, 14 Aug 2007 00:15:24 -0400:
>>>> Ok, is there a quick & dirty way to determine which .pre file (or
>>>> local.cf, there are 3 of those too) is actually running the show?
>>> all the files in /etc/mail/spamassassin
>>>
>>>>> No, that is something you put yourself there.
>>>> Sorry Kai, the comment string inserted in front of the loadplugin
>>>> statements (all of them) specifically said that sa-update had disabled
>>>> them because the --allowplugins wasn't being passed to sa-update.
>>> Hm. Can just say I don't have it here, never seen it and sa-update is run
>>> from cron.daily and without any addition to the command line.
>> The "openprotect" SARE rules sa-update channel includes a pre file that
>> loads just about every plugin known to man for some (unknown to me)
>> reason. If you don't use the --allowplugins options with their channel
>> sa-update will comment out the plugins they try to load to protect you
>>from the channel running any code.
>> Daryl
>
> Which explains what I found to a Tee, thanks Daryl.
>
> BTW, what is the name of their *.pre file?
According to one of your emails from yesterday, it's loadplugins.pre.
It'll be the pre file in their update directory on your system.
Daryl
Re: So lets change it to "sa-update doesn't"
Posted by Gene Heskett <ge...@verizon.net>.
On Tuesday 14 August 2007, Daryl C. W. O'Shea wrote:
>On 8/14/2007 6:31 AM, Kai Schaetzl wrote:
>> Gene Heskett wrote on Tue, 14 Aug 2007 00:15:24 -0400:
>>> Ok, is there a quick & dirty way to determine which .pre file (or
>>> local.cf, there are 3 of those too) is actually running the show?
>>
>> all the files in /etc/mail/spamassassin
>>
>>>> No, that is something you put yourself there.
>>>
>>> Sorry Kai, the comment string inserted in front of the loadplugin
>>> statements (all of them) specifically said that sa-update had disabled
>>> them because the --allowplugins wasn't being passed to sa-update.
>>
>> Hm. Can just say I don't have it here, never seen it and sa-update is run
>> from cron.daily and without any addition to the command line.
>
>The "openprotect" SARE rules sa-update channel includes a pre file that
>loads just about every plugin known to man for some (unknown to me)
>reason. If you don't use the --allowplugins options with their channel
>sa-update will comment out the plugins they try to load to protect you
>from the channel running any code.
>
>Daryl
Which explains what I found to a Tee, thanks Daryl.
BTW, what is the name of their *.pre file?
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)
In 1750 Issac Newton became discouraged when he fell up a flight of stairs.
Re: So lets change it to "sa-update doesn't"
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 8/15/2007 8:58 AM, Gene Heskett wrote:
> On Tuesday 14 August 2007, Daryl C. W. O'Shea wrote:
> [...]
>>> So, we're back to my subject line, sa-update doesn't [Big Grin]
>>>
>>> Whose NXDOMAIN error is this?
>> NXDOMAIN isn't an error (at least not a DNS error), the record simply
>> does not exist. For some, again unknown, reason (although I've
>> speculated about why it's this way [1]) "openprotect" is always way
>> behind in publishing the needed DNS record for each new release of SA.
>>
>> Just use my channels [2] and be done with the hassle once and for all.
>>
> Ok, I've now done this, and issued the command with an added -D appended.
> Excruciatingly verbose in the dbg mode, looks like it is now invoking a
> session of spamassassin --lint -D for each .cf file processed and there are
> 32 of them as I didn't include the local.cf in the update-channels files
> listing.
>
> And it still finishes up with 3 NXDOMAIN errors, for imageinfo.cf, pdfinfo.cf
> and stock.cf. Do I need to change the first 2 to a rulesemporium address?
> What about stock.cf? Obsolete?
I don't yet provide channels for Dallas' plugins available via the SARE
site, so you'll have to get them their manually for now.
SARE has no "stock.cf" that I'm aware of, thus I have no channel for it.
I'd imagine that it's something you picked up elsewhere along the way.
> And that stanza about the metadata I posted before is unchanged:
> ==========
> [23365] info: rules: meta test FM_DDDD_TIMES_2 has
> dependency 'FH_HOST_EQ_D_D_D_D' with a zero score
> [23365] info: rules: meta test FM_SEX_HOSTDDDD has
> dependency 'FH_HOST_EQ_D_D_D_D' with a zero score
> [23365] dbg: rules: meta test LOCAL_OBFUSCATEDM has undefined
> dependency 'LOCAL_DOLLARS_BODY'
[...]
> ============
> Which I would like to fix.
Just ignore it, it's harmless. If you really want to fix it, you'll
have to make corrections to the SARE rulesets and contribute it to them.
> And finally, may I put this in my crontab for a weekly run?
Weekly, daily, hourly, whichever you like. There have been no SARE rule
updates in months though, so weekly is probably fine.
> Thanks Daryl.
No problem.
Daryl
Re: So lets change it to "sa-update doesn't"
Posted by Kai Schaetzl <ma...@conactive.com>.
Gene Heskett wrote on Wed, 15 Aug 2007 08:58:52 -0400:
> And that stanza about the metadata I posted before is unchanged:
> Which I would like to fix.
Gene, it was told to you several times how to fix that. Check for the
rules these meta rules are based on. Check if they exist and check if the
plugins (if they are based on plugins) are enabled and work.
You want to use grep for that and the main directories where to look are
/etc/mail/spamassassin (your site-specific rules)
/var/lib/spamassassin/<some subdirectory> for all updates from channels
And if you have questions about this take on *one* example at one time,
explain what you did for researching this and why you still need an answer
after the research. Open a new thread and give it a good subject.
Hijacking threads by changing to "very useless" subjects in the middle of
a thread that wasn't even talking about your problem is not nice at all.
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
Re: So lets change it to "sa-update doesn't"
Posted by Gene Heskett <ge...@verizon.net>.
On Tuesday 14 August 2007, Daryl C. W. O'Shea wrote:
[...]
>> So, we're back to my subject line, sa-update doesn't [Big Grin]
>>
>> Whose NXDOMAIN error is this?
>
>NXDOMAIN isn't an error (at least not a DNS error), the record simply
>does not exist. For some, again unknown, reason (although I've
>speculated about why it's this way [1]) "openprotect" is always way
>behind in publishing the needed DNS record for each new release of SA.
>
>Just use my channels [2] and be done with the hassle once and for all.
>
Ok, I've now done this, and issued the command with an added -D appended.
Excruciatingly verbose in the dbg mode, looks like it is now invoking a
session of spamassassin --lint -D for each .cf file processed and there are
32 of them as I didn't include the local.cf in the update-channels files
listing.
And it still finishes up with 3 NXDOMAIN errors, for imageinfo.cf, pdfinfo.cf
and stock.cf. Do I need to change the first 2 to a rulesemporium address?
What about stock.cf? Obsolete?
And that stanza about the metadata I posted before is unchanged:
==========
[23365] info: rules: meta test FM_DDDD_TIMES_2 has
dependency 'FH_HOST_EQ_D_D_D_D' with a zero score
[23365] info: rules: meta test FM_SEX_HOSTDDDD has
dependency 'FH_HOST_EQ_D_D_D_D' with a zero score
[23365] dbg: rules: meta test LOCAL_OBFUSCATEDM has undefined
dependency 'LOCAL_DOLLARS_BODY'
[23365] dbg: rules: meta test LOCAL_OBFUSCATEDM has undefined
dependency 'LOCAL_DOLLARS_SUBJ'
[23365] dbg: rules: meta test LOCAL_OBFUSCATED has undefined
dependency 'LOCAL_DOLLARS_BODY'
[23365] dbg: rules: meta test LOCAL_OBFUSCATED has undefined
dependency 'LOCAL_DOLLARS_SUBJ'
[23365] dbg: rules: meta test SARE_HEAD_SUBJ_RAND has undefined
dependency 'SARE_XMAIL_SUSP2'
[23365] dbg: rules: meta test SARE_HEAD_SUBJ_RAND has undefined
dependency 'SARE_HEAD_XAUTH_WARN'
[23365] dbg: rules: meta test SARE_HEAD_SUBJ_RAND has undefined
dependency 'X_AUTH_WARN_FAKED'
[23365] dbg: rules: meta test SARE_HEAD_8BIT_NOSPM has undefined
dependency '__SARE_HEAD_8BIT_DATE'
[23365] dbg: rules: meta test SARE_HEAD_8BIT_NOSPM has undefined
dependency '__SARE_HEAD_8BIT_RECV'
[23365] dbg: rules: meta test SARE_MULT_RATW_03 has undefined
dependency '__SARE_MULT_RATW_03E'
[23365] dbg: rules: meta test SARE_RD_SAFE has undefined
dependency 'SARE_RD_SAFE_MKSHRT'
[23365] dbg: rules: meta test SARE_RD_SAFE has undefined
dependency 'SARE_RD_SAFE_GT'
[23365] dbg: rules: meta test SARE_RD_SAFE has undefined
dependency 'SARE_RD_SAFE_TINY'
[23365] dbg: rules: meta test LOCAL_OBFUSCATED_XL has undefined
dependency 'LOCAL_DOLLARS_BODY'
[23365] dbg: rules: meta test LOCAL_OBFUSCATED_XL has undefined
dependency 'LOCAL_DOLLARS_SUBJ'
[23365] dbg: rules: meta test SARE_MSGID_LONG40 has undefined
dependency '__SARE_MSGID_LONG50'
[23365] dbg: rules: meta test SARE_MSGID_LONG40 has undefined
dependency '__SARE_MSGID_LONG55'
[23365] dbg: rules: meta test SARE_MSGID_LONG40 has undefined
dependency '__SARE_MSGID_LONG65'
[23365] dbg: rules: meta test SARE_MSGID_LONG40 has undefined
dependency '__SARE_MSGID_LONG75'
[23365] dbg: rules: meta test SARE_MSGID_LONG45 has undefined
dependency '__SARE_MSGID_LONG50'
[23365] dbg: rules: meta test SARE_MSGID_LONG45 has undefined
dependency '__SARE_MSGID_LONG55'
[23365] dbg: rules: meta test SARE_MSGID_LONG45 has undefined
dependency '__SARE_MSGID_LONG65'
[23365] dbg: rules: meta test SARE_MSGID_LONG45 has undefined
dependency '__SARE_MSGID_LONG75'
[23365] dbg: rules: meta test VIRUS_WARNING_DOOM_BNC has undefined
dependency 'VIRUS_WARNING_MYDOOM4'
============
Which I would like to fix.
And finally, may I put this in my crontab for a weekly run?
Thanks Daryl.
>[2] http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt
--
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)
Mal: "No one's gonna hurt you... any more than we already did."
--Episode #3, "Bushwacked"
Re: So lets change it to "sa-update doesn't"
Posted by Jo Rhett <jr...@netconsonance.com>.
Gene Heskett wrote:
> So what needs to be used in place of "saupdates.openprotect.com"?
>
> I might add that rulesdujour seems to work, but I've not regularly abused
> their site since the DDOS started.
Darryl does a good job of providing all the sare rulesets via sa-update.
All the details are on this (short and easy to read) page.
http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt
--
Jo Rhett
Net Consonance ... net philanthropy, open source and other randomness
Re: So lets change it to "sa-update doesn't"
Posted by Gene Heskett <ge...@verizon.net>.
On Tuesday 14 August 2007, Kai Schaetzl wrote:
>Gene Heskett wrote on Tue, 14 Aug 2007 14:46:55 -0400:
>> [18342] dbg: dns: query failed: 3.2.3.saupdates.openprotect.com =>
>> NXDOMAIN [18342] dbg: channel: no updates available, skipping channel
>> [18342] dbg: diag: updates complete, exiting with code 1
>>
>> So, we're back to my subject line, sa-update doesn't [Big Grin]
>
>Wrong, 3.2.3.saupdates.openprotect.com doesn't exist.
>There is nothing wrong with sa-update, but a lot with openprotect, as
> already some other people told. Actually, it seems that all your problems
> started when you started using openprotect.
>
>Kai
Seems like not enough noise has been made about that to get my attention.
Needs a 72 point headline maybe :)
So what needs to be used in place of "saupdates.openprotect.com"?
I might add that rulesdujour seems to work, but I've not regularly abused
their site since the DDOS started.
--
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)
The price of seeking to force our beliefs on others is that someday
they might force their beliefs on us.
-- Mario Cuomo
Re: So lets change it to "sa-update doesn't"
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 8/14/2007 2:46 PM, Gene Heskett wrote:
> On Tuesday 14 August 2007, Daryl C. W. O'Shea wrote:
>> On 8/14/2007 6:31 AM, Kai Schaetzl wrote:
>>> Gene Heskett wrote on Tue, 14 Aug 2007 00:15:24 -0400:
>>>> Ok, is there a quick & dirty way to determine which .pre file (or
>>>> local.cf, there are 3 of those too) is actually running the show?
>>> all the files in /etc/mail/spamassassin
>>>
>>>>> No, that is something you put yourself there.
>>>> Sorry Kai, the comment string inserted in front of the loadplugin
>>>> statements (all of them) specifically said that sa-update had disabled
>>>> them because the --allowplugins wasn't being passed to sa-update.
>>> Hm. Can just say I don't have it here, never seen it and sa-update is run
>>> from cron.daily and without any addition to the command line.
>> The "openprotect" SARE rules sa-update channel includes a pre file that
>> loads just about every plugin known to man for some (unknown to me)
>> reason. If you don't use the --allowplugins options with their channel
>> sa-update will comment out the plugins they try to load to protect you
>>from the channel running any code.
>> Daryl
>
> Nother Q here. I went to the site and updated my crontab entry for the 3.20+
> specs, then ran that from the cli with a copy-paste, added a -D when it came
> back in half a second, silently the first time, and got this, striping the
> usual preamble:
>
> [...]
> [18342] dbg: gpg: adding key id [deleted by me]
> [18342] dbg: gpg: Searching for 'gpg'
> [18342] dbg: util: current PATH
> is: /usr/lib/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
> [18342] dbg: util: executable for gpg was found at /usr/bin/gpg
> [18342] dbg: gpg: found /usr/bin/gpg
> [18342] dbg: gpg: release trusted key id list:
> [deleted by me]
> [18342] dbg: channel: attempting channel saupdates.openprotect.com
> [18342] dbg: channel: update
> directory /var/lib/spamassassin/3.002003/saupdates_openprotect_com
> [18342] dbg: channel: channel cf
> file /var/lib/spamassassin/3.002003/saupdates_openprotect_com.cf
> [18342] dbg: channel: channel pre
> file /var/lib/spamassassin/3.002003/saupdates_openprotect_com.pre
> [18342] dbg: dns: query failed: 3.2.3.saupdates.openprotect.com => NXDOMAIN
> [18342] dbg: channel: no updates available, skipping channel
> [18342] dbg: diag: updates complete, exiting with code 1
>
> So, we're back to my subject line, sa-update doesn't [Big Grin]
>
> Whose NXDOMAIN error is this?
NXDOMAIN isn't an error (at least not a DNS error), the record simply
does not exist. For some, again unknown, reason (although I've
speculated about why it's this way [1]) "openprotect" is always way
behind in publishing the needed DNS record for each new release of SA.
Just use my channels [2] and be done with the hassle once and for all.
Daryl
[1]
http://daryl.dostech.ca/blog/2007/02/15/apache-spamassassin-318-released/
[2] http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt
Re: So lets change it to "sa-update doesn't"
Posted by Kai Schaetzl <ma...@conactive.com>.
Gene Heskett wrote on Tue, 14 Aug 2007 14:46:55 -0400:
> [18342] dbg: dns: query failed: 3.2.3.saupdates.openprotect.com => NXDOMAIN
> [18342] dbg: channel: no updates available, skipping channel
> [18342] dbg: diag: updates complete, exiting with code 1
>
> So, we're back to my subject line, sa-update doesn't [Big Grin]
Wrong, 3.2.3.saupdates.openprotect.com doesn't exist.
There is nothing wrong with sa-update, but a lot with openprotect, as already
some other people told. Actually, it seems that all your problems started
when you started using openprotect.
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
Re: So lets change it to "sa-update doesn't"
Posted by Gene Heskett <ge...@verizon.net>.
On Tuesday 14 August 2007, Daryl C. W. O'Shea wrote:
>On 8/14/2007 6:31 AM, Kai Schaetzl wrote:
>> Gene Heskett wrote on Tue, 14 Aug 2007 00:15:24 -0400:
>>> Ok, is there a quick & dirty way to determine which .pre file (or
>>> local.cf, there are 3 of those too) is actually running the show?
>>
>> all the files in /etc/mail/spamassassin
>>
>>>> No, that is something you put yourself there.
>>>
>>> Sorry Kai, the comment string inserted in front of the loadplugin
>>> statements (all of them) specifically said that sa-update had disabled
>>> them because the --allowplugins wasn't being passed to sa-update.
>>
>> Hm. Can just say I don't have it here, never seen it and sa-update is run
>> from cron.daily and without any addition to the command line.
>
>The "openprotect" SARE rules sa-update channel includes a pre file that
>loads just about every plugin known to man for some (unknown to me)
>reason. If you don't use the --allowplugins options with their channel
>sa-update will comment out the plugins they try to load to protect you
>from the channel running any code.
>
>Daryl
Nother Q here. I went to the site and updated my crontab entry for the 3.20+
specs, then ran that from the cli with a copy-paste, added a -D when it came
back in half a second, silently the first time, and got this, striping the
usual preamble:
[...]
[18342] dbg: gpg: adding key id [deleted by me]
[18342] dbg: gpg: Searching for 'gpg'
[18342] dbg: util: current PATH
is: /usr/lib/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
[18342] dbg: util: executable for gpg was found at /usr/bin/gpg
[18342] dbg: gpg: found /usr/bin/gpg
[18342] dbg: gpg: release trusted key id list:
[deleted by me]
[18342] dbg: channel: attempting channel saupdates.openprotect.com
[18342] dbg: channel: update
directory /var/lib/spamassassin/3.002003/saupdates_openprotect_com
[18342] dbg: channel: channel cf
file /var/lib/spamassassin/3.002003/saupdates_openprotect_com.cf
[18342] dbg: channel: channel pre
file /var/lib/spamassassin/3.002003/saupdates_openprotect_com.pre
[18342] dbg: dns: query failed: 3.2.3.saupdates.openprotect.com => NXDOMAIN
[18342] dbg: channel: no updates available, skipping channel
[18342] dbg: diag: updates complete, exiting with code 1
So, we're back to my subject line, sa-update doesn't [Big Grin]
Whose NXDOMAIN error is this?
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)
Money is the root of all wealth.
Re: So lets change it to "sa-update doesn't"
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 8/14/2007 6:31 AM, Kai Schaetzl wrote:
> Gene Heskett wrote on Tue, 14 Aug 2007 00:15:24 -0400:
>
>> Ok, is there a quick & dirty way to determine which .pre file (or local.cf,
>> there are 3 of those too) is actually running the show?
>
> all the files in /etc/mail/spamassassin
>
>>> No, that is something you put yourself there.
>
>> Sorry Kai, the comment string inserted in front of the loadplugin statements
>> (all of them) specifically said that sa-update had disabled them because
>> the --allowplugins wasn't being passed to sa-update.
>
> Hm. Can just say I don't have it here, never seen it and sa-update is run from
> cron.daily and without any addition to the command line.
The "openprotect" SARE rules sa-update channel includes a pre file that
loads just about every plugin known to man for some (unknown to me)
reason. If you don't use the --allowplugins options with their channel
sa-update will comment out the plugins they try to load to protect you
from the channel running any code.
Daryl
Re: So lets change it to "sa-update doesn't"
Posted by Kai Schaetzl <ma...@conactive.com>.
Gene Heskett wrote on Tue, 14 Aug 2007 00:15:24 -0400:
> Ok, is there a quick & dirty way to determine which .pre file (or local.cf,
> there are 3 of those too) is actually running the show?
all the files in /etc/mail/spamassassin
> >No, that is something you put yourself there.
> Sorry Kai, the comment string inserted in front of the loadplugin statements
> (all of them) specifically said that sa-update had disabled them because
> the --allowplugins wasn't being passed to sa-update.
Hm. Can just say I don't have it here, never seen it and sa-update is run from
cron.daily and without any addition to the command line.
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
Re: So lets change it to "sa-update doesn't"
Posted by Gene Heskett <ge...@verizon.net>.
On Monday 13 August 2007, Kai Schaetzl wrote:
>Gene Heskett wrote on Mon, 13 Aug 2007 10:24:15 -0400:
>> All copies of the same exact file, by hand. Should I delete the one
>> in /var/lib/perl5?
>
>You can and should delete all that are not in use. The ones loaded with a
>.pre file is in use, the others aren't.
Ok, is there a quick & dirty way to determine which .pre file (or local.cf,
there are 3 of those too) is actually running the show?
>> [28645] dbg: rules: meta test DIGEST_MULTIPLE has undefined
>> dependency 'DCC_CHECK'
>
>Search where this meta test is, it's probably not in the cf for the plugin,
>but in some rules you added. Same for the other warnings, probably, they are
>all meta rules.
>
>> Aha! again, I just found that all the plugins had been disabled in
>> loadplugins.pre because that --allowplugins switch wasn't being used with
>> sa-update.
>
>No, that is something you put yourself there.
>
>Kai
Sorry Kai, the comment string inserted in front of the loadplugin statements
(all of them) specifically said that sa-update had disabled them because
the --allowplugins wasn't being passed to sa-update.
I didn't put it there, ever.
--
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)
No problem is so large it can't be fit in somewhere.
Re: So lets change it to "sa-update doesn't"
Posted by Kai Schaetzl <ma...@conactive.com>.
Gene Heskett wrote on Mon, 13 Aug 2007 10:24:15 -0400:
> All copies of the same exact file, by hand. Should I delete the one
> in /var/lib/perl5?
You can and should delete all that are not in use. The ones loaded with a
.pre file is in use, the others aren't.
> [28645] dbg: rules: meta test DIGEST_MULTIPLE has undefined
> dependency 'DCC_CHECK'
Search where this meta test is, it's probably not in the cf for the plugin,
but in some rules you added. Same for the other warnings, probably, they are
all meta rules.
> Aha! again, I just found that all the plugins had been disabled in
> loadplugins.pre because that --allowplugins switch wasn't being used with
> sa-update.
No, that is something you put yourself there.
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com
Re: So lets change it to "sa-update doesn't"
Posted by SM <sm...@resistor.net>.
Hi Gene,
At 07:24 13-08-2007, Gene Heskett wrote:
>Ok, but the above spamassassin check also reports this, near the end of the
>report:
>
>[28645] dbg: rules: meta test DIGEST_MULTIPLE has undefined
>dependency 'DCC_CHECK'
This meta test depends on the DCC plugin. You can ignore the
warning. The quick fix would be to have an ifplugin:
--- rules/20_net_tests.cf.orig Mon Aug 13 09:33:36 2007
+++ rules/20_net_tests.cf Mon Aug 13 09:34:11 2007
@@ -36,11 +36,14 @@
# Message digest tests
# bug 2220. nice results
+ifplugin Mail::SpamAssassin::Plugin::DCC
+
meta DIGEST_MULTIPLE RAZOR2_CHECK + DCC_CHECK + PYZOR_CHECK > 1
describe DIGEST_MULTIPLE Message hits more than one network
digest check
tflags DIGEST_MULTIPLE net
#reuse DIGEST_MULTIPLE
+endif
>[28645] info: rules: meta test FM_DDDD_TIMES_2 has
>dependency 'FH_HOST_EQ_D_D_D_D' with a zero score
>[28645] info: rules: meta test FM_SEX_HOSTDDDD has
>dependency 'FH_HOST_EQ_D_D_D_D' with a zero score
You can ignore those two warnings.
>[28645] dbg: rules: meta test LOCAL_OBFUSCATEDM has undefined
>dependency 'LOCAL_DOLLARS_BODY'
>[28645] dbg: rules: meta test LOCAL_OBFUSCATEDM has undefined
>dependency 'LOCAL_DOLLARS_SUBJ'
>[28645] dbg: rules: meta test LOCAL_OBFUSCATED has undefined
>dependency 'LOCAL_DOLLARS_BODY'
>[28645] dbg: rules: meta test LOCAL_OBFUSCATED has undefined
>dependency 'LOCAL_DOLLARS_SUBJ'
>[28645] dbg: rules: meta test SARE_HEAD_SUBJ_RAND has undefined
>dependency 'SARE_XMAIL_SUSP2'
>[28645] dbg: rules: meta test SARE_HEAD_SUBJ_RAND has undefined
>dependency 'SARE_HEAD_XAUTH_WARN'
>[28645] dbg: rules: meta test SARE_HEAD_SUBJ_RAND has undefined
>dependency 'X_AUTH_WARN_FAKED'
>[28645] dbg: rules: meta test SARE_HEAD_8BIT_NOSPM has undefined
>dependency '__SARE_HEAD_8BIT_DATE'
>[28645] dbg: rules: meta test SARE_HEAD_8BIT_NOSPM has undefined
>dependency '__SARE_HEAD_8BIT_RECV'
>[28645] dbg: rules: meta test SARE_MULT_RATW_03 has undefined
>dependency '__SARE_MULT_RATW_03E'
>[28645] dbg: rules: meta test SARE_RD_SAFE has undefined
>dependency 'SARE_RD_SAFE_MKSHRT'
>[28645] dbg: rules: meta test SARE_RD_SAFE has undefined
>dependency 'SARE_RD_SAFE_GT'
>[28645] dbg: rules: meta test SARE_RD_SAFE has undefined
>dependency 'SARE_RD_SAFE_TINY'
>[28645] dbg: rules: meta test LOCAL_OBFUSCATED_XL has undefined
>dependency 'LOCAL_DOLLARS_BODY'
>[28645] dbg: rules: meta test LOCAL_OBFUSCATED_XL has undefined
>dependency 'LOCAL_DOLLARS_SUBJ'
>[28645] dbg: rules: meta test SARE_MSGID_LONG40 has undefined
>dependency '__SARE_MSGID_LONG50'
>[28645] dbg: rules: meta test SARE_MSGID_LONG40 has undefined
>dependency '__SARE_MSGID_LONG55'
>[28645] dbg: rules: meta test SARE_MSGID_LONG40 has undefined
>dependency '__SARE_MSGID_LONG65'
>[28645] dbg: rules: meta test SARE_MSGID_LONG40 has undefined
>dependency '__SARE_MSGID_LONG75'
>[28645] dbg: rules: meta test SARE_MSGID_LONG45 has undefined
>dependency '__SARE_MSGID_LONG50'
>[28645] dbg: rules: meta test SARE_MSGID_LONG45 has undefined
>dependency '__SARE_MSGID_LONG55'
>[28645] dbg: rules: meta test SARE_MSGID_LONG45 has undefined
>dependency '__SARE_MSGID_LONG65'
>[28645] dbg: rules: meta test SARE_MSGID_LONG45 has undefined
>dependency '__SARE_MSGID_LONG75'
The above meta tests are from SARE. You may be missing the .cf files
which contain the rules.
Regards,
-sm
Re: So lets change it to "sa-update doesn't"
Posted by Gene Heskett <ge...@verizon.net>.
On Monday 13 August 2007, SM wrote:
>At 19:22 12-08-2007, Gene Heskett wrote:
>>And why not? They've been announced as available, so one would assume a
>>simple run of sa-update would pull them.
>
>The PDFInfo plugin is available from SARE. There is a
>non-spamassassin.org channel to get the updates using
>sa-update. Note that sa-update will not update plugins unless you
>run it with the --allowplugins option.
Aha! Added to the weekly root crontab entry, thanks. But a by hand
execution:
sa-update --allowplugins -D
does not mention it.
>>[root@coyote rulesdujour]# ls -l `locate PDFInfo.pm`
>>-rw-r--r-- 1 root root 23475 Aug 11
>>05:38 /etc/mail/spamassassin/RulesDuJour/PDFInfo.pm
>>-rw-r--r-- 1 root root 23475 Aug 11 05:40 /etc/rulesdujour/PDFInfo.pm
>>-rw-r--r-- 1 root root 23475 Aug 11
>>05:41 /usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin/Plugin/PDFInfo.pm
>
>PDFInfo.pm shows up twice in your search. The last one is not a
>spamassassin.org plugin.
All copies of the same exact file, by hand. Should I delete the one
in /var/lib/perl5?
>>So what file to we add something to, to enable this, and what do we add to
>> it?
>
>You have to load a plugin to enable it. That can be done either
>through the .pre files or the local.cf file using the following syntax:
>
>loadplugin Mail::SpamAssassin::Plugin::PDFInfo /etc/rulesdujour/PDFInfo.pm
Now done, many thanks, and spamassassin --lint -D now shows it.
>The path location is required if the plugin is not in the
>SpamAssassin/Plugin directory.
Ok, but the above spamassassin check also reports this, near the end of the
report:
[28645] dbg: rules: meta test DIGEST_MULTIPLE has undefined
dependency 'DCC_CHECK'
[28645] info: rules: meta test FM_DDDD_TIMES_2 has
dependency 'FH_HOST_EQ_D_D_D_D' with a zero score
[28645] info: rules: meta test FM_SEX_HOSTDDDD has
dependency 'FH_HOST_EQ_D_D_D_D' with a zero score
[28645] dbg: rules: meta test LOCAL_OBFUSCATEDM has undefined
dependency 'LOCAL_DOLLARS_BODY'
[28645] dbg: rules: meta test LOCAL_OBFUSCATEDM has undefined
dependency 'LOCAL_DOLLARS_SUBJ'
[28645] dbg: rules: meta test LOCAL_OBFUSCATED has undefined
dependency 'LOCAL_DOLLARS_BODY'
[28645] dbg: rules: meta test LOCAL_OBFUSCATED has undefined
dependency 'LOCAL_DOLLARS_SUBJ'
[28645] dbg: rules: meta test SARE_HEAD_SUBJ_RAND has undefined
dependency 'SARE_XMAIL_SUSP2'
[28645] dbg: rules: meta test SARE_HEAD_SUBJ_RAND has undefined
dependency 'SARE_HEAD_XAUTH_WARN'
[28645] dbg: rules: meta test SARE_HEAD_SUBJ_RAND has undefined
dependency 'X_AUTH_WARN_FAKED'
[28645] dbg: rules: meta test SARE_HEAD_8BIT_NOSPM has undefined
dependency '__SARE_HEAD_8BIT_DATE'
[28645] dbg: rules: meta test SARE_HEAD_8BIT_NOSPM has undefined
dependency '__SARE_HEAD_8BIT_RECV'
[28645] dbg: rules: meta test SARE_MULT_RATW_03 has undefined
dependency '__SARE_MULT_RATW_03E'
[28645] dbg: rules: meta test SARE_RD_SAFE has undefined
dependency 'SARE_RD_SAFE_MKSHRT'
[28645] dbg: rules: meta test SARE_RD_SAFE has undefined
dependency 'SARE_RD_SAFE_GT'
[28645] dbg: rules: meta test SARE_RD_SAFE has undefined
dependency 'SARE_RD_SAFE_TINY'
[28645] dbg: rules: meta test LOCAL_OBFUSCATED_XL has undefined
dependency 'LOCAL_DOLLARS_BODY'
[28645] dbg: rules: meta test LOCAL_OBFUSCATED_XL has undefined
dependency 'LOCAL_DOLLARS_SUBJ'
[28645] dbg: rules: meta test SARE_MSGID_LONG40 has undefined
dependency '__SARE_MSGID_LONG50'
[28645] dbg: rules: meta test SARE_MSGID_LONG40 has undefined
dependency '__SARE_MSGID_LONG55'
[28645] dbg: rules: meta test SARE_MSGID_LONG40 has undefined
dependency '__SARE_MSGID_LONG65'
[28645] dbg: rules: meta test SARE_MSGID_LONG40 has undefined
dependency '__SARE_MSGID_LONG75'
[28645] dbg: rules: meta test SARE_MSGID_LONG45 has undefined
dependency '__SARE_MSGID_LONG50'
[28645] dbg: rules: meta test SARE_MSGID_LONG45 has undefined
dependency '__SARE_MSGID_LONG55'
[28645] dbg: rules: meta test SARE_MSGID_LONG45 has undefined
dependency '__SARE_MSGID_LONG65'
[28645] dbg: rules: meta test SARE_MSGID_LONG45 has undefined
dependency '__SARE_MSGID_LONG75'
[28645] dbg: rules: meta test VIRUS_WARNING_DOOM_BNC has undefined
dependency 'VIRUS_WARNING_MYDOOM4'
I had taken DCC and PYZOR out per a message about similar errors a week or so
ago, but it didn't seem to be the correct fix as can be seen above.
Aha! again, I just found that all the plugins had been disabled in
loadplugins.pre because that --allowplugins switch wasn't being used with
sa-update.
However, even after fixing that file, a rerun of sa-update with that switch
and a spamassassin restart, the --lint -D output above remains. What should
I do about that?
Many Thanks.
>Regards,
>-sm
--
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)
What we need is either less corruption, or more chance to participate in it.
Re: So lets change it to "sa-update doesn't"
Posted by SM <sm...@resistor.net>.
At 19:22 12-08-2007, Gene Heskett wrote:
>And why not? They've been announced as available, so one would assume a
>simple run of sa-update would pull them.
The PDFInfo plugin is available from SARE. There is a
non-spamassassin.org channel to get the updates using
sa-update. Note that sa-update will not update plugins unless you
run it with the --allowplugins option.
>[root@coyote rulesdujour]# ls -l `locate PDFInfo.pm`
>-rw-r--r-- 1 root root 23475 Aug 11
>05:38 /etc/mail/spamassassin/RulesDuJour/PDFInfo.pm
>-rw-r--r-- 1 root root 23475 Aug 11 05:40 /etc/rulesdujour/PDFInfo.pm
>-rw-r--r-- 1 root root 23475 Aug 11
>05:41 /usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin/Plugin/PDFInfo.pm
PDFInfo.pm shows up twice in your search. The last one is not a
spamassassin.org plugin.
>So what file to we add something to, to enable this, and what do we add to it?
You have to load a plugin to enable it. That can be done either
through the .pre files or the local.cf file using the following syntax:
loadplugin Mail::SpamAssassin::Plugin::PDFInfo /etc/rulesdujour/PDFInfo.pm
The path location is required if the plugin is not in the
SpamAssassin/Plugin directory.
Regards,
-sm