On Tue, 4 May 2004 11:40:48 +0100, "Matt Sergeant"
<msergeant(_at_)messagelabs(_dot_)com> said:
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.
Ok.
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.
Groovy.
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.
Groovier.
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.
Bummer.
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).
Then the BCP, IMO, shouldn't be that it not be done.
Perhaps the BCP could be narrowed.
I'll review the RR discussions. I recall discussion of broken Notes
installs...
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.
Sorry, that's true, a point Barry further drove home.
I think when it's clearer where the BCP is drawing the lines it draws,
this will be a bit clearer.
Optimist and pessimist listers and listees are currently able to
interpret the BCP rather differently.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg