ending the spam.assassin.prefs.conf madness.

Anthony Peacock a.peacock at CHIME.UCL.AC.UK
Tue Nov 22 15:58:50 GMT 2005


Hi,

> > -----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.
> 
> Ref:
> http://search.cpan.org/~jmason/Mail-SpamAssassin-3.1.0/lib/Mail/SpamAs
> sassin .pm

This is very neat, but I would actually prefer Julian's proposal.  By 
doing it Julian's way it is patently obvious what is happening with 
the SA config files.  And anyone maintaining SA can see that there is 
a mailscanner.cf file that may override other settings.

The issue I was raising above, was purely that there are some SA 
config directives that _have_ to go in the site_rules_path, and some 
that can be set via a user prefs file.  For maximum flexibility in 
the configuration I would like to see the two file option, where we 
keep a separate spam.assassin.prefs file as well as a 
site_rules_path/mailscanner.conf file.

However, if people think that manageing two files with such subtle 
differences would be over complicated for the 90% of users that want 
a simple out-of-the-box install.  Then I would prefer a 
site_rules_path/mailscanner.conf file with a soft link from the 
spam.assassin.prefs file.

I think Matt expressed the difference between the different config 
directives better than I can.

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



More information about the MailScanner mailing list