Karsten Bräckelmann <guenther <at> rudersport.de> writes: > > just local.cf, IIUC, but potentially any of the 47 files in my hosting > > provider's /usr/share/spamassassin and /etc/mail/spamassassin dirs (or any > > Aah... no. :) The stuff in /usr/share/spamassassin (granted, plus the .pre > files) is exactly the *base*. Stock SA. No user-servicable parts inside. This > dir won't even be used, after an sa-update.
Ah, okay, that's good to learn, thanks. That's not a detail I found out from the docs (but I should have understood it from the directory hierarchy). > Frankly, there are some important differences between SA and postfix > "configuration". Just to start the list, not exhaustive: > > 'postconf' without the handy -n switch dumps about 500 lines. The > equivalent dump for SA including the rules is about 6000 lines. And > that's a plain dump, *without* following and unfolding meta rules or > anything. > > Also, frankly, I don't think SA rules are really the same as settings. This is maybe one of the communication difficulties here. When I think "config" I'm really thinking what you're calling "settings". At this point I'm not as interested in the rules. (I haven't gotten past grokking the more fundamental "config" of the system, which I feel I should understand before I move on to rules.) Perhaps the confusion here arises from the fact that rule definition is a subset of "proper" config? (I don't even know if this is the case for sure as I haven't gotten to rules.) > There are exactly two (sensible) possible places for custom configu- > ration. /etc/mail/spamassassin and the user_prefs, if any. I'm not assured a sensible installation when I am not the person who did the installation. (Perhaps not even then.) But, again, good to learn this information. Thank you. I note that so far this seems like orally-transmitted folk knowledge more so than documented system nature. > > others if they happen to have configured such), plus my user_prefs file > > (_except_ any items which are prohibited from being overridden (except the > > privileged settings which are actually allowed by allow_user_rules (except > > 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. 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. 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. 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. I'm not sure if I'm clear with where I've been going with all this. To know the effective config I am having to search for more bodies. And the process appears to be unbounded. Thankfully I have SA sherpas to help out, but I really didn't want to bother you guys in the first place and I think that it would be nicer if noobs like me didn't bother you guys. Not that I want to encourage surliness and "RTFM!" from the natives, but an in-effect config printer might help, as it might also help a lot of debugging. > > [...] Meaning, if I want to know for sure exactly what results in the > > effective config, do I consult the POD? Or maybe the POD and the man pages, > > and perhaps a particular wiki article and that's it, period. > > POD == man pages. > > Anyway, you're contradicting yourself. POD plus a single wiki page -- to grok > the FULL configuration? That's what you requested to be dumped by a > postconf-alike. Right, 6000 lines full of meta-rules and ghastly REs. > Understood after the tiny bit of lecture you mentioned? No way. I imagine the full config with rules would be awful, yeah. But what about config aside from rules? That's really what I'm talking about. (postconf doesn't really output "rules".) Isn't there something of a semantic distinction between "bayes_auto_learn" and "redirector_pattern"? I think the Conf POD page gives one just about everything one needs to understand any non-rule config. Don't folks ever want to list out non-rule configs? The response here may be "if I change a config I can see the effects". What happens if you can't? Maybe one never runs into a situation where the config one places in user_prefs fails to go into effect exactly as intended? > > I imagine just about every SA admin here has played out the scenario > > repeatedly and knows the locations of the bodies. "Come on, there are only > > four." Heck, even though I didn't install the SA here and I'm coming at > > this as a total noob I may already have all the critical details I need. > > But how am I to know that? This is what I mean by open-ended. > > As a "noob", you aren't interested in the full postconf dump, are you? You > want your custom settings, -n... Right. Either the non-rule settings, or the custom (non-default) settings. Preferrably option for either. > 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'm not asking to dissect to deepest innards. If I could just say something like `spamassassin --print-config rewrite_header`, that would do it. > Maybe you should try to ask specific questions, and explain what you want to > accomplish. I maintain that a config printer (at least without rules) is a good idea, but I'll stop trying to persuade about it. 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.) RSK
