View Issue Details

IDProjectCategoryView StatusLast Update
0002456unrealircdpublic2006-04-27 19:08
Reporterfinkoisti Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionno change required 
Product Version3.2.3 
Summary0002456: New feature using bans
DescriptionIs it possible to add # mark also in unrealircd so that it means one number as usually? Now the unreal only understand's * as anything and ? mark as any character..But the character is not so usefully anymore than earlier..Now we need more choices to fight back against the flooders...
3rd party modules

Activities

codemastr

2005-04-01 13:20

reporter   ~0009686

I'm not so sure I like this idea. It will cause a great deal of confusion for clients.

syzop

2005-04-01 13:56

administrator   ~0009687

I second that, IMO things should be either the classical wildcard match form (so * and ?) or regex, not some kind of other form "in-between".

Also, when you say bans a lot of people assume you are talking about channel bans (because server bans are usually referenced to as *lines), so what are you refering to?
If refering to *lines or ban ... blocks in the conf, then there are some requests in the bugtracker for regex support on that. But I suggest using spamfilter target u, very powerful and most likely what you need (and even more powerful than a classical *line if you use a non-kill target).. '/spamfilter add u kill - stupid_bot Bot\d!.+' etc.

aquanight

2005-04-01 22:09

reporter   ~0009693

Last edited: 2005-04-01 22:15

I wouldn't mind seeing something like this. (In fact, I think IRCnet already has it, but I dunno.) The only question would be then how much longer until wildcard formats start looking like VB's Like operator and less like plain ol' DOS wildcards :) .

And as far as clients go, I don't really forsee too much of a problem. The only thing I can think of is if you're in mIRC and want to list all users matching AAZ#### you won't get any matches, etc...

codemastr

2005-04-03 17:21

reporter   ~0009700

[quote]And as far as clients go, I don't really forsee too much of a problem. The only thing I can think of is if you're in mIRC and want to list all users matching AAZ#### you won't get any matches, etc...[/quote]
mIRC != all clients. That seems to be the biggest problem when ever I refer to client issues! Just as one example, eggdrop. I set a ban on a###!*@*. I have the option for non-persistent (whatever it is called) bans so that the +b is only set when it is needed. Now, a user a123 joins, however he doesn't get banned. Why? Eggdrop doesn't recognize that he matches a###!*@* and therefore allows him in.

Another issue is with services. "Unban Me" commands will be broken, as will akick lists and other things. It will cause more harm than good in my mind.

aquanight

2005-04-04 15:10

reporter   ~0009702

Right, but the only reason I didn't mention eggdrop is because it looks like IRCnet definately has # in bans/etc, so stuff like eggdrop is going to have to support it eventually anyway.

(Of course, IRCnet seems to like just doing it's own thing but... :P )

w00t

2005-04-05 02:33

reporter   ~0009703

Why?

IRCNet is not the be-all and end-all for IRC, remember. They seem to enjoy breaking things, and making life rather hard (/squery, anyone?)

vonitsanet

2005-04-05 06:18

reporter   ~0009704

No No No...
It will confuse most of the people and many scripts will not work.

syzop

2006-04-27 19:08

administrator   ~0011633

no plans for this, sorry.

Issue History

Date Modified Username Field Change
2005-04-01 13:16 finkoisti New Issue
2005-04-01 13:20 codemastr Note Added: 0009686
2005-04-01 13:56 syzop Note Added: 0009687
2005-04-01 22:09 aquanight Note Added: 0009693
2005-04-01 22:15 aquanight Note Edited: 0009693
2005-04-03 17:21 codemastr Note Added: 0009700
2005-04-04 15:10 aquanight Note Added: 0009702
2005-04-05 02:33 w00t Note Added: 0009703
2005-04-05 06:18 vonitsanet Note Added: 0009704
2006-04-27 19:08 syzop Status new => closed
2006-04-27 19:08 syzop Note Added: 0011633
2006-04-27 19:08 syzop Resolution open => no change required