Gary wrote: >>> debug: bayes: 5651 untie-ing db_seen >>> debug: metadata: X-Spam-Relays-Trusted: >>> debug: metadata: X-Spam-Relays-Untrusted: >>> debug: decoding: no encoding detected >>> debug: is spam? score=0 required=5 >>> debug: tests= >>> debug: subtests=
> Luke's debug output showed SpamAssassin is expecting: > using "/usr/share/spamassassin" for default rules dir > So as a test I created an empty /usr/share/spamassassin directory and > started up 'amavisd debug-sa'. I got the exact same error Luke shows > here. > "By default, configuration data is loaded from the first existing > directory in: @@DEF_RULES_DIR@@; @@PREFIX@@/share/spamassassin; > /usr/local/share/spamassassin; /usr/share/spamassassin ." > To me this could indicate that at one time, the rules files were > placed in /usr/share/spamassassin. Upon subsequent removal of that > installation, and upon installation of another version, the rules were > possibly placed in /usr/local/share/spamassassin but the empty > /usr/share/spamassassin directory was left behind. Sounds good anyway. > So, in this case, possibly simply deleting the empty /usr/share/spamassassin > directory may solve the problem. At this point I imagine one could > optionally create a symlink from /usr/share/spamassassin to the > directory where the rules are currently stored. This may avoid issues > like this in the future (or create new ones!). > For the config files, it looks like there are a lot more places to > look: > "Site-specific configuration data is used to override any values which > had already been set. This is loaded from the first existing directory > in: @@LOCAL_RULES_DIR@@; @@PREFIX@@/etc/mail/spamassassin; > @@PREFIX@@/etc/spamassassin; /usr/local/etc/spamassassin; > /usr/pkg/etc/spamassassin; /usr/etc/spamassassin; /etc/mail/spamassassin; > /etc/spamassassin ." > I managed to ask Luke last night to tell me what was in > /etc/mail/spamassassin. There is local.cf and nothing else. > Local.cf is not configured. The absence of the init.pre file makes > me think the installation is either incomplete or the config files > from this particular installation are also somewhere else and > /etc/mail/spamassassin/local.cf is also a leftover from a previous > installation. The ordering of file location in SpamAssassin and the order that Perl programs are found also explains the problem on another recent post: > configuration file "/usr/share/spamassassin/20_body_tests.cf" requires > version 3.000004 of > SpamAssassin, but this is code version 3.000001. Maybe you need to use the -C > switch, or > remove the old config files? > Skipping this file at > /usr/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/Conf/Parser.pm line 329. > (and other lines regarding more cf's) Here, a new version of SpamAssassin has been installed using one method, and a previous version that was installed by another method still remains on the disk (or at least the Perl program remains on the disk). Perl found the old version's SpamAssassin.pm program files before finding the new one's, so that part messed us up. The new program installed its rules files in /usr/share/spamassassin, and because of the order in which SpamAssassin looks for files, the rules in /usr/share/spamassassin are going to be used. The old version could have installed its rules files there also, but have since been overwritten. As a work-around, by locating the old version of SpamAssassin.pm and renaming it, the new version will be found instead, and the program will start working. Of course, amavisd-new debug-sa output will show where spamassassin is looking for its config files: debug: using "/etc/mail/spamassassin/init.pre" for site rules init.pre debug: config: read file /etc/mail/spamassassin/init.pre ... debug: using "/etc/mail/spamassassin" for site rules dir debug: config: read file /etc/mail/spamassassin/local.cf So all a person would have to do is make sure the current version of their local.cf, init.pre and custom rules are located there. The fun part is that I imagine that the order in which files are located could be different for different versions of SpamAssassin, possibly different ports of SpamAssassin, and different ports of Perl. Sorry for the long winded note. I had some free time and writing it out helps me get it straight in my head. Gary V ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ AMaViS-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
