Dynamic groups, autogroup

[Howard Chu]

Content preview: For the record - I've never liked the autogroup overlay. It's
a fairly brute-force solution to what should be dynamic groups, making them
into static ones. The limitation in dyngroup/dynlist about being unable to
match member=foo filters is annoying, of course. But having worked thru a
similar problem in the contrib/adremap overlay, the solution now is obvious
- just use an additional search request, to find all of the dynamic groups
in the scope (autogroup already does this once, at startup time) and then
feed the filter attribute to each, one by one, doing the same evaluation
that dyngroup's Compare handler already does. [...]

Content analysis details: (-1.1 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: highlandsun.com]
0.8 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server
[12.218.80.3 listed in dnsbl.sorbs.net]
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]

For the record - I've never liked the autogroup overlay. It's a fairly
brute-force solution to what should be dynamic groups, making them into static
ones.

The limitation in dyngroup/dynlist about being unable to match member=foo
filters is annoying, of course. But having worked thru a similar problem in
the contrib/adremap overlay, the solution now is obvious - just use an
additional search request, to find all of the dynamic groups in the scope
(autogroup already does this once, at startup time) and then feed the filter
attribute to each, one by one, doing the same evaluation that dyngroup's
Compare handler already does.

For sites with very large groups, dynamic groups are generally the right
approach, for size/efficiency reasons. autogroup throws away any efficiency
gains, but we can get them back.