At 12:23 PM +0100 4/30/04, Tony Finch wrote:
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".
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
bill(_at_)scconsult(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg