SA installer oddities:

[Alex Broens]

On 4/8/2008 7:35 PM, Julian Field wrote:
> 
> 
> Alex Broens wrote:
>> Jules
>>
>> Finsihed the install and BEFORE adding my own stuff to 
>> /etc/mail/spamassassin I checked the *.pre files for redundant loads:
>>
>> init.pre
>>
>> includes:
>>
>> loadplugin Mail::SpamAssassin::Plugin::URIDNSBL
>> loadplugin Mail::SpamAssassin::Plugin::SPF
>> loadplugin Mail::SpamAssassin::Plugin::RelayCountry
>> loadplugin Mail::SpamAssassin::Plugin::Razor2
>>
>>
>> v310.pre
>>
>> includes:
>>
>> loadplugin Mail::SpamAssassin::Plugin::RelayCountry
>> loadplugin Mail::SpamAssassin::Plugin::SPF
>> loadplugin Mail::SpamAssassin::Plugin::URIDNSBL
>>
>>
>>
>> v320.pre
>>
>> includes:
>>
>> loadplugin Mail::SpamAssassin::Plugin::RelayCountry
>> loadplugin Mail::SpamAssassin::Plugin::SPF
>> loadplugin Mail::SpamAssassin::Plugin::URIDNSBL
>> loadplugin Mail::SpamAssassin::Plugin::Razor2
>>
>>
>>
>> [13756] dbg: plugin: did not register 
>> Mail::SpamAssassin::Plugin::RelayCountry, already registered
>> [13756] dbg: plugin: did not register Mail::SpamAssassin::Plugin::SPF, 
>> already registered [13756] dbg: plugin: did not register 
>> Mail::SpamAssassin::Plugin::URIDNSBL, already registered
>>
>> [13756] dbg: plugin: did not register 
>> Mail::SpamAssassin::Plugin::RelayCountry, already registered
>> [13756] dbg: plugin: did not register Mail::SpamAssassin::Plugin::SPF, 
>> already registered
>> [13756] dbg: plugin: did not register 
>> Mail::SpamAssassin::Plugin::URIDNSBL, already registered
>> [13756] dbg: plugin: did not register 
>> Mail::SpamAssassin::Plugin::Razor2, already registered
>>
>>
>> seems to me there a lot of redundant stuff being loaded and reloaded 
>> and reloaded - not sure at this point what you added and what's 
>> default (need to take SA source apart and check)
> All this registering of plugins is done once when each MailScanner child 
> starts up. It makes no difference to mail processing speed at all.
>>
>> May I suggest you don't modify the .pre files after install and point 
>> admins to check the stuff being loaded in the 3 .pre files and enable 
>> whatever specials they may need.
>> The standard enabled SA plugins will produce a decent working SA 
>> withotu any pain.
> My ClamAV+SpamAssassin package automatically enables these plugins:
> Mail::SpamAssassin::Plugin::RelayCountry
> Mail::SpamAssassin::Plugin::SPF
> Mail::SpamAssassin::Plugin::URIDNSBL
> Mail::SpamAssassin::Plugin::Razor2
> 
> To make sure these get loaded regardless of what version of SpamAssassin 
> you are using, it writes these into all of v320.pre, v310.pre and 
> init.pre. Attempting to load them all 3 times probably adds a 
> millisecond to the startup time of MailScanner, but I really don't care 
> a hoot about that :-)

forcing loads on a possible older SA version which doesn't support 
certain plugins will cause lint errors and fail an sa-update or sa-compile.

Mail::SpamAssassin::Plugin::URIDNSBL is in init.pre

been there for ages -what can your installer fix if its already enabled 
by default?

Mail::SpamAssassin::Plugin::RelayCountry is not enabled by default as it 
adds a certain overhead

Razor2 is enabled BEFORE its installed - if you warn ppl they must 
install it, why not let them enable the plugin?

you may say, mainly cosmetics, but when linting they just don't make the 
results look MS-like :-)