On Wed, 12 Nov 2008, David Romerstein wrote: > On Wed, 12 Nov 2008, Randy Presuhn wrote: > > > Agreed, but if those analogies are correct, they also undermine the argument. > > Neither the email sender nor the recipient (the ones to whom email is most > > important) typically have any voice whatsoever in the selection of the DNSBL. > > End recipients *absolutely* have a voice in the DNSbl selection process. > They have the option of voting with their feet if their ISP chooses a > DNSbl that negatively impacts them. That assertion reflects a lack of thought about the process. The user with the ISP using the poorly administered DNSBL is the target of my email and may not know about the missing mail or may be an organization who doesn't care. Their support staff is happy about the amount of real spam blocked and will easily down play the frustration of their users re. false positives. It is my observation that even within companies producing anti-spam products, it is difficult to get effective reporting of FPs and FNs. The majority of users of large ISPs like AOL, MSN, Earthlink, NetZero, etc. just swear at their computers and do nothing. Just because the DNSBL does exactly what it says it will, doesn't mean that the mail administrators configuring use of that DNSBL really understands the implications. Sounds good to exclude mail from dynamic IPs ... the flaw is in the detection of dynamic IPs. Given that the well known DNSBL causing me grief totally ignores my requests for removal, I have no reason to blame my ISP for the situation nor have I any reason to believe my ISP would have any more luck. So why should I take all the steps to reprovision my network with new public IPs from another ISP with no assurance the problem won't repeat. One email target ISP, readily white listed my mail server's IP. They admitted they knew that the DNSBL they referenced to bounce my mail was poorly administered but still used it. The contractor I was attempting to email would hardly see an ocassional issue as reason to change is published email provider. In the end, walking isn't a viable alternative. Someone else mentioned that due dilligence was needed on the part of folks providing email spam filtering based on specific DNSBLs. Exactly were does one find reliable rating of such services? How do you determine what the trash to value ratio is in a specific DNSBL's database? In my experience, the damage to email services are more in the area of administration and policy of the DNSBL than at the protocol level. Documenting the current protocol as Informational seems sufficient. Put the IETF reputation behind BCPs which describe how well run DNSBLs should be administered. Perhaps define how a mail administrator might evaluate a DNSBL's performance. If interest warrant, follow the suggestion from Kieth (and others?) to form a working group to evaluate protocol alternatives and design a possibly improved protocol. David Morris _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf