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

From: "Chris Lewis" <[email-masked]>
Date: Sat, 01 May 2004 23:03:04 -0400

Matt Sergeant wrote:

> On 30 Apr 2004, at 15:30, Seth Breidbart wrote:
> 
>>> Perhaps 2.2 should say "Failing to meet the criteria for listing MUST be
>>> sufficient grounds for delisting".

>> Why?  I see no problem with a "sticky" list; for instance, to get
>> listed an IP must send >X amount of spam in Y time, to get unlisted it
>> must send <.1X in 10Y.

> Because this is confusing.

> However I don't think it's entirely incompatible with the BCP. The 
> listing criteria could be as simple as "We have detected spam coming 
> from this IP address". How you "detected" it (by spam levels exceeding a 
> threshold) and how you "undetect" it is up to you.

I agree.  The intent was to "frown" on delisting requirements orthogonal 
to the listing.  Like payment of fees, or other things that had nothing 
to do with the listing.

An element of hysteresis (ie: timewise or thresholdwise) is okay, IMO.

I think I prefer Tony's wording.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Bill Cole <[email-masked]>
Date: Sat, 1 May 2004 23:36:49 -0400

At 11:03 PM -0400 5/1/04, Chris Lewis wrote:
>>listing criteria could be as simple as "We have detected spam 
>>coming from this IP address". How you "detected" it (by spam levels 
>>exceeding a threshold) and how you "undetect" it is up to you.
>
>I agree.  The intent was to "frown" on delisting requirements 
>orthogonal to the listing.  Like payment of fees, or other things 
>that had nothing to do with the listing.
>

I agree but it remains imperfect.

It is a matter of phrasing of criteria to some extent. e.g. for the 
CBL, if you describe the condition for listing as "having acted like 
a compromised machine emitting spam within the timeout period and 
without having since requested removal" then failing to meet the 
listing criteria does effect a delisting.

However, this sort of framing of criteria makes room for such things 
as the SORBS donation requirement.

I'm not sure where a solution is.

-- 
Bill Cole                                  
[email-masked]

---

From: Matt Sergeant <[email-masked]>
Date: Sun, 2 May 2004 20:56:17 +0100 (BST)

> as the SORBS donation requirement.

In designing the BCP we didn't think something like SORBS donation 
requirement should be excluded, so long as this requirement is clearly 
listed on their web site.

Matt.

---

From: "Walter Dnes" <[email-masked]>
Date: Sun, 2 May 2004 17:59:08 -0400

On Fri, Apr 30, 2004 at 03:23:10PM +0100, Matt Sergeant wrote

> Our aim with the BCP was not to fit it around _all_ current practices,
> but to fit it around best practices. If you have good reasons for
> going against the guidelines please state them and we can consider
> the modification of the BCP.

  The BCP document assumes that people are nice, or at least polite.  If
they were, there wouldn't be a need for DNSbl's in the first place.  In
a "kinder gentler" world, paragraph 2.6 MUST-have-a-contact requirement
would make sense.  However, in real life, spammers aren't nice.  Consider
the following...

  - MAPS was sued into uselessness by a bunch of dot-coms flush with
    cash from IPO's who engaged in the lawsuit equivalent of a gang-rape

  - Felstein and company left a bunch of people out of pocket thousands
    of dollars in legal fees, even though the civil complaints were
    dropped and the case never got to trial

  - Scott Richter is currently suing SpamCop

  Unlike British Commonwealth countries (Britain, Canada, Australia,
etc) the USA does *NOT* have an automatic "loser pays" clause for
lawsuits.  The USA gave the world SLAPP.  Would you care to provide
multi-million dollar funds in escrow to defend against such lawsuits and
pay off any stupid judgements awarded by juries?

  And it's not merely a case of money.  I wouldn't be surprised if the
mobsters behind some of the spammers resorted to contract killings to
shut down impediments to their "bizniss".  In a climate like this, I
understand why the principals behind SPEWS seek anonymity.  Please
understand that we're dealing with a bunch of thugs, hooligans, and
criminals.  If we get into a streetfight against them whilst restricting
ourselves to Marquis of Queensbury rules, we're guaranteed to lose.

  If I sound passionate, it's because DNSbls help keep my email usable,
which gives me a personal stake in the success/failure of DNSbls.  If
they go under, I'll either switch to whitelist-only, or possibly give up
on email altogether.

  In terms of improvements to this BCP, I have an idea that would render
the rest of the BCP moot...

====================================================================
Paragraph 0
  Internet Service Providers who provide inbound email service to the
public *MUST* allow individual customers to select which DNSbls and/or
filters are applied to their incoming email, except as listed below.
The only exceptions shall be...

  1) When an incoming email is reliably confirmed to be a virus by a
scanner, it may be either rejected at the SMTP stage with a 5xx message
or diverted into a quarantined folder or dropped.  It *MUST NOT* trigger
a DSN to the alleged sender of the email, because email source info
(both From: and Envelope-Sender) is usually forged by viruses.

  2) IP addresses which launch Denial-Of-Service attacks or dictionary
attacks on the ISP may be ignored by the mailserver or firewalled or
null-routed or blocked via other purely defensive measures.
====================================================================

  The real problem is ISPs who use the one-size-fits-all approach, and
use the same DNSbl(s) for all their clients.  Allow people to use which
ever DNSbls they want, and the bad DNSbls lose users, and fade away.
DNSbls with good reputations would have lots of users.  This would also
provide ISPs some protection against lawsuits by spammers, because the
ISP would not be responsible for an individual user's choice of blocking
criteria.

-- 
Walter Dnes <[email-masked]>
Email users are divided into two classes;
1) Those who have effective spam-blocking
2) Those who wish they did

---

From: Barry Shein <[email-masked]>
Date: Mon, 3 May 2004 18:02:20 -0400

I certainly agree with the spirit of what Walter Dnes is saying below.

Looking at the BCP draft makes me feel like I'm watching a bunch of
cub scouts propose how to deal with Al Qaeda.

So if we're voting, in some sense, you can count my vote as "no,
because this draft is embarrassingly naive".

	-b

---

From: Matthew Elvey <[email-masked]>
Date: Mon, 03 May 2004 15:21:17 -0700

> as the SORBS donation requirement.

Which, IMO, is BCP. 

I like Walt's Paragraph 0!

Specific comments:

  Abstract
   1. Introduction
   2. The Guidelines.
   2.1. "Truth in Advertising".
This should be expanded to a list of specific disclosures that MUST be disclosed [promptness, removal process,...], in addition to the general requirement that listing and delisting criteria be provided.
   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.

   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."
   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.
   2.5. Listings SHOULD Be Temporary.
No. Location based RBLs are perfectly legitimate, useful, and there's no reason for them to be temporary.
   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.
   2.7. Removals MUST Be Prompt.
This should be a matter of policy.  "BLs _that claim to be prompt_ must be prompt" makes sense.  
   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!
   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.]
   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.
   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.
It's surprising that we're spending time on this when there isn't even a 
current BCP for how abuse desks should be run.  There's bestprac.org, 
but no IETF document, AFAIK. Cart before the horse if you ask me: most 
BLs are run responsibly; most abuse desks aren't. But a BCP is a good 
idea, so there are some ideas.

---

From: Barry Shein <[email-masked]>
Date: Tue, 4 May 2004 00:16:08 -0400

> about things from the POV of the BL maintainers.

I think one of the worst features of BLs are that they're often run by
volunteers who can then feel sorry for themselves when they get in
over their heads.

But so long as that's disclosed I have no problem with volunteer BLs
existing, per se, not my point. I just don't think the fact that
they're (often) volunteer staffed should be grounds to give them a lot
of slack on BCP.

The problem is there's too much potential for damage and chaos, and
being able to say "well we're not being paid anyhow" isn't really
something very good to codify. Imagine if volunteer MD's said oh well,
we weren't paid anyhow, sorry about the botched surgery, go warn your
friends not to use us anymore...

Free software is one thing, but something like a BL has some non-zero
potential to do significant damage if poorly run, particularly if
suddenly poorly run (it was great until finals week!)

I'd've skipped saying something so obvious but there it was right in
that message, "respect for the tireless *volunteer* BL maintainers".

-- 
        -Barry Shein

Software Tool & Die    | [email-masked]           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
The World              | Public Access Internet     | Since 1989     *oo*

---

From: Matt Sergeant <[email-masked]>
Date: Tue, 4 May 2004 11:40:48 +0100

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:

> 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.

> 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.

> 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.

> 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.

> time seems reasonable to me.

And yet there is a lot of disagreement about this (see multiple 
discussions about RR doing this).

> 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 
______________________________________________________________________

---

From: Bill Cole <[email-masked]>
Date: Tue, 4 May 2004 09:25:38 -0400

At 11:40 AM +0100 5/4/04, Matt Sergeant wrote:

[...]
>happens we could reference said RFC.

Do you mean a descendant of 
http://www.ietf.org/internet-drafts/draft-irtf-asrg-dnsbl-00.txt or 
some additional RFC?

Outlines for orderly shutdown of DNSBL's have been composed and 
posted publicly in 3 waves over the past 3 years (unfortunately in 
the first 2 cases, AFTER operators have listed the entire net to 
drive away users) and it is not a complicated matter or really a very 
controversial issue, it's just quite specific. It boils down to a 
method for shutting down any zone: add a long-TTL NS record for the 
zone into the parent zone with a RHS of either "." or a name in the 
parent zone with a long-TTL A record with a RHS of either '.' or to 
an address in 127/8 other than 127.0.0.1.

The only reason that orderly shutdown has ever been an issue is that 
the most noisily terminated DNSBL's have been run by people who sadly 
have been clueless about DNS. There's no need for a complex dance of 
special entries in-zone alerting users to the death of a DNSBL, 
giving way to eventually just going dead or listing the entire net.

