search

spamhaus / spamassassin-dqs

Spamhaus code for the Spamassassin plugin. See https://docs.spamhaustech.com/40-real-world-usage/SpamAssassin/000-intro.html
Apache License 2.0
54 stars 15 forks source link

Better integration into Linux distribution package management? #39

Closed robert-scheck closed 2 years ago

robert-scheck commented 2 years ago

Right now the integration into typical package management of Linux distributions is somehow working, but not outstanding.

Especially HBL with "You can copy sh_hbl.cf and sh_hbl_scores.cf if you want HBL enabled" from hbltest.sh is unusual. Normally, packages, e.g. RPMs, provide all files and prepared configuration files which might be edited by the administrator if necessary.

Does SpamAssassin support maybe something like this?

define SH_DQS your_DQS_key
define SH_HBL your_HBL_key
ifplugin Mail::SpamAssassin::Plugin::SH 
if SH_DQS != "your_DQS_key"
# …
endif

if SH_HBL != "your_HBL_key"
# …
endif

endif

Something like this would allow to ship all plugin files and an admin would just have to edit the first file to configure SH_DQS and/or SH_HBL as needed. And there still would be no harm if it's not configured.

Or, if it's not supported, is it possible to put this "intelligence" somehow into the eval:function()s of the module code? Like "if passed DNSBL has a string match with your_DQS_key, then do not run this function (or for overriden functions use the original pristine SpamAssassin one) and raise a warning?".

I'm not sure whether my point was clear…

ricalfieri commented 2 years ago

Unfortunately this is the only way we had as of today to distribute the plugin. I see your points but I'm not sure that SA supports what you suggest.

Also adding some checks in the code to understand if a key is HBL enabled or not and have them run and eventually override the original configuration is a bit overkill IMHO :)

Of course if anyone is interested in writing this logic (without interfering with performances) he/she is most welcome to make a pull request