May I suggest that handling whitelist or blacklist rules and any
associated plugins by packaging them as separately installable modules
may be of benefit to SA maintainers. The idea is to reduce the SA dev
workload by handing off responsibility for maintaining and bugfixing
such modules to external developers. These may, as at present, be the
person who independently develops the module or the people who are
responsible for the resources it queries. Here's a little more detail:
- exclude the modules from the default SA configuration and from SA
updates.
- create a library of downloadable modules, one for each external
resource. Each module consists of:
- a .cf file and a .pm file, if required, that should be installed by
putting both in /etc/mail/spamassassin
- version info
- installation and configuration instructions
- attributions: author, the author's affiliations, etc
- a disclaimer saying that SA distributes the module as is and without
liability or responsibility for its correctness
- anybody, including whitelist owners, can supply a module and will be
solely responsible for maintaining it.
- modules MUST be accompanied by regression test data in the form of
messages that demonstrate hits, misses and corner tests.
- SA devs should review the documentation and verify module operation
using the supplied test data to show that the module does what it says
on the tin and doesn't crash SA or interfere with other rules/plugins
before accepting a module for publication.
- the modules should be included in regression tests for new SA
versions. If a module fails a regression test it is excluded from the
library and its author notified. This way unmaintained modules will
eventually disappear with minimal work from SA devs apart from
removing the model from the distribution library and adding it to a
list of no longer supported modules.
There may be problems with this approach that I'm not aware of, but I'm
floating it because AFAIK nobody else has suggested it and it may defang
some of the discussions around whitelists, etc. by making the use of
such rules and modules independent of the SA project.
Martin
