On Fri, 2013-10-25 at 17:04 -0700, Quanah Gibson-Mount wrote:
> Well... Since we run SA via amavis, custom rules are stored in
> /opt/zimbra/conf/sa, and Amavis loads them with:
>
> $sa_siteconfigpath = '/opt/zimbra/conf/sa';
It would have been nice to mention this earlier. What you just said
feels like "Hey, I told you all our SA build config and stuff, but that
fucking doesn't matter because it's just where we dump things. It is not
what SA will use, because we'll override any of the arguments I told
you."
Sorry, but given that one statement, you could have set DEFRULESDIR,
LOCALRULESDIR and LOCALSTATEDIR just as well to /dev/null...
In production, you're using different values all over the place.
Quoting the amavisd release notes, introducing that variable:
"this makes it easier to run multiple instances of amavisd, each with a
different SpamAssassin configuration"
That's what it is intended for. Ad-hoc debugging or multiple instances.
Not to overrule SA general config.
Same with the sa-update --updatedir option.
That stuff is not intended to be a replacement of build time arguments.
Just get your build right, once. Then let the commands use their
suitable defaults. They are defaults for a reason.
> So custom rules are still supported. ;)
>
> However, clearly this entire thing needs a redesign. Hopefully I can get
> to it next week.
First rule of redesign: Any custom command-line option or configuration
MUST have a solid reason. This holds even stronger for paths.
--
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; }}}
