Re: So lets change it to sa-update doesn't
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__TIMES_2 has dependency 'FH_HOST_EQ_D_D_D_D' with a zero score [23365] info: rules: meta test FM_SEX_HOST 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
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
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__TIMES_2 has dependency 'FH_HOST_EQ_D_D_D_D' with a zero score [23365] info: rules: meta test FM_SEX_HOST 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
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
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
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
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
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
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
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
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
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
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. [EMAIL PROTECTED] 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
Re: So lets change it to sa-update doesn't
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. [EMAIL PROTECTED] 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__TIMES_2 has dependency 'FH_HOST_EQ_D_D_D_D' with a zero score [28645] info: rules: meta test FM_SEX_HOST 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
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
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__TIMES_2 has dependency 'FH_HOST_EQ_D_D_D_D' with a zero score [28645] info: rules: meta test FM_SEX_HOST 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
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.
