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

From: "Chris Lewis" <[email-masked]>
Date: Sat, 08 Nov 2008 13:44:18 -0500

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
> <[email-masked]> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Sat, 08 Nov 2008 14:37:56 -0500

I think you're missing the point.

Better "interoperation" of a facility that degrades the reliability of
email, by encouraging an increased reliance on dubious filtering
criteria and rumors, is not a desirable goal.

Even assuming that there's some benefit in having third-party reputation
services (which IMHO is not well-established), use of DNS to communicate
such reputation, and basing such reputation on IP addresses, is itself
very dubious.  The problem isn't just the rumor passing mechanism, but
the mechanism is indeed part of the problem.

It's not as if we're arguing about whether to standardize a facility
that is widely believed to work well.  We're arguing about whether to
standardize a facility that causes problems for everyone.

Back when I started working with email, getting a message reliably
delivered was something of a black art, because you had to know how to
thread your message through the hodgepodge of Internet, uucp, BITNET,
DECnet, fidonet, and whatnot.  That was in some sense understandable
because Internet access was not widely available, and there wasn't
really any common network that everybody could tap into.

Today, getting a message reliably delivered is once again a black art.
But today, it's not for lack of standards or network connectivity.  It's
because so many messages are filtered for dubious reasons, or on the
basis of what are essentially unsubstantiated rumors, or because of
over-reliance on IP source addresses as identifiers.

Keith

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 8 Nov 2008 13:46:55 -0700

Keith Moore <moore at network dash heretics dot com> wrote:

> But today, it's not for lack of standards or network connectivity.
> It's because so many messages are filtered for dubious reasons, or on
> the basis of what are essentially unsubstantiated rumors, or because
> of over-reliance on IP source addresses as identifiers.

Several years ago, my employer's e-mail spam filter blocked the Unicode 
mailing list as a "suspect site."  Earlier this year, GoDaddy (registrar 
of my domain name) did the same, and it took months to figure out what 
was going on.  It's conceivable that someone might have used this 
high-profile mailing list as part of a spam, at some point, but to block 
the entire domain is complete overkill.  I'm no expert on e-mail 
security, and I detest spam, but there is such a thing as a cure that is 
worse than the disease.

--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

---

From: "Chris Lewis" <[email-masked]>
Date: Sat, 08 Nov 2008 16:16:52 -0500

> I think you're missing the point.

Oh, no, I fully understand the point.  In contrast, I think you're
relying on false dichotomies.

> criteria and rumors, is not a desirable goal.

There is no such thing as a filtering mechanism that is 100% accurate,
and hence all are dubious to one degree or another.  Every technique
relies upon factors that are based on intuition and experience, rather
than physical law.   A demonstrable assertion that "IP x is demonstrably
infected with Srizbi and anything it emits is probably crap" and
communicated by DNS is much less dubious than "this combination of
random content fragments makes it look like a Nigerian 419, sorta,
marginally".

Indeed, experience shows that a correctly chosen set of DNSBLs is often
not only more effective than other techniques in correctly identifying
malicious email, can often have far fewer false positives than just
about any other mechanism.

It certainly is counterintuitive that "source reputation" might be more
accurate than "per email evaluation".  But, experience in the field
demonstrates the true reality - the current state of the art is that
intelligently chosen DNSBLs (the aforementioned BCP is intended to help
that) often work much better than complete reliance on the latter.

Furthermore, incorrect DNSBL listings are easier to cope with than, say,
random combinations of SpamAssassin scores that just happen to zap a
desirable email.

This is not specific to SA.  It's just as applicable to other things
like Bayesian.

We run DNSBLs and SpamAssassin here on the MXes.  The former catches 10
times as much as the latter, FPs less, and is a lot easier to explain
and remediate than the latter.  We _hate_ SA FPs, because it's so much
more difficult to ensure that it doesn't repeat.

[The obvious Bayesian/SA remediation (whitelisting email addresses)
isn't good enough.  Virtually all malicious email is forged.  Thus,
whitelisting senders leaves you wide open to getting zapped by forgeries.]

> services (which IMHO is not well-established),

Again, a false dichotomy: DNSBLs are not necessarily third-party, and
other perfectly reputable techniques (eg: outsourcing your spam
filtering to a spam filtering company or relying on your ISPs filtering)
are third party by definition.  Indeed, running your own copy of
SpamAssassin on your own mail box is just as much giving away "control"
of your filtering to a third party with their own evaluations techniques
of greater or lesser dubiousness.

Is it not third party because you can tweak the rules of SA?  You can
also locally whitelist around DNSBL entries.

The only way you can get away from "third party" is to write your own
filters from scratch, and ignore everybody else's heuristics.

I generate several DNSBLs for use here only.  Why shouldn't there be a
standard so that mail server software I buy/lease/license will
interoperate with DNSBLs I create?

"Not well-established"?  You don't seem to have any idea how prevalent
the use of DNSBLs is.  It's probably the industry's dirty little secret
because of the occasional media event.  But there have been similar
media events about other filtering techniques that aren't 3rd party, nor
source reputation.

The reality is: almost everybody uses DNSBLs, and ALL of the very big
sites do.

> use of DNS to communicate
> very dubious.

You may think it dubious, but it is usually more reliable and effective
than any other, and its popularity alone means it needs to be standardized.

Rejecting the standardization of DNSBL protocols because the entries of
a specific DNSBL _might_ be dubious is in itself a dubious position.

> The problem isn't just the rumor passing mechanism, but
> that is widely believed to work well.

It is widely believed to work well.  That's part of the point.

> We're arguing about whether to

No more so than filtering in general.

> over-reliance on IP source addresses as identifiers.

DNSBLs exist and their use is extremely widespread because the industry
_does_ believe in them.  There is a very large number of efforts to
demystify DNSBLs and deal with DNSBL issues.  DNSBLs used to provide
positive reputation, not just negative.  It is no longer the black art
of that hodgepodge of networks both you and I remember trying to support
way back then. It is well-established and has evolved a long way from
Vixie's original RBL.

We have to get our heads out of the sand and put it on a solid standards
footing to finish the job of de-black-arting it.

As for capricious/rumors and so on, please refer to the proposed BCP I
mentioned earlier.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John Leslie <[email-masked]>
Date: Sat, 8 Nov 2008 17:02:38 -0500

Chris Lewis <[email-masked]> wrote:
> 
> ... This is why I, Matt Sergeant, and others have been working on

   First, a meta-comment:

   I hope we don't try to make a class of documents called IRTF BCPs.
The intent behind this, I hope, is to work on it in IRTF's ASRG, then
submit it to the IESG as an Individual Sumbission.

   I don't think that's a good idea either; but I can't criticize it
if the IESG intends to discourage AppsAREA WGs dealing with spam issues,
as at least one previous IESG has done.

] Abstract
] The rise of spam and other anti-social behavior on the Internet has
] led to the creation of shared DNS-based lists ("DNSBLs") of IP
] addresses or domain names intended to help guide email filtering.
] This memo discusses guidelines for the management of public DNSBLs by
] their operators as well as for the proper use of such lists by mail
] server administrators (DNSBL users), and it provides useful
] background for both parties.  It is not intended to advise on the
] utility or efficacy of particular DNSBLs or the DNSBL concept in
] general, nor to assist end users with questions about spam.

   This is reasonably clearly stated. Whether there is any sort of IETF
consensus about the existence of "proper" use seems to be in question.
Much of the document actually describes the history of "DNSBLs", which
I would hope most of us would be happy to see in an Informational RFC.

] 1.1.  DNS-Based Reputation Systems
]...
] This document is intended to provide guidance to DNSBL operators so
] that they may be able to identify what features users would be
] interested in seeing as part of a high-quality, well-managed DNSBL,

   I'm not sure this is a reasonable goal for any IETF document.
Predicting what users will want in the future is extremely iffy.
(Even predicting the present is beyond _my_ ability!)

] 1.2.  Guidance for DNSBL Users
]...
] The DNSBL user MUST ensure that they understand the intended use of
] the DNSBL.

   This doesn't feel like a 2119 MUST. While it _is_ arguably abuse
of a DNSBL, there will inevitably be cases like SpamAssassin where
DNSBLs are used in scoring at a level where it doesn't make sense
for the receiving MTA's administrator to understand any details of
the "intended use".

] 2.1.  Transparency
]...
] A DNSBL MUST abide by its stated listing and delisting criteria.

   This is a better fit to a 2119 MUST, but frankly I don't think we
should encourage DNSBL users to depend on it.

] 2.2.1.  Listings SHOULD Be Temporary
]...
] It is RECOMMENDED that DNSBL operators publish in general terms their
] expiration policy is, even if its only "delist on request" or no
] expiration is performed.

   An absolutely reasonable principle, stated absolutely correctly.

] 2.2.2.  A Direct Non-Public Way to Request Removal SHOULD Be Available
]...
] The DNSBL operator MUST NOT use the list in question in such a way
] that removal requests would be blocked,

   A correct 2119 MUST-NOT...

] and, moreover, SHOULD make mailboxes available in order to allow
] affected users to submit their requests.

   This may not be reasonable. A publicly-known email address can too
easily be DoS'd. A more useful statement, IMHO, would be that any
email-based mechanism for submission of removal requests SHOULD promptly
and clearly indicate whether the request is queued for action on the
request.

====

   There's a lot of good work that went into this document, and I don't
mean to speak against its publication. But it seems to me to be a poor
fit to the IRTF, and I'd be much happier to see this sort of work in
an IETF WG. Writing such a document to avoid becoming quickly outdated
strikes me as an impossible task; and the "right" approach would be to
design services that could avoid the many pitfalls we are seeing with
the current usage of DNSBLs.

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

---

From: Theodore Tso <[email-masked]>
Date: Sat, 8 Nov 2008 17:04:55 -0500

Speaking as someone who runs their own private mail server
(thunk.org), and having suffered from "collateral damage" when an
entire ISP range was listed, and where I had absolutely no way of
getting off a DNSBL that operating in a liability-free zone, with
administrators who refused to communicate with me, and where I had no
way of getting off the list, and thus had my e-mail blocked(*), forgive
me if I'm a bit less sanguine than you about the suitability of
DNSBL's, and whether your BCP will have any effectiveness whatsoever.
If DNSBL operators are content to operate in the dark, and refuse to
communicate, what makes you think they will pay attention to a BCP?

(*) Fortunately in most cases it was people asking me for help with
Linux, so I simply found another way to send the e-mail, and then sent
them a note saying that until they switched ISP's or fixed their mail
server to remove the use of the DNSBL, I would refuse to help them
with their Linux ext3 problem.  :-)

But I view DNSBL's as fundamentally the Wrong Answer, and it breaks
the intended SMTP and Internet architecture, with fundamentally wrong
power dynamics.  Of course, if you run a major mail operation, where
DNSBL's don't dare block you lest it become obvious that the whole
mechanism is corrupt, you don't see these problems.

						- Ted

---

From: Keith Moore <[email-masked]>
Date: Sat, 08 Nov 2008 17:36:53 -0500

Chris Lewis wrote:
> and hence all are dubious to one degree or another. 

Fine.  So please explain to me why, and under what conditions, using IP
addresses as a basis for filtering is reliable.

And please also explain why, and under what conditions, using DNS as a
means of communicating whether a particular IP address is spamming is a
good way to do that.  In particular, please explain how it encourages or
discourages selection of good criteria for filtering, how it enhances or
 degrades accountability for the party blacklisting the site (and/or the
party trusting the blacklist).  Explain the limitations of DNS for doing
this kind of rumor mongering and how they are addressed.  Explain the
mechanism for reporting blacklisting errors to the parties most affected
(which would include not only the senders of inappropriately filtered
messages but the intended recipients of inappropriately filtered
messages) and how use of DNS enhances or degrades those parties'
abililty to improve their email reliability.  Explain how DNS enhances
or degrades a party's ability to correct both a blacklist's mislabeling
of a site and a user's ability to correct his MSP's inappropriate use of
a blacklist.  Explain how the DNS ttl should be chosen and how it should
vary on a per-domain basis.  Explain the security risks associated with
trusting DNS as a blacklist query protocol, and in particular what
potentials exist for denial-of-service attacks and what can be done
about them.

See, it really appears that the design work that we would rationally
expect out of any standards-track protocol has not been done in this
case.  It appears that large-scale use of IP addresses as identifiers
for potential spammers is not well-considered, especially in an era with
widespread use of NAT.  It also appears that use of DNS as a query
protocol is not well considered beyond the fact that such a query could
be implemented by a sendmail rewrite rule.

In other words, this is a hack that has gotten way out of hand.  And not
a particularly well-designed hack at that.

> A demonstrable assertion that "IP x is demonstrably infected with
> Srizbi and anything it emits is probably crap" and communicated by
> DNS is much less dubious than "this combination of random content
> fragments makes it look like a Nigerian 419, sorta, marginally".

I'd probably agree with that statement on its face, but (a) comparing
DNSBL to SA like schemes is damning DNSBL with faint praise.  To my
knowledge nobody has requested that IETF standardize SA, but just
because SA sucks doesn't mean that DNSBL is standards-track quality even
if it sucks a bit less.  (b) DNSBL, in practice, doesn't actually
provide anywhere near that level of assurance.  It doesn't say that a
host is infected with Srizbi, it just alleges that a host is bad.   And
in fact the alleged badness might well have been "this host sent out a
combination of random content fragments that look like a Nigerian 419".
 Indeed, DNSBL doesn't actually say that a host is bad, it associates
the badness with an IP address which might or might not be associated
with the same host now as it was when the badness was observed.  It
doesn't say when traffic from that IP address was observed to be bad.  etc.

> about any other mechanism.

In other words, if you make the selection the filtering criteria someone
else's problem, you can pretend that the problem has gone away - even if
that "someone else" is not responsible to either sender or recipient,
and that "someone else" is not accountable for misrepresentation.

That certainly doesn't sound like something that would pass muster for
standards track.  Maybe the security folks would like to comment on the
sanity of extending trust to unaccountable third parties?

> that) often work much better than complete reliance on the latter.

I can accept that it makes some sense to identify compromised hosts, for
instance, and that blocking mail from hosts known to be compromised with
a spamming virus can in some cases be more reliable than blocking
content based on actual message content.

But there are still several problems: (1) the problem of "intelligently
choosing" DNSBLs (since many mail admins - even those working for large
ISPs - don't seem to be able to choose very well).  (2) the problem of
extending trust to a party not accountable to either sender or
recipient.  (3) the problem of trusting IP addresses as host
identifiers.  (4) various problems associated with using DNS as a query
protocol for this - including caching, ttls, spoofing, lack of ability
to carry all of the information needed for a reasonable decision to be
made, etc.

> random combinations of SpamAssassin scores that just happen to zap a

Marginally easier, yes, because some DNSBLs include TXT records, and
some ISPs return NDNs with those TXT records.  And if the sender is
lucky, his ISP might not drop the NDN.   And so there's at least some
chance that the sender can figure out why his mail was bounced - or ask
someone to do so.  But this has nothing to do with use of a DNSBL per se
- it's equivalent to saying that SpamAssassin, as usually configured,
doesn't bounce mail.

And when I've been asked to track down why a blacklist rejected a
client's mail, the criteria for blacklisting the host have been bogus in
every single case.  For instance I recently found out that a client's
mail had been bounced because the server that sent out the mail didn't
have a PTR record pointing to a DNS name with the letters "mail" or "mx"
in it... and some idiot decided that this would be a good reason to
bounce perfectly legitimate mail.

Obviously there's a problem with "intelligently choosing" blacklists -
maybe mail system administrators are not, overall, very intelligent?
Maybe a system that expects mail system administrators to be able to
evaluate good blacklist criteria is not well-designed?

> interoperate with DNSBLs I create?

Having a standard for reputation servers might be a good idea.  Basing
that reputation on IP address might not be a good idea.  Using DNS to
transmit that reputation might not be a good idea either.

> the use of DNSBLs is. 

I most assuredly do - because I'm constantly trying to figure out why
people's mail has bounced and running into the damn things.

But I think you misread what wrote earlier.  I didn't say that DNSBLs
weren't well-established.   I said the benefit of reputation servers was
not well-established.

> The reality is: almost everybody uses DNSBLs, and ALL of the very big

Sounds like "almost everybody" needs a clue.  No surprise there.

Or maybe what the industry needs are well-vetted mechanisms for
establishing a host or network's reputation, and well-engineered
mechanisms for reporting them, ensuring repeatability, reporting the
problems to people who can get them fixed, making the reputation
services accountable for their actions and so forth.    Not blessing of
a poorly designed hack.

> than any other, and its popularity alone means it needs to be standardized.

Nope.  Go read 2026.  Carefully.  The protocol has to be technically
sound (it's not) and it has to have rough consensus of the whole IETF
community (it doesn't).

> a specific DNSBL _might_ be dubious is in itself a dubious position.

It strikes me that part of the problem with evaluating the quality of
reputation services used to bounce mail is that legitimate users rarely
see when they work well.  They mostly see when they don't work well,
when their mail is filtered for bogus reasons.

> It is widely believed to work well.  That's part of the point.

It's only believed to work well among mail system administrators who are
isolated from their users.   I've never met an end user who thought
DNSBLs worked well.  I've never met a MSA who worked directly with end
users who thought DNSBLs worked well.

> No more so than filtering in general.

Perhaps not, but that doesn't mean it's worthy of standardization.

> _does_ believe in them. 

The industry might believe in them.  But users don't believe in the
reliability of email, because their experience is that email is not
reliable.  And DNSBLs (and mail filtering in general) are the primary
reasons for that.

> footing to finish the job of de-black-arting it.

The first step is to stop assuming a priori that DNS is a suitable
protocol for communicating reputation, and that IP addresses are
suitable as host identifiers.

Keith

---

From: John Levine <[email-masked]>
Date: 8 Nov 2008 22:41:27 -0000

>was going on.

What connection does any of this have to do with DNSBLs?  There are lots
of less than fabulous ways to manage a mail system poorly, most of which
have nothing to do with looking up IP addresses in a DNS list.

R's,
John

---

From: SM <[email-masked]>
Date: Sat, 08 Nov 2008 15:06:06 -0800

>submit it to the IESG as an Individual Sumbission.

Standard Track and BCP RFCs are part of the IETF document 
stream.  The proposed IRTF document stream (draft-irtf-rfcs) doesn't 
create a new class of documents called IRTF BCPs.

Shouldn't the headings of the two documents coming out of the ASRG be 
"Network Working Group" instead of "Anti-Spam Research Group" as the 
intended category is part of the IETF stream?

Regards,
-sm

---

From: John Levine <[email-masked]>
Date: 9 Nov 2008 00:09:58 -0000

>create a new class of documents called IRTF BCPs.

Quite right.  That's why we're having the argument here about
draft-irtf-asrg-dnsbl-08.

>intended category is part of the IETF stream?

The boilerplate in the drafts is all generated by xml2rfc.  I presume
that the RFC Editor can adjust it appropriately.

R's,
John

---

From: "Chris Lewis" <[email-masked]>
Date: Sat, 08 Nov 2008 19:32:09 -0500

> submit it to the IESG as an Individual Sumbission.

It's been through at least four iterations on the ASRG, so it already
has been worked on there.  Extensively.

At this point, I want to make the latest revisions (with John L's and my
"assigned document handler" or whatever that's called) and have
discussions on that.

The current BCP draft went through review at the last IETF, and from
what I've heard from John Levine, received general acceptance with no
significant objection.  I have to review the comments and see if they
need to be encorporated.  My brief glance suggested at most a minor
wording change. But there's a couple emails full of minor grammatical
tweakage that I have to go through first too.  I promised John I'll have
r5 up Monday, but I might be a day or two late.

I _think_ the "irtf" in the name is a historical accident on my part (I
hadn't done this before) and no more - it being much more trouble than
it's worth to change a document draft file name and screw up draft
numbering.  All that will be fixed by the approval/publication process.

John can speak to the IRTF vs. ASRG vs. IETF BCP issue.

> consensus about the existence of "proper" use seems to be in question.

The thrust of the document is around asserting that the only legitimate
judge of "proper use" is the _user_ of the DNSBL, and establishing a
framework of principles and guidelines by which the user can make
informed choices.  The fact that someone else might think there's no
legitimate use has no bearing - it's not their mail server - they have
no say in email acceptance policy.

The BCP is pitched at a level to obviate most issues about, er,
currency.  It's a distillation of the principles people want to
know/should know about/look for in DNSBLs they might think of using,
captured over as long as there's been DNSBLs.  The document was first
started in 2003 (eeek) and has roots much longer ago than that.  I don't
think it'll obsolete much more quickly than DNSBLs themselves do.
DNSBLs won't be going away anytime soon.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Rich Kulawiec <[email-masked]>
Date: Mon, 10 Nov 2008 19:53:50 -0500

> has been worked on there.  Extensively.

Having witnessed those iterations (and contributed in a very minor
way to them), I can report that the process was lively, productive,
and included input from some of the most experienced and knowledgeable
people working in the field.  I believe that the current document (thanks
to Chris's excellent stewardship) equitably and honestly represents the
consensus of the participants, and that small consensus in turns fairly
represents the much larger consensus of mail system operators.

This isn't to say that everyone in either group agrees with how
DNSBLs should be *used*: some advocate scoring, some advocate
combination with other methods, and so on.  But I think it's
reasonable to presume that anyone using them in any fashion has
signaled their implicit agreement with the notion that DNSBLs should
exist and should be used -- at which point we're back to addressing
BCPs for operating them, and the point of this document.

> no say in email acceptance policy.

This is a key point -- one that can't be stressed enough, which is why
I quoted it.  No mail server operator is required to provide services
to anyone (absent a contractual obligation or statutory requirement).
So while it's possible that everyone reading this might concur that
that a particular mail server operator is in error by not providing
services to some host/network/domain/user/etc., we don't get a vote.

---Rsk