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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf