ending the spam.assassin.prefs.conf madness.

[Matt Kettler]

    [ The following text is in the "ISO-8859-1" character set. ]
    [ Your display is set for the "US-ASCII" character set.  ]
    [ Some characters may be displayed incorrectly. ]

Rick Cooper wrote:

>>The code that's relevant from SpamAssassin.pm is:
>>
>>    my $siterules = $self->{site_rules_filename};
>>    $siterules ||= $self->first_existing_path (@site_rules_path);
>>
>>
> 
> 
> That says set the site rules path to site_rules_filename, if provided by the
> calling program,
> and if $siterules doesn't have a value the use the sub first_exiting_path to
> return the first path that exists. It looks at the paths below

That much I understand.. the part I did not understand is if this code is in
Mail::SpamAssassin::init() does siterules become an accessible member of a
Mail::SpamAssassin object or not.

I've never got the hang of figuring out how to tell what variables are
externally accessible and which are not in perl code. As a C++ programmer it all
looks rather haphazard with no clear way of identifying interfaces, except that
which is documented separately in man pages. But then again, I don't know the
language, so that appearance my just come from lack of good understanding.

 For example, as said previously, I have no clue why the "my" does. I assume it
has something to do with scope, but does it make it the equivalent of "private"
(ie: my = mine and mine alone) or "public" (my = my exported member)?


> So if you were to use the attached revision of the script I posted earlier
> it will look in all the possible dirs except /opt/$DIR or $DIR (no way to
> tell what $DIR is).

That much I understand too. I was hoping to find a good way to extract this
information directly from a small perl script invoking a Mail::SpamAssassin
object. This way you'd be able to identify it with 100% accuracy, and would keep
abreast of changes in the SA code.

Unfortunately, it doesn't work that way.

> Perhaps the best thing is get a consensus as to what should be in a
> spamassassin.prefs.conf file for the wide masses of novice admins and allow
> those who know what they are doing modify as they desire. Kind of like the
> basic exim.conf, it is safe and functional out of the box without having to
> know technical details to get the mail system up and running. Novices will
> *always* try and run mail systems without learning what they are doing first
> and it's best to default to least knowledge required to operate, IMHO

I agree wholeheartedly. My actual complaint is that the existing
spam.assassin.pref.conf creates several pitfalls for novice users to fall in.
Something which is clearly bad for novices if we want to help them.

I'm a relatively knowing user and have fallen into many of these traps myself.
This implies very bad things are ahead for the novice.


In general there are several general classes of settings in the existing
spam.assassin.prefs.conf. Some should stay, some are questionable, some should
probably be commented out, and some need proper warnings.


1) settings which make SA aware of mailscanner's behaviors or improve SA's
behavior under mailscanner. These are undoubtedly good.
	envelope_sender_header
	bayes_ignore_header
	rbl_timeout		
	razor_timeout
	pyzor_timeout

(note: the rbl_timeout setting in spam.assassin.prefs.conf is 20, which LARGER
than the SA default of 15 in 3.0+. I think this is contrary to its original
purpose of trying to shorten the RBL timeout from its old default of 30.)

2) settings which fix broken rules in SA by disabling them. Sorta good, but they
cause problem when SA catches up and removes the rule.
	score RCVD_IN_RSL 0

3) added rules distributed for convenience:
	IE_VULN
	FRIEND_GREETINGS
	FRIEND_GREETINGS2

3) settings which make assumptions about the system setup to tune performance.
While these may help, in some cases they over-ride the safer SA defaults and may
create pitfalls for novice users.

	dns_available
	lock_method
	pyzor_path
	dcc_path

4) settings which over-ride the defaults on matters of site preference.
	ok_locales

5) settings which are set for no apparent reason.
	bayes_file_mode

6) settings which are commented out, but could cause problems for the unwary if
used here.
	bayes_file_mode  (need to make sure sa-learn sees this option too, but no
mention of that!)
	bayes_auto_expire (Not all SA versions reliably honor this here. I have seen
this fail on 2.64 until moved to local.cf.)

7) settings which work, but the docs say shouldn't.
	use_auto_whitelist 0

------------------------ MailScanner list ------------------------
To unsubscribe, email jiscmail at jiscmail.ac.uk with the words:
'leave mailscanner' in the body of the email.
Before posting, read the Wiki (http://wiki.mailscanner.info/) and
the archives (http://www.jiscmail.ac.uk/lists/mailscanner.html).

Support MailScanner development - buy the book off the website!