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 <dotis(_at_)mail-abuse(_dot_)org>
Sent: April 03, 2008 6:15 PM
To: Anti-Spam Research Group - IRTF <asrg(_at_)ietf(_dot_)org>
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
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg