Subject: [Asrg] draft-irtf-asrg-bcp-blacklists draft updated.

From: "Chris Lewis" <[email-masked]>
Date: Wed, 04 Jun 2008 11:45:00 -0400

I've just uploaded and authenticated/verified:

http://www.ietf.org/internet-drafts/draft-irtf-asrg-bcp-blacklists-03.txt

Version:  	03
Submission Date:	2008-06-04
Title:	Guidelines for Management of DNSBLs for Email

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.

The document will seek BCP status.  Comments and discussion of this
document should be addressed to the [email-masked] mailing list.

-------------------------------------------------

I believe all of the changes were minor editorial tweaks.

I'd appreciate people going through this carefully to make sure I've not 
finger-fumbled anything.  After a while you can't see the document for 
the words to mangle a phrase.

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

---

From: "David Nicol" <[email-masked]>
Date: Wed, 4 Jun 2008 13:19:44 -0500

s/in a Graceful fashion/Gracefully/
s/author's/authors'/
s/are known to be in operation/operate [ref]/
s/by those people //
s/While listing criteria can sometimes be quite controversial,/Listing
criteria can sometimes be quite controversial, therefore/
s/as long as they're clear to their users what they are./as long as
those criteria are clearly and accurately communicated./
s/e.g./for example/
s/only the assessment/only for assessment/
s/an un-intended way/unintended ways/
s/third party's information guide/third party's information to guide/
s/ultimately with you, the system administrator/ultimately with you,
the postmaster/
s/, perhaps inevitably,//
s/  In this context it has to be remembered that n/  N/
s/Yet, by/By/
s/If the DNSBL operator is too explicit in published policy, an abuser
may be able to "game" it/Abusers may be able to "game" published
policy that is too explicit/
s/conditions for listing still exists/conditions triggering listing still exist/
s/blowing up into/from becoming/
s/have plans/include plans/
s/positive listing for 127.0.0.1 SHOULD be considered/positive listing
for 127.0.0.1 SHOULD be interpretable as/
s/finally shutdown the DNSBL/finally shut down the DNSBL/

the rescan period SHOULD increase using exponential backoff

clearly dividing shoulds for providers and shoulds for users into
their own section would be good IMO
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Tony Hansen <[email-masked]>
Date: Wed, 04 Jun 2008 15:01:30 -0400

> http://www.ietf.org/internet-drafts/draft-irtf-asrg-bcp-blacklists-03.txt

As the putative document shepherd for this doc, before we can submit it 
to the ADs, it needs to pass the NITs checks.

1) There needs to be an IANA Considerations section that states:

	This document has no actions for IANA. [This section may be
	removed before publishing as an RFC.]

2) Remove the unused reference to 'RFC2026':
      '[RFC2026]  Bradner, S., "The Internet Standards Process -- ...

3) The following 3 references are Informational and may not be Normative:

	RFC 3330, 3833, 5156

I'll provide some other notes in another email message.

	Tony Hansen
	[email-masked]

---

From: Tony Hansen <[email-masked]>
Date: Wed, 04 Jun 2008 15:03:13 -0400

> http://www.ietf.org/internet-drafts/draft-irtf-asrg-bcp-blacklists-03.txt

In addition to the NITs I listed in another message, I suggest making 
the following changes for grammatical cleanliness.

	Tony Hansen
	[email-masked]

130,131c130,131
<    different ways, far beyond the designers' of DNS or DNS-based
<    blocking IP lists imaginings.  For example, today, the same basic
---
 >    different ways, far beyond the imaginings of the designers of DNS 
or DNS-based
 >    blocking IP lists.  For example, today, the same basic
134c134
<    DNSWL  listings of well-behaving email source IP addresses
---
 >    DNSWL  listings of well-behaving email source IP/domain addresses
150,152c150,152
<    informational purposes.  For example, implementations that return
<    results based on what geographic region an IP is putatively allocated
<    in, implementations that translate an IP address into a ASN number
---
 >    informational purposes.  For example, there are implementations 
that return
 >    results based on what geographic region an IP/domain is putatively 
allocated
 >    in, implementations that translate an IP/domain address into a ASN 
number
175c175
<    some DNSBLs in some areas, these areas will be mentioned as
---
 >    some DNSBLs in some areas, which will be mentioned as
191c191
<    sources situated at static (unchanging) IP addresses.  Due to the
---
 >    sources situated at static (unchanging) IP/domain addresses.  Due 
to the
207c207
<    what they are.  It is the responsibility of the DNSBL user to ensure
---
 >    what the criteria are.  It is the responsibility of the DNSBL user 
to ensure
229c229
<    queries.  See [DNSBL-EMAIL].
---
 >    queries.  (See [DNSBL-EMAIL].)
255c255
<         such evaluations depend on mail mix used as well as local
---
 >         such evaluations depend on the mail mix used as well as local
312c312
<    document are to be interpreted as described in RFC 2119 [RFC2119].
---
 >    document are to be interpreted as described in [RFC2119].
325c325
<       (ASRG) of the IRTF.  As per section 3 of RFC 2014 [RFC2014]IRTF
---
 >       (ASRG) of the IRTF.  As per section 3 of [RFC2014] IRTF
352c352
<    A DNSBL SHOULD carefully describe the criteria which are the cause
---
 >    A DNSBL SHOULD carefully describe the criteria that are the cause
369c369
<    relays only MUST NOT include IP addresses for any other reason.  This
---
 >    relays MUST NOT include IP addresses for any other reason.  This
384c384
<    available (or shutdown).  See Section 3.1.
---
 >    available (or shut down).  See Section 3.1.
413c413
<    making audit trail data public does not entail revealing all
---
 >    making an audit trail data public does not entail revealing all
428c428
<    Examples: Some DNSBLs will IP ranges if there is reason to believe
---
 >    Examples: Some DNSBLs will list IP ranges if there is reason to 
believe
441c441
<    perfect, and that occasional mistake is inevitable no matter what is
---
 >    perfect, and that an occasional mistake is inevitable no matter 
what is
455c455
<    diligent administrator needs information about the these policies in
---
 >    diligent administrator needs information about these policies in
487c487
<        need not ever get removed, just kept reasonably current.
---
 >        need not ever be removed, just kept reasonably current.
491c491
<        long expiration intervals or only be removed on request after
---
 >        long expiration intervals or only be removed upon request after
515c515
<    what the expiration policy is, even if its only "delist on request"
---
 >    their expiration policy is, even if it's only "delist on request"
547c547
<    methods with low false positive rate as practical SHOULD be chosen.
---
 >    methods with as low of a false positive rate as practical SHOULD 
be chosen.
555c555
<    representative or domain owner) may make valid removal requests,
---
 >    representative or domain owner) may make valid removal requests.
564,565c564,565
<    however, in many DNSBLs this is inadvisable because it requires
<    impractical amounts of effort and hence NOT RECOMMENDED in most
---
 >    However, in many DNSBLs this is inadvisable because it requires
 >    impractical amounts of effort and hence is NOT RECOMMENDED in most
573,574c573,574
<    listed IP address removed immediately, it does not prevent the DNSBL
<    operator from re-listing the IP address at a later time.
---
 >    listed IP/domain address removed immediately, it does not prevent 
the DNSBL
 >    operator from re-listing the IP/domain address at a later time.
592c592
<    DNSBL operators and organizations whose IP addresses have been
---
 >    DNSBL operators and organizations whose IP/domain addresses have been
599c599
<    relationship to the factors which were the cause of the addition to
---
 >    relationship to the factors that were the cause of the addition to
666c666
<    Most IP-based DNSBLs follow a convention of entries for IPs in
---
 >    Most IP-based DNSBLs follow a convention of query entries for IPs in
678,679c678,679
<    that the IP is listed.  This appears to be a defacto standard.  See
<    [DNSBL-EMAIL]
---
 >    that the IP/domain is listed.  This appears to be a defacto 
standard.  See
 >    [DNSBL-EMAIL].
698c698
<    because it is generally prohibited in hostnames, and are highly
---
 >    because they are generally prohibited in hostnames, and are highly
732c732
<    servers for the DNSBL.  Popular DNSBLs are in use by tens of
---
 >    servers for the DNSBL.  Popular DNSBLs are used by tens of
760c760
<        inflicting a DDOS.
---
 >        inflicting a DDOS attack.
762c762
<    5.  The base domain name SHOULD be registered indefinately, so as to
---
 >    5.  The base domain name SHOULD be registered indefinitely, so as to
768c768
<    servers for the DNSBL to point at "TEST-NET" addresses (see RFC3330
---
 >    servers for the DNSBL to point at "TEST-NET" addresses (see
802,803c802,803
<    Assumes DNSBL is named "dnsbl.example.com".  Replace "example.com"
<    and "dnsbl.example.com" as appropriate for the DNSBL
---
 >    This example assumes that the DNSBL is named "dnsbl.example.com". 
  Replace "example.com"
 >    and "dnsbl.example.com" as appropriate for the DNSBL.
810c810
<    The DNSBL MAY list loopback, RFC 1918 [RFC1918], LINK-LOCAL class
---
 >    The DNSBL MAY list loopback, [RFC1918], LINK-LOCAL class
814c814
<    As additional insurance against listings of space that should not be
---
 >    As additional insurance against listings of space that should not 
be listed,
831c831
<    This practise (scanning for vulnerabilities) can represent a risk in
---
 >    The practise of scanning for vulnerabilities can represent a risk in
867c867
<    targetting conditions are no longer met.
---
 >    targetting conditions no longer being met.
886c886
<    systems improperly for DNSBL queries.  The consequences of error can
---
 >    systems improperly for DNSBL queries.  The consequences of an 
error can
906c906
<        or 4.3.2.1.dnsbl.exmple.cm instead of 4.3.2.1.dnsbl.example.com)
---
 >        or 4.3.2.1.dnsbl.exmple.cm instead of 4.3.2.1.dnsbl.example.com).
910c910
<        continuing to query public nameservers
---
 >        continuing to query the public nameservers.
917c917
<        thus heavily increasing load on public nameservers
---
 >        thus heavily increasing load on the public nameservers.
922c922
<    6.  Using the DNSBL incorrectly. e.g.  Some DNSBLs are suitable only
---
 >    6.  Using the DNSBL incorrectly. E.g.  some DNSBLs are suitable only
926,927c926,927
<    While in many cases, it can be difficult detect such situations, to
<    protect against such misconfiguration, it is RECOMMENDED that DNSBL
---
 >    While in many cases it can be difficult to detect such situations, to
 >    protect against such misconfiguration it is RECOMMENDED that DNSBL
964c964
<    outlined in RFC 3833 [RFC3833]
---
 >    outlined in [RFC3833].

---

From: Ian Eiloart <[email-masked]>
Date: Thu, 05 Jun 2008 11:03:11 +0100

> the words to mangle a phrase.

s/rightness or wrongness/rights and wrongs/

I'm not sure about this: "DNSBL providers SHOULD NOT be held
   accountable in any way for the consequences of use of a DNSBL applied
   in an un-intended way."

The implication is that providers may or even should be held accountable 
for consequences of use of a DNSBL applied in an intended way. There are 
two problems with this: (a) it isn't clear whose "intent" is referred to - 
though I guess we mean the intent of the provider not the user (b) many 
DNSBLs don't list any "intended" use - they simply describe the listing 
criteria. In fact, none of the RBLs that I use to block spam (by rejecting 
smtp mail from listed IP addresses) explicitly say that they are intended 
to be used for that purpose - at best they say that some people choose to 
do so.

I think, therefore, accountability should only apply when the published 
criteria don't match the real criteria for listing. Therefore, I'd prefer 
the wording:

"DNSBL providers SHOULD NOT be held accountable in any way for the 
consequences of any use of a DNSBL, provided the published listing criteria 
match the real listing criteria." or even simply "DNSBL providers SHOULD 
NOT be held accountable in any way for the consequences of any use of a 
DNSBL.".

-- 
Ian Eiloart
IT Services, University of Sussex
x3148
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "David Nicol" <[email-masked]>
Date: Thu, 5 Jun 2008 11:20:47 -0500

> it isn't clear whose "intent" is referred to -
> though I guess we mean the intent of the provider not the user

which would be solved by clearly sectioning into BCP for providing and
BCP for use, no guessing would be req'd after that
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: John Levine <[email-masked]>
Date: 5 Jun 2008 17:07:21 -0000

>   accountable in any way for the consequences of use of a DNSBL
>   applied in an un-intended way."

I believe that the example the authors had in mind is the Spamhaus
PBL, which lists IPs that shouldn't be emitting mail directly to the
net, but which can legitmately send mail by logging into a SUBMIT
server and relaying through there.  A common config error on MTAs that
are both MX and SUBMIT is to check the PBL before senders have a
chance to log in, with the effect that roaming users can't send mail.

The next step is then usenet or blog posts ranting about evil Spamhaus
blocked their mail, they're not spammers, blacklists are out of
control, etc. etc., until whoever runs the MTA notices and fixes the
configuration error.

A more subtle example is my korea.services.net, which lists all of the
networks in South Korea with the exception of a few small ones that I
have observed not to be significant spam sources.  It's explicitly
intended for people like me who don't know anyone in Korea and don't
expect mail from Korea. Since it lists all the large ISPs, if you do
get mail from Korea, you'll lose a lot of it.  Again, I've gotten
rants from people about how I'm blocking their very important mail,
it's wildly unreasonable, etc.  (My response: "If a network were
sending you a thousand spams for every real message, what would you
do?  Well, that's what I did.")

So in any event, the real intent is to say that you can't prevent
idiots from doing idiotic things.  If you can come up with a better
way to say that in standards speak, I'm sure the authors will be happy
to adopt it.

R's,
John

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 05 Jun 2008 13:21:11 -0400

> BCP for use, no guessing would be req'd after that

I'd prefer not to do any major surgery on the document at this point. 
It's been _way_ too long already (though that's probably not a very good 
reason ;-).

It would cause some significant flow/replication/redundancy uglies.  But 
I do see the point about interspersing them.

I'm considering a brief summarization section of the "SHOULD/MUST/MAY" 
split between user and provider.   Thoughts?

BTW: thanks for all the comments.  I'm filing them away for a run at 
updates.  I'll be adopting almost all of them (if someone can show me 
how in XML to not have the RFC number replicate in references ;-)  It's 
nice to see that I seem to have gotten it to the point where there isn't 
any substantive changes apparently needed.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 05 Jun 2008 13:34:37 -0400

> chance to log in, with the effect that roaming users can't send mail.

The more significant problem seems to be the destination MTA doing a 
full tranverse of the received headers, and blocks legit email relayed 
another ISP's mail server, because the origin is in the PBL (or some DUL).

PBL is "no direct email".  My scenario is "blocking _indirect_ email". 
Your scenario is "blocking your own users sending properly".  Both of 
them are _not_ what the PBL (or DUL) are supposed to do.

Spamhaus has warnings about this, but, sometimes the users don't or 
refuse to notice.

The CBL has stronger prohibitions about using CBL out-of-scope, but 
seems to realize that sometimes it's not such a bad idea, so if the user 
insists on out-of-scope use (eg: web serverm IRC or full received 
traverse), the user must not blame the CBL for the block, and take the 
support hit themselves.

> way to say that in standards speak, I'm sure the authors will be happy

Maybe ;-)  I also do not believe that the "MUST NOT do X under condition 
Y" says anything about "condition !Y".  If we had intended to say 
something about !Y, we would have said it explicitly.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 05 Jun 2008 11:49:19 -0600

On 05/06/2008 04:03, "Ian Eiloart" <[email-masked]> wrote:

> match the real listing criteria."

That gets into arguments about the intent behind any individual listing,
which we've all seen is an endless morass with no possible resolution.

> or even simply "DNSBL providers SHOULD

Hmm, that'll bring the crazies out even faster.

-- 
J.D. Falk
Return Path

Work with me!
http://www.returnpath.net/careers/

---

From: "David Nicol" <[email-masked]>
Date: Thu, 5 Jun 2008 13:14:09 -0500

My (apparently incorrect) reading of the accountability passage was
that it was intended to impact legal blame assignment, rather than to
rant about human nature. (BCP for humanity:  Humans SHOULD NOT behave
as idiots)

Are there any liability lawyers reading this? Perhaps one might comment.

Here's a draft restatement, burying the implied accusation of idiocy
under a better-specified countermanded example:

Users of a DNSBL MUST understand the intention and recommended use(s)
of a DNSBL before using it.  Providers of a DNSBL MAY refuse to expend
effort in support of unintended uses of their service.  Users SHOULD
NOT expect providers to expend effort supporting use of their service
beyond its purpose as intended by the providers.

Adding a dimension (in this case user/provider) to a linear narrative
is usually implied at a fine grain.  In reference manuals, such as
HOWTO documents, the redundancy of content is acceptable because of
the differing needs of the roles of the audiences. The proposed
document has at least two intended audiences, the user role and the
provider role. The addition of an index of required reading for users
and required reading for providers would I think satisfy the objection
about the interspersal, as long as user/provider roles are explicit at
all points.

section: This document is required reading for users of DNSBLs
users of DNSBLs MUST be familiar with the recommendations in section x, y,z
users of DNSBLs MAY become familar with the provider-specific sections

section: This document is required reading for providers of DNSBLs
providers of DNSBLs MUST be familiar with the r13s in section x,w,v
providers of DNSBLs SHOULD also be familar with the user-specific sections
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Al Iverson" <[email-masked]>
Date: Thu, 5 Jun 2008 13:23:31 -0500

> split between user and provider.   Thoughts?

This seems sound and wise.

Best,
Al

-- 
Al Iverson on Spam and Deliverability, see http://www.spamresource.com
News, stats, info, and commentary on blacklists: http://www.dnsbl.com
My personal website: http://www.aliverson.com -- Chicago, IL, USA
Remove "lists" from my email address to reach me faster and directly.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: John Levine <[email-masked]>
Date: 5 Jun 2008 19:51:14 -0000

>rant about human nature. (BCP for humanity:  Humans SHOULD NOT behave

The IETF does not in general make legal statements.  These assertions
are about network management.

>Are there any liability lawyers reading this? Perhaps one might comment.

Gee I hope not.  Every country is different, but in the US where I
live there is strong statutory protection for good faith blocking of
offensive material which courts have generally interpreted to protect
all sorts of filtering.

R's,
John

---

From: John Levine <[email-masked]>
Date: 5 Jun 2008 19:51:14 -0000

R's,
John

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 06 Jun 2008 11:49:20 +0100

> another ISP's mail server, because the origin is in the PBL (or some DUL).

Oh, well in these cases, the intent referred to is that of the user, not 
the provider! That's the opposite of what I assumed was required.

These are both, probably, cases where the user didn't understand that their 
configurations wouldn't achieve what they wanted to achieve. The provider's 
intent is irrelevant here.

It might be useful to try to think of situations in which you _would_ want 
the provider to be held accountable for a problem. I can only think of a 
few situations:

(a) deliberate mischief on the part of the provider, for example knowingly 
listing a host which doesn't match the listing criteria, or

(b) failing to take reasonable security measures to ensure that another 
party doesn't do (a) above,

(c) failing to adequately document the listing criteria,

(d) substantially changing the listing criteria (because there is no 
mechanism for alerting users - perhaps there should be) - instead, a new 
list should be created.

Both (a) and (c) are present in the RFC, but (b) and (d) aren't. I think 
they should be.

Perhaps the wording should read "DNSBL providers SHOULD NOT be held 
accountable in any way for the consequences of use of a DNSBL, as long as 
the DNSBL meets the standards of this RFC". Or perhaps that's implicit.

---

From: "Seth Breidbart" <[email-masked]>
Date: Fri, 6 Jun 2008 08:14:14 -0500 ( )

> (c) failing to adequately document the listing criteria,

What does that mean?  Inaccuracy is one thing, but could you give an
example of listing criteria that are accurate but inadequate?  I think "IP
addresses that annoy Seth" is a perfectly adequate listing criteria.

> mechanism for alerting users - perhaps there should be) - instead, a new

That's a form of inaccuracy.  (How big a change is "substantially"?)

> the DNSBL meets the standards of this RFC". Or perhaps that's implicit.

"Responsibility for the consequences of the use of a DNSBL (or any other
configuration option) belongs to whoever decided to use that DNSBL (or
other option)."  If someone chooses to use dnsbl.noprimes.org to block
mail, the responsibility is the chooser's.

Seth

---

From: SM <[email-masked]>
Date: Sat, 07 Jun 2008 09:33:01 -0700

>chance to log in, with the effect that roaming users can't send mail.

Does that mean that DNSBL providers are held accountable for the 
consequences of use of a DNSBL in an intended way?

   "It is the responsibility of the system administrators who adopt one
    or more DNSBLs to evaluate, understand, and make a determination of
    which DNSBLs are appropriate for the sites they administer."

The above sentence from Section 1.2 conveys the idea clearly.  The 
Section discusses about guidance for DNSBL Users.  It would be better 
to drop the "accountable" sentence.

Regards,
-sm