Karsten Bräckelmann <guenther <at> rudersport.de> writes: > 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 don't have privs, and conceivably a misspelling isn't fatal. The power is not mine to allow or deny misspellings in site-wide config. > > 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. But it's not called "assuming" if you verify? I must be missing you here, sorry. I would side with "you must verify" rather than "you must assume". > > [> 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...) I'm trying not to come across as unnecessarily contrary; please pardon me when I say that you are wrong here. The SA installation works well enough to score and judge (add X-Spam-Score, e.g.), and it's doing a pretty good job so far. It even marks up subject lines in a way I don't like. It's pretty clear it's operating. It seems likely then that this config check error is from my account running jailed. They've given me visibility to things like /usr/share/spamassasin, but it's likely they haven't given me the entirety of what's driving the site-wide SA. Since I'm not the user that spamd runs as, it's probably not critical to give me access to all of this hosts's SA config. (Querying for the in-effect config becomes especially important if the site-wide config is in part hidden from my account. But it also becomes more complicated -- IPC with spamd? I don't know how spamd is architected. Anyway, sorry, I said I'd stop harping on this.) I'll bypass the portion of your message predicated on SA not operating. Let me know if there's anything in that I shouldn't bypass. > 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. I feel I can trust the competence of the site admins to mostly run a pretty good system. They've locked things down pretty hard, though. This is a difficulty, but the validity of ... well, I wasn't going to talk about that. Anyway the following topic still stands: > > 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.) I _can_ in fact adjust required_score. Is there any reason I wouldn't be able to adjust rewrite_header? RSK
