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