Subject: [Asrg] New draft draft-irtf-asrg-bcp-blacklists-01.txt

From: John Levine <[email-masked]>
Date: Mon, 24 Mar 2008 13:53:36 -0400 (EDT)

We finally have a revised draft of the BCP for blacklists.  Take a look 
and see what if anything merits changes.

Keep in mind that this is a separate document from the one that describes 
how blacklists work.  Both are linked from the wiki 
http://wiki.asrg.sp.am.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---------- Forwarded message ----------
Date: Mon, 24 Mar 2008 17:18:00 +0000 (UTC)
From: [email-masked]
To: [email-masked]
Newsgroups: iecc.lists.ietf
Subject: I-D Action: draft-irtf-asrg-bcp-blacklists-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

 	Title           : Guidelines for Management of DNS Blacklists for Email
 	Author(s)       : C. Lewis, M. Sergeant
 	Filename        : draft-irtf-asrg-bcp-blacklists-01.txt
 	Pages           : 14
 	Date            : 2008-03-24

The rise of spam and other anti-social behavior on the Internet has
led to the creation of shared blacklists and whitelists of IP
addresses or domains.  This memo discusses guidelines for management
of public DNS blacklists (DNSBLs).

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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-irtf-asrg-bcp-blacklists-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 25 Mar 2008 23:47:39 +0800

> and see what if anything merits changes.

As a newbie, I post my opinion in the hope that it can be a useful feedback.

|                         a private DNSBL is used solely by an
|   organization for its own use and the data is not made available
|   publicly.

I would drop "solely". Even if the data cannot be looked up, there may be
forwarding agreements. For example, Hotmail allows postmasters to subscribe
in order to be informed about spam reports related to their IP addresses.

|   This document is also intended to provide guidance to DNSBL
|   administrators so that [...]

Why "also", isn't it the primary purpose? (I'd say there is no substantial
difference between DNSBL operators and administrators.) Rather, I would
mention there that the document also provides guidance for DNSBLs users,
in view of the section that follows.

BTW, a section is missing about end users' role in reacting to bounces.

|   6.   Are web pages for removal requirements accessible and working
|        properly?

That they are working properly is too difficult to assess, for a user.

I would add two points to that list:

* If at all possible, system admins should allow their customers to configure
   which DNSBLs they want to disable for their mail, if any.

* System admins should make sure they don't lock out their own customers. (This
   sounds obvious, but since the corresponding recommendation is made for DNSBL
   admins...)

| 2.2.2.  A Direct Non-Public Way to Request Removal SHOULD Be Available

Some DNSBLs mention that removal requests should come from the person in
charge. Who is that? IMHO, the person in charge for an IP address is the
one mentioned in the corresponding whois record at the relevant RIR. It may
be worth establishing (confirming or denying) that point.

BTW, is it a good practice to send listing/removal notices to the relevant
postmaster or abuse addresses?

| 2.2.3.  Removals SHOULD Be Prompt
|
|    Requests for removal SHOULD be honored without question. [...]

That section apparently assumes more about a DNSBL's policy than the rest of
the BCP. For example, a previous section considers listings associated with
geographic information. Aren't there valid exceptions for automatic delisting?

| 2.2.4.  SHOULD Have Similar Criteria for Listing and Delisting

"Criteria for Listing and Delisting SHOULD be symmetrical." Sounds better?

| 3.4.  Shutdowns MUST Be Done in a Graceful Fashion

Since it has been mentioned that commercial DNSBLs exist, it may make sense
to recommend that they use adequate renewal methods. (For example, Trend Micro
is still missing a credit card based self-renewal web page.)

---

From: John Levine <[email-masked]>
Date: 25 Mar 2008 16:07:57 -0000

>As a newbie, I post my opinion in the hope that it can be a useful feedback.

Thanks for taking a look.

>in order to be informed about spam reports related to their IP addresses.

That's not a DNSBL, that's a feedback loop (FBL).  They're not related.

> I would mention there that the document also provides guidance for
>DNSBLs users, in view of the section that follows.

I'll defer to Chris, but I don't think that's the intention at all.
This is about how to run a DNSBL, not about how a user at some ISP
interacts with the people at his ISP who manage the mail.

>   which DNSBLs they want to disable for their mail, if any.

In my experience, although admins are hardly infallible, users tend to
make much worse decisions.  I cannot tell you how many inane arguments
I've had from users saying "you need to whitelist this IP" when
whatever the problem was had nothing to do with IP blacklisting.

>* System admins should make sure they don't lock out their own
>   customers. (This sounds obvious, but since the corresponding
>   recommendation is made for DNSBL admins...)

Not a bad thing to mention.  Eircom, the large Irish ISP, has exactly
this problem, a mail system that roaming users can't use due to their
sloppy use of DNSBLs.

>be worth establishing (confirming or denying) that point.

That is much more true in some cases than others.  In ARIN territory,
it's fairly rare for space to be SWIPed down to the individual network
customer.

>geographic information. Aren't there valid exceptions for automatic delisting?

Good point, worth a little clarification.

>"Criteria for Listing and Delisting SHOULD be symmetrical." Sounds better?

But it's not right.  In particular, DNSBLs that list due to observed
behavior, e.g. hitting spamtraps, usually stop paying attention to
delist requests for IPs that keep relisting themselves.

>is still missing a credit card based self-renewal web page.)

Way out of scope here.  If your Trend subscription expires, that's not the
same thing as the list being shut down.

R's,
John

---

From: John Levine <[email-masked]>
Date: 25 Mar 2008 16:07:57 -0000

R's,
John

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 25 Mar 2008 12:47:57 -0400

> That's not a DNSBL, that's a feedback loop (FBL).  They're not related.

Still, dropping "solely" isn't a bad idea.  I keep thinking "fish, yum" ;-)

> interacts with the people at his ISP who manage the mail.

The target is DNSBL operators and DNSBL users - DNSBL users are 
typically mail server admins - or at least, that's how we're intending 
it.  If it's not clear, we can fix that.  I consider end-users twiddling 
their own DNSBLs to be out of scope.  Does this need to be clarified?

> whatever the problem was had nothing to do with IP blacklisting.

That is site policy.  Out of scope.

As for reacting to rejections - I pondered adding a fairly general 
section on "filtering BCP" (eg: reject not bounce etc), which could 
include how an end user reacts to a rejection message, but that's a 
whole new can of worms, and I'd just like to get _this_ BCP done and out 
of the way before attempting something like that.

Now that I finally know how to do RFC formatting myself, perhaps I'll do 
more of these things... ;-)

> this problem, a mail system that roaming users can't use due to their

Yup.  Should put in something specifically about "READ the terms and 
conditions and suitability for a given purpose.  Eg: don't block your 
own users with a PBL".

> it's fairly rare for space to be SWIPed down to the individual network

I think it better to leave that up to the DNSBL instructions page.

It certainly isn't advisable in general to hit postmaster@DNSBL etc. 
They may be completely different entities not related to each other. 
Might be worth saying "read the contact instructions dammit!" ;-)

> Good point, worth a little clarification.

Will take that under advisement ;-)

> delist requests for IPs that keep relisting themselves.

We're trying to avoid pure symmetry to give some room for DNSBLs to 
offer additional instructions not entirely symmetrical with the given 
listing, but at the same time, try to heavily discourage the extremes 
(DNSBLs acting like a protection racket).

> same thing as the list being shut down.

Agreed.

---

From: "David Nicol" <[email-masked]>
Date: Tue, 25 Mar 2008 12:38:02 -0500

>  their own DNSBLs to be out of scope.  Does this need to be clarified?

you never know who is going to suddenly become a mail server admin.

I would think a good imaginary reader for this document would be a
literature professor who had a volunteer geek set up a mailing list system
on their home computer which has a dynamic IP and through the magic
of dyndns.org, the whole system works just fine for several years until
one day, after an ice storm, Dr. Nadagik's box loses the DHCP lottery
and is inconvenienced by drawing a nomber formerly occupied by
a neighbor with poor download hygiene and a tendency to have his decrepit
equipment compromised by operators of global anonymous botnets.

Dr. Nadagik's IT staff is long gone, and she decides to figure out what
is going on, as several of the presitigious members of her mailnig list are
no longer getting their messages even though they are still subscribed,
and the list server logs, which she has never actually had occasion to
read before now -- have  some new text in them mentioning a numbered
RFC, whatever that is.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "J D Falk" <[email-masked]>
Date: Tue, 25 Mar 2008 14:24:40 -0400

David Nicol wrote:

> literature professor who had a volunteer geek set up a mailing list
> system on their home computer which has a dynamic IP and through the
> magic of dyndns.org, the whole system works just fine for several
> years until one day, after an ice storm, Dr. Nadagik's box loses the
> DHCP lottery and is inconvenienced by drawing a nomber formerly
> occupied by a neighbor with poor download hygiene and a tendency to
> have his decrepit equipment compromised by operators of global
> anonymous botnets.

Oh, woe betide the poor server whose DHCP, after failure, doth return
askew!  Hast thou so quickly dismissed thy geekly intern, and through
forgetful folly neglect to request that full documentation be laid upon
thy hand?  And now, poor fool, finding much email rejected through past
actions solely of thy neighbor, seek you enlightenment from this poor
RFC?  'Tis but feeble illumination ye shall find here, alas, for 'tis
solely through pedantry and endless argumentation were such as this
writ.  Another intern, methinks, must thou now seek -- and unto that
fresh and welcoming mind deliver such best practices as to make
dizziness ensue.

---

From: John Levine <[email-masked]>
Date: 25 Mar 2008 18:35:00 -0000

>fresh and welcoming mind deliver such best practices as to make

You understand, of course, that this means that now we're going to ask
you to rewrite the whole BCP.

R's,
John

---

From: John Levine <[email-masked]>
Date: 25 Mar 2008 18:35:00 -0000

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Tue, 25 Mar 2008 11:36:34 -0700

On Mar 25, 2008, at 9:47 AM, Chris Lewis wrote:

> offer additional instructions not entirely symmetrical with the  
> given listing, but at the same time, try to heavily discourage the  
> extremes (DNSBLs acting like a protection racket).

Some BL policies do not adhere to the dubious philosophy expressed in  
section 2.2.1  and  2.2.3.

2.2.1.  Listings SHOULD Be Temporary

2.2.3.  Removals SHOULD Be Prompt

Automatic de-listing can be highly counter productive in controlling  
IP address ranges previously producing substantial levels of abuse.   
Requiring owners of an address range to request de-listing establishes  
points of contact to better deal with likely events of future abuse.   
Automatic de-listing, from that standpoint, is less effective at  
curbing abuse.  Automatic de-listing also enables a range of IP  
addresses to operate individually over a detection and listing  
process, which may involve substantial review and owner notification.   
The possible use of owner notification is fully lacking from draft, as  
well as provider indemnification, which represents a different and  
perhaps more responsible means for dealing with abuse.  Automated  
detection and listing although conceptually attractive, is limited and  
often is gamed by abusers.

Sections 2.2.1 and 2.2.3 should be removed or changed to represent  
only one possible mode of operation.  Six months is not a "sensible  
maximum".  This period depends upon how the BL is administered and  
their internal policies.

>> same thing as the list being shut down.

The Trend process requires a P.O. and a contract for valid reasons not  
covered by this draft. : (

-Doug

---

From: "Al Iverson" <[email-masked]>
Date: Tue, 25 Mar 2008 15:28:27 -0400

>  Some BL policies do not adhere to the dubious philosophy expressed in

Could you elaborate upon the relevancy of that fact? I'm not seeing
why it matters.

>  points of contact to better deal with likely events of future abuse.

I think these should stand as is. I think they cover "it's not
suitable to remove your IP address at this time" eventualities just
fine.

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: "J D Falk" <[email-masked]>
Date: Tue, 25 Mar 2008 15:36:43 -0400

More seriously....

Should this document explain some of the differences between a manually
updated list and an automated/reputation-based list?

Suggested updates/changes to existing text are in square brackets:

Abstract

   The rise of spam and other anti-social behavior on the Internet has
   led to the creation of shared blacklists and whitelists of IP
   addresses or domains.  This memo discusses guidelines for management
   of public DNS blacklists (DNSBLs) [by the operators of such
blacklists,
   and may provide useful background for server administrators who use
   DNSBLs.  It is not intended to advise on the utility or effiacy of
   particular DNSBLs or the DNSBL concept in general, nor to assist end
   users with questions about spam.]

[ . . . ]

1.  Introduction

1.1.  DNS-Based Reputation Systems

   Due to the rising amount of spam and other forms of network abuse on
   the Internet, many community members and companies began to create
   and maintain DNS-based reputation systems ("DNSBL") of IP addresses
   and domains identified as problem sources of email.  These lists also
   have been known as blocklists[, or] blacklists.  These lists are
[generally] used
   for filtering email.  [

   ] DNSBLs [may be] either public or private.  A public
   DNSBL makes its data available to any party seeking information about
   data on the list, [while] a private DNSBL is used solely by an
   organization for its own use and the data is not made available
   publicly.  There are also commercial DNSBLs[, available for a fee.
   Furthermore, some are free yet require a fee for higher numbers of 
   queries.]

   The first publicly available DNSBL using the Domain Name System (DNS)
   for distributing reputation data about email senders emerged in 1997,
   shortly after spam became a problem for network operators and email
   administrators.  This pioneer DNSBL focused on identifying known spam
   sources situated at static [(unchanging}] IP addresses.  Due to the
broad adoption
   of this DNSBL, it had a devastating impact on [these] static spam
sources.
   Consequently, abusers found other methods for distributing their
spam[, ]
   such as relaying messages through unsecured email servers or flawed
   formmail scripts on web pages.  Additional DNSBLs were developed by
   others in order to address these changing tactics, and today more
   than 700 DNSBLs are in operation.

[ . . . ]

2.1.  Transparency

[ . . . ]

   In other words, be direct and honest and clear about the listing
   criteria, and make certain that only entries meeting the published
   criteria are added to the list.  For example, some DNSBL operators
   have been known to include ["]spite listings["] in the lists they
   administer[ -- listings of IP addresses or domain names associated
   with someone who has insulted them, rather than actually violating
   the published criteria for inclusion in the list].  There is nothing
inherently wrong with this practice so
   long as it is clearly disclosed.  For example, a DNSBL described as
   listing open relays only MUST NOT include IP addresses for any other
   reason.  This transparency principle does not require DNSBL
   administrators to disclose the precise algorithms and data involved
   in a listing[, but rather the intent behind choosing those algorithms
   and data].

[ . . . ]

3.3.  DNSBLs SHOULD Provide Operational Flags

   Most DNSBLs follow a convention of entries for IPs in 127.0.0.0/8 to
   provide online indication of whether the DNSBL is operational.  [In
   other words, the result of a DNS lookup will be in the range of
   127.0.0.1 through 127.0.0.255.]  Many
   DNSBLs arrange to have a query of 127.0.0.2 return an A record
   indicating that the IP is listed, and a query of 127.0.0.1 return no
   A record (NXDOMAIN).  When both of these indicators are present, this
   indicates that the DNSBL is functioning normally.  See [DNSBL-EMAIL].

   [Other results, such as 127.0.0.3, may have different meanings.]
This
   [o]perational flag usage and meaning SHOULD be published on the
DNSBL's
   web site.

   [Some mail systems are unable to differentiate between these various
   results or flags, however, so a public DNSBL MUST NOT include
   opposing or widely different meanings -- such as 127.0.0.23 for 
   "sends good mail" and 127.0.0.99 for "sends bad mail" -- within the
   same DNS zone.]

[ . . . ]

---

From: Matthias Leisi <[email-masked]>
Date: Tue, 25 Mar 2008 22:27:17 +0100

A couple of remarks from the perspective of an operator of a DNS-based
whitelist (dnswl.org), including some general remarks:

* Large portions of this document apply equally to black- and whitelist.
Therefore it may make sense to enlarge the scope to explictly cover
whitelists as well. The general notion of "DNS-Based Reputation Systems"
would profit even more if whitelists would be explicitly included.

* 2.2.1 Listings SHOULD be temporary: IMO this section should be dropped
- - it describes a certain policy which may or may not fit the purpose of
a particular DNSBL.

* 2.2.3 Removals SHOULD be prompt: Similar to the item above, automated
removals may or may not be a good idea. Considering an Spamhaus-SBL-type
list, this SHOULD for automated removals does not make much sense.

* 3.1 DNSBL Query Root Domain SHOULD be a subdomain: It should be
defined how best to differentiate multiple (possibly related) DNSBLs
under a common domain ("purposeA.dnsbl.example.com" and
"purposeB.dnsbl.example.com" vs. "dnsblA.example.com" and
"dnsblB.example.com").

* 3.2 DNSBLs SHOULD be Adequately Provisioned: For public use, that
should rather be a MUST. "Redundancy" should further be clarified
(number, net-topological location and vendor/versions of software).

* Addition to 3.2 and redundancy: nameservers should provide appropriate
glue records, possibly in different TLDs to protect against single-TLD
issues.

* 3.4 Shutdown: Add an item 5 warning against directing nameserver
lookups at some third-party unrelated to the DNSBL operation (eg an ISPs
nameserver), and noting that such behaviour is similar to inflicting a
dDoS).

* 3.5 Listing of special...: "MAY list loopback" vs. "MUST NOT list
127.0.0.1" - does this make sense?

* Proposal: 3.8 Protect against misconfiguration by users: Common types
of misconfigurations include

- - Using wrong (sub-) zones for querying (4.3.2.1.example.com instead of
4.3.2.1.dnsbl.example.com)
- - Downloading a local mirror of the data, but failing to set up the
local nameserver infrastructure appropriately, and thus keeping querying
public nameservers
- - Downloading a local mirror of the data, but misconfiguring the local
nameserver infrastructure to query a locally invented zone name
(4.3.2.1.dnsbl.local) at the public nameservers.
- - Misconfigured local nameservers to not do meaningful caching, thus
heavily increasing load on public nameservers.

To protect against such misconfiguration, DNSBL operators SHOULD make
efforts to contact administrative contacts to remedy the situation, but
SHOULD also prepare to take appropriate steps to protect the operative
infrastructure (ie, to block abusive users from causing further damage).

- -- Matthias

---

From: "J D Falk" <[email-masked]>
Date: Tue, 25 Mar 2008 17:34:58 -0400

> would profit even more if whitelists would be explicitly included.

Call it "DNS-Based Binary Reputation Systems," and I'd agree.  The full
range of reputation systems in use today is much too broad to fit into
DNS, or into this document.

> - - it describes a certain policy which may or may not fit the purpose
> of a particular DNSBL.

It fits most DNSBLs, though, as a best practice.

> * 2.2.3 Removals SHOULD be prompt: Similar to the item above,
> automated removals may or may not be a good idea. Considering an
> Spamhaus-SBL-type list, this SHOULD for automated removals does not
> make much sense.

Most DNSBLs aren't the Spamhaus SBL.  This is a best practice for just
about everything else.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 25 Mar 2008 14:42:36 -0700

On Mar 25, 2008, at 12:28 PM, Al Iverson wrote:

>> Some BL policies do not adhere to the dubious philosophy expressed  
>> in section 2.2.1  and  2.2.3.
>

This was expanded upon in text you deleted by stating not all BLs  
depend upon full list automation.  Some lists attempt to audit  
networks and provide notifications to afford opportunities to remedy  
issues.  Establishing co-operative relationships often involves time.   
The time expended means such efforts can easily be gamed, especially  
when de-listing is automatic at set intervals or acted upon  
automatically from any request.  Keep in mind, some organizations  
structure their BL services differently.  Some offer BLs run in the  
manner suggested by the current version of the draft and others do  
not.  Trend happens to do both.  The difference between these two  
approaches is rather dramatic in respect to abating UCEs.  Neither  
management style offers a perfect system.  Each offer a level of  
service better suited to a range of individual needs.  This draft  
wrongly assumes only one approach should be used, and that is simply  
wrong in many cases.  Each of these approaches benefits the Internet  
overall, but no one should assume that one approach is always better  
than the other in every case.

Justifying a listing and de-listing policy should consider all factors  
involved.  This draft concludes de-listing interval of 180 days is  
sensible without a basis to support the claim.  It is not enough to  
say this policy has been used by company X, Y or Z.  Control on  
behaviour is the result of many differing policies.  It would be wrong  
to conclude one approach is somehow better than another.  They all  
play different roles and serve different needs.  One size does not fit  
all.  It is a myth the solution to spam is simply a matter solved  
through automation and standardized policies.  It hard to explain just  
how wrong that perspective is.

>> Automatic de-listing can be highly counter productive in  
>> controlling IP address ranges previously producing substantial  
>> levels of abuse. Requiring owners of an address range to request de- 
>> listing establishes points of contact to better deal with likely  
>> events of future abuse.
>

It does not help the cause to have these "SHOULD" statements which, in  
the end, will likely prove highly counter productive.  While  
automation helps, it is not a complete solution, nor will automation  
ever be.  Automation can and is being gamed.

-Doug

---

From: SM <[email-masked]>
Date: Tue, 25 Mar 2008 14:53:26 -0700

>- - it describes a certain policy which may or may not fit the purpose of

It is better that listings be temporary as IP addresses can be 
reassigned.  There is nothing in that recommendation that prevents 
the operator from relisting the IP address.  Such a recommendation 
prompts the operator to review the listings for correctness.

>127.0.0.1" - does this make sense?

Yes.

Regards,
-sm

---

From: John Levine <[email-masked]>
Date: 25 Mar 2008 22:15:08 -0000

>- - it describes a certain policy which may or may not fit the purpose of

Perhaps, listings based on the observed behavior of the IP should be
temporary.  If it's listed because it sends spam, it may well stop
sending spam but if it's listed because it's DHCP space or because
it's in Korea, it won't.

>"purposeB.dnsbl.example.com" vs. "dnsblA.example.com" and

That's in the other document that describes the mechanics.  See the
ASRG Wiki for a copy of it.

>(number, net-topological location and vendor/versions of software).

This doesn't seem like the right place for a treatise on DNS ops.
Adequate should be adequate.

>glue records, possibly in different TLDs to protect against single-TLD

Ops again.

>of misconfigurations include

 way more boneheaded things than any of us can possible imagine.  Don't
see that this is a reasonable thing for people to ask, particularly if
a DNSBL gets a lot of use.  I can also report from experience that there
are plenty of places that misuse a DNSBL and are completely impossible
to contact or correct.

---

From: John Levine <[email-masked]>
Date: 25 Mar 2008 22:15:08 -0000

Ops again.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 25 Mar 2008 15:30:10 -0700

On Mar 25, 2008, at 2:53 PM, SM wrote:

>> * 2.2.1 Listings SHOULD be temporary: IMO this section should be  
>> dropped - - it describes a certain policy which may or may not fit  
>> the purpose of a particular DNSBL.
>

This ignores whether ownership of the address space changed.  In some  
cases, IP addresses can not be handled effectively on an individual  
basis when network stewardship proves ineffective.  This issue is  
evolving along with introduction of IPv6.  Let the games been?

>> 127.0.0.1" - does this make sense?

Agreed.  There also remains a small percentage of subscribers that  
query address octets in the wrong order.  Such problems may require  
specialized services to ensure proper subscriber configuration or just  
greater dependence on Darwin.  : )

-Doug

---

From: "Peter J. Holzer" <[email-masked]>
Date: Tue, 25 Mar 2008 23:42:33 +0100

> sending spam but if it's listed because it's DHCP space or because

Even that can change. I've seen netblocks move from one European country
to another (within the same provider), and I guess it isn't unusual for
a provider to change an netblock from fixed addresses to dynamic or vice
versa.

	hp

-- 
   _  | Peter J. Holzer    | It took a genius to create [TeX],
|_|_) | Sysadmin WSR       | and it takes a genius to maintain it.
| |   | [email-masked]         | That's not engineering, that's art.
__/   | http://www.hjp.at/ |	-- David Kastrup in comp.text.tex
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 26 Mar 2008 09:32:54 -0400

J D Falk wrote:
> dropped

> It fits most DNSBLs, though, as a best practice.

Aside from certain types of static DNSBLs, it's always best practise.
Don't forget the document explicitly says that listings can be 
extended/renewed.

> Most DNSBLs aren't the Spamhaus SBL.  This is a best practice for just

SBL removals are prompt.  Who said anything about automated?
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Matt Sergeant <[email-masked]>
Date: Wed, 26 Mar 2008 11:18:50 -0400

Douglas Otis wrote:
> not.  Trend happens to do both.

OK, so let me just clarify this - when you are listing a netblock (and 
communicating with the owner or whatever you do), you NEVER periodically 
re-check that netblock to make sure it hasn't changed hands or gone 
quiet or anything? It's just listed permanently until the heat death of 
the universe?

Or is it temporary after all?

And if you have reason to remove the netblock, do you not do so 
promptly? Are you holding the owner hostage for some particular purpose?

> sensible without a basis to support the claim.

You've beat this drum before Doug. Please suggest a different figure 
with justification for YOUR figure. The 180 days figure is a maximum 
period which we suggest you list between doing a re-check on your 
listing criteria. It does NOT mean you have to remove the entry after 
180 days, simply that you update the listing within that timeframe as 
IPs do change hands and change purposes.

Despite all of this, these items are SHOULDs so that if your DNSBL 
doesn't meet these criteria it is still ok by the BCP.

> ever be.  Automation can and is being gamed.

So build in anti-gaming measures. The freely run DNSBLs do.

Besides, automatic delisting can be implemented with human intervention 
- notify your administrators that a range is about to be delisted and 
should therefore be re-checked for it's listing criteria, and the 
expiration date moved back if required.

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: "Al Iverson" <[email-masked]>
Date: Wed, 26 Mar 2008 11:29:18 -0400

On Tue, Mar 25, 2008 at 5:42 PM, Douglas Otis <[email-masked]> wrote:
>  depend upon full list automation.

You misunderstand. I'll rephrase.

Why does it matter that some BL policies do not fit the BCP? It seems
clear that regardless of what we come up with, some BLs will not be in
compliance. Are we aiming for best practice, or are we recognizing how
all BLs currently work? I think we should be aiming for best practice.

If if that your concerns relate to MAPS/Trendlists potentially being
out of compliance, that I would suggest that perhaps MAPS/Trend  ought
to show us why their take on best practice is better, not try to bend
the universe to fit their model.

MAPS policy on these cases, specific to removal and review of
listings, were exceedingly problematic back in the day. I assume and
hope that things have significantly changed since then.

Regards,
Al Iverson

---

From: "J D Falk" <[email-masked]>
Date: Wed, 26 Mar 2008 12:26:50 -0400

> hope that things have significantly changed since then.

MAPS practices were the best practices approximately 1997-2000,
primarily because there were no lists with better practices.  Since
then, spam has evolved, DNSBLs have evolved, the internet as a whole has
evolved -- and so have the best practices.  EVERYONE who worked for MAPS
back then will say more or less the same thing.

This document should reflect the CURRENT, BEST practices, not some
nearly-forgotten ancestral set of what seemed like good enough ideas at
the time.

--
J.D. Falk
Receiver Products
Return Path

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Mar 2008 09:45:48 -0700

> nearly-forgotten ancestral set of what seemed like good enough ideas at

Yup.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Tony Finch <[email-masked]>
Date: Wed, 26 Mar 2008 19:55:28 +0000

>IP address ranges previously producing substantial levels of abuse.   

IME as a customer of MAPS, a high proportion of the RBL+'s false positives
that have caused us problems have been caused by MAPS's policy of not
expiring or at least periodically revalidating listings in the RSS. I
particularly remember a problem with an address range that had been
re-allocated to an entirely innocent third party who were suffering
because of data that was several years out of date. It's worse that
MAPS wouldn't accept bug reports from us. We no longer use that part of
the RBL+.

Based on that experience, I think the BCP is right.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
MALIN HEBRIDES: MAINLY NORTH OR NORTHWEST 3 OR 4, OCCASIONALLY 5. SLIGHT OR
MODERATE, OCCASIONALLY ROUGH. SHOWERS. GOOD.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 27 Mar 2008 09:43:07 +0800

> it's fairly rare for space to be SWIPed down to the individual network

IME (in RIPE territory) some connection providers take care to register the
addresses that they allocate "permanently", while others hold that the IP
numbers they provide, even if they are "static", don't actually transfer any
ownership of numbers to their customers.

That is obviously out of scope. However, those practices should have been
standardized already. When talking about what DNSBLs should do, it is hard
to avoid references to the way IPs are allocated. For example:

Tony Finch wrote:
> because of data that was several years out of date.

> a provider to change an netblock from fixed addresses to dynamic or vice

Once there was a draft about including the word "dynamic" in the reversely
looked up names, in order to tag DHCP addresses appropriately. However,
reverse name delegations are also controlled by connection providers.

MAPS still uses the term "Dial Up List", DUL, even if modem dialling is
nowadays confined to the digital divide ghetto. Spamhaus talks about
"end-user" ip addresses, as if renewed MTAs were not the final users of
the IPs they use. "Residential IP" is some times used to deliver the
concept that ordinary people shouldn't mess up with mail servers. Hm...

Even if IP allocation is not the core of this BCP, I think those concepts
should be clarified, referencing the relevant RFC where apropriate, and
paying attention to the mechanisms that are used when numbers are recycled.

Finally, I'd propose privacy officers as potential readers of this BCP:
They should endorse DNSBLs that they determined to be compliant with best
current practices, for it should be part of patrolling the territory.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 27 Mar 2008 15:01:31 +0100

Alessandro Vesely wrote:

> modem dialling is nowadays confined to the digital divide ghetto.

Grmbl, I like my modem.  Admittedly it is not the way to watch
videos.  "Dial-up" also covers ISDN, slightly faster than V.90. 

> I think those concepts should be clarified, referencing the
> relevant RFC where apropriate

Post numbers, please.  I'd know where to find the MTAMARK draft,
unfortunately that never made it.  The reverse lookup draft is
just in WGLC and should be available if needed as reference.

 Frank

---

From: Douglas Otis <[email-masked]>
Date: Thu, 27 Mar 2008 14:05:46 -0700

On Mar 26, 2008, at 8:18 AM, Matt Sergeant wrote:

>> networks and provide notifications to afford opportunities to  
>> remedy issues.  Establishing co-operative relationships often  
>> involves time.  The time expended means such efforts can easily be  
>> gamed, especially when de-listing is automatic at set intervals or  
>> acted upon automatically from any request.  Keep in mind, some  
>> organizations structure their BL services differently.  Some offer  
>> BLs run in the manner suggested by the current version of the draft  
>> and others do not.  Trend happens to do both.
>
> OK, so let me just clarify this - when you are listing a netblock  
> (and communicating with the owner or whatever you do), you NEVER  
> periodically re-check that netblock to make sure it hasn't changed  
> hands or gone quiet or anything? It's just listed permanently until  
> the heat death of the universe?

Two major players are effective at controlling email abuse, individual  
senders and network providers.   Enforcement of the network provider's  
AUPs offers the greatest impact and creates a hierarchy of  
responsibility that fairly distributes costs related to curbing  
abuse.  The provider must also seek remuneration for their services  
and are thus best able to defend against evasive abusers as well.    
The concept of "automated individual IP address blocking" based upon  
automated detection and instant removal is clearly an ideal aimed at  
shifting all culpability onto often anonymous individual senders.  At  
times, an individualized approach in controlling abuse is  
appropriate.  However, the strategy taken depends upon the stewardship  
of the network provider.

Some networks permit high levels abusive, where their traffic might be  
blocked when there lacks justification to re-establish a baseline  
which must endure this abuse.  Soliciting network providers  
involvement sometimes takes years, where blocking just their  
individual IP addresses is counter-productive and ultimately  
ineffective.  This draft is confusing the mechanism with the entity  
being held responsible.

> Or is it temporary after all?

There is no pre-ordained maximums in terms of time (or CIDRs), as  
suggested by this draft.

This draft shifts resolving abuse to individual senders and third- 
party blocking lists, and away from network providers.  While an  
individual IP address approach is suitable for a growing number of  
networks, this draft assumes only the behaviour of individual IP  
addresses plays _any_ role, and completely ignores the role played by  
network providers.  Where in this draft is the most specific AS even  
mentioned?  A BCP about black-hole listings that omits details related  
to ASNs and BGP seems ludicrous.   What role does the AS play in  
abating abuse and identifying responsible entities?  None?  As email  
begins to use IPv6 addresses, the number of addresses able to defeat  
_any_ automated system will again become overwhelmingly apparent.  The  
role network providers must play is not based upon concepts that have  
become antiquated back in the year 2000, as some on this list are  
suggesting.

> promptly? Are you holding the owner hostage for some particular  

How many legal fees will be expended by black-hole list operators  
arguing over whether blocking removal should be automatic on a per IP  
address basis in so many days, or that all IP addresses may not be  
handled separately as a result of this draft's recommendations.  This  
draft appears to be part of an ongoing effort to declare network  
providers innocent of abuse sourced from their networks.  On the  
contrary, only network providers are able to know the entity  
involved.  As a result, _only_ network providers are able to be  
effective at curbing abuse, and as such, must be held responsible when  
they fail to act in curbing abuse.

>> Justifying a listing and de-listing policy should consider all  
>> factors involved.  This draft concludes de-listing interval of 180  
>> days is sensible without a basis to support the claim.
>
> listing criteria. It does NOT mean you have to remove the entry  
> after 180 days, simply that you update the listing within that  
> timeframe as IPs do change hands and change purposes.

This misses points made about the roles network providers MUST play.   
When abuse is resolved to the AS, the concern of "changing hands" is  
completely misplaced.

> doesn't meet these criteria it is still ok by the BCP.

This still assumes blocking is always based upon the IP address and  
not the AS.  This is wrong.  As a result, these ill considered  
"shoulds" may lead to protracted litigation and increased amounts of  
abuse when network providers use this draft's portrayal of best  
practices as an excuse to dodge their responsibilities.  Network  
providers were only included in the historical overview.  How quaint.

>> It does not help the cause to have these "SHOULD" statements which,  
>> in the end, will likely prove highly counter productive.  While  

What are the anti-gaming measures needed to sustain this draft's  
concept of complete black-hole list automation?  Currently there are  
millions of IP addresses changing as a source of abuse every hour that  
then go quiescent for months.  A growing number of these sources have  
even gained access to the provider's outbound servers as well.

> Besides, automatic delisting can be implemented with human  
> intervention- notify your administrators that a range is about to be  
> delisted and should therefore be re-checked for it's listing  
> criteria, and the

Did you say a range of IP addresses?  Shouldn't the draft indicate how  
to determine the boundaries separating different network providers?   
Should this draft dare to discuss the detection of spoofed BGP  
announcements?  Such route spoofing could cause black-hole list  
automation to becoming a method for staging massive DDoS attacks.

As a separate matter, should this draft mention the recognition of  
RFC3464 in conjunction with content removal?

-Doug

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 28 Mar 2008 12:45:23 -0400

> ineffective.  This draft is confusing the mechanism with the entity  

I see your point to a degree.

But, in response, you're conflating listing policy with DNSBL mechanisms.

Remember, listing policies that take a broader view (eg: listing ranges 
or ASN for multiple persistent problems where they may not exist on all 
IPs at any given moment, to make a stronger incentive for the provider 
fix it) will most usually fall under imposing collateral damage.

That is permitted by the draft, as long as it's disclosed.

As for longevity of the listing...

We may be able to get around this concern by being more explicit about 
saying that "reviewing the listing and deciding it's still applicable" 
meets the requirement.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Matt Sergeant <[email-masked]>
Date: Fri, 28 Mar 2008 15:22:48 -0400

>> the heat death of the universe?
[snip]
> There is no pre-ordained maximums in terms of time (or CIDRs), as

I'll take that as a "yes, it can be listed permanently until the heat  
death of the universe", reading between your dancing around the  
question. But see below for further input.

> party blocking lists, and away from network providers.

Utter tripe. It does no such thing. The draft makes no assumptions  
about the contents of the DNSBL, nor the listing criteria. It only  
asks that these things be clear and documented.

> they fail to act in curbing abuse.

OK, clearly we do need a clafification of what a "Listing" may  
consist of. The draft is not meant to suggest that listing == 1 IP  
address. A listing could just mean one entry in your database, with  
whatever mapping that implies to entries in your DNSBL.

The BCP of listings being temporary is to prevent situations like  
SPEWS (and clearly MAPS/Trends too according to other replies on this  
thread) abusive acts of keeping IPs/Ranges/ASNs/whatever listed long  
after the abuse has stopped. Simple as that.

> When abuse is resolved to the AS, the concern of "changing hands" is

Not really. Just a confusion about what an entry in the DNSBL means.  
If the entry is an ASN (even if the DNSBL lists IPs ultimately) then  
you still need to periodically check that ASN for continued abuse. If  
the abuse stops, delist it.

> not the AS.  This is wrong.

It doesn't assume that. But clearly clarification is required.

> Did you say a range of IP addresses?

See above - we need to clarify what an entry/listing is.

> Shouldn't the draft indicate how

Way out of scope.

> announcements?

Umm, no. Way out of scope.

> RFC3464 in conjunction with content removal?

Not even slightly near being in scope.

Matt.

---

From: "David Nicol" <[email-masked]>
Date: Fri, 28 Mar 2008 15:39:05 -0500

>  Way out of scope.

listing these reasonable nearby concerns in an "out of scope"
section makes sense, in a document with the purpose (among
others) of defining terms.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Douglas Otis <[email-masked]>
Date: Fri, 28 Mar 2008 14:49:40 -1000

On Mar 28, 2008, at 9:22 AM, Matt Sergeant wrote:

>>> hands or gone quiet or anything? It's just listed permanently  
>>> until the heat death of the universe?
> [snip]
>>
> I'll take that as a "yes, it can be listed permanently until the  
> heat death of the universe", reading between your dancing around the  

The following was authored by Dave Rand, who is not an active  
participant in this mailing list, but was asked for comment on this  
issue.  He is available for additional questions, comments or  
statistics at dlr_at_kelkea.com.

-----
Just before we go off on a tangent, let's remember what RBL listings  
(and I'm using the MAPS trademarked RBL now owned by Trend Micro as a  
very specific example) are for.

RBL listings are for addresses (or address ranges) which have sent  
spam, and for which an RBL nomination has been processed.  The RBL  
nomination process includes contacting the responsible service  
provider which is advertising that space on the Internet.  The service  
provider has had an opportunity to review the RBL listing prior to it  
becoming active, and has chosen either not to respond, or has not  
dealt with the issue in question.  The RBL listing *WOULD NOT HAVE  
BEEN MADE* if the service provider had delt with the issue.

Now, let's look at a few examples, live spam attempts in the last few  
minutes.  These three examples were not selected in any, other than a  
tail of the current mail server log on my system, and happened to come  
during the same second.

03/28/2008 16:51:30: SPAM aborted while talking with (200.121.80.112)  
- "MAPS RBL".
03/28/2008 16:51:30: SPAM aborted while talking with (210.76.64.22) -  
"MAPS RBL".
03/28/2008 16:51:30: SPAM aborted while talking with (88.249.244.18) -  
"MAPS RBL".

As it happens, the first one came from an RBL listed address which has  
been listed since 2006 - and is still spamming.  The second, for more  
than a year, and still spamming.  The third, for more than a month,  
and - you guessed it, still spamming.

I note, with interest, that these addreses are also listed on several  
other blacklists, but that's not important for the purpose of this  
issue.

In each case, the service provider was notified in advance of the  
listing, and was given an opportunity to deal with it.  In two out of  
the three cases, I know this personally to be true, and the third I  
know by documentation.

So, what's an appropriate listing policy?  Until the problem is fixed,  
and the service provider in question notifies (by replying to the  
original nomination, for example) that the issue is corrected.

These are three examples, totally at random.  Finding accurate contact  
information for the end users of the addresses is essentially  
impossible, and (in at least one country on this list) prohibited by  
law.  The one and only contact information which must be documented,  
at least for the most part, is the ASN advertising the space on the  
internet.

AS4134, AS6147 and AS9121 are responsible for these addresses.  In at  
least two of the three cases, I know that the adminstators are fully  
aware of this, and have tried to bring effective abuse policies in  
place.  They have, so far, failed.

So, RBL(tm) listings get listed until the problem is fixed, and the  
responsible party contacts the blacklisting provider.  There has been  
some suggestion that an automated removal process could be used if the  
listing is no longer generating spam, for example.  The only party  
which could determine this with any accuracy would be service provider  
for that address, as they are the only ones that have access to the  
traffic to determine it.  The blacklist operator can see but a very  
small part of the internet, and has no way to determine with any  
reasonable degree of assurance that the problem has indeed been fixed  
- the absence of bad traffic on a small part of the internet in no way  
can determine the "goodness" of an address.  It *can* determine  
badness, but not goodness.  Goodness can only be determined by the guy  
at the router - that's the service provider.

Here's some more numbers for you to consider:

During 2005, there were an average of 2.1 million unique IP addresses  
per month sending spam.  During 2006, 4.2 million.  During 2007, 10.0  
million.  At this rate, somewhere between 20 million and 100 million  
per month will be sending spam in 2008.

IP address reputation is the only way in which mail servers can keep  
up today, and that reputation is persistant until corrected.  IP  
addresses, in general, don't "get better" with time.  They get worse.   
Once fixed, they tend to stay fixed *because* someone has gone to the  
trouble of bringing it to the surface- but unchecked, the spam will  
continue to flow.

I have detailed information on this trend going back as far as 1995 or  
so.

The Service Providers *must* take a more pro-active stance in dealing  
with the problem, and they must either make detailed contact  
information available for the end users of the address space (which is  
currently illegal in many countries), or they must promptly pass  
complaints on to end users, and then monitor for compliance.

Automated removal (and for that matter, automated addition) to any  
long term blacklist is bad.  Active participation to prevent blackhole  
listings by the service provider in question is the right way to do  
things.

Stopping the spam in the first place, by effective port 25 blocking,  
bot/infection detection, and proper monitoring is by far the best  
way.  This would quickly put all RBL services out of business,  
forever.  I favour this approach.

-----

-Doug

---

From: "Peter J. Holzer" <[email-masked]>
Date: Sat, 29 Mar 2008 10:46:44 +0100

> statistics at dlr_at_kelkea.com.

I have bcc'd him, to avoid getting his email address into any archives
in clear text.

> spam,

From a user's point of view, I disagree. RBL listings are for addresses
(or address ranges) which *will* send spam. Of course that's impossible,
but that's the user's expectation. He doesn't want to know whether a
specific IP address sent spam 3 years ago or even 5 minutes ago. What he
wants to know is whether the message he is about to receive over the
connection that was just opened will be spam or ham. So that is the goal
which RBLs should try to approximate (while knowing that they can never
fully achieve it).

> and - you guessed it, still spamming.

This doesn't address the question whether listings should expire.
Of course all of these are still spamming - that was the selection
criterion. 

> IP  addresses, in general, don't "get better" with time.  They get
> worse.   

To prove or disprove this claim, you would need to take a sufficiently
large sample of addresses which were spamming in the past and find out
whether they are still spamming today. 

