[WikiEN-l] JarlaxleArtemis/Grawp

[SQL]

Martijn Hoekstra wrote:
>
> ]
> It seems hard to believe that Verizon would let such a rangeblock sit
> for long. I think the only message we need to get over to them is
> "dude, we're not kidding. We don't want to rangeblock your entire ISP,
> but this one person who has an internet account with you is causing us
> major headaches. Because of your dynamic IP adresses, we are unable to
> deal with it on an individual level. We are open to suggestions on how
> we can solve the problem, but if you are really not willing to help us
> out here, we simply have no other choise but to block every IP adress
> in your range from editing, as much as we'd hate to do that"
>
> I can't believe that bigwigs at Verizon would be willing to let that
> happen, the question is just how to get through to the right people
> that can do something about it.
>
>
>   
This is commonly a way other services handle(d?) abusive users from 
unresponsive ISP's. E.g. If I start spewing viagra spam to a few million 
guessed e-mails, and my ISP refuses to do anything about it, other 
customers on my ISP will soon find that other SMTP servers will not 
accept messages that originate in my netblock (well, depending on setup, 
but, last time it happened it seemed like 6/10 messages I sent were 
refused). In some peering situations, at least earlier on, this was a 
common sort of scenario as well, when it came to other destructive forms 
of abuse, like Denial of Service, and the like. This approach generally 
gets results very quickly.

This is the only real way to deal with a user like this. Sure, there 
will be a lot of collateral damage, and, there will be some disruption. 
The thing we need to decide for ourselves is -- Is ridding ourself of 
this user worth the disruption it would cause to the website? Also would 
need to keep in mind he will probably get a new ISP (or at least abuse 
from school, etc... Those should be easier to hunt and abusemail however)

As far as the difficulty of blocking him, it would not be too terribly 
hard to make an extension that blocks users from editing by passing a 
regular expression over their hostmask. E.g. /.*\.dsl\.verizon\.net/i or 
whatever the mask for his type of connection is. (This may actually 
allow us to further narrow this approach and reduce collateral, by the way).

Simply placing a block message along the lines of "In order to protect 
our project from a user or handful of users on Verizon DSL, we have 
disabled editing from this netblock, until Verizon takes action on 
ticket # XYZ123.", or something like that.

SQL