>discussions about RR doing this).

There are huge disagreements over when security probes without 
explicit permission might be acceptable. It is surprising to me that 
there is not already an RFC of some sort covering that, as it is an 
issue that extends far beyond the issue of spam.

>>In general, it seems like the authors don't have much respect for 
>>the tireless *volunteer* BL maintainers and need to spend more time 
>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.

Do you consider technical best practices relevant to this BCP or not?

I ask because it seems that the draft is focused on policy best 
practices, and while that is useful it is not the low-hanging fruit. 
A few tips for those well-meaning but not always technically adept 
volunteers would be good, and facilitate things like orderly 
shutdown. For example:

MUST have NS records for the base zone and any sub-zone that 
represents a discrete list (this facilitates scalability and hence 
attack resistance of a list, as well as making orderly shutdown more 
orderly)

MUST NOT make the availability of documentation of the list dependant 
on continued operation of DNS for the list's zone. (This keeps the 
documentation of a list out of the line of fire of attacks and allows 
for the continued existence of something like a web page saying "It's 
dead!" even after an orderly shutdown)

SHOULD NOT have any records in the DNSBL zone other than DNSBL 
entries (again, this assists in orderly shutdown, because it makes 
the zone used fo0r the list disposable)

MAY list loopback, RFC1918, LINK-LOCAL, class D/E, and any other 
permanently reserved or special-use IPv4 addresses and MUST publicly 
document  any such listings. (It is a rare month when no one 
expresses shock in public that some address with purely local meaning 
is in some DNSBL. It has been suggested that some reserved address be 
used as a test for whether a list is alive. )

Those may be slightly debatable on strength, but it seems to me that 
if there is going to be a formal codification and documentation of 
DNSBL practice, it would be a good thing to at least alert people 
referring to the documents to some of the technical pitfalls hit by 
prior operators and how to avoid them.

-- 
Bill Cole                                  
[email-masked]

---

From: Bill Cole <[email-masked]>
Date: Tue, 4 May 2004 09:26:50 -0400

>they're (often) volunteer staffed should be grounds to give them a lot

Absolutely correct, indeed the reason there needs to be a BCP is that 
there is an established history of some of those amateur volunteers 
(including one owner of a small ISP) doing spectacularly bad things 
with their DNSBL's.

Draft 00 doesn't cover the most common and easiest to avoid technical 
sloppiness  of DNSBL's. I hope that is going to be fixed.

-- 
Bill Cole
[email-masked]

---

From: Matt Sergeant <[email-masked]>
Date: Tue, 4 May 2004 16:00:04 +0100

> Do you consider technical best practices relevant to this BCP or not?

I'd like input from Chris on this question as I had not really 
considered technical best practices.

Matt.

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 04 May 2004 12:28:10 -0400

Matthew Elvey wrote:

> 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.

> 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.]

> 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.

> reason for them to be temporary.

Good point.

> 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.

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.]

> This should be a matter of policy.  "BLs _that claim to be prompt_ must 

I think this may be a good change.

> 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.

> 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.

> See the SPEWS FAQ for why this is a bad idea.

Which section?

> Scanning in response to an attempt to email a system for the first time 

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.

> 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? ;-)

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 04 May 2004 12:44:45 -0400

> cub scouts propose how to deal with Al Qaeda.

I had to deal with the GruBourVulis - you remember that, don't you?  I 
assure you, I know rather more about this than a cub scout...

>  > would make sense.  However, in real life, spammers aren't nice.  Consider

We're well aware of them.  Amongst other things, Matt and I were 
physically present when Felstein went after Alan Murphy of SpamHaus (and 
the FTC commissioner ;-)

You're presupposing the BCP requires BL operators to identify 
themselves.  It does not.  ORDB, CBL and many other BLs do not. Just a 
non-public contact address or web site.  Via anonymizing relays if desired.

>  > they go under, I'll either switch to whitelist-only, or possibly give up

Put me in for a big ditto on that.  This BCP should have almost zero 
effect on current useful BLs.  Furthermore, I suspect that this will 
encourage more large sites to use BLs. Which is a huge win for BLs and 
anti-spam.

>  > the rest of the BCP moot...

The primary intent behind the BCP was to give BL operators an 
understanding that they should formalize their operations well enough to 
allow ISPs (or individuals) to make informed choices on what BL they 
use.  To make it clear to them, for example, whether spite listings were 
to be expected, or whether you could rely on the BL's "reasonably 
timely" response to problem reports. In other words, accurate depictions 
of what the BL does, how well they're run, to help a site or user 
determine how much trust to place in the BL.

Sites and users need to know these things in order to make informed
choices.

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.

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 04 May 2004 13:14:47 -0400

> considered technical best practices.

Technical best practises are best suited for John Levine's DNSBL RFC. 
Most of the things you'd want to be there should be elevated to RFC 
"MUST"s or "SHOULD"s, because that is what DNSBL "client" 
implementations need to program to.

I've always considered our BCP to be a "policy" BCP, not a technical 
one.  An operational guide.

That being said, John Levine and I debated whether "DNSBL shutdown" 
should be documented in his RFC or our BCP.  I _personally_ would have 
preferred it being in the RFC.  However, the "implementations" of 
high-volume DNSBL shutdown we've seen heretofore have all been, um, 
"suboptimal" ;-) [+], and I as yet haven't seen a "reasonable" one yet 
(at least one that I understood.  I know someone who has commented at 
length on "how to do this right", perhaps I can get a detailed explanation.

I talked to Yakov and John about this and they both suggested we leave 
this undefined in this draft rather than expend time trying to invent a 
wholly new procedure.

[+] In some cases I can't say that I blame them...  But it would be nice 
to have a suggested method so that BL operators don't find themselves in 
a bind later.  As one possible example: _don't_ use a BL domain name you 
wouldn't mind deregistering later.

---

From: Seth Breidbart <[email-masked]>
Date: Tue, 4 May 2004 13:21:57 -0400 (EDT)

> as to which BL to use is practical, desirable or even useful.

I think that is the best commercial practice; however, it's for ISPs,
not the lists themselves.  Is there any way that a list can either aid
or prevent an ISP if the ISP wishes (not) to provide such granularity?
I think the point is moot wrt lists.

> our users (employees) don't get that option by policy.

You're a company, not an ISP.  (Even an ISP's practies wrt its
employees might well differ from those wrt its customers.)

Seth

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 04 May 2004 13:49:08 -0400

> I think the point is moot wrt lists.

Exactly.  This BCP is about lists, not list users, yet, this BCP is 
intended to give the information that an ISP or user would want to know 
in order to make informed choices if such granularity was available, or 
even if it wasn't.

> employees might well differ from those wrt its customers.)

That's why I said that ;-)

---

From: Barry Shein <[email-masked]>
Date: Tue, 4 May 2004 16:20:49 -0400

> assure you, I know rather more about this than a cub scout...

To be perfectly honest, not really, tho I know the word is a
combination of two or three names one of which is Steve Boursy and
another is a guy named Grubor and I assume another Vulis.

Did they ever shoot at you?

-- 
        -Barry Shein

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 04 May 2004 16:58:33 -0400

> Did they ever shoot at you?

Just about everything short of that, including death threats, $50K 
"rewards" for my demise, and bogus police complaints (about stealing > 
$500,000 worth of Suns on other people's credit cards) etc.

---

From: "Matthew Elvey" <[email-masked]>
Date: Tue, 04 May 2004 14:03:42 -0700

> SPEWS (or any other blocklist) complies is outside of the scope IMHO.
Ok.
> (which doesn't have footnotes). I think this can be covered in the 
Groovy.
> public if a public version of the audit trail is provided.
Groovier.
> happens we could reference said RFC.
Bummer.
> 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 
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.

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 04 May 2004 17:42:00 -0400

> I'll review the RR discussions.  I recall discussion of broken Notes

RR took the position that "if you expect us to accept your email, you 
shouldn't quibble about us making sure that your system is secure".

These were "email in hand" scans, not unprovoked.  Most "vulnerability" 
blacklists are at least "email in hand".  I can't think of anybody doing 
unprovoked scanning now.

I think the wording is poor.  It should be "No unprovoked scanning or 
probing".  Where "mere existance" shouldn't be considered sufficient 
provocation ;-)

Mebe we should be much more specific and decide whether we want to say 
"email in hand" or "spam in hand" (from this IP).

---

From: Matthew Elvey <[email-masked]>
Date: Tue, 04 May 2004 16:48:37 -0700

> Outlines for orderly shutdown of DNSBL's have been composed and posted 
> publicly in 3 waves over the past 3 years (unfortunately in the first 
> 2 cases, AFTER operators have listed the entire net to drive away 
> users) and it is not a complicated matter or really a very 
> parent zone with a long-TTL A record with a RHS of either '.' or to an 
> address in 127/8 other than 127.0.0.1.
>
> special entries in-zone alerting users to the death of a DNSBL, giving 
> way to eventually just going dead or listing the entire net.

Yes, I remember the long discussions well.  This would be *great* to 
have in the BCP (or perhaps RC, perhaps better expressed: with 
[counter-]examples.)  It would have saved a lot of grief, methinks.

>
> [And a bunch of other technical BCP that I (elvey) would also strongly 
> like to see added - good stuff.]

---

From: Matthew Elvey <[email-masked]>
Date: Tue, 04 May 2004 18:18:27 -0700

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

>> 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."

>> 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."
>
>
> 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.

> 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.

> 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.)

> I think this may be a good change.

:)

> 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.

> 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.
>

 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".

> Scanning/probing them in response to an email they try to send you is 

It's not different from what the BCP as currently written prohibits.

> all are incorrect.  Unfortunately, aside from suggesting you google 
> for my name on Usenet (eg: NANA.bulletins) in the 1994-2000 period, 