To find out whether the recommendation in the draft ("expire unless
further abuse is observed") is workable you need to find out how many
are still spamming today but are not detectable by your normal listing
mechanism.

As an example, let's assume that from 1000 IP adresses which were listed
6 months ago, 990 are still spamming today. If 985 of them are
detectable by your normal procedure, it is better to automatically
expire. You will now have 5 false negatives, but if you don't you will
have 10 false positives (Of course these 10 IP addresses may never be
used for a legitimate mail server).

I realise of course that these measurements would have to be done on a
global scale to be accurate, and that is impossible.

> The blacklist operator can see but a very  small part of the internet,
> and has no way to determine with any  reasonable degree of assurance
> that the problem has indeed been fixed  - the absence of bad traffic
> on a small part of the internet in no way  can determine the
> "goodness" of an address.

Right.

> responsible party contacts the blacklisting provider.

If this is the criterion, all you have to do to conform to 2.2.1 is
check your mailbox every 6 months. If nobody has reported that the
problem is fixed, the criterion still applies and you can extend the
listing for another 6 months. (of course the BCP contains other
recommendations, too)

	hp

---

From: Matt Sergeant <[email-masked]>
Date: Sat, 29 Mar 2008 11:12:45 -0400

> listing for another 6 months. (of course the BCP contains other

Thank you - that's exactly what I was thinking.

Doug: does this make sense to you? This is in full compliance.

---

From: "Al Iverson" <[email-masked]>
Date: Sat, 29 Mar 2008 11:03:32 -0500

>  Doug: does this make sense to you? This is in full compliance.

This seems like full compliance to me, as well.

Al

---

From: Douglas Otis <[email-masked]>
Date: Sat, 29 Mar 2008 08:14:32 -1000

On Mar 29, 2008, at 5:12 AM, Matt Sergeant wrote:

>>> So, RBL(tm) listings get listed until the problem is fixed, and  
>>> the responsible party contacts the blacklisting provider.
>>

A draft regarding practices for black-hole lists should define the  
entity able to assert network governance to be the organization  
advertising the address space.  How this organization is identified is  
missing, which in itself is misleading.  Not defining Autonomous  
Systems leads one to a naive view that listings concern only  
individual IP addresses, and not address ranges within space  
advertisements.  Black-hole list operators should have a goal of  
ensuring providers enforce their own AUPs, and that their AUPs  
prohibit UCEs and other forms of email abuse.  Black-hole list  
operators can not adequately detect and enforce AUPs, only the  
organization advertising the address space and routing the traffic  
have this ability.  Nothing has changed over the decades in this regard.

Insurance companies rate drivers by police registered infractions,  
where each likely represents many unobserved occurrences.   In the  
case of network abuse, the driver is the network provider, where their  
ratings may be such that none of their address space is trusted.  This  
determination of trust could be analogous with insurance companies,  
where some drivers do not warrant coverage.  Listing should not expire  
on their own as "Listings SHOULD Be Temporary" requires.   
Rehabilitation should _always_ require an action by network  
providers.  Change the title to "Listings SHOULD be acted upon by  
Network Providers."  (Until such time, no listing SHOULD expire.)

Of course, reading a provider's response to notifications should not  
be delayed, as your sentence now seems to imply.  Section 2.2.1 and  
2.2.3 are illogical when viewed as the network provider being listed,  
and not individual IP addresses.  Only the provider can be expected to  
know who was granted access, and whether abuse is being curbed.  An  
effective black-hole list MUST function in co-operation with the  
network providers.  This draft must define this entity.  Only network  
providers are able to provide governance and effectively control  
abuse.  This draft should not attempt to perpetrate a myth that  
network governance can be found through black-hole list automation.

Bad actors control millions of compromised systems individually.  Any  
automated process reveals where traffic is being detected within a  
brief period.  The latency for changes to campaigns in avoiding  
detection has become ever shorter, which demonstrates a high degree of  
automation by bad actors.  Only network providers are able to assert  
the required governance and ensure the efforts of the black-hole list  
operators are not defeated.

-Doug

---

From: "Al Iverson" <[email-masked]>
Date: Sat, 29 Mar 2008 14:52:16 -0500

On Sat, Mar 29, 2008 at 1:14 PM, Douglas Otis

>  missing, which in itself is misleading.

I don't understand your response. Is that a yes or no on the "six
months" question? If it's a no, can you elaborate on that, perhaps on
that alone?

Regards,
Al Iverson

---

From: Douglas Otis <[email-masked]>
Date: Sat, 29 Mar 2008 16:40:47 -1000

On Mar 26, 2008, at 9:55 AM, Tony Finch wrote:

> IME as a customer of MAPS, a high proportion of the RBL+'s false  
> positives that have caused us problems have been caused by MAPS's  
> policy of not expiring or at least periodically revalidating  
> listings in the RSS. I particularly remember a problem with an  
> address range that had been re-allocated to an entirely innocent  
> third party who were suffering because of data that was several  
> years out of date. It's worse that MAPS wouldn't accept bug reports  
> from us. We no longer use that part of the RBL+.
>

Tony,

RSS listings offer automatic retesting and removals without involving  
network operators, only a request needs to be made via the supporting  
website.  There should be no reason for a listing not to be removed?   
If you were misinformed, this is most unfortunate.

See:
http://www.mail-abuse.com/removereq_rss.html

Both open proxy and open relay listings are _not_ routinely retested  
without request.  Open relays and proxies stay active for years, and  
often appear used for purposes unaffected by black-hole lists.

-Doug

---

From: Matt Sergeant <[email-masked]>
Date: Sat, 29 Mar 2008 23:04:54 -0400

On 29-Mar-08, at 10:40 PM, Douglas Otis wrote:
> without request.  Open relays and proxies stay active for years

While this may be true, often their IPs don't. Perhaps you should  
reconsider your lack of re-testing policy.

I'd rather not block the support of this BCP just because MAPS'  
outdated policies don't match it.

Matt.

---

From: Douglas Otis <[email-masked]>
Date: Sat, 29 Mar 2008 18:18:32 -1000

On Mar 29, 2008, at 5:04 PM, Matt Sergeant wrote:

>> Both open proxy and open relay listings are _not_ routinely  
>> retested without request.  Open relays and proxies stay active for  
>> years
>

What is the meaning of IP?  Several complained about the initial  
test.  However, these small open proxy and open relay lists provide  
valid reasons NOT to expire listings automatically and require  
additional testing.

> outdated policies don't match it.

This draft can not be considered a Best Current Practice for operating  
black-hole lists without, at the minimum, clarifying the _only_  
confirmable entity able to assert the governance necessary for  
delisting.
Delisting policy SHOULD BE based upon the actions of the network  
provider, however long that takes.  After all, the network provider  
(the entity advertising the address space) is the _only_ confirmable  
entity able to assert network governance.

This draft defines wishes and desires, but lacks a basis in reality.   
Listing or delisting automation is easily gamed, giving a significant  
advantage to bad actors.  This draft assumes listings can be safely  
added and removed and lacks requisite interactions with network  
providers.  You mentioned something about anti-gaming strategies, but  
then did not clarify the role of the _only_ confirmable entity related  
to the address in question and able to ensure the cessation of  
abuse.   When IPv6 introduces a few quadrillion more IP addresses, the  
complete lack of a confirmable entities associated with individual IP  
addresses will become more apparent.

The black-hole list DNS query mechanism places IP octets in reverse  
order.  This approach facilitates publishing network blocks using  
wildcard entries, and frequently corresponds to AS advertisements.   
While the DNS transaction may be for a single IP address, the listing  
itself often involves a range of IP addresses.

-Doug

---

From: Steve Atkins <[email-masked]>
Date: Sat, 29 Mar 2008 21:48:17 -0700

On Mar 29, 2008, at 9:18 PM, Douglas Otis wrote:
> black-hole lists

Black hole is a very specific technical term in this context, relating  
to packet
routing. Is that what you mean?

Cheers,
   Steve

---

From: "Chris Lewis" <[email-masked]>
Date: Sun, 30 Mar 2008 00:58:34 -0400

> valid reasons NOT to expire listings automatically and require  

My experience has been that if you use a open proxy or open relay list 
that don't retest starts yielding significantly higher FPs as the age of 
the entry increases.

So much so that I (and I note Spamhaus also in the case of the XBL) 
check the entry age in NJABL proxy, and ignore entries older than (I 
think in both our cases) 120 days.

Part of the reason that I found SORBS lists of these types of 
vulnerabilities problemmatic.  You couldn't get entry age info, I 
understand that SORBS did not (and perhaps still doesn't) expire 
entries, and the FP rate was higher than I was willing to accept.  So we 
stopped using them.

> entity able to assert network governance.

You would require an ISP's hostmaster request delisting of an IP that 
belongs to a, say, business class customer with their own infrastructure 
and admin staff simply because the customer doesn't have their own ASN. 
  Or even a corporate with multiple divisions with their own staff.

That's simply not going to fly.

Not the least being that the network provider usually does NOT have 
access to the equipment with the problem. They may be confirmable, but 
they can't necessarily assert true (as in, _fix_ specific problems) 
governance, short of disconnection.

> advantage to bad actors.

Check out Makey's DNSBL statistics.  The CBL/XBL is proof to the contrary.

> itself often involves a range of IP addresses.

That's stating the obvious.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Matt Sergeant <[email-masked]>
Date: Sat, 29 Mar 2008 23:01:24 -0400

On 29-Mar-08, at 2:14 PM, Douglas Otis wrote:
> advertisements

No Doug. You're missing the point again. The BCP doesn't attempt to  
define how a list should be defined, nor what it should contain.  
ASNs, IPs, rDNS entries, First Names, X-Mailer entries, whatever you  
want. It does NOT attempt to define this. If it does, point out where  
it does that and help us fix the problem. If you can't, please shut  
the hell up because you're simply whining instead of trying to help.

Matt.

---

From: "Al Iverson" <[email-masked]>
Date: Sun, 30 Mar 2008 11:41:46 -0500

On Sat, Mar 29, 2008 at 11:58 PM, Chris Lewis
>  that don't retest starts yielding significantly higher FPs as the age of

I agree. I created the MAPS RSS, and even I know its "never delist
until asked" policy is problematic. Today, if it were up to me, I
would auto-expire listings. I think we need to be careful to not let
this documentation be limited by a need to justify MAPS' current
policy where it may differ from best practice.

Regards,
Al Iverson(sm)

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 30 Mar 2008 21:14:42 +0200

> just in WGLC and should be available if needed as reference.

I guess you mean draft-ietf-dnsop-reverse-mapping-considerations-06.
It has a number of interesting consideration w.r.t. DNSBLs, as it also 
considers anti-spam as a topic. Specifically, in-addr.arpa could be 
considered a DNSWL in its own right.

The other relevant topic is [r]whois maintenance. I'm not an RFC 
connoisseur, and I'm quite lost here. The specs, e.g. rfc1714 or 
rfc3912, limit themselves with protocol specification, even if they 
suggest that tracking IP assignment is the intended usage. Rfc2050 
mentions a database that is maintained by adding reassignment 
information, but doesn't say if and how it is published. Perhaps, 
there is room enough in the DNSBL BCP to informally suggest that 
published information about IP assignments _is_ available, and that 
the point of contact mentioned there is responsible for referring to 
the final user of a given number. Policies and obligations for 
actually providing such reference obviously vary.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Douglas Otis <[email-masked]>
Date: Sun, 30 Mar 2008 19:29:15 -1000

This message is posted on behalf of Dave Rand.
---

This is Dave Rand again, again - I am not part of this mailing list,  
and am responding via this forum simply to provide facts, figures and  
current status.  I continue to be available for questions, comments  
and backing data.

There are several different kinds of lists, and in my previous email,  
I referred specifically and only to the RBL(tm).

Al Iverson, the originator of the RSS (which is *not* the RBL) brings  
up a good point, and that would be that automated re-testing of  
certain types of blackholing *can be* a good thing.  I will point out  
that automated re-testing was, in the day, considered abuse by  
itself.  The current RSS contains only about 500 confirmed open relays  
which have sent spam - the oldest of which (listed by Al himself) is  
about 8 years old.  This oldest listing is still open, still running  
at the same IP address, still has the same in-addr (and, as far as I  
know still running in the same closet without any system  
administration at all).  The Open Relay Plauge is pretty much over,  
and the RSS was certainly responsible for curing many systems, and we  
have Al to thank for that.

The RSS (which looks at open relays) and OPS (which looks at open  
proxies) are examples of semi-automated blackholing lists.  In the  
early days, MAPS demanded that a human look at each and every spam  
prior to testing, so that systems were not tested without cause.  I  
know I looked at an awful lot of spam, prior to unleashing the RSS  
tester on systems.  Regardless, we got a *lot* of complaints from  
people because "we were attempting to break into their system" -  
despite the spam coming from their systems.

There just aren't a lot of open relays any more.

The RBL(tm) is a *fully manual* process.  No automation.  It is the  
"list of last resort".  It is used to stop spam coming from  
*persistant* spam sources - ones that have been brought to the  
attention of the service providers, and that the service provider has  
ignored.

If you want to put in the draft that "fully or semi-automated lists  
should have a retest interval", that's fine with me.  In fact, this  
would help blocklist providers defend against "you are cracking our  
system!" complaints. Define the retest interval to be something  
reasonable, and I'm certain that all reputation providers doing  
automated listing will help.

Automatic expiration for automated lists?  Well, we know that 8 years  
isn't long enough.  I don't know what it should be.  20 years?

But fully manual lists, where details of the of issue have been  
communicated to the service provider, and the service provider given  
an opportunity to respond?  Sorry.  If you are advertising routes for  
your customers, and cashing their cheques, then you have an obligation  
to deal with the complaints.  Yes, I know you don't control their  
gear, but you *do* control their connection, and you *can* apply  
filters, or apply wire-cutters as appropriate.

I don't have the stats for the XBL/CBL, but I do have long term (10  
year+) stats for the MAPS data, and I know that *in general*,  
addresses that send spam *do not* get better until some action is  
taken.  I do see cycles of inactivity - but with 100M+ compromised  
hosts out there, that's not surprising at all.  But the spam almost  
always comes back, until the root problem is addressed - securing the  
network (usually by blocking port 25, by the service provider).

Service providers will continue to be held accountable for *dealing  
with the complaints*.  No, I'm not suggesting, in any fashion, that  
you have to monitor connections 24x7 for "illegal or immoral  
activity", but once a complaint has been registered, and found to be  
valid, then the service provider has an obligation to deal with it.  I  
know they don't want to deal with complaints, and many efforts in the  
last few years have been for certain Service Providers to find new  
ways to evade this responsibility.

If the service providers can find a way to make full, accurate,  
customer-contact information available to the list operators, then we  
can work out a way to share the burden for complaints.  In many  
countries, however, this is either illegal, or not workable, so the  
Service Provider is the only one with valid contact information (well,  
they know how to get hold of them when the bill isn't paid, anyway :-)

Perhaps I am mis-reading this, or perhaps I'm just confused about the  
intent of the draft to insulate service providers from any requirement  
of action.  If I am, I apologize to the group.  Again, I am *all for*  
automated re-testing of automated listings.  I, and Trend Micro, is  
completely against automated removal of any reputation data, without  
the Service Provider's guidance.

Guys, have a look at https://nssg.trendmicro.com/nrs/reports/rank.php

No surprise that the top 10 service providers also have some of the  
largest number of RBL listings.  And if *just* the top 10 service  
providers did *anything* to reduce the amount of spam that their  
customers generate, we would be dealing with at least an order of  
magnitude less spam on the network.

So, once again, I call on the service providers to put the reputation  
providers out of business:  Stop the spam, at the source.  I know you  
can, and you know you can too.  Just in the last year, 3 networks have  
gone from the top-10 to off-the-list.  Your network could be next.   
Your network should be next.

This pattern has been repeated since the dawn of the RBL.  Service  
providers have changed their policies, and stopped spam coming from  
their networks.

Again, I am available off list for questions or comments.  I've taken  
arrows, rocks and bomb threats for years, too, so please not too many  
of these.

---

-Doug

---

From: Steve Atkins <[email-masked]>
Date: Sun, 30 Mar 2008 22:51:11 -0700

> This message is posted on behalf of Dave Rand.

While Dave often has a unique perspective, I'm slightly concerned
that anyone would interact with the ASRG in a write-only manner.
If Doug represents Trend Micro policy, he can present and discuss
it here himself. If this is, instead, a private observation from Dave,  
it might
be better if Dave were to present it as a private observation himself,
rather than as a statement presented by an employee.

> attention of the service providers, and that the service provider has

That seems to clash with past statements of the MAPS RBL team.
IIRC, the RBL was intended to punish those who, in the sole discretion
of the RBL staff, "support spam" in some vague, abstract way. It was
not intended solely to actually block or stop spam. Listings were  
punitive,
and intended to cause business damage, not to actually block spam,
and there was no consistent policy or oversight.

Has that policy changed since the Trend buy-out? If so, there are
probably some useful lessons to learn from why those policies have
changed, and the benefits of doing so. Dave?

Cheers,
   Steve

---

From: Douglas Otis <[email-masked]>
Date: Sun, 30 Mar 2008 20:06:33 -1000

On Mar 29, 2008, at 6:48 PM, Steve Atkins wrote:
>>
>> This draft can not be considered a Best Current Practice for  
>> operating black-hole lists
>
> Black hole is a very specific technical term in this context,  
> relating  to packet routing. Is that what you mean?

 From a legal perspective "black list" is a technical term that does  
not apply to black-hole lists or block-lists.  The term "black list"  
in this draft may unnecessarily obligate a black-hole or block-list  
operator to clarify the difference in possible litigation.  The  
RBL(tM) (real-time black-hole list) information ultimately pertains to  
the reputation of the network provider.  Blocking or black-holing  
should be contained within the provider's advertised space.  Properly  
establishing this containment and identifying the provider is critical  
for any block/black-hole list operator.  This aspect of block/black- 
hole listing is currently missing from the draft.

The block/black-hole listing information is currently distributed in  
several forms, such as BGP, DNS, or data transfers of various types.   
When published using BGP, this information can safely can be called  
black-hole listing in the classic sense.  When published using DNS,  
most MTAs return an error code, where this might be better described  
as block-listing, or perhaps even conduct-listing, because blocking  
may not be the result of the listing.  A term that should not be used,  
to avoid confusion with legal definitions, would be black-listing.

-Doug

---

From: Andrew Kirch <[email-masked]>
Date: Mon, 31 Mar 2008 02:30:16 -0400

> to avoid confusion with legal definitions, would be black-listing.
Speaking from a strictly American legal point of view, idiots are going
to sue regardless of what you call it, and changing the name doesn't
waive aa DNSBL/black hole list/black list's protection under 47USC230.  
I do agree that we should be consistent in terminology and would
recommend the use of DNSBL throughout.

Andrew

---

From: Andrew Kirch <[email-masked]>
Date: Mon, 31 Mar 2008 02:43:20 -0400

> isn't long enough.  I don't know what it should be.  20 years?

I agree here that there should not be a defined maximum, even under the
weight of a SHOULD directive.  I would note that in general it is a best
practice to automate the removal of anything automatically added.  We
automate open proxies, spamtrap data, open relays, and rhsbl data.  We
have automated the removal of all but the last.  (We're still working on
a weighting system to increase the removal penalty, and provide an out
of band contact to manually remove false positives (especially for those
institutions that are victims of Phishsing and other forgery based scams).
> last few years have been for certain Service Providers to find [email-masked]  
I think you've misread to some extent here, and I have contacted the
authors privately requesting that this be clarified.  I assume good
faith here from two long-term members of the anti-spam community who
have not had direct experience running a blacklist, and don't perceive
anything in the draft as any sort of attempt to insulate service
providers.  The draft itself is designed to establish best common
practices for us the DNSBL maintainers, so it really won't speak much to
providers responsibilities, or requirements.  This can, and should be in
another draft.
> Your network should be next.
Here, here!
> arrows, rocks and bomb threats for years, too, so please not too many  

Andrew
AHBL.org

---

From: Douglas Otis <[email-masked]>
Date: Sun, 30 Mar 2008 21:08:19 -1000

On Mar 30, 2008, at 7:51 PM, Steve Atkins wrote:

> that anyone would interact with the ASRG in a write-only manner. If  
> Doug represents Trend Micro policy, he can present and discuss it  
> here himself. If this is, instead, a private observation from Dave,  
> it might be better if Dave were to present it as a private  
> observation himself, rather than as a statement presented by an  
> employee.

Several subscribers on this list made comments concerning policies  
used by MAPS.  Dave Rand was requested to comment since he has more  
than a unique perspective.  Please note he has also offered his  
contact information.

>> attention of the service providers, and that the service provider  
>> has ignored.
>
> That seems to clash with past statements of the MAPS RBL team. IIRC,  
> the RBL was intended to punish those who, in the sole discretion of  
> the RBL staff, "support spam" in some vague, abstract way. It was
> punitive, and intended to cause business damage, not to actually  
> block spam, and there was no consistent policy or oversight.

Of course, any listing might be seen as punitive by the network  
provider.  Listing depends upon observed abuse and inaction by the  
network provider.  That has not changed.  Assessment information is  
being bolstered, and remains a work in progress.  The fundamentals  
have not changed, but these are not found this draft. : (

There is only one confirmable entity able to abate spam, the network  
provider.  Efforts might be measured over an aggregate of advertised  
address space. Tools available to the block/black-hole list operators  
are modest compared to that of the network provider.  When a majority  
of advertised address space appears involved in high levels of abuse,  
consolidation of these portions may occur.  Before there is any  
listing published, the co-operation of the network provider is  
sought.  Only the network provider is able to abate abuse, where this  
indeed may involve removing access.  Removing access may also be seen  
as negatively affecting business.  But of course, so might high levels  
of email abuse.

-Doug

---

From: SM <[email-masked]>
Date: Mon, 31 Mar 2008 02:03:11 -0700

>current status.  I continue to be available for questions, comments

I gather that Dave Rand is not following the discussion as he is not 
part of the mailing list.  It's not conducive to have a discussion 
under these circumstances.

>automated listing will help.

This draft is not a license for DNSBL operators to scan hosts or do any tests.

>isn't long enough.  I don't know what it should be.  20 years?

The DNSL operator is free to have an expiration of 20 years.  This 
draft is a BCP.  It's up the operator to determine whether they wish 
to follow it or not.

>of action.  If I am, I apologize to the group.  Again, I am *all for*

If there's any requirement for service providers to act upon, it 
makes adoption of the draft more difficult.

Regards,
-sm

---

From: Andrew Kirch <[email-masked]>
Date: Mon, 31 Mar 2008 08:55:02 -0400

SM wrote:
> to follow it or not

Speaking as a DNSBL operator it'd be easier if the BCP were set up such
that we can follow it rather than having to explain to each and every
twit who wants to play lawyer why we don't follow it.  If this is to be
a set of best common practices lets ensure people can use them.  (this
really should go without saying)

Andrew
AHBL.org

---

From: "David Nicol" <[email-masked]>
Date: Mon, 31 Mar 2008 08:06:40 -0500

On Mon, Mar 31, 2008 at 7:55 AM, Andrew Kirch <[email-masked]> wrote:
>  twit who wants to play lawyer why we don't follow it.

One way to achieve this is to cover recomendations and then
recommend a procedure for declaring a variance from recommendation.

Instead of "operators should whizziwaz the famzimple" the BCP can say
"operators should establish and follow a consistent policy and procedure
about when or if they whizziwaz the framzimple." and then follow that
with discussion of alternatives and why each would be better for each
situation.

These discussions can be fully prosaic, with or without naming actual names.

Yes that is a lot of work and makes the document longer,
but every twit who wants to play lawyer (1) has to read more before he
comes to you and (2) might learn something he did not know when
he began reading the document.

-- 
... but world war IV will be fought with rocks
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 31 Mar 2008 09:15:37 -0400

Andrew Kirch wrote:
> I assume good
> providers.

It would be a mistake to assume "not had direct experience".  For either 
of us.  Beyond that I'll only note that the draft does not require DNSBL 
operators to identify themselves.

META: Say, John, what are the mechanics of updating the draft?  Do I 
just start on a 02, and at a reasonable point, hand you a new one to get 
distributed?
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: John Levine <[email-masked]>
Date: 31 Mar 2008 14:12:54 -0000

>just start on a 02, and at a reasonable point, hand you a new one to get 

Yup.  If you're feeling masochistic, you can also post working versions to
the list for comment.

Once we post the -02, I should go point it out to the rest of the IRTF and
if we want it to be a formal BCP, the IETF powers that be.

R's,
John

---

From: John Levine <[email-masked]>
Date: 31 Mar 2008 14:12:54 -0000

R's,
John

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 31 Mar 2008 10:26:49 -0400

> if we want it to be a formal BCP, the IETF powers that be.

We seem to have garnered enough comments so far that it'd be best to 
make the mods now.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Peter J. Holzer" <[email-masked]>
Date: Mon, 31 Mar 2008 16:50:59 +0200

> really should go without saying)

I think that "best current practice" should be exactly that: *Best*
current practice, not the lowest common denominator. It is expected that
some or even many will have to change their operation if they want to
conform to BCP, and some may find it unfeasible or not worth the
trouble.

I don't really see the problem with this point, though. At least one of
the authors is of the opinion that for a list which explicitely
documents the responsiveness of the provider as a criterion,
periodically checking whether the provider has responded conforms to
this point:
http://www.ietf.org/mail-archive/web/asrg/current/msg13420.html

(Personally, I would add that the DNSBL maintainer should also
periodically check whether the netblock still belongs to the same
provider)

I would expect that a manually maintained list has a lot more problems
with "2.2.3.  Removals SHOULD Be Prompt".

	hp

---

From: Matt Sergeant <[email-masked]>
Date: Mon, 31 Mar 2008 11:52:51 -0400

> isn't long enough.  I don't know what it should be.  20 years?

I had to stop reading here. Perhaps you're feeding Dave  
misinformation, Doug.

It has been clearly stated to you how the draft works in this  
situation - the listing criteria for this 8 year old open relay is  
STILL ACTIVE, so it doesn't get delisted.

Please forward that to Dave to correct his misinformation.

Matt.

---

From: Andrew D Kirch <[email-masked]>
Date: Mon, 31 Mar 2008 12:03:14 -0400

> conform to BCP, and some may find it unfeasible or not worth the
"Best current practice" implies that someone is _currently_ running 
their foo in the manner bar described by the BCP.  I don't know that 
there's a significant difference between a lowest common denominator 
solution for the first public revision of the document.  I don't think 
any of us are going anywhere, and as awareness and compliance with the 
first version of this document becomes a reality, we can talk about 
expanding it.
I think the question this document needs to answer is "What do I as a 
DNSBL maintainer have to do to publish valid information?", and possibly 
"what do I as an end user/abuse role/network role need to provide and 
expect of a DNSBL maintainer".  If the lowest common denominator is 
ensuring my list has valid information (as what we're trying to avoid, 
of course, is invalid information) then I think we'll do fine even with 
the first draft, although I am in this for the long haul and will always 
be looking to make the standards better, I just want to start on common 
ground, otherwise we'll have adoption problems.

Andrew

(once the gods built a perfect society, they never let the humans in.  
It remains, to this day, perfect)
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Al Iverson" <[email-masked]>
Date: Mon, 31 Mar 2008 11:06:40 -0500

>  Please forward that to Dave to correct his misinformation.

I am also concerned that my comments were incorrectly characterized in
Dave Rand's missive. I did not advocate automatic retesting. I was
referring to automatic expiration, which I have found to be a best
practice, and I would recommend to others, in any sort of
exploit/relay abuse type of list. Timeliness matters.

I would second (or is it third?) the request that Dave should either
participate or not participate. I don't think his method of dictating
something out of band occasionally and having Doug Otis drop it into
the conversation is really moving anything forward.

Regards,
Al Iverson

---

From: der Mouse <[email-masked]>
Date: Mon, 31 Mar 2008 12:45:25 -0400 (EDT)

> their foo in the manner bar described by the BCP.

I don't think so.  Rather, for each point, there should be someone
doing that.  That there is anyone who does them all is not, I think,
necessary (or, for a BCP with more than a few points, very likely).

/~\ 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: "Chris Lewis" <[email-masked]>
Date: Mon, 31 Mar 2008 13:03:11 -0400

> necessary (or, for a BCP with more than a few points, very likely).

Note that the draft was explicitly designed to be as inclusive as 
possible of existing DNSBLs.  Most of the popular DNSBLs are already in 
full compliance and/or differing only in a few points.  Heck, even SPEWS 
would only have been off compliance on one major (and perhaps one or two 
minor) points for most of its lifetime.

Please keep that in mind - if it seems otherwise, that means we have a 
wording problem.  Which is why I'm redrafting 2.2.1 and 2.2.3... ;-)

Why would we implement a BCP that (to some) seems so inclusive/"loose"? 
  Two reasons:

1) Tell DNSBL _users_ what points they should look for, and at least by 
omission, what _not_ to expect.

2) Explicitly recognize that DNSBL operators should be able to implement 
whatever listing policies they want.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Andrew D Kirch <[email-masked]>
Date: Mon, 31 Mar 2008 13:10:55 -0400

> necessary (or, for a BCP with more than a few points, very likely).
This was the point I was making, apologies if I was unclear.

Andrew

---

From: "David Nicol" <[email-masked]>
Date: Mon, 31 Mar 2008 13:31:58 -0500

>  minor) points for most of its lifetime.

 s/compliance/conformance/

"out of compliance" is a problem.  "out of conformance" is diversity.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Matthew Sullivan <[email-masked]>
Date: Tue, 01 Apr 2008 07:21:25 +1100

> under these circumstances.

So who are you and what do you have to do with DNSbls?

> draft is a BCP.  It's up the operator to determine whether they wish 

Speaking as a DNSbl creator/operator/maintainer/owner I would like to 
point out that 'BCP' stands for 'Best *Current* Practices'...  I see 
little point in any BCP document that does not actually relate to the 
*CURRENT* practices whether best or not.  I would expect as a minimum 
that any document you wish to create would have input from the most used 
DNSbls in the world (at least the top 3, but I would expect in reality 
that it were the top 10 or more) and it would actually reflect their 
current practices where there is common ground. 

> makes adoption of the draft more difficult.

Creating a document that mandates or indicates operation other than how 
the *current* DNSbls operate will make the draft pointless as it will be 
ignored and the  DNSbl operator will say that they are not going to 
change their policy for a bunch of people with no clue about real life 
operation of DNSBls.

Regards,

Mat

---

From: Matthew Sullivan <[email-masked]>
Date: Tue, 01 Apr 2008 07:34:40 +1100

Peter J. Holzer wrote:
> current practice, not the lowest common denominator. 

Emphasis should be placed on *Current* as much *best*.  Having a bunch 
of people come up with how they think a DNSbl should/must be run 
(especially when some of them have *no* experience running even a small 
DNSbl let alone a global one) will be counter productive at best.

/ Mat

(Yes I know some here do run global ones, yes I know some here are 
involved in large ones, however there are names here that have nothing 
to do with any current  DNSbl operating let alone running a current one 
themselves.)
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Matthew Sullivan <[email-masked]>
Date: Tue, 01 Apr 2008 07:41:23 +1100

> change their policy for a bunch of people with no clue about real life 

Sorry, that's a pre coffee mail - so could have been worded a lot more 
tactfully, but my point is very clear I think.

/ Mat

---

From: "J D Falk" <[email-masked]>
Date: Mon, 31 Mar 2008 16:58:33 -0400

Matthew Sullivan apologized:

>> the *current* DNSbls operate will make the draft pointless as it will
>> be ignored and the  DNSbl operator will say that they are not going
to
> tactfully, but my point is very clear I think.

Given that you're one of the handful of current DNSBL operators
participating in this conversation, do you feel that the document (with
the changes Chris is working on) is acceptable?

If credentials are necessary, here are some of mine:
- product manager at MAPS, 2000-2001
- designed Hotmail's internal BL while working there 2001-2004
- worked on Yahoo!'s internal lists (of all colors) 2004-2007
- regular speaker on reputation theory & practice at MAAWG
- currently indirectly involved with Return Path's Sender Score
Certified whitelist, and directly working on the Sender Score Blacklist
and other reputation-based products.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: SM <[email-masked]>
Date: Mon, 31 Mar 2008 13:59:27 -0700

>So who are you and what do you have to do with DNSbls?

Replying to that question off-list.

>change their policy for a bunch of people with no clue about real life

A document that doesn't take into account the views of DNSBL 
operators is pointless.  I don't think that's what the author of the 
draft is attempting to do.

Regards,
-sm

---

From: Matthew Sullivan <[email-masked]>
Date: Tue, 01 Apr 2008 08:08:22 +1100

> the changes Chris is working on) is acceptable?

I'm going to read it over the next 2 days (free time permitting and will 
send some comments - as I noted to CL, they are likely to be without 
tact which some regard as rude, this is not the intent just the reality 
of how I review stuff).
> If credentials are necessary, here are some of mine:

Credentials are not required, but as I thought I pointed out current is 
the most important word of BCP, and best a close second.  If a BCP is 
designed that does not follow Best *Current* Practice - regardless of 
whether it is Best or not it is not worth the electrons it is written 
with (paper written on).

Regards,

Matthew

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 31 Mar 2008 17:33:54 -0400

SM wrote:

Edits are []
> operators is pointless.   I don't think that's what the author[s] of the
> draft is [are] attempting to do.

It already does.

Speaking of which, we might be able to side-step such arguments by 
mentioning specific DNSBLs in the "Thanks" section.  I already have one 
lined up if others are willing.  Anybody?  [Privately if you wish.]

Also: perhaps the most worrying point to some DNSBL operators is that a 
document such as this could be used in an adverse manner in a court 
case.  I just had an idea that there could be a "DNSBL user" MUST 
accepting full responsibility for all consequences of a listing, with 
verbiage that they're the ones choosing to use it in a particular 
manner.  That would draw a few bits and pieces out of other bits of the 
document (eg: "fully within their rights to list for any reason 
whatsoever") into one section.

Thoughts?

---

From: Andrew Kirch <[email-masked]>
Date: Mon, 31 Mar 2008 17:47:03 -0400

> change their policy for a bunch of people with no clue about real life 

As all that stuff for the AHBL I amplify and agree with all the points
Mat makes herein.

Andrew
AHBL.org

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 1 Apr 2008 02:08:40 +0200

Chris Lewis wrote:

> I just had an idea that there could be a "DNSBL user" MUST 
> accepting full responsibility for all consequences of a
> listing, with verbiage that they're the ones choosing to
> use it in a particular manner.

Telling users that they MUST aim higher if they do not wish
to shoot into their own foot is kind of pointless.  But you
could still make the responsibility clearer in the draft:

- If you are going to allow a third party to make blocking
- decisions for you, you MUST understand the policies and
= practices of those third parties because responsibility
= for blocking decisions remain ultimately with you, the
= system administrator.

+ If you are going to use the recommendations of a third
+ party for your blocking decisions, you MUST understand
= the policies and practices of those third parties because
= responsibility for blocking decisions remain ultimately
= with you, the system administrator.

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 1 Apr 2008 03:03:30 +0200

Alessandro Vesely wrote:

>> The reverse lookup draft is just in WGLC and should be available
>> if needed as reference.
 
> I guess you mean draft-ietf-dnsop-reverse-mapping-considerations-06.

Yes.  Maybe in combination with the "iprev" method explained in
http://tools.ietf.org/html/draft-kucherawy-sender-auth-header

> connoisseur, and I'm quite lost here.

Whois is a minefield, IMO the last thing a DNSBL BCP needs is to 
explore whois ratholes.  I hope John's technical draft makes it
*before* the BCP.  A DNSBL BCP will run into serious trouble, no
matter what the authors say, the topic is controversial.

> Rfc2050 mentions a database that is maintained by adding
> reassignment information, but doesn't say if and how it is
> published.

Thanks, I didn't know that.  I can't say if it's still up to date.

Embarassing, I don't exactly know how "whois.cymru.com" does its
magic, but rxwhois outputs the result after checking some DNSBLs
for a given IP.

 Frank