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

Julian Field wrote:
> Okay, I understand that I shouldn't be putting site-wide settings in
> spam.assassin.prefs.conf as it stands.

Julian.. Here's another point to consider... Why should MailScanner's
installation be modifying the site options AT ALL?

For example, you're specifying "lock_method flock" in spam.assassin.prefs.conf.
But in doing so, you're assuming the user has no NFS shares.

Many of these options aren't really mailscanner specific, but site
implementation specific.

It might be nice to provide a "suggested" mailscanner.cf file for people to use,
but I largely don't see the point of MailScanner's installation specifying
bayes_paths, lock_method, dcc_path, etc as it does now. In general, many of
these have done me more harm than good.

The only major option I see of as having any value is the "use_auto_whitelist"
However, that's largely moot now.

1) the AWL was fixed to avoid some of the problems I cited in it long ago, so I
feel much less strongly about the problems of site-wide AWL usage.

2) the AWL is a plugin as of 3.1.0, so this option isn't the preferred way of
disabling the AWL. It's preferred to not load the module at all, saving memory.
And, for anyone who has done it the preferred way, this option will cause parse
errors.



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

Can you access the $siterules member of Mail::SpamAssassin? I don't know enough
perl to tell the difference between public and private, but this is where
Mail::SpamAssassin stores what site rules directory it's actively using.


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.

IMHO, you're doing a bit too much for the user, and running into problems you
shouldn't be having in the first place.

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

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