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

On 5/4/04 9:28 AM, Chris Lewis sent forth electrons to convey:

> Matthew Elvey wrote:
>
> >   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.
>
> I can think of a couple.  Here's one: a blacklist entry that was 
> created solely on the existance of an open proxy, yet delisting 
> required that the system owner provided rDNS and postmaster 
> accessibility IN ADDITION to fixing the proxy.  Desirable yes, but, 
> this goes beyond the BLs stated purpose, and unnecessarily conflates 
> anti-spam with non-spam issues.  rDNS/postmaster were irrelevant to 
> the original listing, they should remain irrelevant to a subsequent 
> delisting. 
That's not a valid example.  If these additional requirements were not 
in the BL's stated delisting, then this issue was covered in
2.1. "Truth in Advertising".  2.2 is unnecessary and confusing.  The BLs stated purpose could include enforcing these 

requirements on wannabe-former listees.  I.e. it may be false that "this 
goes beyond the BLs stated purpose."
> >   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."
>
> That was deliberately somewhat vague, rather than requiring explicit 
> details, for precisely the reasons you indicate.  For example, the CBL 
> does not enumerate exact detection heuristics, but does provide what 
> its criteria is: "exhibits symptoms of being compromised by a spam 
> trojan or open proxy".
Vagueness here is undesirable.  Here's my specific text suggestion: 2.3 
would benefit from the addition of sentences like:  The precise 
algorithms and data used for listing and delisting do not need to be 
disclosed.  Some criteria may be vaguely defined 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.
>
> It provides general guidance.  This is a BCP, not a RFC.  It is 
> intended to forestall "blacklist an entire country because of one 
> spam". Some may claim that SPEWS violates this, but not me - it's 
> abundantly clear that SPEWS follows an escalation path.  The fact that 
> someone might disagree whether a given BL complies is the simple 
> nature of BCPs.
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.
>
> Good point.
>
> >   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.
>
> It's least commonly used practise.  Almost all BLs maintain a contact 
> email address or web site of some sort.  The BCP doesn't require the 
> operators of the BL to identify themselves.  Eg: the CBL is in 
> compliance.  So is ORDB.
> SPEWS could, if they wished to, implement a non-public channel of some 
> sort without exposing themselves.  Even by anonymizing relays. 
> Unfortunately, their policy of "replies by NANAE/NANAB" unnecessarily 
> politicizes the process, and results in a very large number of sites 
> simply ignoring them altogether. Few ISPs dare the wrath of NANAE, 
> much as we would wish otherwise. 
I can't think of any benefit that 2.6 would provide.  I claim that any 
question re. SPEWS is likely going to be answered faster and better via 
a nanae/nanabl posting.  Please provide a specific counterexample, but I 
request that you assume that the folks who run SPEWS are as friendly as 
the posters on nanae/nanabl. 
Most any ISP that fears the wrath of NANAE probably already knows any 
info that a posting on NANAE, or a private inquiry to SPEWS would 
provide, and is choosing to ignore it.   All those free, trusted, 
subpoena-proof, malicious-Tier1-ISP-proof anonymizing relays ... 
something many RBL maintainers probably don't know to be available; I 
don't.  If the BCP is going to suggest this, links or some such to 
working mixmaster software/sites/RFCs would be appropriate (RFCs 
generally musn't have bare URLs in 'em; I forget what the workaround for 
that is.)
> [This is my only BCP-derived criticism of SPEWS btw.]
>
> >   2.7. Removals MUST Be Prompt.
> > This should be a matter of policy.  "BLs _that claim to be prompt_ 
> > must be prompt" makes sense.
>
> I think this may be a good change.
:)

> >    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!
>
> We didn't say what the "audit trail" was.  A date stamp (perturbed if 
> you wish) of detection would be adequate.  CBL does that.
Great, IF the BCP  makes it clear that this is adequate.  Currently, a 
claim that the BCP(-wannabe) requires a full unmunged copy of a spam 
causing a listing would be hard to argue against.
Here's another specific text suggestion: 2.9 would benefit from the 
addition of a fragment like:  "...SHOULD make [insert :part of ] it 
publically...". The precise data does not need to be disclosed.  Some 
data provided from the audit trail may be hidden, removed or altered to 
slow down spammer adaptation.  A full internal audit trail MUST be kept. 
Perhaps then the SHOULD could become a MUST.
> >   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'd like to, unfortunately, this isn't backwards compatible - most 
> implementations would treat "a specific result code" as being 
> "listed", resulting in "block the world".  I've seen some proposals 
> for DNS server tricks that would serve the dual purpose of 
> decommissioning the blacklists and getting the queries _off_ the 
> no-longer-BL server. But we thought that would take to long to 
> codify.  If someone wants to propose something, it would be good.
> >   3. Special Rules for Blacklists Listing Insecure Machines.
> > See the SPEWS FAQ for why this is a bad idea.
>
> Which section?
From A45:
Due to abuse by spammers, open email relays no longer have any place on 
the Internet. Some may want to debate this, we won't.
It was 3.1's "spam in hand" requirement that prompted my comment.   A 
BLs policy should state whether it will list w/o "spam in hand".
> >   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.
>
> Not to me, because it's too far along the line of "we scan 0/0").
>
> Scanning/probing them in response to an email they try to send you is 
> different.
It's not different from what the BCP as currently written prohibits.

> >   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.
>
> You're making at least three huge assumptions here, and I assure you, 
> all are incorrect.  Unfortunately, aside from suggesting you google 
> for my name on Usenet (eg: NANA.bulletins) in the 1994-2000 period, 
> answering this directly would have you holding me to a higher standard 
> than our proposed BCP would. In other words, what makes you think I'm 
> not running a public BL and know full well that POV? ;-)
:)  Call it a gut feeling.  I suppose if you were behind a fabulous BL 
that was highly effective while remaining compliant with even the 
strictest interpretation of this draft, I wouldn't be surprised by the 
POV I discern in the draft.  But I don't know of any such BL.  E.g. I 
think even the CBL and SBL are not compliant with a strict 
interpretation, hence some of the suggestions I've made.  I tend to read 
and write with a <how could this be interpreted by a competent malicious 
lawyer> hat on.  Apologies and thanks if you do.  Some compromised 
machine BLs may well already be compliant...
Oh, and good point in another email - the BCP should encourage BL usage.

> I don't think BCP'ing a requirement that ISPs permit their users 
> choice as to which BL to use is practical, desirable or even useful.
> Indeed, such a BCP would be a complete waste of time for _us_, because 
> our users (employees) don't get that option by policy. 
There are good arguments on both sides of this, e.g:
Good argument: We block email from open proxies/relays.  This is a 
security issue; we must protect ourselves from attack.
Good argument: Some ISP or gov't agency has caused the machine of an org 
they don't like to be listed as open relay on some BL, even though it 
isn't an open relay, in order to suppress free speech.  It is possible 
for a white hat BL operator to be an unwitting censor in this way.
This is one more reason why I like SPEWS' use of nanabl.  If a BL is 
allegedly misbehaving, I've always thought it should be the subject of a 
public discussion in a well defined forum.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg