On Fri, 8 Jun 2018 at 19:31, Michael Peddemors <mich...@linuxmagic.com> wrote: > On 18-06-08 09:14 AM, Stefano Bagnara wrote: > > [...] > > In fact I still have to understand how spam reports and false positive > > reports are collected in the whole plesk world (I guess you know what > > I'm talking about): [...] > > Well, like any system, I think that you are probably looking at this too > simply, it could be that the system administrator has chosen to reject > instead of flag.. It depends on the system implementation. This isn't > related to any specific RBL, but how it is used. > > Some use it to 'block', some use it to tag, and it doesn't matter which > RBL it is, SpamHaus, SpamRats, UCE-Protect, Invalument, Barracuda.. (or > a subset of their offerings) or a more specific purpose list..
I agree, but when a lot of users for an RBL use it to reject at the smtp level then you loose your false-positive feedbacks. If there a big sample of users that use the list but are not able to report false positives, then you can't say anymore that the list have "low false positive". In order to try to go back in topic, I think this "false positive loop" that is often missing for smaller users that simply stack up a number of DNSBLs and reject for every match, is an issue and an issue that need more attention and priority than the ipv6 stuff. IPv6 will increase the fragmentation and more fragmentation will mean more servers with low volumes and more servers with low volumes means much more chance of false positive listings... and if you don't have an almost 100% coverage for false positive collections this is going to fall apart. Unfortunately I don't have a recipe or a proposal about how we could make it possible for recipients (they are the first source of the truth wrt spam) to report false positives for email they didn't receive at all because of the RBL used at SMTP rejection. Also there are a lot of final users using emails systems with mark-as-spam and mark-as-no-spam buttons that in the end do not generate spam reports or false positive reports to the systems resposible for that classification. > [...] > But it does depend on the technology being used by that operator. Some > will only be able to do it at one level or another, but it still creates > less problems than if they didn't have it in place. I don't fully agree. 1) In the plesk world (as I took that as an example) there are defaults and the defaults are not an "operator" stuff (AFAIK the DNSBL enabled by default don't get any false positive reports from plesk users) 2) When we talk about RBL we are not only talking about the technology itself, but also in how they are (and can be realistically) operated.. The whole IPv6 RBL discussion is about that, IMHO... the technology itself could work... but in order to make it work you would have higher costs and a lot more resources to be invested in the way you "operate" it, in order to get similar efficiency. So we can't prescind from how RBLs are "usually" operated when we try to understand their status and their potentials. Stefano _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
