ietf
[Top] [All Lists]

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

2008-11-08 13:45:39
As the architect of a large email infrastructure, a senior technical
advisor to the Mail Anti-Abuse Working Group, and ASRG member, I find
myself disagreeing with the points made by John and Keith that I
included at the end.

As a consumer (and producer) of DNSBLs, I need technical standards that
define DNSBL protocol so I can spec/build/acquire/use software that
interoperates correctly and maintains/improves the reliability of our
email and email in general.

I also want policy predictability in the DNSBLs I use or am likely to
encounter when our users send email, but that does not belong in a DNSBL
technical standard on protocols.  It belongs in a different document.
More below.

Yes, the very existence of DNSBLs is unfortunate, but they have become
an outright necessity for many mail systems.  Our (and many other,
including all of very largest) mail infrastructures heavily rely on
DNSBLs for the majority of their filtering.  No other filtering
technique deals as effectively with the massive floods of spam and other
malicious content that we receive (in some cases well in excess of 90%
of all email).

Yes, some people honestly believe that the use of DNSBLs for blocking is
a bad idea.  But those objections fall away when they're used in
aggregate scoring systems like SpamAssassin, where they're just one
minor factor of many.  DNSBLs need to be standardized, whether they
block an email, tweak a score a bit like SpamAssassin, or as in some
environments, improve an email's likelihood of getting through (eg:
whitelists).

There are many advanced non-DNSBL techniques that can and do work well
in place of DNSBLs on small to medium systems.  Unfortunately, they are
either considerably less ineffective or are impractical in large to very
large systems trying to withstand the full spectrum of email abuse that
they have to deal with daily.  DNSBLs (locally sourced or otherwise)
often make the difference between email remaining useable or becoming
unuseable in environments like ours.

It is but one tool of many tools.  Yet, for many infrastructures, by far
the most effective.  Virtually every major email system uses DNSBLs in
one way or another, whether it's visible or not, whether it's used
directly by themselves, or in concert with other mechanisms (eg: scoring).

Failing to standardize the technical protocols used by them would be a
major mistake.

More specific points:

1) There are no technical omissions in the specification that I am aware
of.  It is a technical specification of the bits on the wire (the
protocol), with little else.

2) I presume the "technical omissions" comment was intended to mean a
lack of standardization of "how things got on and off DNSBLs".  These
are not, and should not, be considered technical issues.  Specifying how
something got on and off a DNSBL would be equivalent to insisting that
RFC2822 attempt to standardize how mail readers insert an email address
in the To header.  RFC2822 specifies the format of To headers, not how
they got there.

Yes, there are issues about such things, and consistency in some of
these areas is desired.  But, they do not belong in a technical
standard.  This is why I, Matt Sergeant, and others have been working on
a DNSBL policy BCP what could be considered a companion document:
http://www.ietf.org/internet-drafts/draft-irtf-asrg-bcp-blacklists-04.txt

I hope to make a few final grammatical changes to the above document in
the next few days and move it on towards last call.

3) Making draft-irtf-asrg-dnsbl a standard (and ultimately approving the
BCP) serves to improve the consistency and interoperability of DNSBLs,
and therefore email itself.  Not making it a standard only perpetuates
uncertainty on the protocol itself, failure to implement software that
interoperates correctly, unpredictable (and some times capricious)
failure modes, and ultimately impairs the reliability of email.

Case in point: If a DNSBL domain becomes unregistered, and is picked up
by a reseller, they usually insert DNS A record wildcards causing web
queries to go to a common web page.  Or if a DNSBL domain is mispelled
by its users, it may collide with a different domain that wildcards A
records.  Such scenarios aren't rare, they happen frequently.  Without
this standardization, the implementors of DNSBL clients don't realize
that DNSBL queries that return A records outside of 127/8 is an error
condition not a positive result.  Such mail servers usually end up
blocking ALL of their email - concrete examples of where lack of
standardization drastically impairs email interoperability.

John C Klensin wrote:

Sadly, I have to agree with Keith.   While these lists are a
fact of life today, and I would favor an informational document
or document that simply describes how they work and the issues
they raise, standardizing them and formally recommending their
use is not desirable at least without some major changes in our
email model and standards for what gets addresses onto --and,
more important, off of-- those lists.

    john


--On Friday, 07 November, 2008 18:38 -0500 Keith Moore
<moore(_at_)network-heretics(_dot_)com> wrote:

DNSBLs work to degrade the interoperability of email, to make
its delivery less reliable and system less accountable for
failures.  They do NOT meet the "no known technical omissions"
criterion required of standards-track documents.

The fact that they are widely used is sad, not a justification
for standardization.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>