[ This one got lost due to a moderation mixup; putting it back on dalnet-src. -- Quension ] Hello, I would like to propose the following channel mode addition: * +U - A user without matching PTR/A DNS records may not join unless set +r. I believe the mode may have been proposed previously but lacked the +r exclusion. I think this may turn the argument slightly. Firstly, let me explain the need for the channel mode. I believe there are a few reasons why such a mode is necessary. In my experience, the vast majority of problem users come from one of three categories: a) The "script kiddie". This user revels in agonizing others and possesses a substandard grasp of common decency. This user may have access to a wide variety of IP space and is difficult to stop. I, personally, can not think of a server-side solution to this problem (nor a client-side solution!). b) The "angry visitor". For whatever reason this user is having an unpleasant experience. Clash of personalities, personal politics, whatever. This user might just leave on his own, but a /kickban will ensure. User has little desire to return. No additional steps necessary. c) The "general, nonsensical irritant". This is the big one. This includes clone bots, spam bots, zombies, flooders, spammers, and the dredges of society. Short of implementing an IRC CAPTCHA, there is little one can do to prevent such activity. However, in my experience, these users hail from ISPs who are too lazy, apathetic, or a combination thereof to implement a standardized DNS system. The proposed mode targets these users. Some might suggest using the existing +R to filter out these users, but I find this significantly hinders the ability of a channel to gain new users. "How is this different, idiot?" I hear you ask. Well, the difference is the place of the burden. With my proposed channel mode, the burden is placed on the ISP instead of the user. +R requires an existing knowledge of DALnet's services -- which, in my opinion, is an unfair burden. +U, however, requires an existing knowledge of DNS for the network administrator of a presumably large ISP. I do not feel this is an inappropriate burden. If emerging ISPs had better DNS infrastructures, it would be trivial for a channel administrator to ban them if they experienced large problems from those providers. While it is technically possible to ban the offending ISPs' netblocks using CIDR notation, i feel it is an unfair burden of the channel administrator to research every block the provider owns. Additionally, with multiple providers, this may fill the banlist quickly. In the event an innocent user suffers at the hands of their ignorant ISP, the +r exemption comes into play. I think this is as near a CAPTCHA as one can hope in such an event. Clearly a channel mode that may prevent users from joining a channel based on decision they have little power over should not be in place on official help channels. "Make a script, you lazy jerk!" The only way to implement this feature on the client-side is to parse on-join events, apply a regex to the host, and make a decision. This works, but causes two problems: * With a sufficiently large channel, the ban list will fill. * With a sufficiently large channel, the scrollback buffer of the client will fill (or at least become a burden on the conversation -- join, kick, ban. join, kick, ban. join, kick, ban) Also, this doesn't take into account +r umode. An automated system would have to WHOIS each user and parse those results as well. With a new channel mode, there is only ever 1 line, the mode change, and no bans are required. I expect the largest amount of criticism will come from the "there are plenty of annoying users who have resolvable hosts" crowd. I agree, we'll never be able to filter out all of them. The same argument was probably used against +R. Some users have registered nicknames and still spam. There's no silver bullet, but we can always strive to improve. Also, if the mode isn't appropriate for your channel, you don't have to set it! ;) Cheers, --adam / killer