In any case i have the impression that setting auto_whitelist_path in the config-file does not work. Using its rule base, it uses a wide range of heuristic tests on mail headers and body text to identify spam'', also known as unsolicited commercial email.
SPAMASSASSIN WHITELIST VALIDATION CODE
However the validation code also needs some relaxations as auto_whitelist_path is a file but the validation code checks for a directory. SpamAssassin is a mail filter to identify spam using text analysis and several internet-based realtime blacklists.
This corresponds to my observations that auto_whitelist_path is always set to the default value, regardless of the configfile.Īs a workaround txrep_path can be renamed to auto_whitelist_path. I believe the variable 'txrep_path' isn't referenced anywhere else in the code so this might be a typo. What seems fishy to mee is that the value is saved to 'txrep_path' and not to 'auto_whitelist_path'. Looking at the code i found the following fishy snippet in lib/Mail/SpamAssassin/Plugin/TxRep.pm:ĭefault => '_userstate_/tx-reputation', Now note how /tmp/myhome/.spamassassin/tx-reputation is created, regardless of dual-storage being disabled and regardless of the auto-whitelist-path settings in local.cf. To reproduce you can invoke: `mkdir -p /tmp/myhome cat /tmp/ham | HOME=/tmp/myhome sa-learn -dbpath /my/path -ham` So spamassassin will always try to write to //.spamassassin/tx-reputation which throws a permission denied. In our setup sa-learn is invoked by a webservice and we do not have a HOME env var. The code will always try to lock and write to ~/.spamassassin/tx-reputation regardless of dual storage.
This bug is having quite some impact as it makes it impossible to disable dual storage for txrep. In fact the code will always use '_userstate_/tx-reputation' regardless of the settings in local.cf. When i add `auto_whitelist_path /some/path` to my local.cf, this option is not picked up by spamassassin.