On 5/1/04 8:36 PM, Bill Cole sent forth electrons to convey:
However, this sort of framing of criteria makes room for such things
as the SORBS donation requirement.
Which, IMO, is BCP.
I like Walt's Paragraph 0!
Specific comments:
Abstract
1. Introduction
2. The Guidelines.
2.1. "Truth in Advertising".
This should be expanded to a list of specific disclosures that MUST be
disclosed [promptness, removal process,...], in addition to the general
requirement that listing and delisting criteria be provided.
2.2. Same Criteria for Listing and Delisting.
The discussion has made it clear to me that this is a meaningless entry; I can
think of no blacklist policy that would and should be considered a violation.
2.3. Listing/Delisting Criteria MUST Be Easily Available.
There needs to be some accomodation/clarification. Is
http://www.spamcop.net/fom-serve/cache/297.html good enough for 2.1 and 2.3? I can't tell! This needs to be clear, e.g. is this ok?: "Some rules are spelled out in vague terms to slow down spammer adaptation."
2.4. Collateral Damage Only as a Measure of Last Resort.
Some claim SPEWS violates this, but SPEWS itself disagrees (and seems to at
times act specifically to avoid it) and as those parties will always disagree,
I see no benefit to the entry.
2.5. Listings SHOULD Be Temporary.
No. Location based RBLs are perfectly legitimate, useful, and there's no reason
for them to be temporary.
2.6. MUST Have a Direct Non-Public Way to Request Removal.
This is actually poor practice IMO. BCP would be to NOT have a non-public way
to be contacted. Works well to prevent SLAPP suits.
Requiring any contact attempt be via a public forum is BCP.
2.7. Removals MUST Be Prompt.
This should be a matter of policy. "BLs _that claim to be prompt_ must be prompt" makes sense.
2.8. Removals MUST Be Possible in Absence of List Maintainer.
2.9. MUST Have an Audit Trail.
No. BLs based on spamtraps are BCP. Many spammers listwash spamtraps if they
can. NOT providing a full public audit trail is BCP!
2.10. Shutdowns MUST Be Done in a Graceful Fashion.
I suggest a specific result code be codified to represent [urgent action needed
by admin, e.g. this list has shut down, etc.]
3. Special Rules for Blacklists Listing Insecure Machines.
See the SPEWS FAQ for why this is a bad idea.
3.1. No Automated Probes [Scanning or Probes? - inconsistent].
Scanning in response to an attempt to email a system for the first time seems reasonable to me.
3.2. Reasonable Re-scan Periods.
In general, it seems like the authors don't have much respect for the
tireless *volunteer* BL maintainers and need to spend more time thinking
about things from the POV of the BL maintainers.
It's surprising that we're spending time on this when there isn't even a
current BCP for how abuse desks should be run. There's bestprac.org,
but no IETF document, AFAIK. Cart before the horse if you ask me: most
BLs are run responsibly; most abuse desks aren't. But a BCP is a good
idea, so there are some ideas.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg