ending the spam.assassin.prefs.conf madness.

[Julian Field]

    [ 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. ]

Okay, I understand that I shouldn't be putting site-wide settings in 
spam.assassin.prefs.conf as it stands. Is there any way of
(a) telling SpamAssassin to use spam.assassin.prefs.conf as a site-wide 
settings file,
or
(b) working out automatically exactly where the site-wide settings 
should go on any given installation. On things like Solaris the correct 
location is damn near impossible to find. Telling people to go and edit 
their site-wide SpamAssassin settings file is not much use. I need to be 
able to work out the precise location of the best file to use, and do 
the necessary editing for them in the install script. That's why I have 
always done it the way I have. It pretty much worked okay, and the file 
was in an easy-to-find location that (1) I could work out and (2) users 
would be able to find it again later if they needed to change something 
6 months later when they had forgotten what the install script told them.

An ideal solution would be a soft-link in the MailScanner/etc directory 
to the real location of the file. But I still have to find the real file.

All constructive ideas are most welcome.

Anthony Peacock wrote:

>Hi Matt,
>
>  
>
>>Richard Edge wrote:
>>    
>>
>>>Thanks Matt. As mentioned in another message I am using 3.1 not
>>>3.01. It was a typo on my part. I have removed antidrug.cf. The
>>>spam.assassin.prefs.conf suggested renaming the local.cf file so
>>>that it wouldn't be used. Are you suggesting then that it be used to
>>>disable certain SpamAssassin functions/tests?
>>>
>>>      
>>>
>>I'm suggesting, that the advice in spam.assassin.prefs.conf is
>>dangerous. I have no idea why Julian suggests this, as it's a BAD
>>IDEA.
>>
>>
>>Among other things, spam.assassin.prefs.conf should not contain any
>>privileged or administrator options.
>>
>>These options work in this file on some versions of SA, but this is
>>largely accidental because currently only the spamd code strictly
>>enforces all aspects of the privilege parsing rules.
>>
>>According to the documentation of spamassassin, many of the options
>>that Julian has in spam.assassin.prefs.conf should be ignored, and may
>>well be ignored in a future version.
>>
>>In particular, use_auto_whitelist has proven unreliable if declared in
>>spam.assassin.prefs.conf under 3.0.x. It only seems to work if
>>declared in the place the docs for 3.0.x tell you it needs to be. At
>>the site config level i
>>
>>
>>IMNSHO, spam.assassin.prefs.conf should _ONLY_ contain options that
>>you want to use under MailScanner, but not when using the command
>>line. Fundamentally this is a user_prefs file, and should be treated
>>as such. It is NOT a local.cf replacement.
>>
>>Using your local.cf for your site-wide settings guarantees that these
>>settings will properly apply to sa-learn, and spamassassin --lint,
>>without requiring you to remember to use -p
>>/etc/MailScanner/spam.assassin.prefs.conf every time.
>>
>>Very often people add bayes_path statements to
>>spam.assassin.prefs.conf, but fail to pass -p to sa-learn. In this
>>case, all their manual training becomes useless, as it goes to the
>>wrong place.
>>
>>Currently I've reduced my spam.assassin.prefs.conf to be empty except
>>for timeout adjustments.
>>
>>I'd strongly suggest mailscanner users think long and hard about their
>>options placement, and avoid using spam.assassin.prefs.conf for
>>settings which really belong in local.cf. Treat this file not as a
>>"master config" but as a way of customizing SA's behavior for
>>MailScanner.
>>    
>>
>
>Thanks for eloquently expressing something that I have been meaning 
>to write for a little while now.  I got bitten by the advice in the 
>MailScanner spam.assassin.prefs file, until I realised that it should 
>be considered a user prefs file, and not a replacement for local.cf.
>
>I am all for making life easy and not having commands in lots of 
>different places, but instructing people to delete local.cf is an 
>oversimplification.  I now have a basically empty spam.assassin.prefs 
>file, as I want most of the SA configurations to be applied site 
>wide, whilst running the SA command line tools as well as running 
>from MailScanner.  And some of the configuration commands are not 
>valid in a user prefs file anyway.
>
>I think it is a very good idea that Julian has created installs that 
>can install and configure a complete MailScanner, SA, ClamAV and MTA 
>setup 'out of the box'.  This makes life very easy for people 
>starting from scratch, who may not have the knowledge and experience 
>to stitch this all together.  However, this does cause confusion when 
>somone wants to implement a feature of SA that cannot be configured 
>in a user prefs file. (There was something recently, but I can't find 
>it in the archives right now.)  
>
>Please do not take this as a pop at Julian or any of the other 
>contributors.  I just think it would be better to make the 
>distinction between SA's different config files, rather than glossing 
>over them.
>
>  
>

-- 
Julian Field
www.MailScanner.info
Buy the MailScanner book at www.MailScanner.info/store
Professional Support Services at www.MailScanner.biz
MailScanner thanks transtec Computers for their support

PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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