You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2016/12/15 13:50:34 UTC
[Bug 7383] New: auto_whitelist_path from config not used
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7383
Bug ID: 7383
Summary: auto_whitelist_path from config not used
Product: Spamassassin
Version: 3.4 SVN branch
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: spamassassin
Assignee: dev@spamassassin.apache.org
Reporter: kvr@vasco.com
Target Milestone: Undefined
When i add `auto_whitelist_path /some/path` to my local.cf, this option is not
picked up by spamassassin. In fact the code will always use
'__userstate__/tx-reputation' regardless of the settings in local.cf.
This bug is having quite some impact as it makes it impossible to disable dual
storage for txrep. The code will always try to lock and write to
~/.spamassassin/tx-reputation regardless of dual storage. In our setup sa-learn
is invoked by a webservice and we do not have a HOME env var. So spamassassin
will always try to write to //.spamassassin/tx-reputation which throws a
permission denied.
To reproduce you can invoke: `mkdir -p /tmp/myhome; cat /tmp/ham |
HOME=/tmp/myhome sa-learn --dbpath /my/path --ham`
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.
Looking at the code i found the following fishy snippet in
lib/Mail/SpamAssassin/Plugin/TxRep.pm:
setting => 'auto_whitelist_path',
default => '__userstate__/tx-reputation',
code => sub {
...
$self->{txrep_path} = $value;
}
What seems fishy to mee is that the value is saved to 'txrep_path' and not to
'auto_whitelist_path'.
I believe the variable 'txrep_path' isn't referenced anywhere else in the code
so this might be a typo.
This corresponds to my observations that auto_whitelist_path is always set to
the default value, regardless of the configfile.
As a workaround txrep_path can be renamed to auto_whitelist_path. However the
validation code also needs some relaxations as auto_whitelist_path is a file
but the validation code checks for a directory.
In any case i have the impression that setting auto_whitelist_path in the
config-file does not work.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7383] auto_whitelist_path from config not used
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7383
kvr@vasco.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kvr@vasco.com
--- Comment #1 from kvr@vasco.com ---
Created attachment 5426
--> https://bz.apache.org/SpamAssassin/attachment.cgi?id=5426&action=edit
A workaround to make auto_whitelist_patch work
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7383] auto_whitelist_path from config not used
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7383
Kevin A. McGrail <km...@pccc.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kmcgrail@pccc.com
--- Comment #2 from Kevin A. McGrail <km...@pccc.com> ---
I think you are on to something. Likely some code left over from a plugin used
as a template?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7383] auto_whitelist_path from config not used
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7383
Henrik Krohns <ap...@hege.li> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|NEW |RESOLVED
CC| |apache@hege.li
--- Comment #6 from Henrik Krohns <ap...@hege.li> ---
Better late than never? Feel free to test if you can..
Sending spamassassin-3.4/lib/Mail/SpamAssassin/Plugin/TxRep.pm
Sending trunk/lib/Mail/SpamAssassin/Plugin/TxRep.pm
Transmitting file data ..done
Committing transaction...
Committed revision 1864014.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7383] auto_whitelist_path from config not used
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7383
Sean Greenslade <se...@seangreenslade.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sean@seangreenslade.com
--- Comment #3 from Sean Greenslade <se...@seangreenslade.com> ---
I just ran into this bug while enabling txrep, so it is still an issue as of
3.4.2.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7383] auto_whitelist_path from config not used
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7383
Jason <ja...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jasonrabel99@gmail.com
--- Comment #5 from Jason <ja...@gmail.com> ---
I just decided to try switching over too and caught this while reading other
things.
Looking at the code it appears that 'auto_whitelist_file_mode' a couple blocks
below the 'auto_whitelist_path' also needs to be adjusted.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7383] auto_whitelist_path from config not used
Posted by bu...@bugzilla.spamassassin.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7383
Kevin A. McGrail <km...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|Undefined |4.0.0
--- Comment #4 from Kevin A. McGrail <km...@apache.org> ---
Yes, I think txrep used the AWL plugin as a "template" and there is some
criscross. I'm targeting this for 4.0
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 7383] auto_whitelist_path from config not used
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7383
--- Comment #7 from Jason <ja...@gmail.com> ---
Change appears to be working, file timestamp is getting updated regularly for
the specified filename.
--
You are receiving this mail because:
You are the assignee for the bug.