:)  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.
>

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.

---

From: Matthew Elvey <[email-masked]>
Date: Tue, 04 May 2004 19:16:05 -0700

On 5/4/04 2:42 PM, Chris Lewis sent forth electrons to convey:

> f

Sounds good.

> "email in hand"

That would work too, IMO.

>  (from this IP).

PHB: SpamSchool 101: BLs don't block (or embargo) anything.  The users 
of BLs do.  

You say BLs (including RHSBLs, yes?) must not be anonymous, but provide 
no counterargument to my and others arguments for anonymity.

>Best Practices require that any party that seeks to hold
>the Internet community accountable should itself accept
>accountability.
>
Says you.  Besides, accountability and anonymity are not mutually 
exclusive.  Part of the goal of the ASRG is to provide both at the same 
time.

Perhaps the draft would benefit from a section pointing out that BL 
maintainers are merely expressing an opinion, and it is their absolute 
right to do so free of legal encumberance, and in violation of the BCP, 
but that by heeding the BCP they may gain the trust of their users.

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 04 May 2004 22:58:40 -0400

> no counterargument to my and others arguments for anonymity.

We're not arguing against (nor does the BCP) anonymity.  Just saying 
that there should be a non-public contact mechanism.  I'll amplify that 
in a reply to the comment about spews tomorrow morning.

> but that by heeding the BCP they may gain the trust of their users.

This'd probably be a good idea for the introduction.

---

From: "Walter Dnes" <[email-masked]>
Date: Wed, 5 May 2004 00:05:50 -0400

On Tue, May 04, 2004 at 12:44:45PM -0400, Chris Lewis wrote

> > >   In terms of improvements to this BCP, I have an idea that
> > > would render the rest of the BCP moot...

> Indeed, such a BCP would be a complete waste of time for _us_,
> because our users (employees) don't get that option by policy.

  That's not what I meant.  I specifically refered to clients.  The
employees are *NOT* your paying clients, so that requirement can not be
read as applying to them.

  The ISP I use for my remote inbox has enduser-configurable blocking
rulesets.  I block Nigeria, most of non-English Asia, Isreal, chunks of
Europe, and 200.0.0.0/7 (Latin America).  People over there effectively
see challenge/response from me.  Before anyone starts ranting about
"Challenge Response Authentication Protocol", my challenge is a 550
message issued right after the RCPT: stage of the SMTP transaction.  It
contains a URL pointing to my webpage which lists my current, temporary,
unfiltered email address.

  Different people end up on different spam lists.  And of course, someone
who has business contacts, friends, and/or family in the above-mentioned
countries would obviously not like my particular configuration.  I see
the biggest problem with DNSbl usage (and filter usage for that matter)
as being the one-size-fits-all approach.  People are different, and
there email requirements are different.

  The document is about best practices with regards to DNSbls, and it
should include ISPs' usage thereof.  *THE* biggest problem associated
with DNSbls today is that endusers often don't have a say about their
usage (not even whitelisting ability).

  It's easy for many in the "NANAE elite" crowd to switch ISP and
re-route incoming email addressed to a personal domain, without having
to notify dozens or hundreds of contacts about a new email address.  Joe
average does not have that ability, and big corporations find ISP
switchovers a painful experience.  They are stuck with being blacklisted
even if they personally don't spam.  This creates lots of public
resentment which the DMA will capitalize on.

  Failing to address that problem will give the DMA allies (like David
Berlind) in their fight to outlaw DNSbls or at least ram ISP-wide
whitelists down ISPs' throats.  Making use-of-DNSbls an enduser decision
will allow ISPs to point the finger at paying customers and say that
they excercised freedom of choice.  It will take away spammers' main
argument in lawsuits and for anti-DNSbl legislation.

---

From: Bill Cole <[email-masked]>
Date: Wed, 5 May 2004 00:27:12 -0400

At 1:14 PM -0400 5/4/04, Chris Lewis wrote:
>Technical best practises are best suited for John Levine's DNSBL 
>RFC. Most of the things you'd want to be there should be elevated to 
>RFC "MUST"s or "SHOULD"s, because that is what DNSBL "client" 
>should be documented in his RFC or our BCP.  I _personally_ would 
>have preferred it being in the RFC.  However, the "implementations" 
>of high-volume DNSBL shutdown we've seen heretofore have all been, 
>um, "suboptimal" ;-) [+], and I as yet haven't seen a "reasonable" 
>one yet (at least one that I understood.  I know someone who has 
>commented at length on "how to do this right", perhaps I can get a 
>detailed explanation.

Well, I'm pretty sure that you've seen me and at least one other 
(probably more respected) DNS geek say approximately the same thing 
that I posted this morning, on the same day back when RFG was 
complaining about people continuing to query his dead lists.  Others 
posted very similar (i.e. effectively identical) suggestions in 
response to RFG directly then. I'd very much appreciate some clue as 
to why it is suboptimal or unclear.

Just to repeat for clarity, in excruciating detail:

If a DNSBL had, when operating, entries of the form 
1.0.0.127.dnsbl.example.com and the operator wishes to shut down the 
DNSBL, retaining the functionality of example.com as a working domain 
and minimizing queries from people who have not gotten the message 
yet about the shutdown, one of three sets of records should be added 
to the example.com zone (assuming BIND-like syntax and an $ORIGIN of 
example.com):

Set 1:

dnsbl		604800	IN	NS	.

Set 2:

dnsbl		604800	IN	NS	deadend
deadend		604800	IN	A	.

Set 3:

dnsbl		604800	IN	NS	deadend
deadend		604800	IN	A	127.255.255.255

The three options break down pretty easily. #1 is simplest but I'm 
not sure that it is technically proper. #2 is probably technically 
proper, but the '.' RHS may be confusing for some people (or even 
resolvers) who see it. #3 seems to me the wisest choice, because it 
does not depend on a resolver understanding the '.' RHS and is likely 
to look clearly abnormal to any human likely to examine query 
results. Steve Atkins seems to like the '.' but it seems too cute to 
me.

The effect of all of these, assuming sane resolver function, is that 
any resolver trying to query any of the now-dead DNSBL's records will 
be directed to ask the question of a nameserver that cannot exist. 
The long TTL (a week, which is the default maximum in BIND 9 and so 
is about as long as is useful) means that resolvers will query the 
nameserver for example.com, be told to ask the bogus nameserver for 
any DNSBL records, and cache that referral for a week.

I personally prefer option #3 because it adds a bit of a twist that I 
think is useful. Most common (many? all?) IP implementations will not 
by default understand that an address in 127/8 other than the 
standard loopback of 127.0.0.1 is bogus, and so will query that 
address as if it were a normal IP address of a real nameserver. That 
means that queries against the DNSBL will each take the amount of 
time it takes the requester's resolver to time out on a query. This 
means that the people who continue to use the DNSBL after its demise 
will likely notice a problem, and on investigation will be able to 
discern that the list is dead, yet they will not be subject to the 
severe problems that come from the sadly customary practice of 
listing the whole world to get the attention of users who have not 
yet given up.

>I talked to Yakov and John about this and they both suggested we 
>leave this undefined in this draft rather than expend time trying to 
>invent a wholly new procedure.

It has to be done at some point, unless these drafts are intended to 
end their lives as drafts.

>[+] In some cases I can't say that I blame them...  But it would be 
>nice to have a suggested method so that BL operators don't find 
>themselves in a bind later.  As one possible example: _don't_ use a 
>BL domain name you wouldn't mind deregistering later.

I don't think that's necessary, and it's really rude to the 
registry-level nameservers.

I think the rule along those lines should be that a DNSBL should be 
logically severable in all ways at a domain element boundary (aka: a 
dot)  which is also a DNS zone cut (i.e. there are NS records for 
the severable domain name) and which is disposable in the event that 
the DNSBL is shut down. In short: a DNSBL should be within a DNS 
equivalent of an airplane 'comfort bag.' It should not be used to 
carry anything else that you might ever want to keep.

I wrote the MUST's and SHOULD's a bit back in the thread.

-- 
Bill Cole                                  
[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Wed, 05 May 2004 08:52:52 +0100

Bill Cole <[email-masked]> wrote:
>results.

#2 is a syntax error. The IP address on the RHS of an A record is not
a domain so it must have four numerical parts separated by dots. Nothing
else will do.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
LANDS END TO ST DAVIDS HEAD INCLUDING THE BRISTOL CHANNEL: NORTHWEST 6 OR 7,
DECREASING 5 IN THE EAST. SHOWERS. GOOD. MODERATE OR ROUGH, OCCASIONALLY VERY
ROUGH AT FIRST IN THE WEST, BECOMING SLIGHT IN THE EAST.

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 05 May 2004 14:17:45 -0400

> 2.1. "Truth in Advertising".

You _could_ do it that way.  But this runs into a number of problems. 
One of which being a crack to stick the wedge of impropriety in. 
Believe me, it's best for the blacklist _owner_ to do whatever they can 
that has the slightest whiff of ulterior motives.  Ie: "pay me to get 
out of the list".  Which is either extortion or protection rackets or both.

I strongly believe that any blacklist owner who does think through all 
of the ramifications of "extra delisting requirements" will realize it's 
in their best interests to avoid them.  In a legal sense.  Objectivity 
and pinpoint accuracy is always to be preferred if there's no compelling 
reason to do otherwise (ie: SPEWS being inherently and deliberately 
subjective).  Subjective isn't _wrong_, just unnecessary-to-the-goal 
subjectivity is dangerous - to the blacklist admin's legal liability - 
even if only a frivolous claim.

When I was Usenet despamming (for about 6 years), there were many 
opportunities to do things like this.  Some perfectly reasonable, some 
not.  And I've watched other de/anti spammers go through some of the 
same temptations and the flamewars and worse that resulted.  It's simply 
never preferable to do anything that is even remotely close to imposing 
something on the listee that benefits _you_, or isn't directly related 
to the listing.  That ONLY provides leverage for legal action, justified 
or not.

That's 10 years hard labour in the trenches (with at times an average of 
one lawsuit threat per _day_) speaking.

This recommendation serves to _lessen_ the BL owner's potential legal 
problems, not the opposite.

> disclosed.  Some criteria may be vaguely defined to slow down spammer 

I think clarification of intent along that line would be a good idea.

> a nanae/nanabl posting.

For the most part you're perfectly right.  NANAE or NANABL will usually 
come up with a good explanation (albeit buried deep amongst the insults 
and entirely wrong answers).

In theory, and much of the time in practise, it works acceptably well.

_If_ it's asked, and _if_ one or more of the answerers manage to figure 
out the answer and _if_ the questioner is able to seperate the wheat 
from the chaff (nay, buckshot ;-), fine.

But, these things fail a whole lot more than people appreciate.  I'm on 
lists where things like this are discussed honestly.

1) listees (especially ISPs) sometimes have no idea whatsoever why <some 
IPs> are listed.  Sometimes it's subtle (like a stale DNS entry), or 
some connection that's not published in the SPEWS entry.  I full well 
believe that SPEWS listings result from unanswered complaints.  On the 
other hand, one can easily expect some of these complaints going astray 
(for a whole host of reasons, including not identifying the responsible
party correctly in the first place).  Having a failsafe to get the right
answer is desirable.

I've seen plenty of ISPs saying "I have no idea why this is listed. 
We've never got any complaints about this customer".  Or, worse, when 
they can't figure out what customer the listing is a result of. Yeah, 
sometimes they're lying.  But not always.

2) A whole host of *SPs and personnel simply refuse to have anything to 
do with NANAE or NANABL.  I've done my bit to try to persuade them 
otherwise, including in some cases "fronting" requests and guiding them 
thru the minefield.  But it almost never happens.

3) I've seen NANAE/NANABL grasping at straws to find out the ultimate 
reason for a listing, and never finding it.  Or not knowing if it has 
been found.

My goal in anti-spam is to block spam.  To prevent spam from being sent 
in the first place.  To make it as easy as possible for ISPs to clean up 
problems or, gasp, point out mistakes.  Even escalation has a positive 
role to play.

I have no problem with SPEWS' general "ask NANAE" here, as long as there 
is a channel of last resort.

CBL does something like this - you can delist yourself, and it happens 
within a few hours.  They also have a removal limiter to refuse 
delisting if the same IP is removed too often.  Then you're guided to 
contact the CBL directly.

I'm sure that the vast majority of CBL delistings occur without having 
to go anywhere near the email address.  The ones that do can't be that 
high volume, because I've not had problems dealing with them by email. 
And if you do deal with them by email, you still don't find out who they 
are.

> BLs policy should state whether it will list w/o "spam in hand".

Okay.

> :)  Call it a gut feeling.

Heh.  Matt has run a public BL.  Not for very long mind you, but 
apparently a lot of people used it during that period.

As for the gut feeling w.r.t. me, well, I think that John Levine and a 
few others (besides Matt) might be persuaded to tell you that your gut 
feeling is wrong, without going into details ;-)

> E.g. I 
> interpretation, hence some of the suggestions I've made.

If the BCP can be twisted that far by a reasonable person, it needs to 
be adjusted.  Thanks for your comments!

> Oh, and good point in another email - the BCP should encourage BL usage.

I view the BCP as helping in the following ways:

- Blacklist owners have an idea of (a) what they're getting into and (b) 
what they should say to make the operation (not necessarily identity) of 
the blacklist transparent.
- Blacklist users know what they're getting.  So they won't be surprised 
or blindsided.  They can make informed decisions on whether to use it or 
not.
- By being as transparent as possible about the operation of the list, 
the blacklist owner shifts legal responsibility for use of the list onto 
the user of the blacklist.  Which is where it should be.

Even a blacklist that is run entirely capriciously can protect 
themselves from legal liability by making it damn clear to the potential 
blacklist user that it _is_ capricious.  This BCP tells the blacklist 
owner which things at a minimum they should describe, so that the 
listee's argument can only be with the BL user.

This BCP is _intended_ to be of benefit to both owners and users of BLs. 
Transparency benefits BCP owners even more than users...  The only 
reason to lessen transparency is where necessary to prevent spammer 
evolution.

Maybe we have to amplify the introduction more along the above lines to 
help ameliorate most of the legal concerns and make that intent more 
obvious.

---

From: John Levine <[email-masked]>
Date: 6 May 2004 04:59:54 -0000

>deadend		604800	IN	A	127.255.255.255

The value in an A record is a 32 bit IPv4 address, so Set 2 doesn't
work.  Sets 1 and 3 are OK, though.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
http://www.taugh.com

---

From: Matthew Elvey <[email-masked]>
Date: Thu, 06 May 2004 11:34:19 -0700

On 5/5/04 11:17 AM, Chris Lewis sent forth electrons to convey:

>> That's not a valid example.  If these additional requirements were 
>> not in the BL's stated delisting, then this issue was covered in
>
>
> Believe me, it's best for the blacklist _owner_ to do whatever they 
> can that has the slightest whiff of ulterior motives.  Ie: "pay me to 
> get out of the list".  Which is either extortion or protection rackets 
> or both.
>
> of the ramifications of "extra delisting requirements" will realize 
> it's in their best interests to avoid them.  In a legal sense.  
> Objectivity and pinpoint accuracy is always to be preferred if there's 
> no compelling reason to do otherwise (ie: SPEWS being inherently and 
> deliberately subjective).  Subjective isn't _wrong_, just 
> unnecessary-to-the-goal subjectivity is dangerous - to the blacklist 
> admin's legal liability - even if only a frivolous claim.
>
> same temptations and the flamewars and worse that resulted.  It's 
> simply never preferable to do anything that is even remotely close to 
> imposing something on the listee that benefits _you_, or isn't 
> directly related to the listing.  That ONLY provides leverage for 
> legal action, justified or not.

Simply being on a list someone runs seems to provide all the leverage 
for legal action any spammer has needed to sue.   Having 2.2 seems like 
barricading one door of a room with 3 open doors. 

>
> That's 10 years hard labour in the trenches (with at times an average 
> of one lawsuit threat per _day_) speaking.

I'd really like to hear more about this (off-list).  Appreciate the 
above info!

>> Vagueness here is undesirable.  Here's my specific text suggestion: 
>> 2.3 would benefit from the addition of sentences like:  The precise 
>> 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.
>
>
> For the most part you're perfectly right.  NANAE or NANABL will 
> usually come up with a good explanation (albeit buried deep amongst 
> the insults and entirely wrong answers).
>
> _If_ it's asked, and _if_ one or more of the answerers manage to 
> figure out the answer and _if_ the questioner is able to seperate the 
> wheat from the chaff (nay, buckshot ;-), fine.
>
> But, these things fail a whole lot more than people appreciate.  I'm 
> on lists where things like this are discussed honestly.
>
> 1) listees (especially ISPs) sometimes have no idea whatsoever why 
> <some IPs> are listed.  Sometimes it's subtle (like a stale DNS 
> entry), or some connection that's not published in the SPEWS entry.  I 
> full well believe that SPEWS listings result from unanswered 
> complaints.  On the other hand, one can easily expect some of these 
> complaints going astray (for a whole host of reasons, including not 
> identifying the responsible
> 2) A whole host of *SPs and personnel simply refuse to have anything 
> to do with NANAE or NANABL.  I've done my bit to try to persuade them 
> otherwise, including in some cases "fronting" requests and guiding 
> them thru the minefield.  But it almost never happens.

If any of them do not have long listings at 
http://www.spamhaus.org/sbl/listings.lasso?isp=isp.tld then that's 
interesting, but I wonder if that's not the case.  In other words, are 
these ever folks to whom your 1) above applies?  I guess you're saying 
it is; more often than people appreciate, it does.
In any case, I'd rather not see their unreasonable fear to post in a 
public place legitimized by BCP accomodation.  (From what I've seen, 
competent (e.g. non-threatening, speficfy an IP and SPEWS #) nana* posts 
from listees not wearing black hats attract little 'buckshot'.)

> My goal in anti-spam is to block spam.  To prevent spam from being 
> sent in the first place.  To make it as easy as possible for ISPs to 
> clean up problems or, gasp, point out mistakes.  Even escalation has a 
> positive role to play.
>
> I have no problem with SPEWS' general "ask NANAE" here, as long as 
> there is a channel of last resort.
>
> And if you do deal with them by email, you still don't find out who 
> they are.

Pretty nifty.  Still I don't see why e.g. that email address 
auto-forwarding to a public place (perhaps read-only) would be wrong.  
But I don't have the experience you have, so perhaps you can enlighten 
me with an example of info that needs to be conveyed non-publicly.  In 
other words, if the listee is going to make false statements, they'd be 
more comfortable doing so privately, but I can't think of a legit need 
for a Direct *Non-Public* Way to Request Removal.

>>  From [SPEWS FAQ] 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.

:)

> apparently a lot of people used it during that period.
Oops.

> feeling is wrong, without going into details ;-)

Ok, I believe you.

>
>> E.g. I think even the CBL and SBL are not compliant with a strict 
I think it's been a productive discussion!  Looking forward to -01.  
Thanks! 

> This BCP is _intended_ to be of benefit to both owners and users of 
> BLs. Transparency benefits BCP [you mean BL, I guess - elvey] owners 
> even more than users...  The only reason to lessen transparency is 
> where necessary to prevent spammer evolution.
>
> Maybe we have to amplify the introduction more along the above lines 
> to help ameliorate most of the legal concerns and make that intent 
> more obvious.

(I suggested some legal-issue wording for this in another post.)