Skipping all the "print my config" stuff. Maybe tomorrow. For now,
there's more important things than custom config...
On Sun, 2009-03-01 at 01:24 +0000, Ray wrote:
> Karsten Bräckelmann <guenther <at> rudersport.de> writes:
> > > those privileged settings which are actually "administrator" privileged
> > > settings which cannot be allowed via allow_user_rules))), but minus
> > > misspellings and possibly minus rules following misspellings in any of the
> > > config files.
> >
> > Hell, no! Assuming there are mis-spellings is inherently broken. Do lint
> > check your configuration after *any* change. No complaints, no
> > mis-spellings.
>
> I'm not sure I understand you here.
You must not assume or allow for mis-spelled configuration keywords or
otherwise illegal syntax. Just lint check. If it comes back clean, all
is good. If it doesn't, you NEED to fix it anyway.
> I think that assuming there are _no_ misspellings in someone else's site-wide
> config is leaving a door open to problems. As you appear to indicate, lint
> checking the config to validate it is very important.
Yes, you must exactly assume that. There are no site-wide mis-spellings.
And you can verify it easily.
> No complaints and I can
> then assume that the effective config is not modulated by errors, which is a
> good (yet additional) step toward knowing the effective config. I would be
> sorely pressed to understand the implications of lint complaints that I
> couldn't
> understand like:
>
> [> check: no loaded plugin implements 'check_main': cannot scan! at
> [> /usr/lib/perl5/site_perl/5.8.8/Mail/SpamAssassin/PerMsgStatus.pm line
> 164.
Ahem. Your SA is crippled. It does nothing. It can't. (And no, this is
not about a mis-spelling...)
At this point, back down and take a deep breath. By chasing a non-
functional rewrite_header setting, you are seriously barking up the
wrong tree. Don't care about that setting. Don't care about any such
setting. SA doesn't work -- this is what you need to check.
The above is supposed to be enabled by /etc/mail/spamassassin/v320.pre:
loadplugin Mail::SpamAssassin::Plugin::Check
A stock and most vital part. If it isn't, your install is seriously
broken. To stress this part again -- the stock, vanilla v320.pre ships
with that very line.
Unless you messed with these .pre files, removing loadplugin settings, I
suggest you go back to square one -- install SA properly. Which might
involve telling your hoster to do so.
FWIW, if that line exists, another explanation is a missing Perl module.
In either case it's about the equivalent of a missing .so in your
postfix analogy. postconf would be useless here...
> The response here may be "that's not a lint message, and you can safely ignore
> it". But my point is that I'm required to understand this to know its effect
> on
> the config if I am manually parsing the config and don't have a tool to show
> the
> effective config.
Nope, this is by far *worse* than a failing lint check.
> > I guess you're approaching this from the wrong end. It's almost like you
> > don't
> > trust the default config. The first thing for a new user after installing
> > any
> > application (and ensuring it works) is to customize it. Not to dissect and
> > anatomize its deepest innards.
>
> Not "default config", site-wide config.
>
> The Vim installation at this hosting provider is twitted so it can't syntax
> highlight, among other problems. I take that and the above `spamassassin -D`
> error message as signs that I ought not necessarily trust the SA config.
>
> Together, the untrustworthiness of the site-wide config and the complexity and
> folk knowledge required to parse out the effective config, combined with
> config
> documentation syntax underspecification (I'll get to this in a moment) lead me
> to wishing I had a simple way to check the effective config.
I don't know about general trustworthiness of site-wide config in your
case. The above is a gross failure. Which might just be a broken install
and simply needs to be fixed. Bad, but not necessarily affecting trust.
Trustworthiness is much more -- it involves not breaking or even
changing without knowledge. If you can't trust your system admin, switch
your system.
> One specific problem I'm having is that my user_prefs config for undoing the
> site-wide rewrite_header does not appear to be working. How does a user stop
> SA
> from rewriting the header? (Note that this effort is a step towards the goal
> of
> preserving spam for later manually-directed `sa-learn` training.)
It looks more like SA isn't doing anything, cause basically SA has never
been run on your system. See above.
First, install SA properly, and make it run. Then check back with the
custom settings again.
--
char *t="\10pse\0r\0dtu...@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; }}}
