https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6668
--- Comment #12 from Kevin A. McGrail <[email protected]> 2011-10-03 21:11:59 UTC --- > 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. > Er, yeah, that sounds like a pretty good definition to me. Especially if SA > actually slaps on a "X-Spam-Status: No" header, which would be the case here. > > > We have to ship SA in a way that is safe for the vast majority of users > > which > > might not be the most effective for blocking all Spam. > > 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. 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. > I don't claim to know the intentions of the owners of DNSWL and SEM. But I'm > not convinced that it's inappropriate to intentionally affect scores > (preferably with false negatives instead of false positives) in order to get > the attention of an administrator to explain the problem and get them to > either > stop sending millions of queries a day, or start sending money. 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. But again, I am one vote and this is my opinion. > 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. - The description in the Rule was generic, suitable for all RBLs and pointed to a URL under SA's control. Perhaps even just one rule for all the RBLs that can give an error code response. > 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 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. 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. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
