ending the spam.assassin.prefs.conf madness.

[Anthony Peacock]

Hi,

> -----BEGIN PGP SIGNED MESSAGE-----
> 
> On 22 Nov 2005, at 15:42, Rick Cooper wrote:
> 
> >> -----Original Message-----
> >> From: MailScanner mailing list
> >> [mailto:MAILSCANNER at JISCMAIL.AC.UK]On Behalf Of Anthony Peacock
> >> Sent: Tuesday, November 22, 2005 10:10 AM To:
> >> MAILSCANNER at JISCMAIL.AC.UK Subject: Re: ending the
> >> spam.assassin.prefs.conf madness.
> >>
> >>
> > [...]
> >>> If I create a mailscanner.cf in there, and put everything from
> >>> spam.assassin.prefs.conf in it, and just softlink that 
> >>> mailscanner.cf and spam.assassin.prefs.conf, then does this do the
> >>> Right Thing(TM)?
> >>
> >> I am not too sure it does.  SpamAssassin works with the concept of
> >> two files, a 'site' config and a 'user' config.  Some configuration
> >> settings should go in the 'site' config and others in a 'user'
> >> config.
> >>
> >> The site_rules_path/mailscanner.cf file should be for site wide
> >> config options.
> >>
> >> The spam.assassin.prefs file should be for options that are only
> >> applicable when running MailScanner.
> >>
> >
> > How about this. Don't put the spamassassin.prefs.conf in the normal
> > site_rules dir at all.
> >
> > When Ms loads create a new Sa object, get the site_rules_path and 
> > read all the .cf files into a variable and reading into it 
> > spamassassin.prefs.conf last. Now destroy the original object and
> > create a new object  setting the new({config_text => MSRules}) to
> > the value of that variable. This,  according to the docs, will cause
> > SA to ignore all site and user prefs stuff  and use the value of
> > config_text instead. I don't think MailScanner uses  the user prefs
> > anyway. Once that is done you should be able to destroy the 
> > original variable and free the memory and the SA package would be
> > using what it always did. This should result in
> > spamassassin.prefs.conf in being the overriding site rules provider
> > while MailScanner is running and  completely ignored when sa-* is
> > run from the command line. If Julian has time  to test it that would
> > be great, otherwise I could get to it sometime this week-weekend.
> 
> A sample implementation would be good, but we are starting to get 
> near the end of the month. So if this is going in the next release, I 
> would like to sort it this week. I don't quite understand your
> description above, <pessimistic>sounds  complicated and
> error-prone</pessimistic>. I am all in favour of an  install-time
> simple solution. Otherwise you can end up making life  impossible for
> the advanced guys who like to tweak. I try to please  everyone if
> possible :-) 

My vote is to KISS, and go for the soft link route.

That way makes it very obvious for someone maintaining/debugging SA 
to see that there is an extra cf file that _may_ be overwriting some 
settings.


-- 
Anthony Peacock       
CHIME, Royal Free & University College Medical School
WWW:    http://www.chime.ucl.ac.uk/~rmhiajp/
"Minds, like parachutes, function best when open."

------------------------ 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!