Subject: Re: [Asrg] draft-irtf-asrg-bcp-blacklists-01 March 24, 2008

From: Al Iverson <[email-masked]>
Date: Thu, 3 Apr 2008 20:47:20 -0500

Wrong -- MAPS did not notify the network provider in many cases. This was never RSS policy back then, for example. Nor did MAPS go to great lengths to identify network providers for many RBL listings. Sorry, Doug, I was there before you and I personally observed it.

Of course, even if correct, this is still out of scope, as BLs are not limited to IPs.

Regards,
Al
The original RSS policy guy-----Original Message-----
From: Douglas Otis <[email-masked]>
Sent: April 03, 2008 6:15 PM
To: Anti-Spam Research Group - IRTF <[email-masked]>
Subject: Re: [Asrg] draft-irtf-asrg-bcp-blacklists-01 March 24, 2008

On Apr 1, 2008, at 8:48 AM, Chris Lewis wrote:
>> Determining the network provider helps establish their reputation,  
>> which should represent a significant factor in whether their  
>> 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.

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

[The entire original message is not included]
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Douglas Otis <[email-masked]>
Date: Thu, 3 Apr 2008 19:38:12 -0700

On Apr 3, 2008, at 6:47 PM, Al Iverson wrote:

> Wrong -- MAPS did not notify the network provider in many cases.  
> This was never RSS policy back then, for example. Nor did MAPS go to  
> great lengths to identify network providers for many RBL listings.  
> Sorry, Doug, I was there before you and I personally observed it.

With respect to DUL, RSS, and OPS, you would be right.  RSS and OPS  
represent the difference between automated and manually generated  
lists.  This was the reason to differentiate between automatic and  
manually generated lists.  Of course, this draft might suggest re- 
scanning these types of list at some interval.  Automatic expiration  
would be hard to justify, especially due to their small size, and the  
extremely low number of complaints they generate.  Tony, not knowing  
about the automatic retest request, suggests this should function  
should have been more prominent.

Statements on network provider reputation was in response to a comment  
made by Chris Lewis that _no_ list currently is based upon network  
provider reputation.  While AS reports may have been in the hands of  
only a few, this does not mean they were not applied.  Be assured,  
this currently is the case.

> Of course, even if correct, this is still out of scope, as BLs are  

Please review the recommended changes.  None of the changes assume a  
listing is based upon the IP address.  These changes actually mitigate  
this assumption regarding the use of IP addresses such as "collateral  
damage" or automatic removal being a simple matter of adding back a  
few more IP addresses.   The error in this regard is found in the  
current draft.  The changes being recommended move in the direction  
you suggest.

-Doug

---

From: Andrew D Kirch <[email-masked]>
Date: Thu, 03 Apr 2008 23:22:21 -0400

> current draft.  The changes being recommended move in the direction  
Doug,
Ok, honest to God, I've been reading your proposals for the better part 
of a week and I still have no earthly idea what your advocating, who's 
using it currently, or how it's going to either make DNSBL's better, or 
fight spam.  Because of this confusion, I requested that several days 
ago someone put together a second draft that could be approved later as 
an optional enhancement to this draft so that I could review it 
separately.  While there's been some sort of idea bandied around, I am 
not clear on what this idea is, nor on how it would be described in an 
IETF draft.  Would you please put something like this together so that 
we can review it, rather than arguing about how wonderful it is, but in 
a manner that seems to me to provide little substance?  I promise I'll 
read the draft as soon as it's out, just like I've read all the others.  
I'll also be happy to offer comments and criticism, and if it makes 
sense the AHBL will implement it, and help push it forward, but right 
now I don't know what you're arguing for, I don't know whether it's even 
germane to this draft, so I'm asking such that I can review a clearly 
worded definition of what you want, please draft it.

Andrew
AHBL.org

---

From: "Al Iverson" <[email-masked]>
Date: Thu, 3 Apr 2008 22:26:10 -0500

On Thu, Apr 3, 2008 at 9:38 PM, Douglas Otis <[email-masked]> wrote:
>  With respect to DUL, RSS, and OPS, you would be right.

And RBL, too. The day-to-day handlers of RBL listings at that time (of
which I was one) were not doing the kind of fancy "roll it up by the
AS and notify that person" notifications that you're ultimately
leading toward here. In many/all cases, first level responsible party
was the first or only notification. This would often be the hosted
entity, not the network provider.

There may have been *some* RBL listings where things worked this way,
but not all, and probably not even most.

BTW this is such a weird conversation. Since we have Trend Micro as
the succsesor entity to a company who repurposed a technical term
"black-hole" for a service mark applied to a very specific commercial
reputation mechanism.......

...maybe the RBL doesn't fit within the scope of this BCP whatsoever.
RBL practice doesn't represent common blacklist practice. It doesn't
even look like other BLs, on nearly every conceivable level.

It's a bit like selling root beer based on the premise that it's
old-timey because it used to be made on Grampa's farm. Even though,
nowadays, it comes from a giant, commercial factory.

Am I alone in standing outside, looking at this thing, and thinking,
"No longer a duck"? I'm not hearing it quack. Why does the discussion
keep coming back to how we need to make all the actual ducks look like
your thing, which might have been a duck eight years ago, but, even
thoug we seemingly do NOT have a small aquatic bird of the family
anatidae on our hands.

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: "Al Iverson" <[email-masked]>
Date: Thu, 3 Apr 2008 22:34:21 -0500

On 4/3/08, Al Iverson <[email-masked]> wrote:

Sorry, typo'd. Meant:

Am I alone in standing outside, looking at this thing, and thinking,
"No longer a duck"? I'm not hearing it quack. Why does the discussion
keep coming back to how we need to make all the actual ducks look like
your thing, which might have been a duck eight years ago, but,
nowadays, doesn't like a duck. We seemingly do NOT have a small
aquatic bird of the family anatidae on our hands.

Regards

---

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

Al Iverson wrote:
> And RBL, too.

I think the idea of adding bits and pieces about prior notification, 
identification of network providers, and limiting removal requests to 
network providers for the purposes of the BCP has been thoroughly laid 
to rest.  As such, what MAPS did[not]/does[not] do in those areas is 
entirely moot.

Similarly, (and I'm as guilty as anyone else), it's a bad idea to get 
too close to explicitly making suppositions based on law, I've yanked 
them all (I think), and I don't think any purpose is served by keeping 
that conversation in the BCP thread either.

I'd like to keep this discussion directly on the content of the BCP.

Thanks.