On Fri, Nov 14, 2008 at 04:08:50PM -0500, Al Iverson wrote:
Is this unique to DNSBLs? If not, then why does it merit deeper
consideration in the context of DNSBLs?
what you are arguing is that rather than trying to address the harm done
by DNSBLs, IETF should ignore that harm by ruling it out of scope for
the current discussion.
I suggested no such thing. I asked for the opposite -- help somebody
who doesn't get it understand exactly what the connection is.
I think the issue of the badly-run DNSBL's can be handled handled by
amplifying the first paragraph of the Security Considerations section.
Currently, it merely talks about the most blantent problems caused by
a DNSBL causing all mail to be rejected, or no mail to be rejected.
It doesn't talk about DNSBL's using different criteria than what they
have advertised for their list, or that a potential DNSBL could use
the trust given to mail receivers to explicitly block an IP block in
retaliation for criticism or to pursue some other vendetta.
Mentioning that these things can and have happened I think is simply
acknowledging the obvious, and that a poorly chosen DNSBL can cause
great harm.
I would also encourage the "how to run a DNSBL responsibly" to be
published at the same time, so that draft-irtf-asrg-dnsbl could
reference the "this is how you do it right" (while acknowledging the
only out of band mechanisms can be used to ensure that a DNSBL
operator is truly following the criteria they claim to be using).
This of course ignores the question of whether a document which is
intended for the Standards Track should be abusing DNS 'A' records or
not. It may be that a much better approach is to put this on
Informational describing the current state of affirs, warts and all,
and then to create a better document which is Standards Track later
on.
- Ted
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf