Subject: [Asrg] draft-irtf-asrg-bcp-blacklists-00

From: Tony Finch <[email-masked]>
Date: Fri, 30 Apr 2004 12:23:31 +0100

One comment:

Section 2.2. MUST Have the Same Criteria for Listing and Delisting.

This rule appears to be saying the wrong thing, when you consider sections
2.5 ... 2.7 which specify other less strict ways of being delisted.

Perhaps 2.2 should say "Failing to meet the criteria for listing MUST be
sufficient grounds for delisting".

-- 
Tony Finch  <[email-masked]>  http://dotat.at/

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

---

From: Bill Cole <[email-masked]>
Date: Fri, 30 Apr 2004 09:24:49 -0400

>sufficient grounds for delisting".

I don't think that even makes sense. Neither has routinely been true 
of most widely-used DNSBL's. The clearest example of an almost 
completely non-controversial and extremely useful list that comes 
nowhere near symmetry in listing and delisting is the CBL. Listing 
and delisting are not simply asymmetric, but orthogonal: addresses go 
one for acting in ways that are common to compromised machines that 
emit spam, and delisting occurs purely for the asking.

In many lists historically (notably the MAPS RBL and the Spamhaus 
SBL) the apparent delisting criteria have been quite a bit less than 
failing to meet the listing criteria, particularly for escalated 
listings. On the other side, it has been my experience in maintaining 
private blacklists that they tend in practice to be tilted the other 
way, with listings being based on rather minimal indication of a 
problem and delistings requiring not just an end to the triggering 
behavior, but some sort of assurance that it will not recur and that 
there is a positive benefit to delisting. My own explanation for this 
covering my own local blacklist is at 
http://www.scconsult.com/scbldetails.html, with the learest bit on 
that abpout 2/3 of the way down the page. I know that this document 
is not aimed at private blacklists and that private and public are 
inherently different, but it is worth considering that multiple 
varieties of blacklist seem to reliably fail to meet a standard of 
symmetry.

In the end, a requirement for symmetry in a BCP doesn't really have 
any meaning. Existing lists are not managed that way in practice, but 
it is a fairly simple matter of formal logic to change their 
published criteria without changing actual practice so that there is 
formal symmetry. For example, the CBL could define its listing 
criteria as having acted like a compromised spam source more recently 
than having had a removal requested or a listing timeout. IOW: take 
the practical delisting criteria, negate them, and add them to the 
listing criteria.  I believe that since Section 2.2 is not actually 
practiced in spirit recognizably anywhere, but that it could be 
formally met without any change in practice and simple adoption of 
more convoluted formal criteria. In short, Section 2.2 does not 
express 'best current practice' in any sense.

I think it also may be better to approach the blacklist issue from a 
model focused on process rather then one concentrated on criteria. 
Every listing has a trigger event, and while that event may be 
triggering an evaluation of criteria,  it may well be (as it seems to 
be with the CBL)  that the event itself carries all the necessary 
information to evaluate the listing criteria, and that a delisting 
cannot possibly be a logical reverse of a listing. For example, one 
might want to list machines that have been seen to HELO with the IP 
address of the server to which they are connecting. That is grossly 
incorrect behavior that  is done fairly frequently by spam-sending 
cracked machines. It is also a very good predictor of future spam 
from the same machine without the telltale bogus HELO, because the 
usual mode of compromise includes an open proxy on the machine, 
making it open to spammers of all intelligence levels and a wide 
range of HELO choices. It is logically impossible to reverse that 
basis for a listing: what is done is done. I believe that it makes 
more sense to recommend that lists define (as far as possible) their 
listing and delisting *processes* clarly, and forget about 
recommending some sort of symmetry for criteria.

(Incidentally, I bring up the CBL for examples because I believe that 
by any measurable standard it is by far the best DNSBL ever 
published, and that any BCP which essentially defined it as 
mismanaged would be making a very harmful mistake.)

-- 
Bill Cole
[email-masked]

---

From: Matt Sergeant <[email-masked]>
Date: Fri, 30 Apr 2004 15:03:44 +0100

> sufficient grounds for delisting".

