Hi, Maybe this isn't a coder-com discussion topic, but I encountered for what the banlist size matter counts kinda the same situation. Sorry for some non-coder-com related answers / solutions, but in a way it provides a short-term solution for his problem too.
As I recall, #usa uses some eggdrops. They also have a good approach on active operators. The channel I spoke abouth in my last mail, also had to deal with clone attacks & full banlists. Actually, if the abusers are good, ad they mostly are, you're banlist is never large enough. If you unban bans to add new ones, they rejoin with that host you just unbanned etcetera. X now has a limit in it, that already helps a bith. Actually, if you can't change the size off the banlist by yourself, you have to be very creative to stop the abusers. We encountered success when using X's banlist in stead off manual bans by ops, together with unbanning ourselves (or if we were not alive, our "bots" took care off the unbanning). The wonderfull thing abouth X's banlist is that he can always put a banmask, even when the banlist is full (I don't know abouth now, but at that time it was possible). This option is accessible in all registered channels. Large channels that are not registered, are mostly warez/mp3/... channels, channels that are refused for registration by CService. Since they are not supported by CService, they shouldn't be using too much memory for their bans? There are also some smaller channels that don't need to have a banlist size off 45 bans... Why not adding some kind off solution in X so X decides what the size off the channel's banlist is? Is that possible? regards NicoS ----- Original Message ----- From: "Christopher Robin Wilding" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, October 23, 2002 11:10 PM Subject: [Coder-Com] | At 14:03 2002-10-23 -0400, Kev wrote: | >Undernet's AUP prohibits spamming, so you can email logs to | >[EMAIL PROTECTED] It'll likely result in suspension of his account, and | >hopefully also a complaint from abuse@ to the user's ISP. This is clearly | >not as good as letting the user do this himself, but it's a trade-off | >we've made to add some privacy for our users. | > | | I know this isn't entirely the realm of coder-com, but it would be | *really* nice for something to this effect to be summarized somewhere on the undernet.org website, so that Joe-luser knows this too. | | Quite a few users I know see the new host hiding option as a loss of | accountability, since no detailed information demarcating what | [EMAIL PROTECTED] can/will and can't/won't do. | | In my situation, as one of the ops in #usa (which tends to have 200-350 users during any part of the day), the host-hiding option further stresses what I consider to be a far too small banlist size even further; just the simple addition of this 'v-host on the cheap' means more bans added to our pending list of bans, and more bans set in such a channel. | | I know I'm calling someone's baby ugly, but this feature didn't have the logistical/social side of the equation as well thought out before it was enacted. | | My fear is that cservice fakers that -still- pop into channels to play social engineering tricks (/msg <nick> your cservice user/pass to 'save' it) will use the compiled list of accounts, coupled with modified proxy/clone flooding scripts to make a chan-ops duties all the more cumbersome. | | Being that it wouldn't be all that hard for some kiddie to accrue 31+ | cservice accounts that first spate of 31+ unique <stolenacct>.users.undernet.org clone floods will mean channels will start enacting bans on *!*@*.users.undernet.org | | After all, once there's more than 30 bans, the source addresses for the flood aren't kept at bay with just 30 individual bans. I really would hate to see the host-hiding feature's positive benefits of user privacy, and individual accountability ruined by such a turn. | | So, rather than being entirely negative about the feature, I will suggest a few things that can improve/avert rough spots: | | A more permanent page on the undernet.org site, and/or links on the MOTDs would help diseminate the information about the feature, along with a page that details, for abusive users on *.users.undernet.org, what information is needed to be emailed off to [EMAIL PROTECTED] . | | The Channel ban list size needs an increase, in some way -- the simple solution would be to simply increase the list size allowed up from 30 (easy for coders, it's a config change, but a pain for admins - it's a server reboot). | | I'd like to discuss a few other alternatives I have in mind becuase I | believe strongly that a change IS needed for the better. | | But before I do, it'd be best to get input from the coders and/or admins that have profiled servers recently to see what the current situation is, and how proposed banlist changes would affect things, pro and con. There's not much sense in proposing fanciful ideas that either tax ram, and/or bandwidth, and/or cpu excessively over the current state, unless there's a genuine improvement. | | | Congradulations, you've just made it through another wordy tirade of: | Christopher Robin / ChrstphrR | | P.S. In case there's no formal user-com liason in coder-com, I cc:'d this onto user-com@ to mull over as well. | |
