[Bug 5964] New: Different "default rules dir" used by spamassassin and sa-update

[bu...@bugzilla.spamassassin.org]

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5964

           Summary: Different "default rules dir" used by spamassassin and
                    sa-update
           Product: Spamassassin
           Version: 3.2.5
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P4
         Component: sa-update
        AssignedTo: dev@spamassassin.apache.org
        ReportedBy: ignaciob@123plaza.com


This problem is being discussed in
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5752 and
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5751

However I would like to point to the direct cause of the problem, being that
installation of spamassassin + bundled rules and sa-update are configured with
different paths for default rules directories; for spamassassin this is set to
"/usr/share/spamassassin" and for sa-update is set to "/var/lib/spamassassin"
therefore the problem. 

If you happen to run sa-update with no options, you will see a duplicate set of
rules being installed/updated in "/var/lib/spamassassin/<version>", but the
problem is that when spamassassin runs, asides from looking into
"/etc/mail/spamassassin" will also look into "/var/lib/spamassassin/<version>"
as well as in "/usr/share/spamassassin". Thus creating the possibility of
having duplicate or even triplicate set of rules in these directories. 

You can easily corroborate this by running "spamassassin -D --lint" and
noticing the multitude of lines containing "merged duplicates:" messages.

If you combine this with the fact that users and admins alike are not aware of
these default rules installation, you get a recipe for disaster when users
start adding rules to the directory "/etc/mail/spamassassin" totally oblivious
to the fact that there might be additional set of rules installed in other
directories.

To make it even more disastrous, some packagers also include automatic
installation of the cron script that runs sa-upadte on a daily basis. So no
matter what you do, you will sure get your duplicate set of rules.

Asides from this being already a bad problem, it gets compounded when you
have rules in a directory that have been updated, and not updated in
others, then with time you will experience an incremental slowdown in
performance by spamassassin, until it becomes barely usable.

As explained to me by other users, in the past it has been customary to place
tools in "/usr/share/spamassassin" (e.g. rule-sets) to be later used by copying
the contents to  "/var/lib/spamassassin", Which to me makes plenty of sense.

What ever you do I please ask you NOT to force any rules filtering upon the
users, mainly because many older systems do not have enough memory, or can not
handle the load with so many rules loaded. Also consider that when an upgrade
is performed, users will continue to use older set of rules in place (e.g.
SARE) in addition to newly installed sets. 

Despite the fact that SARE rules have been deprecated, this is not widely known
on the web, and a prolific indication of this can be easily found when
searching for spamassassin tutorials or howtos, that recommend installing "the
latest" spamassassin along with SARE rules, rulesdujour.


Regards,

Ignacio


-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.