[ 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
