On Tue, 2013-10-22 at 16:25 -0700, Quanah Gibson-Mount wrote:
> --On Tuesday, October 22, 2013 12:18 AM +0200 Karsten Bräckelmann wrote:
>
> > By setting $DEF_RULES_DIR to the same value as $LOCAL_RULES_DIR, placing
> > stock rules in what's supposed to be strictly for site-specific conf,
> > you override the fresh rules pulled by sa-update.
>
> I'm not positive that is correct -- When sa-update runs, it pulls down the
> rules and adds a cf file to include them, with the name
> updates_spamassassin_cf. Given load order seems to be alphabetically
> dependent, it should still override, I'm hoping. ;)
Well, what did you set $LOCAL_STATE_DIR to?
Continuing with the default dirs I used in my previous post, local state
dir would be /var/lib/spamassassin. SA generally, and sa-update in
particular are using a *versioned* schema inside local state dir.
Thus, if you set $LOCAL_STATE_DIR to the same as $LOCAL_RULES_DIR, you
will end up with a 3.00x00y/ directory in your site-specific config.
That versioned directory contains the update-channels in a dedicated dir
each (and a .cf file to include the contents). The versioned directory
will not be traversed recursively.
I stand to what I said.
But hey, don't just take my word for it. Please run 'spamassassin -D'.
The debug output will tell you which configuration SA reads, in what
order.
--
char *t="\10pse\0r\0dtu\0.@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;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
