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

From: der Mouse <[email-masked]>
Date: Sun, 9 Nov 2008 12:25:23 -0500 (EST)

[Keith Moore]
>> The fact that [DNSBLs] are widely used is sad, not a justification
>> for standardization.

True.  The justification is not simply that they are widely used; it is
that they are widely used, they are often done wrong, they are of
tremendous value when done right, and of actively negative value when
done wrong.

[John C Klensin]
> 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.

And this, I mostly disagree with.

Just because something is something we'd rather not have around does
not mean standardizing it is a bad idea.  SSH is an example; I would
much rather the net were still the open, friendly place it was back in
the ARPAnet and NSFnet days, where SSH was unnecessary.  But that's no
longer today's net, and SSH or something like it is necessary; I think
standardizing it is a Good Thing (indeed, a necessary thing in the case
of SSH).

Similarly, I too find DNSBLs' necessity regrettable.  But I do find
them necessary, and I think we're better off standardizing those
aspects that are currently agreed-upon enough to standardize.

I do not think that standards for how addresses get onto and off of
DNSBLs is even desirable.  As long as the list is technically well-run
and adheres to what it tells its users its (de)listing policies are,
exactly what those policies are is entirely up to the list; a wide
variety of policies is good because there is an equally wide variety of
receiving sites' desires - and because the price to the net of a DNSL
nobody uses is so close to zero as no matter, so there's no harm in
having a wide variety available to pick from.

And that "technically well-run" is the part that I think not only can
be standardized but should be standardized.

Not that my opinion counts for all _that_ much, since I'm not the one
doing the work.  But it's not total randomness; email operations and
administration has been part of my paid job for some 18 of the last 25
years, and I was on the CAUCE Canada board before we merged with CAUCE
USA.  (I think I'm actually still technically on CAUCE North America
board, but I've been trying to get out of abuse-fighting for a year or
two now).

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

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

> tremendous value when done right, and of actively negative value when

I agree that this might be a justification for standardizing some sort
of reputation protocol.  But it's not at all clear the document at hand
describes a protocol which is technically sound, and it certainly
doesn't have rough IETF consensus.  I'm willing to defer judgment about
whether such a protocol might reasonably resemble DNSxL, or whether it
can reasonably use DNS at all - but I have reason to doubt it.

Keith

---

From: der Mouse <[email-masked]>
Date: Mon, 10 Nov 2008 14:50:43 -0500 (EST)

>> True.  The justification is not simply that they are widely used; it
>> is that they are widely used, they are often done wrong, they are of
>> tremendous value when done right, and of actively negative value
>> when done wrong.
> I agree that this might be a justification for standardizing some
> sort of reputation protocol.  But it's not at all clear the document
> at hand describes [...]

Perhaps.  But this is not a place where the IETF gets to choose what
will be used.  DNSLs are in live use, have been for years, and will
continue to be; the IETF can jump up and down all it wants, but that
isn't going to change - the question is whether people will use DNSLs
with an IETF standard or without one, not whether people will use
DNSBLs or something else the IETF likes more.  (In principle it's
possible people might switch to something better.  But I sure don't see
any such "something better" even on the horizon, much less in even
experimental use - and even if one appears, the adoption time is going
to be measured in years.  DNSLs will be here for a long time to come.)

What the IETF _does_ have a chance to do here is to improve the quality
of a critical piece of Internet infrastructure (email without DNSLs in
today's net is either unusable or very heavily balkanized) by
standardizing those aspects that are in shape to be standardized.  The
IETF says "rough consensus and running code".  We have the running
code.  We even have something close to rough consensus in the field, in
the form of the many DNSL providers and users; I hope the IETF can
recognize that consensus and echo it enough to do what it can to help.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: SM <[email-masked]>
Date: Tue, 11 Nov 2008 14:02:10 -0800

>recognize that consensus and echo it enough to do what it can to help.

As this document is Standard Track, it's in the IETF 
stream.  Documents on the Standard track require IETF review and the 
consensus of the IETF community.  It's not the same as rough 
consensus in the field.

Quoting the document:

   "This document represents the consensus of the Anti-Spam Research
    Group of the Internet Research Task Force."

If this document is published in its current form, I suggest removing 
the IRTF Notice.

There is a large user-base for DNSBLs as it's viewed as a cheap 
(resource-wise) way to stop spam.  Most MTAs have built-in features 
to query DNSBLs and reject incoming SMTP connections if the IP 
address is listed.  Some vendors enable DNSBLs in the default 
configuration of the MTA they ship.  This has lead to problems over 
the years as some DNSBLs were receiving queries even after they were 
shut down.  Some of them resorted to returning positive responses for 
all queries get the attention of the mail administrator as it caused 
all mail to be rejected.  The document recommends that:

   "DNSxL clients SHOULD periodically check appropriate test entries to ensure
   that the DNSxLs they are using are still operating."

That would require a change, for the better, in the implementation of 
DNSBLs in MTAs.  I would go further and suggest that DNSxL clients 
should rate limit their queries if the test address does not exist 
and must not generate queries to the DNSxL if the test is 
unsuccessful after a period of time.

In Section 6:

   "A client MUST interpret any returned A record as meaning that an
    address or domain is listed in a DNSxL."

There have been cases where a mail server used a DNS server which 
returned an A record instead of NXDOMAIN.  That can lead to incorrect 
results if the above recommendation is followed.  It may be better 
for the client to validate the returned A record for correctness.

The Security Considerations could have been more exhaustive for a 
Standard Track document.  For example, if the DNSxLs are 
unresponsive, it can affect mail delivery.  DNSBLs are 
somewhat  different from other DNS based services due to their 
controversial role.  They are generally subject to Denial of Service 
and it is worth the emphasis instead of only having a pointer to RFC 3833.

   "Since DNSxL users usually make a query for every incoming e-mail
    message, the operator of a DNSxL can extract approximate mail volume
    statistics from the DNS server logs."

Operators of some types of DNSxLs might also be able to extract some 
information about the senders.

As mentioned in the document, name-based DNSBLs are also used to 
check the domains found in URLs in message bodies.  That can lead to 
unintended information disclosure.

Regards,
-sm