https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6400
--- Comment #14 from Karsten Bräckelmann <[email protected]> 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.
