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