I'll address some specific points, and hope that Chris can comment on
those I've avoided.
On 3 May 2004, at 23:21, Matthew Elvey wrote:
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.
Because this is just a BCP, whether or not there's disagreement that
SPEWS (or any other blocklist) complies is outside of the scope IMHO.
2.5. Listings SHOULD Be Temporary.
No. Location based RBLs are perfectly legitimate, useful, and there's
no reason for them to be temporary.
A valid point. I believe in an earlier draft we had a footnote about
location based BLs, and it may got lost in the conversion to RFC format
(which doesn't have footnotes). I think this can be covered in the
verbiage for the rule.
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!
OK, this could be clarified to some extent. The authors took the
examples of SPEWS, SBL and CBL as guidance here, which all have audit
trails. However these audit trails don't include the spamtrap addresses
used to generate the listings, so I can see that some clarification
could help here in terms of what data is useful to display to the
public if a public version of the audit trail is provided.
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.]
We tried to avoid codifying a specific shutdown procedure. We would
hope to see that appear in an RFC, rather than in a BCP. If that
happens we could reference said RFC.
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.
And yet there is a lot of disagreement about this (see multiple
discussions about RR doing this).
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.
On the contrary, the authors have thought about this a great deal, and
have discussed the issues here with blocklist maintainers to try and
reach a reasonable level for the BCP that is both achievable, and also
a high enough bar that the BCP is actually useful. If we set the rules
so flexible that anything is possible then there would be little point
in publishing it.
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