[quote user="pmerik"]
I suggest that Content Control should accumulate weights from all rule sets. Possibly as an option with an associated threshold, in addition to the per file thresholds.
Rationale: Content Control is a valuable spam fighting tool because it can catch tricks that would fool Bayesian filters, e.g concatenation like ArbitraryWordViagraArbitraryFemaleName. This suggestion would make it possible to update/replace SPAMBUST.DAT (as part of the Pegasus install package) without overwriting user additions. Plus it would encourage a more fine-grained rule structure.
If my primary suggestion is not feasible, then I suggest either
- that the file-size limit of the internal editor be removed, or
- that the internal editor be disabled and an external editor be launched when the limit is exceeded
Erik
[/quote]
I would have to agree. When building my own filters, I prefer to have a variety of smaller sets of filters so that I can order, and apply fine control. One file for RECEIVED headers, another for pharmacy type spam, another for enormous appendages, etc. Even if there is the capacity to identify the active filters so that they are able to be strung together.
It would also be useful to be able to apply a global set of filters (uneditable), and then apply user-based filters.
[Having changed ISP's and they're not having as a good set of spam filtering, I am back into doing a bit more of my own.]
Regards Andrew
[quote user="pmerik"]<p>I suggest that Content Control should accumulate weights from all rule sets. Possibly as an option with an associated threshold, in addition to the per file thresholds.
</p><p>Rationale: Content Control is a valuable spam fighting tool because it can catch tricks that would fool Bayesian filters, e.g concatenation like ArbitraryWordViagraArbitraryFemaleName. This suggestion would make it possible to update/replace SPAMBUST.DAT (as part of the Pegasus install package) without overwriting user additions. Plus it would encourage a more fine-grained rule structure.</p><p>If my primary suggestion is not feasible, then I suggest either</p><ol><li>that the file-size limit of the internal editor be removed, or</li><li>that the internal editor be disabled and an external editor be launched when the limit is exceeded</li></ol><p>Erik
[/quote]</p><p>I would have to agree.&nbsp; When building my own filters, I prefer to have a variety of smaller sets of filters so that I can order, and apply fine control.&nbsp; One file for RECEIVED headers, another for pharmacy type spam, another for enormous appendages, etc.&nbsp; Even if there is the capacity to identify the active filters so that they are able to be strung together.&nbsp;&nbsp;
It would also be useful to be able to apply a global set of filters (uneditable), and then apply user-based filters.
</p><p>[Having changed ISP's and they're not having as a good set of spam filtering, I am back into doing a bit more of my own.]
</p><p>Regards Andrew
</p>
