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

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.
>   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".  The degree to which its divulged its criteria hasn't 
affected its effectiveness - probably the most effective/FP-averse 
blacklist ever built [It blocks something on the order of 70-75% of all 
of our spam all by itself, with almost indetectable FPs.  The next best 
public BL we use is the SBL at 16%.  SORBSproxy would be around 40%, but 
we don't use it because of its very high overlap with the CBL and the 
storage requirements of using it.]
>   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.
>   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.
[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.
>   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?

>   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.
>   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? ;-)
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg