Ban version
I just wanted to check to see if this was just a suggestion of if this would really work? I've been looking for a way to keep non-version connections from getting on since I've seen people try to flood rooms with bots that give no version reply.aquanight wrote: It probably won't help this issue, but I think something can/should be added to put a tkl ban on users that don't send a version reply. Something like:And that would make the CTCP VERSION exchange part of the user login (with the PING/PONG exchange, DNS lookup, and Ident check).Code: Select all
ban version { timelimit 10s; action kill /* or tempshun/shun/kline/zline/gline/gzline */ ; reason "Network rules require your client to respond normally to a VERSION request."; };
Somehow, I find it strange that legimate users would break the standard for clients by refusing Version replies: especially since most clients won't let you do this.codemastr wrote:It would also keep out legitimate people like myself who do not reply to version requests.
(This doesn't work in mIRC:)
Code: Select all
ctcp *:VERSION:*:*:halt
Plus, most networks I've seen require version replies. Having the ability to ban versionless clients at the ircd would be helpful to those networks because the ones I've seen either use a bot or rely on the opers to handle versionless clients.
Break?? standards?? I've never heard of a REQUIREMENT for version replies.Somehow, I find it strange that legimate users would break the standard for clients by refusing Version replies
Well, fortunately many (if not all) clients let you ignore all CTCPs... which is exactly what I use (/ignore -t * in mIRC), I don't see any need to disclose information on which exact product and version I'm using, what time it is on my computer, etc... codemastr probably has similar reasons and there are a whole lot of others.specially since most clients won't let you do this.[..]
?? I don't know where you go to then.. I've never been on such a network.Plus, most networks I've seen require version replies.
-
- Former UnrealIRCd head coder
- Posts: 811
- Joined: Sat Mar 06, 2004 8:47 pm
- Location: United States
- Contact:
Well CTCP is not a standard. And if you want to call the CTCP specification a standard, mIRC breaks it anyway since it doesn't respond to a CLIENTINFO or USERINFO. And actually, to be honest, mIRC is the only client I've ever seen that forces you to keep the version reply. So I don't know where you got "most" from. Especially on Linux, it's open source, so even if the client doesn't provide a method, you could always do it yourself! And as Syzop pointed out, you can indeed disable all CTCPs in mIRC.Somehow, I find it strange that legimate users would break the standard for clients by refusing Version replies: especially since most clients won't let you do this.
But, not all of us run mIRC. I don't, I run Klient. And it lets you hide the version reply no problem. I just uncheck the little checkbox next to "Version" and *poof* disabled. And as Syzop indicated, there are legitimate reasons to block it. I block it because I'm beta testing the next release Klient and I hate that people version me and then ask me to send them the beta version. So rather than deal with them, it's easier to just turn off version replies.
Such as? I can connect to DALnet, EFnet, Undernet, IRCnet, and Quakenet without responding to version replies. I've yet to try to connect to a single server that banned me because I didn't reply to a version request.Plus, most networks I've seen require version replies.
EFnet *requests* a version reply, it doesn't *require* it.EFNet comes to my head with this
[01:12] CTCP VERSION from: B-Drone ([email protected])
[01:12] Response disabled in CTCP options, not responding
I wasn't disconnected. I can do everything a user who replies to a version can.
-- codemastr