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