Yes, we tried to change the wording of this at the last minute to 
forward reference 2.5, but I still felt it wasn't entirely clear. The 
above wording seems better to me. Chris?

Matt.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Matt Sergeant <[email-masked]>
Date: Fri, 30 Apr 2004 15:10:17 +0100

On 30 Apr 2004, at 14:24, Bill Cole wrote:

> nowhere near symmetry in listing and delisting is the CBL.

Delisting in the CBL complies perfectly with the RFC. It is a timeout 
(as per 2.5) or if the problem is cleared up (as per 2.2) or removal 
without question (as per 2.7).

---

From: Matt Sergeant <[email-masked]>
Date: Fri, 30 Apr 2004 15:23:10 +0100

On 30 Apr 2004, at 14:24, Bill Cole wrote:

> In many lists historically (notably the MAPS RBL and the Spamhaus SBL) 
> the apparent delisting criteria have been quite a bit less than 
> listings.

According to the details at 
http://www.spamhaus.org/sbl/sbl-rationale.html this is not the case. In 
all escalations I've seen the SBL do, once the problem is cleared up on 
the escalated network the listing is removed. Do you have recent 
counter examples? I'm sure the SBL operators would be interested.

I can't comment on the RBL as I haven't studied it enough.

> On the other side, it has been my experience in maintaining private 
> blacklists that they tend in practice to be tilted the other way with 
> listings being based on rather minimal indication of a problem and 
> delistings requiring not just an end to the triggering behavior, but 
> some sort of assurance that it will not recur and that there is a 
> positive benefit to delisting. My own explanation for this covering my 
> own local blacklist is at http://www.scconsult.com/scbldetails.html, 
> with the learest bit on that abpout 2/3 of the way down the page. I 
> know that this document is not aimed at private blacklists and that 
> private and public are inherently different, but it is worth 
> considering that multiple varieties of blacklist seem to reliably fail 
> to meet a standard of symmetry.

As you rightly point out, the BCP is specifically focussed on public 
blacklists, as detailed in section 2 "The Guidelines".

Our aim with the BCP was not to fit it around _all_ current practices, 
but to fit it around best practices. If you have good reasons for going 
against the guidelines please state them and we can consider the 
modification of the BCP.

> it is a fairly simple matter of formal logic to change their published 
> criteria without changing actual practice so that there is formal 
> symmetry. For example, the CBL could define its listing criteria as 
> having acted like a compromised spam source more recently than having 
> had a removal requested or a listing timeout. IOW: take the practical 
> delisting criteria, negate them, and add them to the listing criteria. 
>  I believe that since Section 2.2 is not actually practiced in spirit 
> recognizably anywhere, but that it could be formally met without any 
> change in practice and simple adoption of more convoluted formal 
> criteria. In short, Section 2.2 does not express 'best current 
> practice' in any sense.

My gut feeling is it might not be worded right, or you've read it 
wrong, as the intent is in the right place, and it does in the authors' 
experience meet best current practices.

> cannot possibly be a logical reverse of a listing.

This (I think) is your misreading. The BCP in no way means that 2.2 is 
the *only* delisting option. 2.5 is another option for delisting (which 
the CBL uses).

> by any measurable standard it is by far the best DNSBL ever published, 
> and that any BCP which essentially defined it as mismanaged would be 
> making a very harmful mistake.)

Indeed, and the authors agree. We do not thing we have done that.

Matt.

---

From: Seth Breidbart <[email-masked]>
Date: Fri, 30 Apr 2004 10:30:31 -0400 (EDT)

> sufficient grounds for delisting".

Why?  I see no problem with a "sticky" list; for instance, to get
listed an IP must send >X amount of spam in Y time, to get unlisted it
must send <.1X in 10Y.

Seth

---

From: Matt Sergeant <[email-masked]>
Date: Fri, 30 Apr 2004 17:20:26 +0100

> listed an IP must send >X amount of spam in Y time, to get unlisted it

Because this is confusing.

However I don't think it's entirely incompatible with the BCP. The 
listing criteria could be as simple as "We have detected spam coming 
from this IP address". How you "detected" it (by spam levels exceeding 
a threshold) and how you "undetect" it is up to you.

Matt.