Subject: RE: [Asrg] Comments on draft-church-dnsbl-harmful-01.txt

From: "Nick Nicholas" <[email-masked]>
Date: Mon, 27 Mar 2006 20:33:50 -0800

On Monday, March 27, 2006 at 7:43 PM Chris Lewis wrote:

> John R Levine wrote:
> > This document has been submitted to the RFC editor for possible 
> > publication.  They have asked for the ASRG to comment on 
> it.  Comments 
> > could include how accurate it is, changes that would be 
> needed before 
> > publishing it, etc.
> 
> There's a number of logical inconsistencies, false 
> conclusions, and even just plain wrong arithmetic.  The 
> sample set is grossly too small etc etc. etc.

Not to mention the historical inaccuracies ...

I'd put some time into this if I had any, but I'm already hammering away
at You Know What.  I might take the time to throw a few rocks at it
after Chris & Co. get something started.

Is an appropriate response: "This is such a poorly thought-out,
inaccurate and shoddy piece of work that the ASRG doesn't wish to waste
any further time with it."?  Or does the ASRG need to spell out why it's
sooo baaaadd?

Regards,

Nick

PS:  How in the world did it get from -00 to -01?  I thought -00 would
die the quiet death it deserved after it was originally put forward.
Was there even a scintilla of support expressed for -00 or is its
continued existence simply sheer bull-headedness on the part of the
author, another Dean Anderson?

--
 
Nick Nicholas
Knowledge Engineer
Habeas Inc.
650-694-3320
[email-masked]

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: John Levine <[email-masked]>
Date: 28 Mar 2006 05:37:21 -0000

>any further time with it."?  Or does the ASRG need to spell out why it's

The latter.  The IETF's understanding of spam issues is not strong and
as I found at last week's meeting, there's a lot of poorly informed
sympathy for the "all DNSBLs are bad" argument.

>PS:  How in the world did it get from -00 to -01?

All that means is that the author sent in a new draft.  Anyone can
send in a draft, if it meets the mechanical criteria, they'll publish
it as a draft.

R's,
John

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 28 Mar 2006 01:25:58 -0500

> sympathy for the "all DNSBLs are bad" argument.

How detailed does this have to be?  Point-by-point refutation, or
something a bit more general?

Timeframe for responses?

---

From: John Levine <[email-masked]>
Date: 30 Mar 2006 04:43:22 -0000

>something a bit more general?

Point by point suggestions for improvement, e.g., section 42.1 argues
foo, whereas the author seems unfamiliar with bar which contradicts
his points.  Basically enough to hand back to the author to say "fix
all this and we'll look at it again."

>Timeframe for responses?

Didn't say, a week or two should be OK.

R's,
John

---

From: Daniel Feenberg <[email-masked]>
Date: Thu, 30 Mar 2006 06:46:51 -0500 (EST)

> all this and we'll look at it again."

Surely that form of response conceeds the correctness of the sentiment 
expressed in the draft title. The problem with the draft is not that it 
has mistakes, but that it is a mistake.

Daniel Feenberg
feenberg is at nber dotte org

---

From: John Levine <[email-masked]>
Date: 30 Mar 2006 12:17:57 -0000

>has mistakes, but that it is a mistake.

Better tell him to fix the title, too.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Thu, 30 Mar 2006 08:15:19 -0800

On Mar 30, 2006, at 3:46 AM, Daniel Feenberg wrote:

> Surely that form of response conceeds the correctness of the  
> sentiment expressed in the draft title. The problem with the draft  
> is not that it has mistakes, but that it is a mistake.
>

Not at all.

There's certainly a place for a well-written document with the same
title as this one. The title would likely be the main overlap, though.

(DNSBLs are a bad tool in many ways. They're not really very
expressive as a reputation language. The technology for distributing
and using them is pretty poor, and is based solely on a quirk in
sendmails configuration language - the _original_ implementation
of the RBL was distributed in a much more efficient manner. Usage
of them is not standardised enough to actually be useful. There are
many, many flaws with concept and implementation, and that's
before you get to the details of specific lists.)

Cheers,
   Steve

---

From: Tony Finch <[email-masked]>
Date: Thu, 30 Mar 2006 17:48:33 +0100

Steve Atkins <[email-masked]> wrote:
>
>Usage of them is not standardised enough to actually be useful.

Not true! DNSBLs are not only useful, they are crucial.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
IRISH SEA: SOUTH OR SOUTHWEST 5 TO 7, PERHAPS GALE 8 LATER. RAIN THEN FAIR.
MODERATE OR GOOD.

---

From: Steve Atkins <[email-masked]>
Date: Thu, 30 Mar 2006 09:49:58 -0800

> Not true! DNSBLs are not only useful, they are crucial.

I think you misread what I wrote.

Usage of DNSBLs is anything but standardised. That lack of
standards causes significant problems.

Cheers,
   Steve

---

From: Tony Finch <[email-masked]>
Date: Thu, 30 Mar 2006 19:22:03 +0100

>standards causes significant problems.

AFAICT there is a very solid de-facto standard for both IP address
blacklists and mail domain blacklists, and this standard is implemented
interoperably by practially all DNS blacklists and MTAs. What's the
problem?

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
ARDNAMURCHAN POINT TO CAPE WRATH INCLUDING THE OUTER HEBRIDES: EAST OR
NORTHEAST 5 OR 6, OCCASIONALLY 7 WEST OF THE OUTER HEBRIDES ON FRIDAY.

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 30 Mar 2006 13:31:33 -0500

> I think you misread what I wrote.

I wouldn't say he misread what you wrote, I'd suggest you meant
something highly different than what you actually wrote.

> standards causes significant problems.

What do you mean by "standard usage"?

The common access protocols are well standardized in a defacto sense,
and will soon be formally.

Standardizing anything else about them seems to me to be about as useful
as standardizing ice cream flavours.  Perhaps useful to define exactly
what "vanilla" means taste- and smell-wise so consumers know what
they're getting, but delineating which flavours are permissible in a
standard is just plain wrong.

I'm not going to eat carrion-flavoured ice cream, but, I'm not going to
stop anyone making it or choosing to buy it - but I might run away
screaming if anyone near me tears the wrapper off one.

[Which is the same reaction I'd have to a MTA responsible for my email
using certain DNSBLs.]

The real problem is that people responsible for choosing DNSBLs aren't
necessarily exercising due diligence and knowing what they're getting.

But like carrion-flavoured ice cream, they have the right to choose it,
no matter how idiotic it may turn out to be given what they're
_supposed_ to be accomplishing.

---

From: Seth Breidbart <[email-masked]>
Date: Thu, 30 Mar 2006 13:35:40 -0500 (EST)

> expressed in the draft title.

Point 0: The title should be corrected to "DNSBLs are harmful to
spammers" or "DNSBLs are helpful to mailbox owners".

Seth

---

From: Steve Atkins <[email-masked]>
Date: Thu, 30 Mar 2006 12:10:58 -0800

On Mar 30, 2006, at 10:31 AM, Chris Lewis wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Steve Atkins wrote:
>>

Well, some issues related to common usage include:

   1. There is no graceful way to shut down a DNSBL.

   2. When end users query a blacklist that has been shut down or has
      never existed there is no easy way to communicate that error to
      them. The main technical approach to that that has been tried has
      been to list the entire internet, but that doesn't work when  
the list
      is being used for scoring, rather than blocking.

   3. Dynamic blacklists are often distributed via batch updates,  
meaning
      that there can be multiple hour delays in propagating changes,  
both
      additions and removals.

   4. There's no way for an end user to tell whether the list they're  
using
      is stale or not. Both the aforementioned distribution problems and
      failed local mirroring processes can cause the data to become  
stale.

   5. The data returned by blacklists in response to an A record query
      varies wildly. Pretty much all return an NXDOMAIN for "not  
listed",
      but the responses for "listed" vary significantly. Some return  
a fixed
      A record. Some return an A record chosen from several values, for
      different listing criteria - including in at least one case one  
of several
      A records for "blacklisted", and a different A record for  
"whitelisted -
      do not block". Others don't return an A record at all, rather they
      return a CNAME, which in turn points to an A record (or sometimes,
      doesn't point to an A record).

Some of these could be resolved if all DNSBLs had something like
a standard address that was always listed (as 127.0.0.2 often, but
not always, is) and end users software monitored that. But, due to
using DNS as the underlying distribution method, there's no way
to ensure that end users do that.

That DNS as used by DNSBLs is primarily a pull protocol, rather than
a push protocol, causes some of these (as well as the scaling issues
that the publicly available blacklists have to deal with). Something  
closer
to BGP would be a much more appropriate way to schlep this data
around. (Or, for the DNSheads in the crowd, Notify+IXFR - but notify
doesn't scale at all well to large numbers of users, unlike BGP which
can be distributed efficiently via a tree).

   6. There is no particular standard for what response to return to a
      sender when you're rejecting their mail at receipt time due to a
      DNSBL listing. The SMTP response code used varies wildly, and
      is often indistinguishable from a no-such-user or a local failure.
      (This can, and often does, cause users to get dropped from the
      mailing lists they've subscribed to due to a temporary or  
transient
      DNSBL listing - and there are some DNSBLs out there that will,
      by their design, block legitimate sources of email for short  
periods).

   7. There's no widely used standard for what to return in the human
      readable part of the rejection message. Many (but not all) DNSBLs
      provide a TXT record to return as part of that message, sometimes
      including a web URL for more information. That's a nice feature,
      despite the significant overhead it adds to the DNS queries,  
but it's
      not used anything like universally. It's not unusual for mail  
to be
      rejected as "550 Listed in SpamHaus.org" for mail that patently
      isn't.

These points are arguably an SMTP / mail filtering standard issue
rather than a DNSBL-related issue, but they're closely related, and
certainly they are some of the things that cause DNSBL usage to
cause inadvertent damage.

There are some other issues that spring to mind too, but this is a  
mailing
list post, not an article, so I'm just touching on some of the  
simpler points.

> necessarily exercising due diligence and knowing what they're getting.

That's certainly true too, and a whole other can of worms, but I
was trying to stick to the technical problems that are common
across some significant fraction of the users of it, rather than the
policy related issues.

Cheers,
   Steve