Matt Sergeant wrote:
On Thursday, Aug 14, 2003, at 00:59 Europe/London, Yakov Shafranovich
wrote:
Some DNSRBLs work on policy level - listing ISPs that support
spammers, listing modem pools, etc. What do we do about them?
I assume you mean SPEWS. It's a tricky question, because technically
SPEWS listing ISPs supporting spammers isn't collateral damage to them -
that's their entire raison d'étre and would be covered by "Truth in
advertising". What the above section really applies to is lists like the
SBL, who have an escalation policy to try and take action against
particular spammers.
But maybe Chris has a different take on it.
Matt, are you scribe now? ;-)
I have a more generic take on this. It wouldn't be far-fetched, for
example, for a proxy DNSBL to escalate, say, the ridiculous levels of
open proxy infestations in some of the Brazilian class B to blocks on
the Brazilian ISP's mail servers, or, the _whole_ class B (SPEWS has
done this a couple of times).
As such, "escalations" aren't necessarily coercive per-se, and in some
cases (such as the Brazilian proxy problem), there is virtually no
detectable collateral damage actually occuring.
Expanding on that bit:
1) Escalation policies should be described as part of the list criteria
page.
2) In that description, the escalation policy should be identified as
either a "collateral damage/coercive" or a "protective" measure (or
both). A "collateral damage" escalation is where you deliberately
target stuff that there's no reason to believe is a spam problem itself
in order to force the owner to do something. A "protective measure"
type escalation is where you're (for example) giving up on individually
tracking thousands of open proxies within a class B, and just blocking
the whole thing.
SBL escalations are almost always coercive. Most SPEWS escalations
start out "protective", and then become coercive once they get bigger.
3) My take is that it's far more important/useful to pre-warn about
coercive escalations (because that's the whole point after all) than
protective ones.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg