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

Matthew Elvey wrote:

> On 5/4/04 9:28 AM, Chris Lewis sent forth electrons to convey:
> > 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".
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.
> > >   2.3. Listing/Delisting Criteria MUST Be Easily Available.
> 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.
I think clarification of intent along that line would be a good idea.

> > >   2.6. MUST Have a Direct Non-Public Way to Request Removal.
> 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).
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.
> > >   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".
Okay.

> > > 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.
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 
> think even the CBL and SBL are not compliant with a strict 
> 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.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg