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

From: Steve Linford <[email-masked]>
Date: Mon, 10 Nov 2008 17:12:56 +0000

I'm coming in a bit late into this strange argument, but from what  
I'm reading it sounds like someone *from IETF* is contesting the need  
for DNSBLs and thus the need for draft-irtf-asrg-dnsbl and on grounds  
which are misguided at best.

I certainly agree that there are hundreds of small DNSBLs run from  
kid's bedrooms which list on incomprehensible wildly over-broad  
policies and that such DNSBLs are both antagonistic and useless and  
as a result are used by almost nobody - that's 'market force'. But to  
pretend that the dozen major DNSBLs make listings based on  
"unauthenticated rumor" or "because the IP did not have 'mail.' or  
'mx.'" is just silly mud-slinging itself based on equally  
"unauthenticated rumor" and is especially odd if it's coming from  
within IETF itself.

The fact some DNSBLs are in widespread use (I can speak only for  
Spamhaus, our DNSBLs are today used by something in the region of 2/3  
of internet networks) is good reason why it's important to publish a  
standard and format for the technology.

Like everyone we'd like to see poorly managed, arrogant or anonymous  
DNSBLs given a high standard to attain ('shape up or ship out'),  
since an irresponsible DNSBL listing something for little discernible  
reason is what creates "I hate all DNSBLs" poster children. Lets have  
the technology, standards and how to do it correctly published for  
the future and leave aside silly "I once had a client blacklisted"  
arguments. The question "are DNSBLs bad for the world" or "are DNS  
queries a bad use" is irrelevant to the need for draft-irtf-asrg- 
dnsbl and a false argument against it.

I can see no legitimate reason for IETF not publishing draft-irtf- 
asrg-dnsbl.

   Steve Linford
   The Spamhaus Project
   http://www.spamhaus.org

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Nov 2008 13:07:40 -0500

Steve Linford wrote:

> I certainly agree that there are hundreds of small DNSBLs run from kid's
> bedrooms which list on incomprehensible wildly over-broad policies and
> that such DNSBLs are both antagonistic and useless and as a result are
> used by almost nobody - that's 'market force'. But to pretend that the
> dozen major DNSBLs make listings based on "unauthenticated rumor" or
> "because the IP did not have 'mail.' or 'mx.'" is just silly
> mud-slinging itself based on equally "unauthenticated rumor" and is
> especially odd if it's coming from within IETF itself.

It's only odd if you refuse to recognize our experiences as valid.

> Spamhaus, our DNSBLs are today used by something in the region of 2/3 of
> internet networks) is good reason why it's important to publish a

Wrong.  Read RFC 2026 and stop demanding that we change our technical
criteria just for you.

> DNSBLs given a high standard to attain ('shape up or ship out'), since
> an irresponsible DNSBL listing something for little discernible reason
> is what creates "I hate all DNSBLs" poster children. Lets have the
> technology, standards and how to do it correctly published for the
> future and leave aside silly "I once had a client blacklisted"
> queries a bad use" is irrelevant to the need for draft-irtf-asrg-dnsbl
> and a false argument against it.
> 
> I can see no legitimate reason for IETF not publishing
> draft-irtf-asrg-dnsbl.

The proposal has neither technical soundness nor rough consensus of the
community.

Keith

---

From: Theodore Tso <[email-masked]>
Date: Tue, 11 Nov 2008 09:38:49 -0500

On Mon, Nov 10, 2008 at 05:12:56PM +0000, Steve Linford wrote:
> "because the IP did not have 'mail.' or 'mx.'" is just silly mud-slinging 
> itself based on equally "unauthenticated rumor" and is especially odd if 
> it's coming from within IETF itself.

Let me get this straight.  It's OK to block e-mail messages on the
basis of unauthenticated rumors, but now you are complaining that it's
somehow dirty pool to block a standard based on the same thing?  After
all, it's the same argument; there's a lot of evil e-mail messages out
there; the cost of letting even one of those messages through is
unacceptable, so false positives are OK.  Similarly, there are a lot
of bad ideas out there, many of which have folks clamoring to have
them be standardized, just as spammers hope to get people to visit
their spamvertised web sites.  And in both cases, it's "just
business"....

I have no problem with the IETF documenting the world as it exists.
That's what an informational track RFC does.  There's a process by
which a specification gets annointed to become a standard, and others
more eloquent than I have already pointed out the dangers of trying to
skip steps in the standardization process.

Questions like, "so how does this work in the face of the expanded
IPv6 address space", ideally should be addressed earlier during the
standardization process, and not in last call (where, "oh well, we'll
just block the whole /48 or /32" might have unfortunate side effects
not forseen yet) --- but which don't make sense if the goal is to
document existing practice.

> standard and format for the technology.

There's a big difference between "use" and "Use".  If a spamassassin
configuration (by default) uses a DNSBL to add a point or a fraction
of a point to a spam score, where it might take a spam score of 10-15
before spam is dropped, that's a very different usage model than
someone who, on the unsubstatiated word of SORBS or APEWS, drops the
e-mail on the floor where it is never seen again.

And for those who would argue that it's not their problem how the
DNSBL is used, since after all that's the responsibility of the folks
using the DNSBL, I'm reminded of the line from the Tom Lehrer song:

	"Vonce the rockets go up, 
	 who cares vhere
	 they come down?
	 It's not my department,
	 says Verner von Brown."

						- Ted

---

From: <[email-masked]>
Date: Tue, 11 Nov 2008 14:53:50 -0000

> there's a lot of evil e-mail messages out there; the cost of 
> letting even one of those messages through is unacceptable, 
> so false positives are OK. 

This is precisely the sort of thing that should have been 
covered in much more detail in the Security Considerations
section of the draft.

> That's what an informational track RFC does.  

> (where, "oh well, we'll just block the whole /48 or /32" 
> might have unfortunate side effects not forseen yet)

Again, this is missing from the Security Considerations.

--Michael Dillon

---

From: Steve Linford <[email-masked]>
Date: Tue, 11 Nov 2008 14:55:17 +0000

On 11 Nov 2008, at 15:38, Theodore Tso wrote:

>> kid's
> Let me get this straight.

Yes please...

> It's OK to block e-mail messages on the
> basis of unauthenticated rumors

No.

   Steve Linford
   The Spamhaus Project
   http://www.spamhaus.org

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 11 Nov 2008 08:00:04 -0800

I'm the sponsor of the DNSBL Internet-Draft.  I've been following this
discussion and it seems to me there have been fair objections raised
to putting the document as-is on the Standards Track.  I'll consult with
the authors about whether they'd like to figure out exactly what the IETF
does have consensus to recommend and change the document, or
whether Informational would make everybody happy.

thanks!
Lisa

---

From: Tony Finch <[email-masked]>
Date: Tue, 11 Nov 2008 16:40:32 +0000

On Tue, 11 Nov 2008, Theodore Tso wrote:
> not forseen yet)

That's a matter of listing policy not of protocol. It would be premature
to lay down regulations about what can be put in an IPv6 blacklist, since
we don't have enough operational experience yet. If you try to guess and
the rules turn out not to work in practice, then they will be ignored and
cast doubt on the rest of the document.

This document should concentrate on the mechanisms, which are simple and
uncontroversial, and leave questions of policy aside.

Note that anti-spam blacklists are distributed by more mechanisms than
just the DNS. Questions of listing policy apply whatever protocol is
used, so they shouldn't be addressed in a document that just describes
a DNS-based query protocol.

> --- but which don't make sense if the goal is to document existing
> practice.

The goal is to document existing practice AND extend it in a straight-
forward way to IPv6 so that implementations are ready BEFORE IPv6 spam
becomes a problem.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
VIKING NORTH UTSIRE SOUTH UTSIRE: SOUTHEASTERLY BACKING NORTHWESTERLY 5 TO 7.
ROUGH OR VERY ROUGH DECREASING MODERATE OR ROUGH. RAIN OR SHOWERS. MODERATE OR
GOOD.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 11 Nov 2008 15:05:52 -0500

> a DNS-based query protocol.

I have a similar objection the proposal of a WG for "reputation lists".

The problem it seems intended to solve is far broader than reputation
lists, and is completely orthogonal to a reputation delivery protocol
standard.

The problems that people ascribe to reputation mechanisms are just as
severe in virtually every other type of filtering method.  Poorly chosen
or implemented content filtering systems have exactly the same problems
as poorly chosen or implemented DNSBLs, and have the same implications
for "reliability of email".  These are SMTP filter signaling protocol
issues, and have nothing to do with filtering engine decision mechanisms.

The real issue underlying this is standards and practises on how the
decision making is implemented _at_ the filter itself.  In other words,
we need generalized principles of practise how filtering should be
signaled through SMTP to enhance reliability, repeatability, and and the
ability to identify/resolve problems.

I've long been considering the draft of a BCP on how filters should
operate.  And have written bits and pieces of it in point form.  Eg:
rejects not bounces, SMTP codes, error texts, C/R, SAV, remediation
channels etc.  That doesn't belong in a DNSBL protocol specification. It
would be entirely missed in a WG about "reputation".  It's covered, in
part, in the still-draft DNSBL BCP, insofar as they directly relate to
details specific to DNSBLs.

If a WG were chartered to explore ways to improve filter
reliability/interoperability, eg: standardizing filter response
mechanisms, I'd participate in that.  But that has nothing whatsoever to
do with DNSBL protocols - which is nothing more then a delivery
mechanism for certain classes of information, the interpretation thereof
the choice of who implements whatever uses it.  [I use DNSBL protocols
for far more than filtering decisions.  It works really well to resolve
IP addresses into ASNs, allocation ranges, ownership and geolocation
information for example.]
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Nov 2008 15:17:31 -0500

Chris Lewis wrote:
> standard. [...]

Assuming IESG is interested in chartering some WG in this space, it's
reasonable to have a discussion about the appropriate scope of said WG.

But I don't buy the "content is independent of the container" arguments.
 In my experience, containers (or protocols, or data representations)
nearly always have implied semantics.  Even if this isn't intentional,
or even if the intention is for them to be free of semantics, they tend
to have them in practice, and the semantics tend to be encouraged or
enforced by the kinds of tools that were built to deal with those
containers.

There is also a strong tendency to tailor the data model to make it fit
the container.  So chances are good that (for example) a data model
designed for use with XML would not fit handily into another
representation such as email-style headers or DNS resource records.
This is part of why I don't assume that DNS is a good way to transmit
reputation information.  I feel confident that a less constrained
protocol would facilitate a better data model.

Keith