>> Den 2012-07-26 17:26, Nißl Reinhard skrev: >>> 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 this behavior? 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 "z_local.pre" file? * Footnote: Methodology. This should reveal the load order (but not the parse order): spamassassin --lint -D config 2>&1 |egrep -o '/.*\.(pre|cf)$' |uniq
signature.asc
Description: OpenPGP digital signature
