Re: [Asrg] draft-irtf-asrg-bcp-blacklists-00

["Matthew Elvey" <matthew at elvey.com>]

On Tue, 4 May 2004 11:40:48 +0100, "Matt Sergeant"
<msergeant@messagelabs.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@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg