ietf-asrg
[Top] [All Lists]

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

2004-04-30 08:08:15
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 failing to meet the listing criteria, particularly for escalated 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.

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.

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.

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.

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).

(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.)

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

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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg