banning *!*@* has some advantages.
When you ban *!*@* from a channel, only voiced and opped people will be able
to talk, to change their nicks, and no one will be able to join.
In chans like #class, it's sometimes useful to have that ban enabled.
Anyway, if someone wishes to lock a chan, he can
Regarding *!*@*.* see Isomer's email. There IS enough security.
Regarding what to do when your username is hacked on undernet...
First, go to http://cservice.undernet.org/live/ login (if you still can) and
change your password, if you cannot login, use forgotten password (link both
in side bar a
I agree The ability to ban *!*@* should be either (a) limited to
cservice staff only, or (b) blocked completely to everyone.
In my opinion, 9 times out of 10, a *!*@* ban is considered abusive and
probably used to maliciously lock up the channel.
I don't really see a need to allow anyone to b
Hello
We are sending this e-mail on behalf of the members
who developed the IRC of Irc-Hispano.org, in order
to organise the first meeting among the main developers
of the IRC of the most important irc networks in the world
Our purpose is to organise a debate from time to time
in one of those ne
> My proposal is to add a new channel setting (level
> 500). For example FULLBAN (OFF or ON) which allow (or
> not) users to set bans on *.* . I guess is a good
> ideea... 10x & please excuse my english.
>
How does the IRC daemon know if a ban is a full ban?
*!*@*
*!*@*.*
*!*@*.???
*!~*@
2002-05-17 14:50:20, skrev Cosmin Marcu <[EMAIL PROTECTED]>:
>Hello.
>
>Almost everybody knows that if you have sufficient
>access in a channel to set a ban through X and you set
>that ban on *!*@*.* X will kick all users from that
>channel. You need access level >= ban level to remove
>it. The p
Hello Cosmin,
Friday, May 17, 2002, 2:50:20 PM, you wrote:
CM> Hello.
CM> Almost everybody knows that if you have sufficient
CM> access in a channel to set a ban through X and you set
CM> that ban on *!*@*.* X will kick all users from that
CM> channel. You need access level >= ban level to remo
> I noticed that some of the temporary error conditions will exit the
> function. You might want to consider using continues in the while
> form.
Thanks for pointing this out.
If the IRC server is configured for low load situations, I'd
prefer not rejecting connections and thus retu
> This change implements multi-accept, based on the idea that
> poll/select can only be efficient, if we succeed in handling
> all available events, i.e. accept all pending connections.
I noticed that some of the temporary error conditions will exit the
function. You might want to co
> Here it is, pretty much tested and working.
Thanks :) looks good, so I committed it.
--
Kevin L. Mitchell <[EMAIL PROTECTED]>
Hello.
Almost everybody knows that if you have sufficient
access in a channel to set a ban through X and you set
that ban on *!*@*.* X will kick all users from that
channel. You need access level >= ban level to remove
it. The problem is that the username's password can be
stolen. So, with a stol
> have you considered adding the multi-accept capability to the
> server?
Feel free to send a patch to patches@--please include ChangeLog entries
and a commit message. If you can't do that, we'll try to look into it
when we get a chance, but it might be a while.
--
Kevin L. Mitchell <[E
12 matches
Mail list logo
