Quote: 'What would you suggest? Perhaps some examples?' You could maybe build this mode in into X. This way you would be able to see wich username is taken by a bot. Since we don't want 50.000 bots connecting to a network (so I guess), you could get an overview. In stead off the email-adress provided, you would provide a username who is responsible for the behaviour off the bot. Abuse will be excluded this way, since abusive bots will also result in a punishment for the owner. The password for the specified username will be submitted @ the email-account off his owner. You will also be able to exclude multiple simultanious logins for the bot's username, since this isn't needed. 'Normal' usernames are allowed to do that. These usernames won't be able to register a channel, nore support a channel registration procedure. Those things could be ignored for bots made/provided by the network (for exemple CService on #CService) or server related eggdrops (for exemple Paris used by Paris.Fr.Eu.UnderNet.Org some years ago).
More technical you could limit the traffic between those users and X. This way the service, who was developped mainly for users and not for bots, will be less laggy @ traffic peaks and users will regain some advantages. On the other hand it could result in a policy that a bot who has access on a specified channel would be opped as first when the channel might become opless as X is in split. This would stimulate channel-owners to follow this procedure. Quote: "Being able to ban bots from channels. Only allowing bots to message people who are on the same channel (disable PRIVMSG thus, only allowing CPRIVMSG). Put a much tighter restriction on (joining/)parting channels, for example a maximum of one PART per 20 minutes. Not allowing bots to talk to channels at all unless they are +o or +v. Keeping a counter per human of the number of times they are msg-ed by a (different) bot per second; if someone is messaged by -say- 10 different bots within 10 seconds then report all bots that msg this target to (a channel with) IRC opers (botnet detection). Disconnect bots that are idling when a server is full and a human wants to connect." Being able to ban bots from channels? That feature already exists :p The restriction seems logic for join/parts: bots don't need that unless they would be running some kind off spam detector with random check. The talking looks a very good one, it would exclude floodbots from putting text on a channel they are not opped on. The counter looks very CPU intensive, maybe you can add make the value for excess flood a bit more tighter so bots who perfom messages will sooner quit. Since bots use a special usermode in this case, there is no need to disconnect them when idling.... You can just restrict the number off botconnections on your server. Each admin decides for himself how many connections they are willing to support. They can still exclude their own bots by putting I-lines on their hosts. regards ------------------------------------------------------------------------ Real Name: Dimitri Logie IRC Name: éL NìçóS <[EMAIL PROTECTED]> Company: Systray Solutions URL: http://www.systray.be Contact: #Systray @ Krey.Net ------------------------------------------------------------------------
