|Main Archive Page > Month Archives > spamassassin-dev archives|
--- Comment #14 from Karsten BrÃ¤ckelmann <firstname.lastname@example.org> 2011-11-30 16:57:34 UTC ---
(In reply to comment #12)
> > We really do not want to introduce new DNS lookups in an existing branch, but
> > strictly with the next major/minor release only and a clear announcement in the
> > release notes.
> Wait, you want to *never* include mailspike in the existing 3.3.* releases, and
> create a separate rule set for 3.4.*? Because of increasing the network load
> by 1 DNS lookup, for a very useful looking RBL? That sounds... not good.
*shrug* Sounds good to me.
> How can you justify that?
Very easily by pointing you to the uproar and lengthy discussion the last (and
first) time a new DNSBL has been pushed with a rule update because it was added
to the sandboxes.
The conclusion of the discussion was clear -- DNSBLs MUST NOT be introduced via
the update channel.
Moreover, since the planned next version will be 3.4, discussing potential
inclusion in a 3.3.x micro version release is a moot point.
(In reply to comment #13)
> I believe we can just encapsulate it in a version check.
Would that not bias the re-scoring, and thus negatively impact 3.3?
-- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.