On 8/22/2012 10:26 AM, Axb wrote: > On 08/22/2012 04:10 PM, Ben Johnson wrote: >> >> I did end-up overriding the bayes_path, which provided a workaround for >> the permissions issues. Cheers to the suggestion. > > This is not a workaround, it's common practice in many types of setups > and documented, but due to numerous reasons can't be set as a default. > If the install routine would require/create a > /etc/mail/spamassassin/bayes path it could bite "other" systems than > standard Linux distros. > (note to myself: discuss this in dev list)
Right; it makes sense that this path cannot have a default value (other than ~/...). That said, it seems that for some users (myself included), setting this path manually is a critical step in creating a maximally functional (that is, Bayes-enabled) SpamAssassin installation. This would be especially true if the SA developers were to change the "bayes_auto_learn" default value to zero, or lower the default value for "bayes_auto_learn_threshold_nonspam" (as a result of my "incident" here). For this reason, it seems prudent for developers/contributors to take one of two actions (or both): 1.) Add the "bayes_path" directive to the default/stock "local.cf" that ships with SpamAssassin, in a commented-out state. I realize that this file may be maintainer/distribution specific, and that there are attendant challenges associated with such a change. This measure would underscore the directive's importance for the administrator who is configuring the software. 2.) Where possible, modify the SpamAssassin installer package to prompt the user for the "bayes_path" during installation. These types of prompts are common among related packages. For example, Postfix asks for all kinds of information during its installation (on Debian-based systems, anyway). Again, I realize that the SA developers likely have no control over how the software is packaged and delivered, so if this point seems valid, I am happy to open distro-specific bug reports (or feature requests). Thanks, Axb. -Ben
