The main arguments in the Church draft are:
1) DNSBL are necessarily out-of-date due to the rapid rate of change in
addressing on the Internet.
2) DNSBL operators use "arbitrary policies".
3) DNSBL are ineffective at blocking spam.
Responses:
1) The first argument relies on the assumption that IP addresses are
reassigned at a frantic pace, which DNSBL operators cannot possibly track.
However, the relative scarcity of IPv4 addresses has led to a common
practice wherein they are meticulously assigned by ISPs. The lifetime of a
public IP address is arguably at least one month, the minimum duration of
most hosting agreements. Under closer examination, argument 1 becomes a
special case of argument 2, namely that DNSBL operators are slow to remove
addresses.
2) While it is true that each DNSBL appears to have its own goals and
policies, one can hardly classify a reputable DNSBL's policies as
arbitrary. Large DNSBLs have documented procedures for removal. Rather, it
could be said that the diversity of policies among DNSBLs is a strength of
the system, that email admins can choose to use DNSBLs whose attitudes
towards email closely mirror their own. Church's personal experience of
having an IP address on a DNSBL, a notable inclusion in the draft, may
provide insight into the motives for writing the draft. It certainly
excuses the presence of the same logical fallacy in the draft as DNSBL
operators are accused of in argument 2: expanding isolated examples into a
general case, which is then tenaciously defended.
3) The statistical sample presented is small, and the analysis lacks rigor.
It begs the question by stating that DNSBLs are prone to false positives,
but uses as evidence a union of results biased towards marking messages as
spam. Furthermore, there is little to suggest in this sample that valid
email is being delayed or blocked. A more objective analysis of the results
might imply that inclusion on a DNSBL is strongly correlative evidence that
an email message is spam.
Obligatory ad hominem attack:
The anecdotal evidence in the Church draft, including but not limited to the
suggestion that spam should be filtered by either Hotmail or the MUA,
implies that the author has experience primarily as an end user. I refer
the reader to RFC 1925 Section 2 paragraph 4.
Summary:
The Church draft focuses strongly on problems with DNSBL use that are
apparent to the author, with the conclusion that DNSBL use should be
shunned. More useful content for a document dealing with DNSBLs would
include suggested practices for DNSBL operators and users, such as
statements of policy, inclusion criteria, and removal procedures.
It's clear that more research is required in this area before the IETF
should consider publishing a document which suggests abandoning a widespread
application of technology generally considered by knowledgeable users to be
useful, without providing a more reasonable alternative.
Regards,
Jim MacLeod
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg