Kurt Buff wrote:
From: Daryl C. W. O'Shea:
Kurt Buff wrote:
3) Lastly, what is this line all about?:
Can't locate object method "finish" via package
"Mail::SpamAssassin::Timeout" at
/usr/local/lib/perl5/site_perl/5.8.8/Mail/SpamAssassin/PluginH
andler.pm line
187.
I'm running SA 3.1.8.
IIRC old versions of the FuzzyOCR plugin cause this. If it's
not that
look at other third-party plugins that you have installed.
Daryl
FuzzOCR is the culprit - I was using 2.3b, but have commented that out, and
it completes now.
Now, I have two smaller questions:
1) My install of FreeBSD 6.2 doesn't have /var/lib, let along
/var/lib/spamassassin, so I used an --updatedir of
/usr/local/etc/mail/spamassassin/sa-updates, which seems to work. Is this
reasonable, or will it conflict with anything? Local.cf and the .pre and
other files reside in the parent directory.
That's probably not a good place for it (in a sub directory of the site
config directory). I believe the config code will recurse into the
subdirectory and load everything a second time (once as local state
data, then again as the local site config) and cause number 2 below...
2) I get some interesting output while running 'sa-update --updatedir
/usr/local/etc/mail/spamassassin/sa-updates --channelfile
/home/vscan/sare-sa-update-channels.txt --gpgkey 856AA88A', and having a
channelfile that specifies a number of 70_sare rules. Things like:
'Subroutine __SARE_SUB_OBFU_LQUOT_head_test redefined at
/tmp/.spamassassin966SSGKUttmp/200512270000.cf, rule __SARE_SUB_OBFU_LQUOT,
line 6.'
show up. Anything to be worried about?
Yes. Either you've got SARE rules already in
/usr/local/etc/mail/spamassassin (from a manually update or Rule du
Jour) or the config code is recursing into the sa-updates sub-dir. I've
move the sa-updates somewhere else (if you don't want to use the default
of /var/lib/spamassassin).
Daryl
