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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf