Subject: Re: [Asrg] Round one modifications to DNSBL BCP draft.

From: Douglas Otis <[email-masked]>
Date: Tue, 1 Apr 2008 07:54:49 -1000

On Mar 31, 2008, at 4:22 PM, Seth wrote:

> Douglas Otis <[email-masked]> wrote:
>> On Mar 31, 2008, at 11:44 AM, Seth wrote:
>>> Douglas Otis <[email-masked]> wrote:
>>>
>>>> Will information be added related to warnings regarding network  
>>>> provider associated address space about to be list?
>>>
>>> I hope not.
>>>
>>> Why do you keep assuming that only things that _have_ network  
>>> providers can be listed?  Who is the "network provider" for a  
>>> "Mailer-agent" header DNSBL?
>>
>> Any IP address used by bad actors for sending UCEs or other types  
>> of abuse is being routed by a network provider.
>
> Which network provider would you recommend notifying about an entry  
> that says "X-Mailer: CloakedSender" is a spam indication?

Most black-hole/block lists are based upon the IP address where the  
octets are in reverse order.  The network provider can be noted by who  
advertised the address space.

See:
http://www.team-cymru.org

This technique depends upon ASNs observed in BGP announcements.  This  
information is often processed with a program like zebra, for example.

Some might be based upon domain names used in abuse, but a necessity  
to inform the owner of the domain is less, but could be done using  
abuse@<example.com>.

Determining the network provider helps establish their reputation,  
which should represent a significant factor in whether their  
advertised space can be trusted.  It will become apparent by a high  
percentage of their addresses abusing the network, the network provide  
does not have or enforce AUPs prohibiting abuse.  A draft about best  
practices should include a section on this topic.  This allows  
notifying the network provider to allow them to pass on timely  
information to owners of likely compromised systems.

> If you want to notify the providers for the emitters of all the spam  
> you get, feel free.  But you aren't going to get others to believe  
> that doing so is a requirement on them.

Defining a function essential for creating a warning when a system  
becomes compromised, but may not normally be sending email is not  
required.  Not implementing this function could not be defined as a  
best practice either.

>> In addition, the network provider is in the unique position of  
>> being able to curtail the abuse immediately.
>
> Tell me again, which provider can curtail the use of "X-Mailer:  
> CloakedSender" immediately?

Only the network provider knows who owns the equipment, as they  
receive payment for the network access they provide.  Their response  
might be to notify these owners.  If the abuse represents criminal  
activity, such as distribution of malware, the network provider may  
also block access.  Either way, the owner of the system become aware  
of the issue.  Since much email abuse is being emitted from  
compromised systems, black-hole/block-list operators coordinating with  
network providers do play a critical role in abating this problem.   
While performing this function is not required, not performing this  
function can not be described as a best practice.

>> How can a BL operator establish relationships with millions of a  
>> network providers' customers, without expecting network providers  
>> to intercede?
>
> How do you define "establish relationships"?  If I publish  
> dnsbl.noprimes.org, have I established relationships with all users  
> of prime-number IP addresses?

When the goal of the black-hole/black list is to enumerate addresses  
emitting abuse, then offering notification to the associated network  
provider dramatically changes the scope of what is being rated, form  
billions of users, to thousands of providers.  Rating providers and  
excluding the worst is often effective.

>> Only network provider can establish AUPs,
>
> Anybody can establish an AUP for his own property.  Lots of web  
> boards have AUPs without being network providers.

Access to the Internet is granted by network providers.  Their  
customers can run any number of services that should constrain their  
activities to comply with that of their network provider.

>> While few black-hole/block list operators are able to coordinate  
>> with network providers and thereby prevent abuse at the source,  
>> _no_ other approach is as effective or as robust.
>
> So you claim; but so what?  Why should there be any obligation on  
> anybody based on your claim (even if true) that something is the  
> most effective or robust approach?

Ignoring the role of the network provider can not be seen as a best  
practice when rating IP address space.

>> A level of trust is required between the BL operator and the  
>> network provider to be both effective and to improve safely.
>
> Since many network providers are quite untrustworthy, that alone is  
> reason to avoid notifying those you don't know.

The level of detail within notifications would be where trust would be  
demonstrated.

>> Defining a BL mode of operation that asks the least of the network  
>> operator, also does the least in terms of curbing abuse.
>
> Nobody else is obligated to act according to your beliefs about what  
> is the most effective.

When asking about the BL being gamed, a fair amount of hand waving  
commenced.  Of course anyone can pretend to be doing something about  
email abuse.  Being effective requires at least which network provider  
is permitting the abuse.

>> Currently, few BLs rate domain names.
>
> So?  This isn't a democracy with each BL having one vote.

This draft is attempting to establish guidelines, where currently the  
vast majority of BL operators pertain to IP addresses emitting email  
abuse.  Rather than ignoring these issues, separate sections could  
enumerate how these other types of lists can "best" server their  
function.

>> IP addresses resolved by the name or used by the name server may  
>> serve as a reference identifier.
>
> Especially for those domains hosted on zombies with 60 second TTLs.

Be careful.  This may occur occasionally when using a provider's  
resolvers.

>>>> In many cases, only the network provider can be identified as  
>>>> being associated with the address space in question.
>>>
>>> In many cases, nobody can be.
>>
>> This is simply not true, or the packet could not be routed.
>
> What is the address space for "X-Mailer: CloakedSender"?

The IP address used by the SMTP client, the IP address being queried,  
represents the provider.  See above.  This information must be  
included in this draft, or it is lacking essential inforamtion.

>>>> Will there be any recommendation regarding the notification of  
>>>> listings?
>>>
>>> The listing is its own notification.
>>
>> No. The goal is to stop the abuse at its source.
>
> Whose goal?  Nobody else is required to act according to your goals.

A best practice should offer this as a goal, of course.

> My goal is to identify prime numbers.

Why would you describe this as a black-hole/block list?

>> As such, prior notification of a listing given the network provider  
>> can then be directed to their customer.
>
> Lots of things "can be".  The fact that something "can be" does not  
> suffice to create obligations.

Network providers are the only entities able to assert governance.   
Rather than attempting to rate billions of individual users, rating a  
few thousand network providers dramatically reduces the scale of the  
the assessment.  BL operators efforts in notifying the network  
providers is not an obligation, but without such notification, BL  
operators will not be as effective in abating abuse.  Abating abuse  
should the goal of a best practice.

-Doug

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

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 01 Apr 2008 14:48:45 -0400

> information is often processed with a program like zebra, for example.

Or home grown stuff using routeviews.

The mechanics of doing this are well understood, however:

> advertised space can be trusted.

Very few existing (at least public) DNSBLs pay any attention whatsoever 
to this.  Those that do usually do little more than ad-hoc aggregate 
statistical reports, eg http://cbl.abuseat.org/country.html and 
http://cbl.abuseat.org/domain.html, or Spamhaus's country/provider top 
100 listings, or Cymru's or helping guide the manual escalation of 
manual listings...

Hence, it misses the "C" ("current") required for a BCP.

It may be the perfect reputational DNSBL design, but it's still not a 
_current_ one, and is hence not eligible for a BCP.

Secondly, it's DNSBL listing policy, not operational practise.  Thus, it 
is out of scope for the document at hand _even_ if such DNSBLs existed 
today.

So while this discussion might lead to ideas for new DNSBLs (I've gotten 
several ideas already - I already do most of the hard computations) with 
more advanced listing criteria, it's totally irrelevant to a DNSBL 
operational BCP.

As a discussion for future work in DNSBL/reputational systems it's a 
reasonable topic for ASRG.  But, it has _nothing_ to do with the BCP - 
this subthread diverged from relevance some time ago.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Al Iverson" <[email-masked]>
Date: Tue, 1 Apr 2008 13:51:42 -0500

>  100 listings, or Cymru's or helping guide the manual escalation of

MAPS seems to be the only one pushing for inclusion of this
requirement. Unless there's strong evidence that other BLs find it to
be a best practice, I say we call the discussion closed on this point
and move on.

It's not only too "type of BL" specific, it seems to be specific only
to a single BL.

Regards,
Al Iverson

-- 
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: Andrew D Kirch <[email-masked]>
Date: Tue, 01 Apr 2008 15:01:00 -0400

> It's not only too "type of BL" specific, it seems to be specific only
I concur, we simply don't use this or see a need to.

Andrew

---

From: Andrew D Kirch <[email-masked]>
Date: Tue, 01 Apr 2008 15:05:00 -0400

> It's not only too "type of BL" specific, it seems to be specific only

one last thought, just because this is struck down now does not mean 
that MAPS should not consider submitting an optional extension to this 
draft in the ongoing process of maintaining the RFC.  My statement that 
we don't use this means it is by no means a BCP, however any DNSBL 
operator should be looking to increase the quality of the data.  If you 
guys really want this standardized, draft it, and submit it for review 
on a stand alone basis.  I'll be more than happy to review a formal 
draft on this process and render my opinions (which I'm sure will be 
many) on this separate draft.  I will probably write additional drafts 
to expand and augment this once we see how it is received, and where 
this process goes next.  This document should be, as was mentioned 
earlier the lowest current denominator among major DNSBL's.

Andrew

---

From: der Mouse <[email-masked]>
Date: Tue, 1 Apr 2008 16:52:40 -0400 (EDT)

> Most black-hole/block lists are based upon the IP address [...]

Yes.  The point is that babblage about network providers and such works
only for the ones that are, WHICH IS NOT ALL OF THEM.

> represents the provider.

This is true, but completely ignores the question.

/~\ The ASCII				der 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
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Douglas Otis <[email-masked]>
Date: Thu, 3 Apr 2008 16:15:59 -0700

On Apr 1, 2008, at 8:48 AM, Chris Lewis wrote:
> Very few existing (at least public) DNSBLs pay any attention  
> whatsoever to this.  Those that do usually do little more than ad- 
> hoc aggregate statistical reports, eg http://cbl.abuseat.org/country.html 
>  and http://cbl.abuseat.org/domain.html, or Spamhaus's country/ 
> provider top 100 listings, or Cymru's or helping guide the manual  
> escalation of manual listings...
>
> It may be the perfect reputational DNSBL design, but it's still not  
> a _current_ one, and is hence not eligible for a BCP.
>
> Secondly, it's DNSBL listing policy, not operational practise.   
> Thus, it is out of scope for the document at hand _even_ if such  
> DNSBLs existed today.

The Internet is a collaboration of separate, privately owned  
networks.  Each network provider freely decides to mutually accept  
each other's address space advertisements and related traffic.  The  
draft, although somewhat improved, still needs to differentiate  
between policies that relate to automated listings, from those that  
are created manually.  Also, do not assume listings pertain to the  
actions of individual IP addresses.  This is _not_ always the case.   
In addition, policy suggestions for listing and delisting should be  
limited to automated lists only.

When MAPS (the original black-hole list) first started, its  
assessments _always_ included the network provider.  It was understood  
who MUST be held responsible.  This is not a new untried idea.  This  
has been the case since MAPS first started, and is still the case  
today.  Then and now, this practice encourages network providers to  
enforce AUPs that prohibit UCEs and other forms of abuse.

Only the network provider knows the entities associated with their  
address space.  Only the network provider can assert the governance  
required to abate abuse.  Ensuring the network provider stays involved  
is vital.  Many systems emitting abuse have been compromised and may  
not normally send email.  Unless the network provider conveys this  
situation to their customers, these systems may continue to emit  
abuse.  Although some email providers abhor assessments that include  
the network provider, privately many acknowledge the effort provides  
an overall, albeit painful, benefit.

The draft is clearly recommending use of automation and excludes any  
role involving network providers.  Unfortunately, automated systems  
are easily defeated because of their automation.  No block list  
receives a comprehensive view of all sources emitted by a network  
provider.  Acceptance of traffic may depend upon a sampling technique  
used in industry to ascertain product quality.  Rejection may not  
involve direct observation of each item, rather this is done through  
sampling.  A conclusion can be safely reached that network provider's  
process lacks the necessary and essential quality controls.

The strategy initially adopted by MAPS has not been made obsolete by  
network providers improving their controls, although many have.  Some  
network providers still do not exercise the requisite governance.  In  
addition, prevalence of Bot-Nets has only made the initial strategy  
taken by MAPs to have been prescient.  In excess of 50,000 compromised  
systems may be leased by bad-actors as a unit.  Such leasing permits a  
bad-actor, within a single spam campaign, to identify _all_ networks  
not conveying abuse to block-list operators.  Those networks that  
convey abuse, when blocking is automated, only require bad-actors to  
emit their campaign at slow rates to identify where abuse is  
monitored.  In this case, automation clearly benefits bad-actors.

In addition to listing automation, recommending a method to request  
automatic removal without involving network operators is ideal for bad- 
actors as well.  After all, bad-actors are often using leased  
resources of compromised systems, and have no relationship with their  
network provider.  After running their "request removal" scripts,  
their leased Bot-Net is ready to emit spam campaigns scrubbed of known  
monitors.  Bad-actors should offer the authors of this draft their  
heart felt thanks for ensuring block-listing is no longer their problem.

Block-lists that incorporate a manual strategy are designed to make  
listing and de-listing uncertain or inconvenient for bad-actors by:

- notifying the network provider of pending listings and waiting for  
their response.

- not automatically removing a listing.

- accepting removal requests only from network providers.

While this is a PITA for many email providers, and appears to be the  
motivation behind the current draft, it would be hard to describe  
policy recommendations contained within this draft as a good or even a  
sustainable practice.

Change:

2.2.1.  Listings SHOULD Be Temporary

To:

2.2.1.  Listings SHOULD Be Temporary for automated listings

Change:

2.2.3.  Removals SHOULD Be Prompt

To:

2.2.3.  Removals SHOULD Be Prompt for automated listings

Conclusions reached in the last three paragraphs of section 2.2.3 are  
naive and wrong.  Strike these paragraphs:

---
Many DNSBLs can effectively use a "no questions asked" removal policy
because by their very nature they will redetect or relist problems
almost immediately.  They can mitigate more organized attempts to
"game" the system by elementary checking and rate-limiting
procedures, increasing lockout periods, rescans etc.  Furthermore, a
few IP addresses more or less do not make a significant difference in
the overall effectiveness of a DNSBL.  Moreover, a "no questions
asked" removal policy provides the huge benefit of a swift reaction
to incorrect listings.

As an example, one popular DNSBL uses a "no questions asked" removal
policy, but does perform rate-limiting and malicious removal
detection and mitigation.

Another important consideration supporting a "no questions asked"
self-removal policy is that it forestalls many conflicts between
DNSBL operators and organizations whose IP addresses have been
listed.  Such a policy also can be an effective deterrent to legal
problems.
---

The last sentence in this section could be seen as a threat.  "Such a  
policy also can be an effective deterrent to legal problems." suggests  
list operators become liable when adhering to their policy when it  
differs from this poorly considered and naive recommendation.  Public  
lists could incorporate ACLs that register the IP addresses of those  
that entered into click-through agreements that indemnifies the  
operator.  The ACL agreement suggestion would be how this draft might  
attempt to offer operators greater legal protection.  This draft seems  
determined to ignore the goal of operating a blocking list.  This goal  
would be to curb abuse at its source.  This is done by network  
operators improving enforcement of their AUPs.  The Internet can not  
continue to exist without network providers ensuring good governance.

3.6.  Use of Collateral Damage MUST Be Disclosed

This section assumes only individual IP addresses are assessed.  The  
list may represent a range of IP addresses pertaining to single  
entity, the rated network provider.  Would listings based upon this  
entity's address space represent collateral damage?  Such a rating may  
suggest this provider is not effective at enforcing reasonable  
Acceptable Use Policies.

Calling this "collateral damage" represents a concerted bias against  
rating network providers.  Clearly, when a listing is constrained to  
that of specific network provider, there would not be _any_ collateral  
damage involving other network providers.

In the Security Consideration Section, block-list operators that  
develop an effective strategy not easily defeated are likely to find  
their resources DDoS attacked.  These resources include monitoring and  
distribution systems.  DNS is a fairly robust distribution method, but  
definitely not the only method available.  Information can be  
distributed as a BGP feed placed within the subscriber's routers. BGP  
offers protection from a range of attacks.  Listing and removal  
automation also exposes the location of the operators resources.   
Automation should be used with extreme caution.

-Doug

---

From: SM <[email-masked]>
Date: Thu, 03 Apr 2008 23:58:36 -0700

>naive and wrong.  Strike these paragraphs:

[snip]

>differs from this poorly considered and naive recommendation.  Public

I agree the last sentence should be removed as it's not up to the 
document to provide legal advice.

>damage involving other network providers.

If you don't want it called collateral damage, you can always say:

3.6 The scope of the listing MUST be disclosed

And elaborate on whether the listing identifies individual IP 
addresses or a range of IP addresses which includes IP addresses 
under the control of a provider even though those IP addresses are 
not the source of abusive email.

Regards,
-sm

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 04 Apr 2008 10:18:32 -0400

> document to provide legal advice.

Already changed.

> not the source of abusive email.

I like where that's going, I'll run with that for the next iteration.  I 
also will add (perhaps paraphrased) Seth's "This is often (but 
inaccurately) referred to as "collateral damage"".  That would neatly 
connect that section to the concept "colateral damage", but at the same 
time negate much of the (invalid) societal baggage inherent with the term.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: SM <[email-masked]>
Date: Fri, 04 Apr 2008 15:30:30 -0700

>time negate much of the (invalid) societal baggage inherent with the term.

I'll skip the discussion of whether the collateral damage is accurate 
or not by not using those words.  Suggested text is:

   Some DNSBLs have adopted a policy of listing a range of IP addresses under
   the control of a provider even though some of those IP addresses are not the
   source of abusive email.  The theory is that customers impacted by such a
   listing will apply pressure on the provider to take action against 
the customer
   which is the source of the abusive email.  Such a DNSBL policy is highly
   controversial, and discussion of its appropriateness is beyond the scope of
   this document.

   A DNSBL MUST specify the scope of the listing and disclose whether 
it may include
   an IP address which has not been identified as the source of abusive email.

Regards,
-sm

---

From: John Levine <[email-masked]>
Date: 5 Apr 2008 01:25:44 -0000

>   it may include an IP address which has not been identified as the
>   source of abusive email.

That's not quite it.  Most of the addresses in the Spamhaus PBL have
never sent spam, after all.

Personally, I think that collateral damage is a reasonable term, and
all of the dnsbls don't block mail weasel wording is counterproductive,
since we're talking about policy, not code.

R's,
John

---

From: Seth <[email-masked]>
Date: Fri, 4 Apr 2008 22:11:30 -0400 (EDT)

>   the control of a provider even though some of those IP addresses are not the

Spot the hidden assumptions.

They aren't true.

>  The theory is that customers impacted by such a
>   which is the source of the abusive email.

Whose theory is that?

>  Such a DNSBL policy is highly

So why bring it up in the first place?

>   an IP address which has not been identified as the source of abusive email.

How is that not part of the listing criteria in the first place?

"This DNSBL lists all IP addresses if the number of spam-emitting IPs
in their /24 exceeds 10."  To anybody who can read, that discloses
whether it may include an IP address that didn't emit spam.

Seth

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 04 Apr 2008 22:43:51 -0400

> never sent spam, after all.

Or listings of fastflux NSes.  They're not emitting email either, but 
they are abusive/related to email spam.

So it's more like "related to email abuse, or highly probable".

I mostly like the tone of SM's suggested wording, I'll try it with some 
modifications.

> since we're talking about policy, not code.

Collateral damage is a loaded term, and carries a lot of baggage from 
outside of the Internet.  I think we have to both mention it (so that 
some people know what we're talking about), but at the same time try to 
partially neutralize the extraneous knee-jerk reaction.

Remember the purpose: we're trying to get the DNSBL operator to provide 
an indicator of aggressiveness (or rabidity if you prefer...).

Not just about adding IPs that aren't abusive in and of themselves, but 
also to what degree they will list IPs that are mixed abuse/non-abuse.

So, not only do we try to get DNSBL users to know about, for example, 
blanket listings of ranges with snowshoing bad bits and some hostages, 
we also want them to have an idea of whether they'd block gmail/yahoo 
etc, because they're mixed sources.

I have two pieces to do before reissuing the BCP.  One is the above, the 
other is domain oriented DNSBL testing.

I rather like dnsbl.test.  What's the reason for including a dot? 
Leaving the dot out reduces the probability (for the most part) with 
colliding with a innocuous link.

Doug's suggestion (inserting underscores) is both good and bad for the 
same reason.  Underscores are illegal in DNS names, hence a good idea. 
But, if they're illegal, the test wouldn't work either.

Theoretically.

Yes, I know that most resolvers/DNS servers handle them just fine, but 
it's probably a bad idea to explicitly mandate a practise in violation 
of existing RFC.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: John Levine <[email-masked]>
Date: 5 Apr 2008 03:07:35 -0000

>colliding with a innocuous link.

RFC 3330 says there'll never be a "test" TLD.  It makes no promises
about a "dnsbltest" TLD, although I agree it's pretty unlikely.

>But, if they're illegal, the test wouldn't work either.

Actually, they're legal in DNS names, just not in host names.  That's
why SRV records and DKIM use _foo components, to be sure they can't
accidentally collide with host names.  For once, I agree with Doug's
suggestion.

R's,
John

---

From: SM <[email-masked]>
Date: Sat, 05 Apr 2008 01:24:01 -0700

>since we're talking about policy, not code.

I think so too but some people commented that it was inaccurate.

>Spot the hidden assumptions.

See above.

>Whose theory is that?

That's what the text in draft-01 says.

>So why bring it up in the first place?

I reworded that section.  I'm not going to argue for or against it.

>whether it may include an IP address that didn't emit spam.

I don't see what the problem is then as the above discloses the scope.

Regards,
-sm

---

From: Rich Kulawiec <[email-masked]>
Date: Sat, 5 Apr 2008 08:18:38 -0400

> partially neutralize the extraneous knee-jerk reaction.

Let me add two other things to this that haven't come up before.

1. "Collateral damage" is a Vietnam war-era euphemism for unintended damage
during a military operation.  I'm guessing that's the baggage you might have
been referring to.  DNSBL listings or their usage are incapable of causing any
damage: they don't conduct DoS attacks, for example.

2. [Most] DNSBL listings larger than a single IP don't have "collateral" effects.
Here's what I mean: suppose spam is received from 1.2.3.42.  Suppose a
DNSBL operator queries the network owner and find that 1.2.3.0/24 is owned
by Foo Networks, and decides to list all of it.  This affects (obviously)
whoever is at 1.2.3.43.  But is it a collateral effect?  No.  Whoever is
at 1.2.3.43 is not the subject of the listing: Foo Networks is.  There's
nothing unintentional about it, there's nothing misdirected about it, it's
not an escalation, it's just an implementation of a particular hypothetical
DNSBL policy which says "if we receive spam from your network, we will list
all of it".  There's nothing wrong or right with that policy: it's just one
choice among many.

Now if (in this example) the DNSBL operator made a typographical error (thus
bringing into play the "unintentional" factor) and listed 1.2.3.0/23 instead
of 1.2.3.0/24 (thus bringing into play the concept of effects extending beyond
the bounds they were intended to) then THAT would be a collateral effect.
It's still not damage of course, but it would at least qualify as "collateral"
in this particular sense of the term.

---Rsk

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 5 Apr 2008 15:42:34 +0200

Seth wrote:

>> The theory is that customers impacted by such a listing will apply
>> pressure on the provider to take action against the customer which
>> is the source of the abusive email.
 
> Whose theory is that?

It's implied.  If IPv4 aaa.bbb.ccc.ddd is the source of net abuse,
and a DNSBL recording it lists more than only this IPv4, then it
has a theory why listing aaa.bbb.ccc.* is better than say listing
*.bbb.ccc.ddd.  And that theory might be wrong if it is based on
obsolete concepts of classes or assumptions about /24 ranges.

>> Such a DNSBL policy is highly controversial, and discussion of
>> its appropriateness is beyond the scope of this document.
 
> So why bring it up in the first place?

Maybe an explanation why simply progressing from listing the IPv4,
then the /31, and so on, is an oversimplification and at some
point doomed, is better.  With a note that "some point" can be
smaller or bigger than /24 depending on the IPv4.

> "This DNSBL lists all IP addresses if the number of spam-emitting
> IPs in their /24 exceeds 10."  To anybody who can read, that 
> discloses whether it may include an IP address that didn't emit
> spam.

That misses the point, when the assumption that all IPs in a /24 
are administratively related, is dubious.  Readers of a listing
policy could arrive at arbitrary conclusions based on the wrong
assumption.  

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 5 Apr 2008 16:10:51 +0200

> I rather like dnsbl.test.  What's the reason for including a dot? 

"test" is a pseudo-TLD reserved for tests in RFC 2606.  "dnsbltest"
could be the next TLD ICANN will create, after "xxx" presumably.

> Underscores are illegal in DNS names, hence a good idea.

All octets from 0x00 to 0xFF are legal in DNS names.  ITYM illegal
in a label of a host, because underscore is not LDH (letter, digit,
hyphen).  A DNSBL test entry is not really a host.
 
> But, if they're illegal, the test wouldn't work either.

Nslookup can do underscores without trouble, gethostbyname can do,
what do you have in mind where underscore wouldn't work ?
 
> it's probably a bad idea to explicitly mandate a practise in 
> violation of existing RFC.

Underscores only violate existing RFCs if you'd claim that it is 
valid in host names used for say SMTP.  Avoiding such host names
is the idea of Doug's proposal, there are several RFCs and drafts
using the same idea.

For the "C" in BCP 127.0.0.2 is good.  If you are determined to
make up new stuff _dnsbl.test or similar is in theory fine.  I've
no idea how you will get hundreds of DNSBLs to adopt it.

 Frank

---

From: Seth <[email-masked]>
Date: Sat, 5 Apr 2008 12:48:55 -0400 (EDT)

> It's implied.

It's implied that there _is_ a theory.

>  If IPv4 aaa.bbb.ccc.ddd is the source of net abuse,

Maybe the theory is "IP addresses owned by entities that don't kick
off spammers are more likely to accumulate spammers than those owned
by entities that do kick off spammers.  Therefore, since <company>
didn't kick off the spammer at aaa.bbb.ccc.ddd, its other addresses
are more likely to have spammers than most IP addresses (Bayes
Theorem)."

> smaller or bigger than /24 depending on the IPv4.

Maybe we shouldn't get into claiming that some policies are better
than others, and only specify that the policy should be explicit and
followed.

> are administratively related, is dubious.

That assumption might not be correct.  But it's irrelevant: it's the
policy stated, that's all.  I think DNSBLs should be allowed to have
whatever policies they want.  It's up to the user of the DNSBL to
decide whether it has policies he wants to apply.

>  Readers of a listing policy could arrive at arbitrary conclusions
> based on the wrong assumption.

All anyone can do is tell the truth.  People will draw arbitrary
incorrect conclusions from anything.

Seth

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 5 Apr 2008 19:40:58 +0200

> are more likely to have spammers than most IP addresses (Bayes

IMO that's in essence what SM proposed, and from your questions my
impression was that you don't like to talk about this theory in the
BCP.  It's a good theory, and noting some known traps and pitfalls
with this theory for naive readers makes sense.

> than others, and only specify that the policy should be explicit
> and followed.

The "explicit and followed" is already covered in the draft, but
some limitations of /32, /31, are not obvious.  After all users
would get really no spam if they reach /0.  If that's not what
they'd do in their own BL they need to check how the policy of a
third party is "better" for what they want.  

I just answered a help request from somebody with no idea what an
IP is.  The BCP should have some things clear, if users are then
determined to reinvent say BLARS they should know the fine print.

> I think DNSBLs should be allowed to have whatever policies they
> want.  It's up to the user of the DNSBL to decide whether it
> has policies he wants to apply.

IMO it is the job of the BCP to allow users an informed decision.

E.g. a list mapping IPs to country codes is a cute idea, but can
be also a way to shoot into your foot if you use it to block mail
or firewall IPs.  Some problems aren't obvious.  The BCP could
list the well-known problems, which caused havoc in the past for
naive users.  

 Frank

---

From: "Chris Lewis" <[email-masked]>
Date: Sat, 05 Apr 2008 15:27:29 -0400

Rich Kulawiec wrote:
> been referring to.

Yup.

> DNSBL listings or their usage are incapable of causing any

Simplistically, listing something for spam when you know it will result 
in non-spam being affected is both collateral and damage.

I think you're saying it's moot, because if the DNSBL operator does make 
a clear statement of the degree that a listing may encompass non-abusive 
behaviour (the collateral), the collateral consequences are knowingly 
accepted and applied by the DNSBL user (hence it isn't collateral), who 
in most cases has the absolute right to accept/non-accept anything for 
any reason they choose - it can't be damage because the sender doesn't 
have a right to trespass on the receiver's property if the receiver says no.

I believe that the basic notion is generally right.

Rather than argue any of that in the BCP, the main thrust on the part of 
the BCP is making _sure_ the DNSBL operator makes the criteria clear. 
If the operator doesn't make it clear, the true criteria is unknown to 
the DNSBL user.  Which is a recipe for bad outcomes, justified or otherwise.

Truth in advertising is the main thrust of the BCP.  Both senders and 
receivers get justifiably PO'd when they're not, and that happening is 
bad not only for the DNSBL operators but the industry as a whole.

> whoever is at 1.2.3.43.  But is it a collateral effect?  No.

Perhaps yes, perhaps no, but I contend it's entirely irrelevant. That's 
the point, and why I think that discussing the rightness or wrongness of 
the terminology is entirely moot. The real question is whether the DNSBL 
operator say what the policy is and stick to it.  Truth in advertising 
again.

If the SBL abruptly replaced their policy with Al's toy "any IP with a 7 
in it" experiment without changing the documented criteria or adequate 
(whatever that might be) prior notice, you'd be pissed too.

Let me be absolutely clear - I don't think that very many DNSBLs _ever_ 
violated "truth in advertising" to any appreciable extent (except for 
one very old infamous case, and perhaps arguably when OSIRUS listed the 
world without warning).  Not even SPEWS did.

The benefit to things like SPEWS from the BCP in this area is simply to 
point out to the DNSBL operator how important it is to make the 
breadth-of-listing criteria as clear as possible.  I think SPEWS could 
have documented it better, but it was there.

Think goober factor.  Some dimbulb starts using, say, Seth's "no 
primes".  It does bad things.  The dimbulb is, well, dim, gets angry 
blames Seth.  Ignorant journalists make it a cause-celebre.  Media 
splash.  Seth gets inundated with other ignorant journalists asking him 
"how long have you been an anti-american/anti-commerce terrorist?".  EFF 
gets on their podium, senior managers at ISPs/major corporates start the 
inquisition of their email administrators about "eradicating DNSBL 
agents of terror" blah blah blah.

Wouldn't it be better for Seth to have published on his web site "this 
DNSBL is a joke.  Don't use it.  Only dimbulbs and idiots would even 
dream of using it".  Even (most) ignorant journalists will eventually 
get it.

[Seth's prime number DNSBL has been a fixture of DNSBL discussions for 
years.  I don't know whether he actually publishes one, and how it's 
documented....]

The bit I will write will be somewhat like SM's.  Not oriented as a 
statement on "collateral damage", but a statement about clarity of 
criteria for listing breadth.  And a much deprecated (perhaps "commonly 
misrepresented as") reference to "collateral damage" so nobody can claim 
we ignored the issue.  Having the BCP pop up when someone enters "DNSBL 
collateral damage" into google is also useful ;-)
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: der Mouse <[email-masked]>
Date: Sun, 6 Apr 2008 10:45:28 -0400 (EDT)

> Doug's suggestion (inserting underscores) is both good and bad for
> the same reason.  Underscores are illegal in DNS names, hence a good
> idea.  But, if they're illegal, the test wouldn't work either.

> Yes, I know that most resolvers/DNS servers handle them just fine,
> but it's probably a bad idea to explicitly mandate a practise in

All 256 octet values are legal in DNS names (go read the DNS RFCs).
Use of octets outside a relatively restricted set is discouraged in DNS
names which name hosts (the exact set varies depending on which
reference you read).  Some protocols break in the presence of some of
the discouraged octets (ssh, for example, has no way to represent a dot
which is part of a name component rather than being a component
separator, though it doesn't use DNS names in the protocol for much).
Others break implementations even if they don't break protocols (0x00,
for example, will break a whole lot of implementations).  And there are
a few protocols, perhaps most notably SMTP, which actually specify
restrictions on the octets that may appear in DNS names used with them.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Rich Kulawiec <[email-masked]>
Date: Sun, 6 Apr 2008 11:05:36 -0400

On Sat, Apr 05, 2008 at 03:27:29PM -0400, Chris Lewis wrote:
[ a bunch of well-thought-out things ]

I think I'm in close-to-complete, maybe even complete agreement with this.
So I'm going to sit back and wait for the next draft.

---Rsk

---

From: "Mark E. Mallett" <[email-masked]>
Date: Sun, 6 Apr 2008 13:30:59 -0400

> colliding with a innocuous link.

For a test name, I wonder if the base name could be used.  e.g., query
multi.surbl.org for a 127.0.0.2 A record .  This is completely out of
band in the sense that you wouldn't accidentally trigger it because of
something in a message body.  OTOH it might add other difficulties such
as when having the base name point to a website.  Sorry if this has
already been brought up; I indeed have read everything, but probably
haven't memorized it all.

Another thought (not out-of-band, but also not likely to be hit)
is the name '.' .. e.g :
 
   %  host '\..geezer.org'
   \..geezer.org has address 127.0.0.2

But for something simple,  just 'test' doesn't seem all that bad.

mm

---

From: John Levine <[email-masked]>
Date: 6 Apr 2008 18:05:35 -0000

>as when having the base name point to a website.

The base name often points to a web site.  That would be a problem.

R's,
John

---

From: "Mark E. Mallett" <[email-masked]>
Date: Sun, 6 Apr 2008 14:24:04 -0400

> The base name often points to a web site.  That would be a problem.

FWIW I spot-checked some of the ones I know about, as I was writing that
note, and came up empty.  But lack of evidence doesn't really mean
anything, and thus I made that note about a website.

At any rate, 'test' does seem good.  From the sidelines.

mm

---

From: "Chris Lewis" <[email-masked]>
Date: Sun, 06 Apr 2008 17:39:29 -0400

> anything, and thus I made that note about a website.

cbl.abuseat.org.

> At any rate, 'test' does seem good.  From the sidelines.

I'm tending towards some combination of dsnbl.test and underscores in 
the "dnsbl" part.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Mark E. Mallett" <[email-masked]>
Date: Sun, 6 Apr 2008 19:40:54 -0400

> > anything, and thus I made that note about a website.

I didn't know that that listed domains.  But even if not, it does
make the point, thanks.

mm

---

From: Matt Sergeant <[email-masked]>
Date: Sun, 6 Apr 2008 21:12:10 -0400

>> anything, and thus I made that note about a website.

Which violates the BCP fwiw. :-)

Matt.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 8 Apr 2008 13:44:17 -0400

On Mon, Mar 31, 2008 at 05:44:13PM -0400, Seth wrote:
> For that matter, who is the "network provider" for a domain, in a
> domain list?  The IP address of the domain might be in the space of
> numerous providers, and change rapidly.  Similarly for the DNS server.

I concur with Seth on this point (among others).  There is little
reason to inform a known bad-actor network provider that it's a known
bad-actor network provider.  (a) It aready knows and (b) doing so will
assist it in evading detection.

> The listing is its own notification.

I also strongly concur on this point.  Given the volume of listings
carried by some DNSBLs, attempts to inform network providers (or domain
registrants) would result in spam or similar abuse.

Network providers and domain registrants who care about whether or not
they're listed have many options: querying DNSBLs, using any of the
web sites that have sprung up which query multiple DNBSLs, or using
tools like "blq" that can do the same.

---Rsk

---

From: Seth <[email-masked]>
Date: Tue, 8 Apr 2008 13:55:29 -0400 (EDT)

> registrants) would result in spam or similar abuse.

I suppose there ought to be support for queries of the type "Please
show all listings in this IP range" to make like easier for network
providers to search.  But even a /8 searching once/day shouldn't be a
noticeable hit to a DNSBL important enough for them to care about
(provided they space out the requests).

Seth

---

From: "J D Falk" <[email-masked]>
Date: Tue, 8 Apr 2008 14:39:36 -0400

Seth wrote:

> providers to search.

When network providers want to know this, they tend to email the DNSBL
operator and ask -- but that kind of interaction appears to be out of
scope for this document.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 08 Apr 2008 22:38:58 -0400

> operator and ask -- but that kind of interaction appears to be out of

There's a little bit being done in this area - a few (Spamcop I think, 
and one or two more) DNSBLs provide a method by which admin can register 
(perhaps one or more ranges etc) and get periodically email-notified of 
listings.

That would be a nice-to-have for particular types of listings, but 
there's not enough "current practise" to be common enough to be "best".

Note, however, there are alternatives that don't require much of the 
DNSBL operator:

The "are you listed?" monitoring systems will query a set of IPs you 
give them, and notify you of DNSBL hits.  Habeus runs one of these. 
Virtually all of those do this for a fee, and unfortunately, monitoring 
more than a handful of IPs this way is prohibitively expensive - ISPs 
trying to get notification on whole pools are out of luck.

Meng's Karmasphere I _think_ offers this service, and it may not charge 
a fee.

Any DNSBL that does zone downloads can be downloaded and scanned using 
grepcidr.  I've suggested that in a couple of cases to ISPs trying to 
proactively fix customers in large lists like the CBL where doing 
queries is impractical.  For those going to the effort of fixing 
customers that way find that it works fairly well.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg