https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6668
--- Comment #13 from Darxus <[email protected]> 2011-10-03 21:39:19 UTC --- (In reply to comment #12) > > Would you like to recommend another URL? > > The URL I wrote was PURELY a place-holder. I could have and should have > written something that implied more firmly that status such as > www.sa.org/foobar. > > The actually link should be determined in the patch. It likely should go to a > wiki article discussing RBL errors. But it definitely shouldn't be a link to > a > vendor, shouldn't say abuse and should be kept non specific. It likely should > have information on disabling the RBL rules as well. Agreed. > > I don't see how that is at at all conflicting with what I have suggested. > > I'm trying to keep my answers too short. I'll rephrase: > > You have suggested that disabling network tests causes FNs because emails then > slip through unmarked. I don't consider those true FNs because I consider them > FNs caused by a misconfiguration of SA. I disagree. That's a false negative, even if it's due to configuration. > SA works best with network tests and > we aren't recommending they are disabled. But some of them need consideration > before they are enabled post-installation. Yep. > We will have to agree to disagree. > > I am 100% convinced it is inappropriate to intentionally affect scores to get > the attention of admins. It is the very definition of collateral damage and > something I would strongly advocate against. Okay. > But again, I am one vote and this > is my opinion. "Votes on code modifications follow a different model. In this scenario, a negative vote constitutes a veto , which cannot be overridden." "...the proposal requires three positive votes and no negative ones in order to pass..." - http://www.apache.org/foundation/voting.html By our rules, it's enough on its own to make this not happen. > > RCVD_IN_DNSWL_HI is currently scored -5. Would you veto a rule that matched > > the return value of 127.0.0.255 with a score of -5 and a description that > > was > > helpful in resolving the situation that could not be construed as > > advertising? > > This needs more thought but I would veto it unless the following points are > met: > > - the NET result of the rules for the RBL in question in total add up to zero > (or subsequently similar e.g. 0.0001, etc.) So if there is a positive score > and > a negative score, the two together = 0. In other words, an RBL can't issue a > response that incorrectly affects scores on purpose due to limits, technical > errors, etc. I believe that requirement would eliminate dnswl.org's interest. Since you're willing to veto without it, I think that's sufficient to consider this thread dead. > > Another possibility I brought up 6 months ago in bug #6220 was, when > > receiving > > a return value of 127.*.*.255, disabling that rule. No more load on the > > provider, no skewed score for the user, no advertising. > > You are mentioning ideas that need to be adopted by RBLs more so than SA I don't understand why you say that. It's just another way of handing a 127.0.0.255 within spamassassin. So as far as RBLs and WLs are concerned it's still just an implementation of providing a .255 response for users who are over limit. As an example, say an email provider is using spamassassin to filter millions of emails a day. Some of the rules (RCVD_IN_XBL, RCVD_IN_PBL, RCVD_IN_SBL) cause queries is to zen.spamhaus.org. That being over their free use threshold, they start returning (only) 127.0.0.255 for all queries, to indicate the over limit condition. SpamAssassin notices the 127.0.0.255 value, and stops running all rules that hit zen.spamhaus.org. > but > this sounds a bit like a DoS ready to happen AND it's a case where the rule > that implemented this likely couldn't be on by default as shipped by SA. If > they are smart enough to turn on the feature, they likely know enough about > RBL > queries to perform local caching, rsync, etc. How is that a DoS ready to happen? Are we having another misunderstanding here? > I run quite a number of RBL public nameservers. I don't consider the traffic > to be that big a deal and I can blackhole queries quite easily. Are they RBLs that spamassassin has enabled by default? I run one dnswl.org mirror, and the only reason I can do that is my provider is willing to overlook my bandwidth limit due to a belief that dnswl is worth supporting. Mirroring dnswl.org causes almost all of my bandwidth usage. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
