antispam at khopis
Aug 2, 2012, 7:27 PM
Post #6 of 6
>> Den 2012-07-26 17:26, Ni▀l Reinhard skrev:
Re: How do I reenable AWL on spamassassin 3.3 after upgrade from 3.1
[In reply to]
>>> reading the manuals, I've discovered that the AWL plugin isn't
>>> loaded anymore in spamassassin 3.3. Therefore I put the
>>> following lines into local.cf:
> On Fri, 27 Jul 2012 02:57:26 +0200 Benny Pedersen wrote:
>> oh no, do not put loadlugin into *.cf files its wrong pr design,
>> but so much wiki and bad behavior still continues
Speaking Hawaiian? (wiki == "quick") Or does the wiki actually suggest
On 07/26/2012 06:14 PM, RW wrote:
> It seems inelegant, but is there a practical reason why this
> shouldn't be done. Some optional plugins such as Botnet and iXhash
> load themselves from their own .cf files.
Yes, there is a practical reason.
In short, .pre files are read before .cf files, allowing all rules
access to all plugins. If a plugin was loaded in a .cf file, it would
not be available to .cf files that load earlier.
There is a very careful ordering to the loading of files to ensure that
newer versions and overrides are correctly loaded. Others should
correct me if I have this wrong*
1. Load /etc/spamassassin/*.pre
2. If /var/lib/spamassassin/[version] exists:
(a) Load its *.pre files and then its *.cf files
(b) Otherwise, load *.pre then *.cf in /usr/share/spamassassin
3. Load /etc/spamassassin/*.cf
4. Parse in order of loading
5. If an "include" line is encountered, interrupt everything and
(a) load the named file
(b) parse the named file
Files within a directory are sourced by asciibetical order (same as
`ls`). Sub-directories are NOT examined. Each individual file is read
from top to bottom, pausing for "include" directives as noted above
(this is how the updates area can have a hierarchy).
This lets /etc/spamassassin/local.cf (or wherever your system puts it)
run last, thus allowing you to trump scores and definitions.
Because of the loading order, third party plugins and configs whose
installations suggest /etc/spamassassin should have file names that
asciibetically precede local.cf, ideally starting with two digits and an
underscore, mimicking the SA upstream (e.g. 20_drugs.cf).
Getting back to your question, this means that if Botnet or iXhash are
depended on before they are loaded, the dependent rule won't load
correctly. The default install of iXhash doesn't have a problem here
because it's a self-contained item, so it loads the plugin and then uses
it later on in the same file.
This is not advisable because when you then go in to add additional
rules for that plugin, say by adding rules querying the third-party
iXhash repository from Spam-Eating Monkey in external.cf, it won't work
because the iXhash plugin isn't loaded until iXhash.cf. Furthermore, it
prevents third-party sa-update channels from using the plugin since they
are loaded in step 2 while local.cf is loaded in step 3.
It also makes maintenance (and troubleshooting) harder, though
SpamAssassin will take it. (There are lots of things SA can do that are
ill advised, like meta rules that use the ternary operator.)
The .pre files that live in /etc are kind of stuck named like that
(including init.pre, which is essentially v300.pre) due to their
location (otherwise, upgrading would require wiping them, which is taboo
in the Unix world). I'd suggest installing an empty "local.pre" were it
not for the fact that this would come /before/ the others. Maybe a
* Footnote: Methodology.
This should reveal the load order (but not the parse order):
spamassassin --lint -D config 2>&1 |egrep -o '/.*\.(pre|cf)$' |uniq