Matthias Leisi wrote: > [Disclosure: I am the leader of the dnswl.org project; I provided some > input into the DNSxL draft as far as it concerns whitelists.] > > Keith Moore schrieb: > >> These incidents happen one at a time. It's rarely worth suing over a >> single dropped message, and yet the aggregate amount of harm done by IP >> based reputation services is tremendous. > > I would not want to reduce the situation to blacklists only. You use the > correct term - IP based reputation services - but fail to mention that > this includes whitelists, and that decisions other than "drop" can be > made based upon data returned by such services. I suspect DNSWLs have problems also, but I haven't tried to analyze the problems with DNSWLs to the extent I have the problems with DNSBLs. > Regarding the "dropped message": While outside the scope of the DNSxL > draft, it is pretty much consensus that messages should not be dropped > in the sense of deleted or "stored in a seldomly reviewed quarantine > folder", but that a clear SMTP 5xx error code should be returned. I don't think it should be outside the scope of a standard. > I believe it is generally agreed that false positives are the main risk > with spam filter solutions. This applies both to individual tools like > DNSxLs and to the "filtering machine" as a whole as perceived by the > recipient (and the sender). No automated solution can guarantee the > absence of false positives. > > On the other hand, the manual solution is far worse in terms of false > positives, in my experience - the human error rate is pretty high when > eg a spammy inbox must be reviewed manually. Agreed. But it is not uniform for all recipients - it depends highly on how much legitimate mail they receive, how much spam they receive, and the similarity between the two. And there's a important difference in liability between a recipient filtering his own mail and an unrelated third party filtering it for him. >> And the relative number of complaints is not >> a reliable indicator of those costs. > > It's probably the best indicator available? perhaps, but that doesn't make it a compelling argument. Keith _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf