Tony Finch wrote: > Note that anti-spam blacklists are distributed by more mechanisms than > just the DNS. Questions of listing policy apply whatever protocol is > used, so they shouldn't be addressed in a document that just describes > a DNS-based query protocol. I have a similar objection the proposal of a WG for "reputation lists". The problem it seems intended to solve is far broader than reputation lists, and is completely orthogonal to a reputation delivery protocol standard. The problems that people ascribe to reputation mechanisms are just as severe in virtually every other type of filtering method. Poorly chosen or implemented content filtering systems have exactly the same problems as poorly chosen or implemented DNSBLs, and have the same implications for "reliability of email". These are SMTP filter signaling protocol issues, and have nothing to do with filtering engine decision mechanisms. The real issue underlying this is standards and practises on how the decision making is implemented _at_ the filter itself. In other words, we need generalized principles of practise how filtering should be signaled through SMTP to enhance reliability, repeatability, and and the ability to identify/resolve problems. I've long been considering the draft of a BCP on how filters should operate. And have written bits and pieces of it in point form. Eg: rejects not bounces, SMTP codes, error texts, C/R, SAV, remediation channels etc. That doesn't belong in a DNSBL protocol specification. It would be entirely missed in a WG about "reputation". It's covered, in part, in the still-draft DNSBL BCP, insofar as they directly relate to details specific to DNSBLs. If a WG were chartered to explore ways to improve filter reliability/interoperability, eg: standardizing filter response mechanisms, I'd participate in that. But that has nothing whatsoever to do with DNSBL protocols - which is nothing more then a delivery mechanism for certain classes of information, the interpretation thereof the choice of who implements whatever uses it. [I use DNSBL protocols for far more than filtering decisions. It works really well to resolve IP addresses into ASNs, allocation ranges, ownership and geolocation information for example.] _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf