https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6400
--- Comment #18 from João Gouveia <[email protected]> 2011-11-30 17:36:54 UTC --- (In reply to comment #15) > (In reply to comment #14) > > 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. > > That uproar was because that blacklist (spam eating monkey) was automatically > detecting "abuse" and causing many false positives. (bug 6220) > > > (In reply to comment #13) > > > I believe we can just encapsulate it in a version check. > > An interesting suggestion. > > > Would that not bias the re-scoring, and thus negatively impact 3.3? > > And an excellent question. > > What do you folks think about polling the users list about adding a new DNSBL > to existing 3.3 releases? Should I just post, asking? > > What's the worst that will happen if these rules are enabled for existing > 3.3.* > releases? João, can you confirm that mailspike will not cause false positives > as a result of detecting high amounts of traffic? So worst case, people get > no > DNS response, and the score is not affected? Also, worst case, we revert the > addition a day later. Yes, I can confirm that. We have also deployed a DNSBL mirror network, which is on standby and ready to kick in, in case we start getting too much traffic. > > (All, of course, depending on getting rule updates happening again, bug 6702.) (In reply to comment #15) > (In reply to comment #14) > > 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. > > That uproar was because that blacklist (spam eating monkey) was automatically > detecting "abuse" and causing many false positives. (bug 6220) > > > (In reply to comment #13) > > > I believe we can just encapsulate it in a version check. > > An interesting suggestion. > > > Would that not bias the re-scoring, and thus negatively impact 3.3? > > And an excellent question. > > What do you folks think about polling the users list about adding a new DNSBL > to existing 3.3 releases? Should I just post, asking? > > What's the worst that will happen if these rules are enabled for existing > 3.3.* > releases? João, can you confirm that mailspike will not cause false positives > as a result of detecting high amounts of traffic? So worst case, people get > no > DNS response, and the score is not affected? Also, worst case, we revert the > addition a day later. Yes, I can confirm that. We have also deployed a DNSBL mirror network, which is on standby and ready to kick in, in case we start getting too much traffic. > (All, of course, depending on getting rule updates happening again, bug 6702.) (In reply to comment #15) > (In reply to comment #14) > > 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. > > That uproar was because that blacklist (spam eating monkey) was automatically > detecting "abuse" and causing many false positives. (bug 6220) > > > (In reply to comment #13) > > > I believe we can just encapsulate it in a version check. > > An interesting suggestion. > > > Would that not bias the re-scoring, and thus negatively impact 3.3? > > And an excellent question. > > What do you folks think about polling the users list about adding a new DNSBL > to existing 3.3 releases? Should I just post, asking? > > What's the worst that will happen if these rules are enabled for existing > 3.3.* > releases? João, can you confirm that mailspike will not cause false positives > as a result of detecting high amounts of traffic? So worst case, people get > no > DNS response, and the score is not affected? Also, worst case, we revert the > addition a day later. Yes, I can confirm that. We have also deployed a DNSBL mirror network, which is on standby and ready to kick in, in case we start getting too much traffic. > > (All, of course, depending on getting rule updates happening again, bug 6702.) -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
