Manuales

Modos de Usuario

  • B: [2]  
    Este modo marca “bots” o “servicios” oficiales de la red.
  • d:  
    Este modo indica que el usuario no atiende a los canales. Es decir, aunque esté en varios canales, no recibe los mensajes que aparezcan en ellos. Útil para bots.
    En el whois aparecerán los canales en los que está el usuario con un signo menos delante del nombre, para indicar este flag.
  • g:  
    Recibe notificaciones del servidor, como kill.
  • h: [2]  
    Este modo define a un usuario como helper u operador de red. Este modo sólo está disponible si el usuario tiene también el flag r.
    Este flag se activa automáticamente cuando el usuario tiene flag r y aparece en la base de datos de operadores de red.
    Un usuario con este modo puede:
  •  
    • Utilizar el X-MODE
    • Entrar en cualquier canal, poniendo la clave OPER
    • Utilizar diversos bots de servicio
    • Activar sobre sí mismo el flag X.
    El usuario pierde automáticamente este flag si pierde el flag r.
  • i:  
    Usuario invisible. Sólo aparece si sabemos su nick exactamente o estamos en un canal común.
  • k: [3]  
    Usuario Channel Service. Un usuario en este modo:

    • No se le puede quitar op ni hacer kick
    • Puede enviar mensajes a canales aunque estén en modo n
    • Puede entrar en un número arbitrario de canales [3]
    • En Undernet, no se le puede hacer KILL. En IRC-Phoenix/ESNET, .
    Este flag puede ser activado si tenemos flag h o o [3].
  • o: [3]  
    IRCop. Este flag define a un usuario como administrador de la red. Se activa mediante el comando “oper”. Un usuario con este modo:

    • Lo mismo que en Undernet
    • Puede activar sobre sí mismo el flag k [3]
    • Puede activar sobre sí mismo el flag X [3]
    • Puede entrar en cualquier canal indicando la clave GOD [3]
    • Puede utilizar el modo X-MODE [3]
  • O:  
    IRCop local.
  • r: [2]  
    Nick registrado. Este modo se pone por el servidor, bajo respuesta de un comando nick autentificado. Si el nick no está registrado, el flag se desactiva.
    El usuario no puede ni activar ni desactivar este flag. Es automático.
    Anteriormente, la activación de este flag suponía la activación automática del flag x, pero IRC-Phoenix decidió, en su momento, desvincular completamente ambos modos. Si el usuario es un operador de red o helper, se activa automáticamente el flag h.
    La desactivación de este flag supone la desactivación automática del modo h. Si el usuario no tiene el flag o, se desactiva también el flag X.
    Anteriormente, la desactivación de este flag también desactivaba el modo x, pero en la actualidad ambos modos están complemtamente desvinculados.
    SNO_OLDSNO 1 Mensajes diversos
    SNO_SERVKILL [3] 2 Server kill, típicamente por colisión de nicks
    SNO_OPERKILL 4 kill de IRCops
    SNO_HACK2 8 Desincronizaciones de la red
    SNO_HACK3 16 Desincronizaciones temporales de la red
    SNO_UNAUTH 32 Conexiones no autorizadas
    SNO_TCPCOMMON 64 Errores TCP/IP
    SNO_TOOMANY 128 Demasiadas conexiones
    SNO_HACK4 [3] 256 Operaciones en canales por parte de UWorld o similares [3] Peticiones de cambio de nick que no provienen de un servidor con ULINE.
    SNO_GLINE 512 g-lines
    SNO_NETWORK 1024 Cortes y fusiones de la red
    SNO_IPMISMATCH 2048 DNS Directo e inverso no coinciden
    SNO_THROTTLE 4096 Notificaciones de activación y desactivación de throttle
    SNO_OLDREALOP 8192 Mensajes sólo para IRCops
    SNO_CONNEXIT 16384 Entradas y salidas de usuarios en el nodo local
    SNO_RENAME [2] 32768 Informa de las peticiones de cambios de nick solicitadas por un Service.
    SNO_RENAME2 [2] 65536 Informa de los cambios de nick en el nodo actual.
  • Si no se indica una máscara, los subflags activados por defecto son:
    • Para un usuario normal: SNO_NETWORK | SNO_OPERKILL | SNO_GLINE
    • Para un IRCop o IRCop local: SNO_NETWORK | SNO_OPERKILL | SNO_GLINE | SNO_HACK2 | SNO_HACK4 | SNO_OLDSNO
    Los flags SNO_CONNEXIT y SNO_OLDREALOP sólo están disponibles para IRCops e IRCops locales.
    Lo mismo con los flags SNO_RENAME y SNO_RENAME2.
  • S: [2]  
    Un usuario con este modo tiene el nick “suspendido”. Esto es, el nick no se lo podrá poner ningún otro usuario, pero no le dará acceso a ningún servicio de la red.
    Este modo es incompatible con “+r”.
  • w:  
    Recibe wallop.
  • x [2]  
    IP protegida.
    Antiguamente este flag se activaba automáticamente al activarse el flag r. Si el usuario perdía el flag r, perdía también este flag. En la actualidad IRC-Phoenix desvincula ambos modos.
  • X [2]  
    Visualización de IPs protegidas. Con este flag, un usuario tiene acceso a la IP real de usuarios con modo x.
    Para acceder a este modo es necesario tener los flags r y h, o bien el flag o. Si el usuario no tiene el flag o, pierde este flag si pierde el flag r.  
     
     
     
     
     
     
     
     
     

Modos de Canal

  • b: [1]  
    Pone un ban sobre un usuario del canal.
  • i:  
    Canal en modo invitación. Sólo pueden entrar usuarios que sean invitados por operadores del canal.
  • k: [1]  
    Pone clave en el canal. Para quitar este modo es preciso indicar la misma clave.
  • l: [1]  
    Fija un límite máximo de usuarios en el canal. Los usuarios adicionales no pueden entrar a menos que sean invitados por un operador del canal.
  • M: [2]  
    Los usuarios sin modo “+r” (no registrados), y sin OP o VOZ, ven el canal como moderado. Los usuarios con “+r” usan el canal de modo normal.
  • m:  
    Pone el canal en modo moderado. Sólo pueden hablar los operadores del canal o los usuarios con voz
  • n:  
    Con este modo, sólo pueden enviar mensajes al canal aquellos usuarios que estén dentro del canal.
  • o: [1]  
    Da o quita op a un usuario del canal.
  • p:  
    Canal en modo privado.
  • R:  
    Solo permite la entrada en el canal a usuarios con modo “+r”. Es decir, a usuarios con nick registrado en la base de datos distribuída.
  • s:  
    Canal en modo secreto. El canal no aparece en la lista de canales (a menos que estemos dentro), y los usuarios que están dentro de él no ven reflejado este hecho en el whois, a menos que quien ejecute el whois también esté en el canal.
  • t:  
    Con este modo, sólo pueden cambiar el topic de un canal los operadores del mismo.
  • v: [1]  
    Da o quita voz a un usuario del canal.
  • x: [2]  
    Modo espúreo, resultado de utilizar el X-MODE en un canal.

 
 
 
 
 
 
 
 
 
 

AWAY

Sintaxis: AWAY [mensaje] 
Uso: El comando AWAY sirve para indicar a los demás usuarios que usted no está 
en ese momento prestando atención al IRC. Para entrar en este estado debe de 
especificar un mensaje, para salir del estado de AWAY basta que ejecute el 
comando sin poner mensaje. 
Su estado de AWAY aparecerá cuando le hagan un WHOIS. 
GHOST

Sintaxis: GHOST 
Uso: Libera una sesión fantasma de un nick desconectándolo del servidor.

INVITE

Sintaxis: INVITE 
Uso: Dirige una invitación al nick especificado para que entre en el canal que 
indicamos. Es necesario tener estatus de operador del canal para poder ejecutar 
este comando. Si el canal se encuentra en modo +i (ver comando MODE) solo 
podrán acceder a él usuarios que han sido previamente invitados.

JOIN

Sintaxis: JOIN <#canal> [clave] 
Uso: Nos introduce en el canal especificado, si este está protegido con clave es 
necesario incluirla en la orden. Si en canal no existe será creado para nosotros y 
entraremos a él como usuario único. Todo canal que se queda vacío deja de existir 
como tal hasta que sea de nuevo creado al entrar alguien, no hay que confundir 
esto con el hecho de que un canal se encuentre registrado en los servicios de la red 
de IRC, eso no implica que el canal esté siempre ocupado y por tanto exista, sino 
que tiene una cobertura de servicios de la red cuando está activo y tiene usuarios 
en su interior. 
KICK

Sintaxis: <#canal> [razón] 
Uso: Este comando solo puede ser empleado por aquellos usuarios que tengan 
estatus de operador del canal. Provoca la inmediata expulsión del nick especificado 
del canal que se indique, esta expulsión podrá ir acompañada de un mensaje. El 
comando /KICK no evita la entrada posterior del usuario expulsado, para esto hay 
en utilizar el “baneo”. Vea el modo +b en el comando /MODE, apartado “modos de 
usuario en un canal”.

LINKS

Sintaxis: LINKS 
Uso: Nos devuelve una lista de servidores que se encuentran conectados a la red 
de IRC en la que nos encontramos.

LIST

Sintaxis: LIST [ cadena | -MIN num | -MAX num ] 
Uso: Este comando nos proporciona una lista de los canales que existen y se 
encuentran visibles en el momento en que se solicita, indicándonos el nombre de 
cada canal, el número de usuarios que hay en su interior, y el Topic o descripción 
del canal si este ha sido especificado por sus usuarios (ver comando /TOPIC). Sin 
parámetros proporciona una lista completa, los parámetros permiten hacer 
búsquedas más selectivas. Leer el punto 2 de este documento para ver una 
descripción mas detallada del significado de los parámetros opcionales. Muy 
importante: recuerde que la lista de canales solo representa una situación estática, 
es decir, referida al momento en que usted la solicitó, eso quiere decir que si entra 
mas tarde en uno de ellos puede que el número de usuarios de su interior no 
coincida con el que le apareció en la lista.

ME

Sintaxis: ME 
Uso: Envía un mensaje a la pantalla activa de canal o de privado precediéndolo de 
su nick como si este formase parte del propio mensaje. 
Por ejemplo, si su nick es “JuanJo” y ejecuta el comando: /me tiene hoy un mal día, 
el mensaje que se presentará será: * JuanJo tiene hoy un mal día.

MSG

Sintaxis: MSG 
Uso: Este comando nos permite enviar mensajes a un determinado canal o en 
modo privado a un determinado nick. Es el comando que normalmente su cliente 
de IRC asume por defecto cuando usted simplemente escribe una frase en una 
pantalla de canal o de nick sin especificar comando alguno. Si usted envía un 
mensaje a un canal en el que no está este solo se leerá en dicho canal si este no 
tiene activado el modo +n (ver comando /MODE).

NAMES 
Sintaxis: NAMES 
Uso: Nos proporcionará una lista de los nicks que se encuentran en un determinado 
canal. Si usted no se encuentra en ese canal los usuarios que están en modo 
invisible (ver comando MODE) no aparecerán en esa lista siempre que no estemos 
en otro canal en que ellos están también) 
NICK 
Sintaxis: NICK [< : | !> ] 
Uso: Le permite especificar y cambiar el nick, apodo o nombre por el que los 
demás le identificarán en el IRC. Este apodo está limitado a un máximo de 9 
caracteres, en el caso de ser un nick registrado deberá introducir la contraseña de 
ese nick. Si utiliza el separador “:” se pondrá el nick identificándolo en el sistema 
mientras que si utiliza como separador “!” liberará una sesión fantasma del nick al 
mismo tiempo que se lo pone. 
NOTICE 
Sintaxis: NOTICE 
Uso: Otra manera de enviar un mensaje a un determinado nick o a todos los que 
forman parte de un canal. 
PART 
Sintaxis: PART <#canal> 
Uso: Nos hace salir inmediatamente del canal indicado. 
QUIT 
Sintaxis: QUIT 
Uso: Envía al servidor de IRC una orden que produce nuestra desconexión 
inmediata del IRC. Es la forma habitual de cerrar la sesión. Adicionalmente usted 
puede añadir un mensaje que será visto por los demás usuarios junto a la 
notificación de su salida. 
SERVER 
Sintaxis: SERVER [nombre:puerto:contraseña] 
Uso: Conecta al servidor especificado.

TOPIC 
Sintaxis: TOPIC <#canal> 
Uso: Sirve para especificar o modificar el Tópico o descripción que acompaña al 
nombre del canal. El texto del topic será enviado a todos los usuarios que entren en 
el canal y acompañará al nombre de este el la lista que se obtiene con el comando 
/LIST. Si el canal se encuentra en modo +t (ver comando /MODE) el Topic solo 
podrá ser modificado por los usuarios que tengan estatus de operador del canal. 
WHO 
Sintaxis: WHO [nombre] [o] 
Uso: El comando WHO lo emplea un cliente para generar una consulta que 
devuelve todos los usuarios visibles del IRC o una lista de información que coincida 
con la máscara o nombre completo del parámetro [nombre]. El comando devuelve 
el servidor principal, el servidor de IRC, el nombre real, el nick, y los canales en los 
que se encuentra el usuario. El parámetro “o” se indica para conocer los operadores 
activos del servidor o mascara de la red. Es decir, cuando se emplea dicho 
parámetro, únicamente se devuelve información de los operadores de la red de 
IRC, no de todos los usuarios en general. 
WHOIS 
Sintaxis: WHOIS 
Uso: Este comando le proporcionará información acerca de un determinado nick 
pudiendo ver si se encuentra en ese momento en el IRC. Si el usuario al que 
hacemos el WHOIS se encuentra conectado al IRC obtendremos una información 
que dependerá del cliente de IRC que estamos usando y de la versión del servidor 
al que estemos conectados. Normalmente usted podrá ver los datos referidos a la 
conexión de ese nick: la dirección de dicha conexión, su identificador de usuario 
(identd), si se encuentra o no away (ver comando /AWAY), el tiempo IDLE (el 
tiempo que lleva inactivo), si tiene o no estatus especial en el IRC, etc. 

WHOWAS 
Sintaxis: WHOWAS 
Uso: Es útil para pedir información sobre un usuario que ya no se encuentra en el 
IRC. Si este está aun en el historial de nicks del servidor nos proporcionará una 
información similar a la de /WHOIS.
 
 
 
 
 
 

Sección 1 – Comportamiento de los Operadores 
———————————————-

1.1 Comportamiento en canales oficiales

Se consideran canales oficiales de la red únicamente #opers_help, #opers y los Canales registrados por la administración de la red. El resto de canales de la red son considerados no oficiales.

Mientras está en #opers_help, el operador de la red está al servicio de 
los usuarios. Por lo tanto, el trato a los usuarios ha de ser formal y aunque 
no es necesario el trato de usted, tendrá que ser lo más educado posible y 
restringiendo la jerga del IRC (’k’ en vez de ‘qu’, ‘io’ en vez de ‘yo’, etc).

En caso de no disponer del tiempo suficiente para atender a todos los 
usuarios, abandonaremos el canal o bien nos deoparemos. Si debemos 
marcharnos o hemos de ausentarnos por unos minutos, les rogaremos que 
esperen o bien que acudan a otros operadores del canal. Así mismo, si 
observamos que algún operador que está con op en #opers_help y se ha 
ausentado, le deoparemos para que los usuarios no le formulen preguntas 
que no pueden ser contestadas. En caso de peticiones que no podamos / 
debamos atender, se lo haremos saber con la máxima educación posible y si 
siguen insistiendo les ignoraremos. Se ruega a los operadores no utilicen 
scripts que automáticamente se vuelvan a dar op al ser deopados. En el 
caso de tener alguno de estos scripts, al ser imposible deopar al oper, se 
procederá a killearle para que abandone el canal.

Los operadores no están en la red para explicar el uso de los bots. Si un 
usuario tiene alguna duda sobre el uso de los mismos les remitiremos a la 
ayuda de cada bot o a http://www.irc-Phoenix.org/ayuda/tutorial/. Un 
cierto numero de add-ons de ayuda están a disposición de los nuevos 
operadores.

Cuando estamos atendiendo a los usuarios en #opers_help, procederemos a 
dar voz (modo +v) al usuario en cuestión para que los demás operadores 
presentes en el canal sepan que el usuario ya está siendo atendido. De 
esta manera evitaremos duplicidades, al preguntar siempre los usuarios 
sus dudas a todos los operadores simultáneamente. En el caso de producirse 
eso, el usuario será baneado del canal #opers_help y será ignorado. Debido 
a que no está permitido hablar en #opers_help, si un usuario al que hemos 
dado voz (+v) habla en el canal, le pediremos que no hable en el canal, ya 
que esta siendo atendido por query. En el caso de que persista, el usuario 
será baneado del canal #opers_help e ignorado.

1.2 Comportamiento en canales que se están atendiendo

Es fundamental no abusar del status de operador, todas las partes tienen 
el derecho a ser oídas. Si la mayoría de los registrados no nos desean en 
ese canal, abandonémoslo y dejemos el problema sin atender. Respetemos las 
particularidades de cada canal. No interferiremos en política interna y 
acudiremos solo cuando sea solicitada nuestra colaboración.

1.3 Comportamiento en canales (Genérico)

· No intervendremos en la política interna del canal a menos que vulneren 
alguna norma. 
· No cambiaremos fundadores y, en caso de que el 60% de registrados 
del canal lo solicite, provocaremos unas votaciones entre los usuarios 
registrados. Ver sección ‘4.2.6 Cambios de Fundador’ para más información 
sobre el procedimiento a seguir. 
· No daremos registros ni aumentos de nivel en canales ni cambiaremos los 
modos del mismo. En el único caso en que podremos modificar la lista de 
registros de un canal será cuando un usuario este registrado contra su 
voluntad en canales de tematica ofensiva (ver punto 4.2.14). 
· Ninguna acción deberá ser tomada sobre un canal sin aprobación del 
usuario fundador y, si este no esta on-line, le notificaremos de nuestra 
acción vía memo. (Con la excepción del caso del punto anterior). 
· Si en un canal se nos pide seguir ciertas normas las seguiremos en tanto 
que podamos y sean razonables. 
· Si en un canal no desean nuestra presencia, abandonaremos el canal.

1.4 Ética del operador

· No abusar del status de operador. 
· No utilizar dicho status para beneficio propio o de amigos. 
· Escuchar tanto a otros operadores como administradores, podemos aprender 
mucho de ellos. 
· Utilizar siempre el castigo menos dañino: mejor un ban que un kill y 
mejor un kill que un gline, y mejor que todos estos, un ignore. 
· Ser educados, pacientes y respetuosos con los usuarios. 
· En caso de existir problemas en los cuales somos parte afectada, 
recurriremos a otro compañero operador mas neutral que nos ayude. 
· En caso de insultos o amenazas, la postura mas recomendable es el 
silencio. 
· Procuraremos no tomar como personales las ofensas por parte de usuarios. 
· Los operadores como tales tienen un deber hacia la red y sus 
administradores. Se deberá tratar de supervisar el buen funcionamiento 
de la red periódicamente. No se es operador para lucirlo en el whois. 
· Los operadores no deberían ser vistos en canales ilegales como pueden 
ser #000kopias, #nazis o #fotos_niños.

No respetar estos puntos desembocará, en la mayoría de casos, en una falta 
de respeto o mala reputación entre los usuarios, pero, si esta situación 
se prolongase, podría significar la pérdida del status de operador.

———————————————- 
Sección 2 – Comportamiento de los Usuarios 
———————————————-

2.1 Comportamiento inadecuado de usuarios

Frecuentemente, el trato de los usuarios hacia los operadores o hacia 
otros usuarios no será el más apropiado, y nos veremos obligados a actuar 
para remediar esa situación. Estos son algunos castigos que podemos 
aplicar a los usuarios.

2.1.1 Kills

Los kills generalmente son usados como aviso por alguna acción. 
Determinados caso de acoso, de abuso del nivel en canales, ‘takeovers’, 
etc…

2.1.2 G-Lines

Es un aviso más serio y supone la desconexión de toda la red a esa IP por 
un periodo más o menos largo. Aquí existen varios tipos, las g-lines 
temporales (menos de 5?) y las de mayor duración, estas ultimas suelen 
ser aplicadas como castigo excepcional o para cerrar accesos no 
autorizados desde determinadas ips. Un caso típico de g-line es a la 
gente de canales de venta de cds, pornografía infantil, etc, o 
reincidentes en molestias continuadas, etc.

2.1.2.1 G-lines por Oper

El uso de G-lines a través del bot OPeR está limitado a Operadores que 
además sean ircops. La sintaxis del comando es /msg oper block [+tiempo] 
nick razón. El parámetro tiempo es opcional, y en el caso de no ser 
indicado, se presupondrá que es 5 minutos. El tiempo puede ser 
especificado en minutos, horas o días, poniendo m, h o d a continuación 
del número, respectivamente. (Así, 30m serán 30 minutos, 24h serán 24 
horas y 31d serán 31 días) El uso de G-Lines de más de diez minutos es 
solo efectivo en el caso de que tratemos con una persona que disponga de 
ip fija, ya que de lo contrario, puede saltarsela simplemente 
reconectándose a Internet, viéndose la siguiente persona a la que sea 
asignada esa ip afectada injustamente.

2.1.3 Suspensión de Nicks

Otra posible sanción, posiblemente más efectiva, pero a la vez más 
traumática para el usuario (puesto que le priva e su ‘personalidad’ 
cibernética) consiste en suspender el nick por un tiempo. Es importante 
detallar el motivo de la sanción así como la duración de la misma. Se 
debería usar para nicks problemáticos o reincidentes, o como aviso por 
cortos periodos de tiempo. (Para más información, consulte la sección 
Suspensión de nicks).

2.2 Engaños y Estafas

Muchos son los posibles engaños a sufrir por los operadores: usuarios 
haciéndose pasar por otros para obtener la clave del nick, insultándonos 
mientras tiene un nick puesto para conseguir que lo suspendan tras haberlo 
robado, falsos nukes para conseguir una g-line para su enemigo favorito, 
etc. Hay una larga lista de ellos y este no es el sitio para enumerarla. 
La experiencia y nuestra sabiduría serán nuestra única arma y escudo 
contra estos engaños. De nuevo la paciencia será una buena recomendación 
en estos casos. Una conversación con el usuario puede evitar mayores males 
y ser mas efectiva que una suspensión de nick de buenas a primeras.

———————————————- 
Sección 3 – Cuestiones referente a nicks 
———————————————-

3.1 Comprobación de datos de nicks

Siempre que vayamos a realizar cualquier acción sobre un nick, comprobaremos 
que realmente estamos tratando con el dueño del nick en cuestión. 
Para ello, primero comprobaremos que esté identificado (orden /msg nick 
status usuario) y únicamente seguiremos adelante si el usuario esta en STATUS 3 
(Identificado). A continuación, comprobaremos su e-mail (orden /msg nick 
info usuario) y lo verificaremos con el usuario. Si éste no sabe el email 
al que esta registrado su nick, le informaremos que no se puede efectuar 
ninguna clase de cambio de dato en el nick.

3.2 Problemas con emails anónimos

A partir del 17/Octubre/2000, se limitó la lista de emails anónimos a los 
emails con dominios *.cc , *.to y *.nu. Sin embargo, no se descarta 
reactivarla en el futuro si la situación lo requiriese. Cualquier 
operación con CReG por parte de un usuario con nick registrado en uno de 
los dominios anteriores, resultará en la pérdida instantánea de su nick.

3.3 Número de nicks por usuario

Actualmente, el número de nicks por persona es de cuatro, aunque, debido a 
que los proveedores de Internet otorgan a los usuarios un número elevado 
de cuentas y de aliases de éstas, se puede dar el caso de un usuario que 
tiene muchos mas nicks registrados. Si nos encontramos a un usuario que 
tiene un elevado número de nicks mediante diferentes cuentas de pago, 
donde queda patente que se está cometiendo un abuso por parte del usuario, 
le pediremos por favor que de de baja aquellos nicks que no utilice y 
seguiremos el procedimiento de drops de nicks estipulado en este manual.

3.4 Robos/Pérdidas de nicks

Muy frecuentemente, los usuarios pierden las contraseñas de sus nicks, ya 
sea por descuido o porque le han “robado” la contraseña del nick. Este es 
el procedimiento a seguir para los diferentes casos de pérdidas y robos.

3.4.1 Email del nick operativo

Frecuentemente encontraremos a usuarios que afirman que su nick ha sido 
robado o que simplemente han perdido la contraseña. Ante esta situación 
lo primero que debemos hacer es verificar que estemos tratando con el 
dueño del nick en cuestión. Para ello preguntaremos al usuario el email 
al que está registrado el nick. En caso de que el usuario conozca el 
email procederemos a la orden de sendpass al usuario (/msg nick sendpass 
usuario). Pasados varios minutos el usuario recibirá en su email la 
contraseña actual del nick. Recomendamos al usuario que, una vez recibida 
cambie la contraseña de su nick para que no se la vuelvan a robar.

3.4.2 Email del nick inoperativo

Debido a que existen muchas y variadas formas de conocer los emails de 
una persona, los puntos 4.2.1 y 4.2.2 no serán aplicados excepto en casos 
donde sea muy obvio que el email está realmente inoperativo.

3.4.2.1 Set Email

Mediante la orden set email de nick, un administrador puede cambiar el 
email al que está registrado un nick. Este comando debe ser utilizado 
únicamente como recurso de emergencia si un usuario realmente ha perdido 
el acceso a la cuenta de correo, que en la mayoría de casos no han 
perdido sino que no recuerdan como hacerlo. En el caso de que sea 
imprescindible realizar un set email, seguiremos el procedimiento de 
verificación de datos como en la pérdida/robo de nicks. Además, existen 
dos excepciones a esta práctica. Si el cambio de email se debe a que el 
email de un cybercafé ha cambiado el set email lo deberá solicitar el 
responsable del cybercafé. Por otro lado si el usuario posee un elevado 
número de registros, o si por lo tanto posee uno o más registros con 
levels altos en canales importantes, dejaremos el tema en manos de un 
administrador.

3.4.2.2 Getpass sobre nicks

El comando getpass permite conocer el password de un nick. Debido a la 
tendencia al abuso que produciría este comando, está totalmente 
restringido a administradores de services. Aún así, nunca se debe dar la 
contraseña por IRC a un usuario, sino que se deben seguir los 
procedimientos de sendpass establecidos en el punto anterior. El comando 
Getpass desaparecerá en el futuro con la implantación de la base de 
datos distribuida, y actualmente sólo está disponible a titulo de 
información. Solo se debe pedir getpass en casos extremos y únicamente 
para verificación y NUNCA para darle el password al usuario.

3.5 Cambio de datos de nicks

Aunque reservadas para administradores, existen varias funciones para 
cambiar el email y la contraseña de un nick de forma remota.

3.5.1 Set email

Mediante la orden set email de nick un administrador puede cambiar el 
email al que está registrado un nick. Este comando debe ser utilizado 
únicamente como recurso de emergencia si un usuario realmente ha perdido 
el acceso a la cuenta de correo, que en la mayoría de casos no han 
perdido sino que no recuerdan como hacerlo. En el caso de que sea 
imprescindible realizar un set email, seguiremos el procedimiento de 
verificación de datos como en la pérdida/robo de nicks. Además, existen 
dos excepciones a esta práctica. Si el cambio de email se debe a que el 
email de un cybercafé ha cambiado, el set email lo deberá solicitar el 
responsable del cybercafé. Por otro lado, si el usuario posee un elevado 
número de registros, o si por lo tanto posee uno o más registros con 
levels altos en canales importantes, dejaremos el tema totalmente en 
manos de un administrador.

3.5.2 Set password

Mediante esta orden, es posible fijar el password de un usuario. Debido a 
la potencia de este comando, está totalmente restringido a 
administradores, y debe ser utilizada únicamente en casos excepcionales.

3.6 Suspensión de nicks

Las causas de suspensión de un nick pueden ser varias, entre las que están 
los intentos de engaño a usuarios haciéndose pasar por ircops u 
operadores, mensajes masivos continuados, violaciones continuadas de las 
normas de la red, molestias, insultos o coacciones a operadores, nicks 
similares a los de un operador y/o administrador o al de los bots, etc.

Para suspender un nick usaremos la orden /msg creg SNICK SUSPEND 
. Pasado el tiempo especificado, creg levantará 
automáticamente la suspensión del nick. La máxima duración de una 
suspensión es de siete días. Si se considera que el usuario merece una 
suspensión de un tiempo mayor, acudiremos a un administrador. Al suspender 
un nick el usuario recibirá un mensaje de NiCK indicándole que su nick ha 
sido suspendido, así como la razón de la suspensión.

Si queremos levantar la suspensión de un nick por alguna razón, usaremos 
la orden /msg creg SNICK UNSUSPEND . Si queremos información sobre 
un nick suspendido, usaremos la orden /msg creg SNICK LIST , y 
recibiremos información sobre quien lo suspendió, cuando expira, y el 
motivo de la suspensión.

Cabe señalar también que no se puede realizar ninguna acción sobre un nick 
suspendido, como pudieran ser drops, sendpasses, o cualquier otra acción 
que se detalle en esta sección del manual, aún cuando el usuario se 
muestra arrepentido de sus acciones.

3.7 Drops de nicks

Posiblemente, esta sea la acción que más veces debe realizar un operador. 
Para evitar drops de nicks en casos de robos, no está permitido que un 
usuario borre su propio nick, y debe acudir a un operador para realizar 
esta acción.

3.7.1 Peticiones de drop

Si un usuario nos solicita que borremos un nick de su propiedad, ante 
todo le preguntaremos la causa de la baja del nick. En primer lugar, 
procederemos a verificar que conoce el email al que está registrado el 
nick y que está correctamente identificado (status 3). En el caso de que 
estas verificaciones sean positivas, daremos de baja el nick a traves de 
CREG con la orden /msg creg dnick drop nick razón. Vigilaremos mucho en 
el caso de nicks que lleven registrados mucho tiempo o que sean 
fundadores de uno o mas canales, ya que podría tratarse de un intento de 
robo de nick.

3.7.2 Nicks mal registrados

Si un usuario nos solicita que demos de baja un nick porque ha escrito el 
email mal, porque no le ha llegado la contraseña, etc, verificaremos 
mediante la orden info que realmente exista un problema con ese nick. En 
el caso de que un nick no haya sido nunca utilizado, el campo ‘Ultima 
hora por la red’ coincidirá con el campo ‘Hora de Registro’, o por lo 
contrario, marcará como ‘Última hora por la Red’ el 01/Ene/1970. En estos 
casos, pediremos al usuario el email al que lo han registrado, 
comprobaremos que el campo ‘Última máscara’ (que en este caso marcará la 
máscara que tenía el usuario cuando registro el nick) coincide con la 
máscara del usuario que nos pide el drop. En el caso de que estas 
comprobaciones sean afirmativas, daremos de baja el nick.

3.7.3 Drops forzados

Debido a que existe la suspensión de nicks, no se debe utilizar el drop 
excepto cuando sea imprescindible o cuando se vaya a proceder a un forbid 
de nick. De esta manera en la mayoría de casos procederemos a la 
suspensión de un nick, no a un drop de éste.

3.8 Forbid de nicks

El acceso a la función forbid está restringido a los administradores de 
los servicios, y únicamente será utilizada en el caso de nicks que se 
asemejen a los nicks de operadores y/o bots de servicio o usuarios con un 
largo historial de problemas. Para levantar un forbid, sólo es necesario 
dropear el nick, aunque un operador nunca levantará un forbid sin 
consultarlo previamente con un administrador.

———————————————- 
Sección 4 – Cuestiones referente a canales 
———————————————-

4.1 Registro de Canales

Todo el mundo quiere tener un canal registrado propio. Estos son 
procedimientos a seguir para el registro de canales en iRC-Phoenix.

4.1.1 Peticiones de Registro Expiradas

Para que un canal pueda ser registrado se requieren 24 apoyos al 
mismo y solo hay siete días para conseguirlos. Si en este plazo no se 
logran estos apoyos, el proceso de registro expirará y no será posible 
volverlo a registrar sin la intervención de un operador. Si un usuario 
nos solicita el registro de un canal que está expirado, permitiremos su 
registro mediante la orden /msg creg permite #canal. A continuación el 
usuario podrá reiniciar el proceso de registro del canal.

4.1.2 Canales Dropados

Si un canal ha sido borrado/dropado, para volverlo a registrar es 
necesaria la intervención de un operador. 
Distinguimos dos posibles causas del drop:

· Si la causa del drop del canal fue por petición expresa del fundador de 
éste, permitiremos el registro del canal mediante la orden /msg creg 
permite #canal. 
· Si el canal se dropeó por ir en contra de las normas establecidas por 
la red o por alguna clase de polémica o problemática interna, no se 
permitirá el registro del canal.

4.1.3 Canales Prohibidos

Si un canal está prohibido, no es posible bajo ninguna circunstancia 
volver a registrarlo. Las prohibiciones de canales suelen estar motivadas 
por peticiones propias del canal o por prologados problemas con el canal. 
Los operadores no pueden por otro lado permitir el registro de canales 
prohibidos, quedando esta tarea restringida a administradores.

4.1.4 Canales ya Registrados

Más de un usuario intentará  el registro de un canal que ya está 
registrado. Le notificaremos que no es posible duplicar un canal.

4.1.5 Canales Suspendidos

Si un canal está suspendido, no es posible el re-registro del mismo, 
aunque la suspensión esté impuesta desde haga mucho tiempo. Si un usuario 
nos lo solicita, le notificaremos que se ponga en contacto con la 
administración para intentar levantar la suspensión del canal.

4.1.6 Anulación de Canales

En ocasiones el founder del canal se da cuenta que se ha confundido a la 
hora de poner el nombre del canal, o bien una diversidad de problemas que 
le llevan a solicitar la anulación del mismo. Verificaremos que no esta 
ya con los 24 apoyos y pendiente de aprobación de Phoenix, asimismo 
comprobaremos que es el founder, que esta identificado, y que coincide el 
mail. Posteriormente utilizaremos /msg creg anula #canal.

4.1.8 Numero de canales en proceso a la vez

Creg solo permite que cada usuario tenga un canal en proceso de registro 
a la vez como fundador del mismo, efectuándose la cuenta por mails como 
en el punto anterior. Mientras un nick tenga un canal en proceso de 
registro, ningún otro nick registrado al mismo email podrá poner otro en 
proceso. Podrá, sin embargo, realizar apoyos en canales donde no sea el 
fundador.

4.1.9 Aceptación de Peticiones de Registro

Una vez se han logrado los 24 apoyos necesarios para el registro de un 
canal, la petición de registro pasa al equipo encargado de aceptar o 
denegar las peticiones de registro, formado actualmente por jovi, Andromeda 
y Muxikal. No debemos darle esa información a los usuarios bajo ninguna 
circunstancia. El proceso de aceptación suele tardar entre 24 y 72 horas 
en completarse, después de que el último apoyo haya sido realizado. Para 
que un canal sea aceptado, no puede violar ninguna de las normas disponibles 
en http://www.irc-Phoenix.org/admin/canales.html.

4.1.9.1 Peticiones de Registro Denegadas

Un canal puede ser denegado por tener una descripción poco clara o 
inexistente, por ser un canal comercial o por ser un canal oficial. En 
el caso de las descripciones poco claras o inexistentes, si un usuario 
lo solicita, el canal puede ser permitido por un operador con la orden 
/msg CReG permite #canal. Con ello el canal quedará libre para ser 
registrado de nuevo. Si se trata de un canal oficial o comercial, no 
deben permitirse. Comunicaremos a los usuarios que deberán dirigirse a 
comercial@irc-Phoenix.org para el registro de un canal comercial o a 
info@irc-Phoenix.org para un canal oficial. 
Alguna vez, veremos un canal cuyo motivo de denegación no esté claro. Si 
creeis que se trata de un error (al fin y al cabo, los tres son humanos y 
pueden equivocarse), hablad con uno de ellos. Si consideran que, efectivamente, 
el deniega fue erróneo, pueden volver a poner el canal en su estado anterior 
usando el comando /msg creg enregistro #canal y proceder a la aceptación del 
mismo. Este comando está limitado a los administradores de la red y los 
operadores Andromeda y Muxikal.

4.1.9.2 Peticiones de Registro Rechazadas

Un canal puede ser rechazado por estar fuera de normas, por tener emails 
no válidos en los apoyos (una misma persona ha usado varios emails para 
apoyar el mismo canal), o por tratarse de un canal reservado para la red 
(por ejemplo, los canales contra el terrorismo). Un canal rechazado NO 
puede ser permitido, sea cual sea la razón. Aunque un administrador de 
la red tiene la facultad de hacerlo, actualmente no se permiten 
canales rechazados cualesquiera que sean las razones o excusas. Si nos 
piden un canal rechazado, informaremos al usuario de las razones del 
rechazo y de la imposibilidad de su registro.

4.1.10 Expiración de Canales

No confundir este punto con el punto 1.1 ‘Peticiones de Registro 
Expiradas’. Cuando un canal no es utilizado en un plazo de 20 días por 
ninguno de sus usuarios registrados, el canal expira. Debido a que CReG y 
CHaN son totalmente independientes entre sí, cuando un canal expira en 
CHaN para CreG sigue estando registrado. Si alguien nos solicita un 
re-registro del canal, sea o no el mismo fundador que tenía antes, 
procederemos a un drop del canal (/msg creg drop #canal temporal) y a 
un permite (/msg creg permite #canal). A partir de ese momento, el canal 
podrá volver a ser registrado.

4.1.11 Desacuerdo entre CReG y CHaN

Como bien hemos aclarado en el punto anterior, a veces se producen 
situaciones donde los dos bots no se ponen de acuerdo sobre el estado de 
un canal. Otra posible situación que haya causado esto es un error 
interno de los services o bien una pérdida de la base de datos, aunque 
ambas cosas son muy esporádicas. Para estas situaciones, en las que CHaN 
pierde el registro de un canal pero CReG conserva los datos originales, 
se habilita el comando restaura (/msg creg restaura #canal), que restaura 
el registro de un canal. 
Sin embargo, no debéis confundir un error de database con un canal expirado 
4.2 Canales registrados

A continuación detallamos las pautas a seguir en las actuaciones en 
canales ya registrados en la red.

4.2.1 Bans

Frecuentemente, seremos cuestionados sobre la presencia de bans en 
canales que afectan a los usuarios. Distinguimos los siguientes criterios 
de actuación.

4.2.1.1 Bans demasiado genéricos

En muchas ocasiones, algunos canales deciden banear de forma genérica 
para librarse de forma rápida y sencilla de usuarios que podrían ser 
potencialmente molestos para su canal. Distinguimos varios tipos de 
bans genéricos y varios criterios de acutuación.

4.2.1.1.1 Bans a cybercafes

Si el administrador de un cybercafé  nos solicita intervenir porque ha 
sido baneado toda su ip (y todos sus clientes, por lo tanto), entraremos 
al canal en cuestión y recomendaremos (pero nunca obligaremos) a los 
usuarios con op que retiren el ban. Si no hay operadores en el canal o 
los que haya llevan inactivos desde hace una hora o mas, retiraremos el 
ban. Hemos de ir con cuidado con los cybercafes que tienen una ip por 
máquina, ya que en este caso, aplicaremos el mismo procedimiento que un 
ban a un usuario particular. (Ver punto 2.1.2)

4.2.1.1.2 Bans a scripts

Se permitirán los bans a scripts siempre que se haya decidido por la 
mayoría del canal y que sea conocido por su administración del mismo. Se 
contempla esto debido a que algunos scripts abusan de los colores o de 
otros elementos que pueden ser molestos para el resto de usuarios. En 
el caso de que se produzca un ban de este tipo en un canal, el operador 
no actuará e informará al usuario que con un cambio de ident podrá 
volver a entrar al canal.

4.2.1.1.3 Bans a Proveedores o Países

No se tolerarán bans genéricos a proveedores o países, sobre todo si se 
trata de canales con una gran afluencia de usuarios. En el caso de 
producirse un ban de este tipo, entraremos al canal, y pediremos a 
alguno de los ops que lo retiren. En el caso de que estos se nieguen, 
retiraremos el ban nosotros mismos y nos quedaremos en el canal para 
evitar que sea restablecido.

4.2.1.2 Bans a usuarios

No actuaremos nunca, bajo ninguna circunstancia, en el caso de que se 
banee a un usuario de un canal, sea cual sea el motivo, nos parezca o no 
nos parezca bien. Informaremos al usuario de que puede quejarse al 
administrador del canal pero que un operador no puede retirarle el ban. 
Tampoco actuaremos si el usuario es un registrado del canal, pero con 
level insuficiente para desbanearse. Es un tema totalmente interno al 
canal.

4.2.2 Abusos

Como siempre, el poder hace que las personas cambien, y en ocasiones, 
abusen del mismo. Distinguimos los siguientes tipos de abusos en un 
canal.

4.2.2.1 Un registrado abusa de su registro

Una vez más, en la mayoría de casos seguiremos un procedimiento de ‘no 
actuación’ e informaremos a los afectados que deben quejarse al 
administrador del canal. Únicamente se intervendrá cuando el registrado 
este llegando a limites de abuso intolerables, como banear a todos los 
usuarios que entren y tengan op en el canal, o en el caso de que no haya 
ningún otro usuario registrado pueda intervenir para frenar un ataque de 
ira de otro registrado. Aún así, nuestra intervención será corta, directa 
y lo más discreta posible. Si el usuario nos increpa, le invitaremos a 
seguir la discusión en privado.

4.2.2.2 Un no registrado abusa del op

Una vez más, en la mayoría de casos seguiremos un procedimiento de no 
actuación, e informaremos a los afectados que deben quejarse al 
administrador del canal. Únicamente se intervendrá cuando no hayan otros 
registrados en el canal que le puedan detener. Aun así, intervendremos 
de forma rápida y discreta.

4.2.3 Robos de Canales

Es bastante frecuente que, aprovechando despistes de los fundadores, 
otras personas se apropien de sus canales. Hay dos formas de conseguir 
esto: una de ellas es conseguir la clave del nick del fundador y la otra 
conseguir la clave del canal. Al conseguir una de las dos claves, 
conseguirán acceso con level 500 al canal, y, normalmente, cambiarán el 
founder del canal u otros aspectos de éste. Si somos informados de que se 
ha producido un robo en un canal, contrastaremos el fundador actual del 
canal con el fundador original/anterior del canal mediante creg, (/msg 
creg info #canal). Una vez se haya localizado y restablecido el fundador 
del canal, marcaremos el canal (/msg creg marca #canal texto) para que 
quede constancia de ello, y recomendaremos un cambio de password al 
fundador del canal.

4.2.4 Takeovers

Cuando recibamos el aviso de que un canal ha sido tomado, primero de todo 
hemos de comprobar que no se trate de un canal de carácter privado. Una 
vez hemos comprobado eso, podemos utilizar la orden /msg chan clear 
#canal modes, entrar al canal y observar si el autor del takeover sigue 
en el canal. En el caso de que siga en el canal, le deoparemos. Si 
contesta a esto con insultos hacia nosotros, solicitaremos una expulsión 
para el individuo.

4.2.5 Cambios de datos de canales

En muchas ocasiones, debido a la incompetencia del fundador, o bien 
debido a otros problemas, será necesario que cambiemos de forma remota 
datos de un canal registrado.

4.2.5.1 Getpass sobre Canales

Debido a que a un fundador no le es necesario conocer la clave de un 
canal para ejercer de administrador, frecuentemente encontraremos a 
fundadores que no conocen la clave de sus canales, siendo imposible 
meterles en la cabeza que no la necesitan.

Todos los operadores tienen acceso a la función getpass de canales. 
Primero, intentaremos convencer al usuario que no necesita la clave, 
puesto que, si esta autentificado con nick, chan le reconocerá el nivel 
automáticamente. Si nos dice que a pesar de estarlo, no le reconoce como 
tal, usaremos el comando /msg chan status #canal nick para saber el nivel 
que chan le reconoce en ese canal. Si el nivel no es 500, es que se ha 
registrado a si mismo con el otro nivel y le comunicaremos que se borre.

Si no podemos convencerle, para darle la clave del canal a alguien 
deberemos comprobar que:

· Es el founder del canal 
· Conoce el email de registro del nick 
· Está autentificado con el nick (status 3) Una vez comprobados estos 
datos, procederemos a obtener la clave con /msg chan getpass #canal

4.2.5.2 Cambios de nombre de Canales

No están permitidos los cambios de nombres de canales bajo ninguna 
circunstancia. Si un fundador desea cambiar el nombre de su canal, le 
informaremos que no es posible tal acción, y le invitaremos a registrar 
un nuevo canal y dejar que el viejo expire por falta de uso.

4.2.5.3 Otros cambios de datos

Nunca, bajo ninguna circunstancia, cambiaremos ningún dato de canales 
excepto cuando estemos autorizados por el fundador para arreglar una 
eventualidad que él no sepa resolver.

4.2.6 Cambios de Fundador

Aunque no debería ser algo frecuente, debido al gran número de canales 
registrados, se realizan diariamente un elevado número de cambios de 
fundador. Distinguimos los siguientes criterios de actuación en cada 
caso.

4.2.6.1 Elecciones en canales

Se distinguirán dos tipos de elecciones: elecciones en canales de pueblos y 
Ciudades, canales de cualquier otro tipo de temática. 
Solamente se pueden exigir elecciones en los canales de pueblos y ciudades, 
estando las elecciones en otros canales a discreción de los administradores de 
la red y de las circunstancias particulares del canal en el que se pidan. 
En ambos casos es un proceso complejo y largo que requerirá la supervisión de 
un administrador y de posiblemente otros operadores mientras dure el proceso.

4.2.6.1.1 Elecciones Solicitadas en este tipo de canales 
(pueblos y ciudades)

No todos los usuarios del IRC han nacido para ser administradores de 
canales y, muy frecuentemente, los usuarios de un canal están 
disconformes con la administración que esté llevando el administrador 
del mismo. La primera recomendación al usuario será que funde un canal 
alternativo al canal del que tiene quejas, y que no vuelva a entrar en 
él. Únicamente se realizarán elecciones en un canal si el canal posee 
como mínimo seis meses de antigüedad, tiene alrededor de 75 usuarios 
registrados en el mismo y al menos el 60% de los usuarios registrados 
en el canal solicitan un cambio de administración. Si se reúnen estas 
condiciones, actuaremos juntamente con un administrador y otro 
operador, ya que la avalancha de acusaciones, insultos, argumentos a 
favor y en contra del fundador puede ser considerable. Se organizarán 
entonces unas elecciones para elegir al nuevo fundador, siguiéndose en 
este caso el procedimiento que marque el administrador que esté 
encargado del tema. Si el canal no reuniera las características 
mencionadas, informaremos al usuario que deben solucionar los problemas 
de canal internamente y que no es posible que iRC-Phoenix organice unas 
elecciones.

4.2.6.1.2 Elecciones en el resto de canales.

Cuando nos pidan elecciones en un canal que no sea de pueblo o ciudad, 
pediremos que nos expliquen las circunstancias y razones por las que 
nos lo solicitan. Si solo desean nuestra intervención para supervisar 
los resultados para que el recuento de votos para que sea mas justo, 
lo haremos sin ningún inconveniente, aunque siempre será voluntario 
del operador aceptar o no. 
En caso que nos pidan forzar unas elecciones, recomendaremos primero 
al usuario será que funde un canal alternativo al canal del que tiene 
quejas, y que no vuelva a entrar en él. En el caso que se trate de 
un canal lo suficientemente genérico con seis meses de antigüedad 
como mínimo y alrededor de 75 usuarios registrados, consultaremos el 
tema con un administrador de la red, quien será el que decida si hay 
razones suficientes para que el iRC-Phoenix organice unas elecciones. 
Un operador de la red no puede decidir por su cuenta celebrar unas 
elecciones. Estas decisiones están solo en manos de los administradores.

4.2.6.2 Cambio acordado de fundador

Aunque casi nunca se suele notificar, se llevan a cabo notables cambios 
de fundador de forma interna en un canal. Cuando nos notifiquen de un 
cambio de fundador, dejaremos constancia mediante la orden marca (/msg 
creg marca #canal texto) para facilitar la tarea de otros operadores en 
el caso de que el canal sufra algún problema en el futuro.

4.2.6.3 Reestablecimiento de fundador

Cuando el nick del administrador de un canal expira o es dropeado, el 
fundador del canal pasa a ser el bot CReG o el operador que lo haya 
dropeado, respectivamente. Lo más habitual es que, en un plazo no 
superior a 48 horas después del drop del nick, reclamen que sean 
restablecidos como fundadores del canal.

4.2.6.4 Canales sin Fundador

Si no ocurriera lo citado en el caso anterior, y el fundador no 
reclamara que le sea devuelto el canal, probablemente lo solicitarán 
otros usuarios del canal. En ese caso, se procederá a asignar el cargo 
de fundador al usuario que posee mayor nivel de acceso en el canal. Si 
hubiera varios usuarios con el mismo nivel de acceso, se les comunicará 
que deben llegar a un acuerdo de forma interna sobre quien será el 
fundador. Si no hubiera un acuerdo entre estos usuarios, el fundador 
pasará a ser CReG hasta que lleguen a un acuerdo.

4.2.7 Cuando Marcar un Canal

Mediante el proceso de marcar un canal (/msg creg marca #canal texto) 
podemos mantener un histórico de los cambios o problemas que haya sufrido 
un canal. Es conveniente marcar un canal cada vez que haya un cambio de 
fundador, cuando repongamos un fundador después de un robo de canal, 
cuando haya algún problema con el canal, etc. Mediante este proceso, 
simplificamos el trabajo del resto de operadores y evitamos duplicidades 
y confusiones que puedan llevar a una mala atención al usuario. 
En las marcas incluiremos los nicks implicados y mails para tener datos 
reales en futuras ocasiones, dado que a veces los nicks expiran y otros 
usuarios intentan hacerse pasar por ellos para provocar problemas en los 
canales.

4.2.8 Suspensión de canales

Se procederá a la suspensión de un canal mediante la orden /msg CReG 
suspend #canal razón cuando se de alguna de las siguientes circunstancias: 
se infrinjan las normas de la Asociación, las actividades del canal no se 
corresponden con las que se indicaron al registrar el canal (la descripción 
en CReG), la suplantación de actividades oficiales de la asociación sin su 
consentimiento, cuando el nombre de un canal se corresponda con una marca 
registrada en el registro de patentes y marcas y el propietario de ésta 
reclame la suspensión, desarrollo de actividades comerciales en canales no 
destinados a ello, problemática constante con los usuarios del canal, etc. 
El suspend no será perpetuo a no ser que infrinja frontalmente las normas 
De Irc-Phoenix (piratería, pedofilia, canales comerciales, delitos cometidos 
en el canal. Aun así en estos casos se le comunicara a un admin. que supervi- 
sará estos suspends cuando hayan superado un tiempo determinado. 
No es lo mismo una suspensión por publicidad que por una de las anteriores 
causas citadas si no son reincidentes. 
No se suspenderán canales por apoyos a partidos políticos legalizados en 
España. Habrá que informarse bien antes de la suspensión, metiendo clones 
hablando con gente y ante una duda consultar con un admin.. 
Es recomendable explicar al founder claramente las razones del suspend y 
las pruebas que nos llevaron a ello. 
Prestaremos especial atención las marcas que tenga el canal en creg, por si 
otro operador esta al cargo del tema o conoce el problema mas ampliamente. 
Asimismo en caso de haberlo suspendido al retirar la suspensión lo marcaremos 
describiendo brevemente los hechos que llevaron al suspend.
 

 

4.2.9 Drops de Canales

Aunque no debería ser una tarea frecuente, en ocasiones deberemos 
proceder a borrar un canal, ya sea por petición del administrador o por 
decisión del equipo de operadores.

4.2.9.1 Drops Solicitados

Muchos administradores de canales se cansan de su canal cuando ven que 
no tiene éxito y piden que sea borrado. Primero de todo, hemos de 
comprobar el tamaño del canal que nos están pidiendo que borremos. Si es 
un canal de un tamaño considerable, es preferible que nos pongamos como 
fundador del canal y hagamos que los usuarios registrados elijan un 
nuevo fundador, antes que eliminar el canal. Si se trata de un canal 
pequeño y sin afluencia, procederemos a verificar los datos del fundador 
del canal, siguiendo los métodos de verificación como si de un drop de 
nick se tratara. Una vez corroborados los datos, ejecutaremos la orden 
de drop (/msg creg drop #canal motivo).

4.2.9.2 Drops No Solicitados

Se droparán canales cuando contradigan en gran medida las causas de 
suspensión de un canal estipuladas en este manual y sus administradores 
no desean cesar. También se utilizará cuando un canal esté dentro de las 
normas de canales no aceptables para el registro, disponibles 
públicamente en http://www.irc-Phoenix.org/admin/canales.html 
#noregistro. Cuando hagamos esta clase de drops, también mediante la 
orden /msg creg drop #canal motivo, especificaremos de forma clara y 
concisa la razón del drop para que otros operadores y los mismos 
usuarios del canal entiendan con claridad. 
No se droparán canales por causas disciplinarias, únicamente se suspenderán. 
Hay que dar al usuario el derecho a reclamar y a defenderse y rehabilitar 
el canal en caso de equivocación, contando que si lo dropamos perderemos 
las posibles pruebas (topics fijados por chan, horas en las que se puso…)

4.2.10 Cierre de Canales

En el caso que un canal suponga una grave violación de las normas de la 
red o en los que se realicen masivamente actividades ilegales tipificadas 
en el código penal (lease canales de copias, pornografía infantil, nazis, 
etc), se procederá a suspenderlo con la orden /msg creg suspend #canal 
razon. Si la actividad persiste, será dropado al cabo de unos días. Si la 
actividad fuera extremadamente grave, y tras consulta en #opers, se 
procedería al drop inmediato del canal y a su prohibición, si fuera 
necesario, por parte de un administrador de la red.

4.2.11 Problemas Frecuentes con Nojoin, Autodeop y Restricted

De tanto en tanto, algún fundador nos avisará de que no entiende porqué 
en su canal no puede dar op o no puede entrar gente que no esté 
registrada. Esta clase de problemas están siempre relacionados con los 
levels del canal y/o sus opciones. Para que personas ajenas al canal, que 
no estén registradas en este, puedan tener op, el level de AUTODEOP debe 
estar a -1, y para que personas que no están registradas puedan entrar, 
el level de NOJOIN debe estar a -1. Si el level de alguno de los dos es 
superior a -1, no podrán conseguir op o serán baneados, respectivamente. 
También hay que tener precaución con la opción restricted, ya que tiene 
el mismo efecto que si NOJOIN estuviera en un level 0 o superior.

4.2.13 Unión de dos o más canales

La red no da soporte a las uniones de canales, aunque si está permitido 
hacerlo, siempre que se encarguen de la unión los respectivos 
administradores de los canales, sin la intervención de un operador. 
Aunque se unan dos o más canales, no constituye esta una razón para que 
ningún canal sea dropeado, de manera que informaremos al administrador 
que deje que el canal expire. El motivo para este criterio de actuación 
es el hecho de que si la unión no resulta, nos reclamarían que 
reestablezcamos el canal, cosa que técnicamente no es posible. De esta 
manera, si esto ocurriera, y el canal ya hubiera expirado por falta de 
uso, deberán volver a registrar el canal como si fuera nuevo.

4.2.14 Borrado de usuarios que no desean registro

Puesto que se ha implementado el comando DELACCESS en Chan, los operadores 
de la red ya no intervienen en estos casos. Si un usuario nos pregunta, le 
informaremos de la existencia del comando y de su uso: /msg chan DELACCESS #canal. 
DELACCESS borra el registro del usuario que ejecute el comando en el canal 
que especifica. No borra akicks ni niveles -1, y no permite al founder del 
canal borrarse a sí mismo.

4.3 Canales no Registrados

Aunque no existen muchos canales no registrados con presencia constante de 
usuarios, existen las siguientes pautas de actuación para estos canales.

4.3.1 Bans

No actuaremos nunca, bajo ninguna circunstancia, en los bans de un canal 
no registrado, sean a cybercafés, scripts, países o individuos. No se 
tolerará bajo ninguna circunstancia que un operador retire bans en 
canales no registrados.

4.3.2 Abusos

No actuaremos nunca bajo ninguna circunstancia en caso de abuso en un 
canal no registrado. Los canales no registrados no tienen soporte por 
parte de la red, con lo cual no se contemplan abusos en estos canales.

4.3.3 Restablecimiento de Op

Con mucha frecuencia, y debido a que no tienen bots que guarden el op, 
seremos solicitados para dar op en canales no registrados. Para hacerlo, 
entraremos al canal, opearemos a la persona en cuestión, y observaremos 
si opea a demás personas en el canal y no se produce ninguna anomalía. Si 
se produjera alguna anomalía, deoparemos a quién hemos dado op y 
preguntaremos en el canal quién debería tener op. Si no muestran 
unanimidad, abandonaremos el canal y les dejaremos sin op, hasta que se 
pongan de acuerdo entre ellos. En el caso de no producirse, abandonaremos 
el canal.

Si infringen la normativa de Phoenix, se deja a libertad de conciencia de 
cada oper el restablecer o no el op con la recomendación de no hacerlo, 
en base a la calibración de la circunstancia.( #hack , #2_hermanos ) 
Si se trata de canales que su función es la comision de un delito 
(#csd , #000roskillas , #warez ) no se dará soporte bajo ninguna circunstancia

4.3.4 Takeovers

Con mucha frecuencia, se producirán takeovers de más o menos envergadura 
en canales no registrados. Algunos de ellos, deoparán a todos los 
presentes y se esfumarán, dejando el canal sin op. Otros, pondrán modos 
restrictivos en el canal y banearán a todos los presentes. Cuando seamos 
avisados de una situación de este tipo, entraremos al canal y 
estudiaremos la situación. Procederemos a deopar al individuo en 
cuestión, banearle del canal, limpiar todos los bans que haya puesto, 
quitar todos los modos privilegiados del canal (siempre que no estemos 
arreglando un canal de carácter privado), y opearemos a quien nos avisó 
del takeover. Seguiremos el mismo procedimiento que cuando restablecemos 
el op.

4.3.5 Canales Privados

Existen canales de carácter privado, esto es, tienen claves de acceso o 
están en modo invite-only permanentemente. En el caso de que tengamos que 
intervenir en un canal de este tipo, respetaremos sus normas de acceso y 
restauraremos los modos tras nuestra intervención. Nunca bajo ninguna 
circunstancia, facilitaremos la entrada de terceras personas a estos 
canales sin la autorización de sus miembros.

4.3.7 Cierre de Canales

En el caso que un canal suponga una grave violación de las normas de la 
red o en los que se realicen masivamente actividades ilegales tipificadas 
en el código penal (léase canales de copias, pornografía infantil, nazis, 
etc), se procederá a cerrarlo con la orden /msg creg apodera #canal. Esta 
orden hace que chan deope a todos los usuarios del canal y ponga los 
modos, dejándolo inoperativo a todos los efectos. Nunca aplicaremos este 
comando sobre canales registrados, sino únicamente sobre canales no 
registrados y muy problemáticos. Cuando el asunto sea mas grave y 
requiera sanciones tales como glines, procederemos a informar del asunto 
en el canal #opers para que un ircop se haga cargo del asunto.

4.4 Canales Comerciales

Los operadores y administradores no podrán realizar ninguna clase de 
acción sobre canales comerciales. Únicamente podrán realizarlas 
el equipo de administradores encargado de los canales comerciales. Los 
operadores / administradores podrán intervenir en ellos cuando se produzca 
alguna acción adversa, como takeovers, avalanchas de usuarios debido a 
publicidad, etc. Los temas de canales comerciales los lleva Sisco.

4.5 Actuación sobre canales de temática problemática

4.5.1 Actuación sobre canales de warez

La asociación no da ni quiere ni permite que ese tipo de canales se 
encuentren visibles en nuestra red. Si aparece un canal no secreto con ese 
tipo de temática se cerrará y se expulsará de la red a los asistentes.

4.5.2 Actuación sobre canales de copias de CDs

La asociación no da ni quiere ni permite que ese tipo de canales se 
encuentren visibles en nuestra red. Si aparece o se nos avisa por parte de 
un usuario de la existencia de un canal no secreto con ese tipo de temática, 
una vez comprobado, se cerrará y se expulsará de la red a los asistentes.

4.5.3 Actuación sobre canales de intercambio de MP3 o con FServes de MP3

Sobre la base de que los formatos en si no son ilegales, si lo es el 
intercambio de material con copyright. Si se comprueba fehacientemente ( 
usease personalmente ) que se está haciendo una replicación industrial o 
indiscriminada de material con copyright se suspenderá el canal. El soporte 
de este tipo de canales no registrados, si se da por parte de un oper, es a 
título personal, aunque la asociación da libertad para dar op o no segun lo 
considere el oper en base al beneficio de la red. En ningún momento será un 
soporte como el del un canal registrado.

4.5.4 Actuación sobre canales de intercambio de pornografía infantil

La pornografía infantil es delito en España, pero se trata de un tema muy 
delicado por lo que hay un operador, Tokeny, encargado en exclusiva del tema. 
Si os encontráis u os informan de un caso de pornografía infantil, debéis poneros 
en contacto con él, darle la información y dejar que se encargue del tema.

4.5.5 Actuación sobre canales de intercambio de pornografía no infantil

La pornografía no es delito en España, por lo que no hay problema en que 
existan y esten registrados.

4.5.6 Actuación sobre canales de IRC-WAR

No se permite su registro pero si su existencia. Si generan problemas pedir 
ayuda a un admin. Son canales que no se les da soporte. El soporte de este 
tipo de canales no registrados, si se da por parte de un oper, es a título 
personal, aunque la asociación da libertad para dar op o no segun lo 
considere el oper en base al beneficio de la red. En ningún momento será un 
soporte como el del un canal registrado.

4.5.7 Actuación sobre canales de hacking

Son canales que la red no les da oficialmente soporte ni permite su 
registro. El soporte de este tipo de canales no registrados, si se da por 
parte de un oper, es a título personal, aunque la asociación da libertad 
para dar op o no segun lo considere el oper en base al beneficio de la red. 
En ningún momento será un soporte como el del un canal registrado.

4.5.8 Actuación contra canales que ataquen al IRC-Phoenix o a sus miembros

/mode ignore on, también tienen derecho a despotricar . En todo pedir 
consejo a un admin e intervenir solamente en caso de multiplicación masiva 
de este tipo de canales

4.5.9 Actuación contra canales de temática no registrable que por una u 
otra razón han conseguido “colarse” y ser registrados

Suspensión del canal e informe a la lista.

———————————————- 
Sección 5 – IPs reales e IPs virtuales 
———————————————- 
A partir de agosto del 2000, los operadores de la red no podemos ver la ip real 
———————————————- 
Sección 6 – Problemas entre usuarios 
———————————————-

Si un usuario nos notifica que está siendo atacado, insultado, amenazado, 
coaccionado, etc. por otro usuario, informaremos al usuario que debido a 
que no podemos verificar que esas acusaciones sean ciertas, no podemos 
ayudarle. Si un usuario está siendo atacado por parte de otros usuarios, le 
informaremos que no podemos atender su queja debido a que no podemos 
verificar que el ataque se esté produciendo realmente. Si nos notifican que 
se está produciendo un ataque masivo contra un canal, entraremos a él, y 
comprobaremos la situación. Si observamos que un usuario está 
atacando/nukeando a los miembros de un canal, y conseguimos que el usuario 
admita su culpabilidad, podremos expulsarle de la red. Si no conseguimos 
una ‘confesión’ por parte del usuario, no podremos intervenir al no poder 
fiarnos de la palabra de quienes afirman que está atacando. El único caso 
en el que podremos expulsar al usuario sin conseguir una confesión del 
mismo es en el caso de que esté atacando al canal con métodos visibles, 
como por ejemplo el uso del bug “con” de Windows o la entrada masiva de 
clones al canal. Nunca podemos utilizar logs, capturas de pantalla, o 
ninguna otra prueba que nos aporten los usuarios, ya que todas son, unas 
más fácilmente y otras más difícilmente, manipulables para conseguir 
librarse de algún enemigo.

———————————————- 
Sección 7 – Otras cuestiones 
———————————————-

7.1 Actuación de los opers en caso de publicidad

7.1.1 Publicidad activa

La publicidad activa es aquella que emplea de métodos ‘agresivos’ como 
enviar mensajes al canal, o mandar saludos a cada usuario que conecta en 
el mismo o cuando lo abandona. 
La publicidad activa es punible ya que molesta a los usuarios y consume los 
recursos de la red en actividades que ya tenemos reguladas (para mas 
información
http://www.irc-phoenix.org/ ). Por tanto estos 
bots/usuarios deberían ser baneados del canal donde se hallen y glineados. 
Esto no es suficiente en muchos casos por lo cual seria recomendable hacer 
una lista de nicks con IPs y demás datos para determinar desde donde acceden 
y poder pedir a sus ISPs correspondientes la toma de medidas.

7.1.2 Publicidad pasiva

Publicidad pasiva es aquella en la que no envían comandos mas que como 
respuesta a acciones de los usuarios. Un ejemplo de ello seria al abrir 
un privado a una persona ausente y que su mensaje de auto respuesta fuera 
una Web o similar. 
Si se trata de anunciar una página web personal, un canal, etc EN MODO 
PASIVO no hay problema. 
Si se trata de un anuncio de una web comercial de dialers, webcams, warez, 
portales comerciales, etc entonces se tiene que actuar como si fuera un bot 
activo.

Normas de Netiqueta

Netiqueta para los usuarios de IRC 
El objetivo de las reglas de netiqueta es proporcionar un entorno agradable para todos, en el que se pueda conversar y hacer amigos sin molestar al resto de usuarios. Por ello conviene seguir una serie de normas básicas:

La primera regla, absolutamente básica, es: “No hagas nada que no quieras que te hagan”.

Está prohibido molestar al resto de los usuarios, o comprometer y degradar el funcionamiento de la red. Elloincluye flooding, ataques CTCP, ping, nukes, etc. Una actuación lo bastante persistente o molesta puede acarrear la expulsión de la red por tiempo indefinido. No envíes mensajes globales a toda la red, ya que generan muchísimo tráfico y, normalmente, no interesan a nadie. Si necesitas buscar usuarios con aficiones comunes, de la misma ciudad, etc., crea el canal apropiado y espera a que la gente vaya entrando poco a poco.

Cuando entres en un canal nuevo sigue durante un rato las conversaciones para 

descubrir cuál es la temática que se está desarrollando. Respeta la temática del canal y utiliza un lenguaje apropiado. Las conversaciones con temáticas no vinculadas al canal deben mantenerse en privado (usando los Query’s o los DCCs).

Evita el uso de mayúsculas, ya que pueden interpretarse como gritos o enfado. Usa los Smileys cuando sea necesario.

Evita el uso de mensajes de bienvenida automáticos. Personalmente me disgusta entrar en un canal y encontrarme con 25 notices diciendo “Bienvenido, Jcea”, enviados de forma totalmente pasiva e impersonal, y cuyos remitentes no es que no sepan quienes somos, sino que -en muchas ocasiones- ni se han enterado de que hemos entrado en el canal. Es mucho más agradable ser saludado por uno o dos usuarios conocidos que nos hayan visto entrar.

Un script mal configurado o utilizado por un usuario inexperto es muy peligroso. Como sabemos que no vais a dejar de usarlos porque nosotros lo digamos, y porque son útiles cuando se saben usar, el consejo es no ausentarse mientras se aprende a utilizar un script nuevo, ya que durante esos minutos en los que no estamos pendientes es posible crear el caos en un canal.

La creación de canales de temática ilegal o considerada improcedente (apología del terrorismo, pornografía infantil, warez, etc.) está prohibida. También lo está el utilizar los recursos e infraestructura de la red para la distribución de mensajes o documentos de las categorías indicadas antes.

Si te apetece iniciar una conversación nueva, no la inicies con un “¿Alguien quiere hablar?”. Es preferible proponer un tema de discursión concreto y esperar la reacción del canal.

Procura no repetir varias veces seguidas una misma línea. Aunque ello puede favorecer tu “visibilidad”, sólo contribuyes a aumentar el nivel de “ruído ambiente” del canal e invitas a que los demás hagan lo mismo, empeorando más -si cabe- la situación. Seguir las conversaciones en un canal de estas características es imposible.

Por último, estimado amigo, un consejo: por muy interesante que sea el IRC, no es un sustituto para la vida real; sí, eso que hay ahí fuera };-). Aprovecha lo mejor de ambos mundos y mantén la cabeza fría Es posible que tu navegador no permita visualizar esta imagen. .

——————————————————————————–

¿Cómo dirigirse a un IRCop? 
Los IRCops somos, por regla general, personas bastante ocupadas. Aunque estemos conectados muchas horas al IRC, eso no significa que pasemos el rato de charla con los colegas, ligando a la rubia de turno o, simplemente, que estemos pendientes de que algún usuario se ponga en contacto con nosotros. Por ello no es raro que estemos “away”. Algunas cosas que deberían ser tenidas en cuenta al dirigirse a un IRCop:

La misión de los IRCops es intentar ayudar a los usuarios cuando hay problemas y procurar que la red funcione lo mejor posible. Pero no hay que olvidar que se trata de una tarea voluntaria y que no se nos paga por ello. El IRC Phoenix es una red puesta en marcha de forma voluntaria y desinteresada. Los usuarios pueden pedir pero, en ningún caso, exigir. Recordad que sois invitados, no los propietarios de la red.

Para repartir un poco la carga, es recomendable que los usuarios se pongan en contacto primero con el IRCop perteneciente a su proveedor.

Para evitar duplicar esfuerzos, un usuario no debería requerir la atención de varios IRCops hasta que sea patente que el elegido en primer lugar no responde.

Dirigirse a un IRCop en un canal en el que no se le ve activo es algo condenado al fracaso. Habitualmente un IRCop estará en varios canales a la vez, pero no los sigue por no tener tiempo para ello.

El estado natural de un IRCop es away ya que, normalmente, conectará desde el trabajo y está  pendiente de otros temas. No obstante lo normal es activar el log de los mensajes que se le envían y revisarlo de vez en cuando.

Debido a ello no tiene mucho sentido mandarles un mensaje con un simple “¿estás?”. El IRCop puede ver dicho texto diez minutos más tarde.

Resulta mucho más productivo enviar una explicación del problema, ya que ésta queda en los logs y, cuando encuentre un rato, el IRCop se ocupará de ella.

Es buena política, también, el avisar al IRCop si el problema se resuelve sólo o se ha ocupado ya algún otro compañero. De esta forma evita perder su tiempo estudiando un problema solucionado hace rato.

Que un IRCop esté away no es razón para no ponerse en contacto con él, si hay motivos suficientes. Aunque no lo parezca revisamos de vez en cuando los canales y los mensajes privados que se nos envían.

Por último, nunca está  de más una cortesía mínima. No nos cuesta nada hacer del IRC un lugar un poquito más agradable para todos. 
 
 

Comandos de OPeR: 
 

GLOBAL Envía un mensaje a TODOS los usuarios por privmsg

/msg oper global [mensaje] 
 

GLOBALN Envía un mensaje a TODOS los usuarios por notice

globaln [mensaje] 
 

STATS Muestra el estado de los servicios y de la red

/msg oper stats 
 

SERVERS Muestra los servidores de la red

/msg oper servers

OPER LIST Lista todos los Operadores de los Servicios

ADMIN LIST Lista todos los Administradores de Servici

LOGONNEWS Añade un LOGONNEWS /msg oper logonnews [msj] 
 

OPERNNEWS Añade un OPERNNEWS /msg oper opernnews [msj]

MODE Cambia los modos de un canal /msg oper  mode #canal +

CLEARMODES Quita todos los modos de un canal /msg oper clearmodes #

BLOCK Expulsa 5 minutos a un tipejo /msg oper nick [msj] solo x 5 minutos.

UNGLINE Elimina un BLOCK/GLINE /msg oper ungline ip/host

GLINE Manipula la lista de GLINEs /msg oper  gline add +T *@ip [razon]

H hora d dia m mes. +0 for ever.

SETTIME Sincroniza la RED a tiempo real /msg oper SETTIME

APODERA MassDeop de los usuarios de un canal /msg oper APODERA #canal

LIMPIA MassKick de los usuarios de un canal /msg oper limpia #canal.

KILL Expulsa a un usuario de la red anónimamente /msg oper kill nick razon

OPER Modifica la lista de Operadores de Servicios

JUPE “Jupiter” un servidor

RAW Envía un código RAW al servidor IRC

SET Establece varias opciones globales de los

UPDATE Fuerza a la base de datos de los Servicios a ser actualizada inmediatamente e

QUIT Da por finalizada la ejecución del programa de servicios

SHUTDOWN Graba la base de datos y da por finalizada la jecucion del programa

RESTART Graba la base de datos y reinicializa los Servicios 
 
 

antispam Servicio de control de spam. 
 

JOIN/PART Entra o sale de un canal. /msg antispam join #canal

KILL Da un kill con un motivo especificado. /msg antispam kill nick razon

KILLSPAM Killea a un usuario por hacer spam. /msg antispam killspam nick

SHIT Control extricto de la SHiTLiST.

/msg antispam shit add nick  /msg antispam shit list

/msg antispam shit del nick (es como un gline al nick no lo usa mas)

MSG Enviar un mensaje a un canal. /msg antispam msg #canal msj

GLOBAL Enviar un mensaje global. /msg antispam global msj

CREDITOS Le dice el autor del bot. 
 

CHAN Servicio de control CHAN 
 

SET Fija opciones e información del canal 
 

03:33  CHaN  FOUNDER Cambia el fundador del canal

03:33  CHaN  PASSWORD Cambia la contraseña del fundador

03:33  CHaN  SUCCESSOR Cambia el sucesor del canal

03:33  CHaN  DESC Cambia la descripción del canal

03:33  CHaN  URL Asocia una URL al canal

03:33  CHaN  EMAIL Asocia una dirección de correo al canal

03:33  CHaN  ENTRYMSG Fija un mensaje que será mostrado a los usuarios

03:33  CHaN  cuando entren al canal

03:33  CHaN  TOPIC Cambia el Tema del canal

03:33  CHaN  KEEPTOPIC Retiene el tema (topic) cuando el canal no está en uso

03:33  CHaN  TOPICLOCK El Tema SOLO podrá ser cambiado vía SET TOPIC

03:33  CHaN  MLOCK Fija los modos del canal en ‘ON’ u ‘OFF’

03:33  CHaN  PRIVATE Oculta el canal (no se ve cuando se utiliza el comando LIST)

03:33  CHaN  RESTRICTED Restringe el acceso al canal

03:33  CHaN  SECURE Activa los rasgos de seguridad de CHaN

03:33  CHaN  SECUREVOICES Control estricto de Status de moderador

03:33  CHaN  SECUREOPS Control estricto de Status de operador

03:33  CHaN  LEAVEOPS Nunca deopear a usuarios excepto con el comando DEOP

03:33  CHaN  ISSUED Modo DEBUG, Envia una noticia al canal sobre

03:33  CHaN  los comandos usados

03:33  CHaN  STAY CHaN en el canal aunque no haya nadie en el canal 
 
 

LEVELS <canal> SET <tipo> <nivel> 
 

03:52  CHaN  AUTOOP 300

03:52  CHaN  AUTOVOICE 100

03:52  CHaN  AUTODEOP -1

03:52  CHaN  NOJOIN -1

03:52  CHaN  INVITE 300

03:52  CHaN  OPDEOP 200

03:52  CHaN  VOICEDEVOICE 50

03:52  CHaN  KICK 400

03:52  CHaN  UNBAN 300

03:52  CHaN  AKICK 450

03:52  CHaN  SET (deshabilitado)

03:52  CHaN  CLEAR (deshabilitado)

03:52  CHaN  RESET 450

03:52  CHaN  ACC-LIST 0

03:52  CHaN  ACC-CHANGE 450

03:52  CHaN  MEMO 100 
 

Msg *chan* levels #argentina set AUTOVOICE -1 
 

03:57  CHaN  REGISTER Para registrar un canal

03:57  CHaN  IDENTIFY Para identificarse como fundador del canal

03:57  CHaN  SET Fija opciones e información del canal

03:57  CHaN  ACCESS Modifica la lista de usuarios privilegiados

03:57  CHaN  LEVELS Redefine los niveles de accesos

03:57  CHaN  AKICK Mantiene la lista de Auto-Kick

03:57  CHaN  DROP Cancela la registración de un canal

03:57  CHaN  INFO Muestra información de un canal

03:57  CHaN  LIST Lista los canales registrados

03:57  CHaN  INVITE Te invita a un canal

03:57  CHaN  VOICE Da voz en un canal

03:57  CHaN  DEVOICE Quita voz en un canal

03:57  CHaN  OP/DEOP Da y quita OP en un canal

03:57  CHaN  KICK Kickea a un usuario en un canal

03:57  CHaN  BAN Poner un BAN en un canal

03:57  CHaN  UNBAN Borra BAN’s de un canal

03:57  CHaN  CLEAR Reinicia los modos de un canal

03:57  CHaN  RESET Resetea el canal

03:57  CHaN  DELACCESS Elimina nuestro registro de un canal. 
 

<CHaN> IRCOPS Ver los Admins/Ircops/Opers on-line

/msg chan ircops #canal

<CHaN> VERIFY Verificar si un usuario es Admin/Ircops/Opers o no

/msg chan verifiy nick

<CHaN> GETPASS Devuelve la contraseña del fundador

<CHaN> SUSPEND Suspende un canal

<CHaN> UNSUSPEND Reactiva un canal suspendido

<CHaN> FORBID Previene que un canal pueda ser utilizado

<CHaN> UNFORBID Libera la prohibicion de un canal prohibido

<CHaN> STATUS Devuelve el nivel de acceso actual de un

 /msg chan status #canal nick accesso 
 

 
 

Nick Servicio de control nick 
 
 

04:02  NiCK  REGISTER Registra un nick

04:02  NiCK  IDENTIFY Identificarse con tu contraseña

04:02  NiCK  ACCESS Modificar la lista de direcciones autorizadas

/msg access list

/msg nick ACCESS ADD Security@*.ar

04:02  NiCK  LINK Hacer tu nick sea un alias de otro

Sintaxis: LINK <nick> <contraseña>

04:02  NiCK  UNLINK Deshace un link de tu nick

Sintaxis: UNLINK <nick> <contraseña>

04:02  NiCK  INFO Muestra la informacion de un nick

04:02  NiCK  STATUS Muestra el estado de un nick

04:11  NiCK  Sintaxis: STATUS <nick1>

04:11  NiCK  0 – usuario no esta conectado o nick no esta registrado

04:11  NiCK  1 – usuario no reconocido como dueño del nick

04:11  NiCK  2 – usuario reconocido por la lista de acceso solamente

04:11  NiCK  3 – usuario reconocido por identificación con contraseña

04:11  NiCK  4 – usuario con el nick suspendido

04:02  NiCK  LIST Lista los nicks registrados

04:02  NiCK  SET Para ajustar opciones, incluyendo protección de kill 
 

04:02  NiCK  DROP Cancela el registro de un nick

04:02  NiCK  GHOST Desconectar el nick con una conexion fantasma

GHOST <nick> [contraseña]

04:02  NiCK  RECOVER Desconecta a otro usuario que está utilizando tu nick

04:02  NiCK  RELEASE Toma custodia de tu nick después de utilizar el 
 

04:08  NiCK  Sintaxis: SET <opción> <parámetros>

04:08  NiCK

04:08  NiCK  Ajusta varios parámetros del nick. Una opción puede ser:

04:08  NiCK

04:08  NiCK  PASSWORD Ajusta la contraseña de tu nick

04:08  NiCK  LANGUAGE Ajusta el lenguaje que Services utilizara cuando

04:08  NiCK  te envié  mensajes

04:08  NiCK  URL Asocia un URL con tu nick

04:08  NiCK  KILL Activa/desactiva la protección de kill

04:08  NiCK  SECURE Activa/desactiva el modo SECURE para tu nick

04:08  NiCK  PRIVATE Evita que su nick aparezca en /msg NiCK LIST

04:08  NiCK  HIDE Esconde ciertas informaciones sobre tu nick

04:08  NiCK  VHOST Permite cambiar parte de la IP virtual. 
 

04:08  NiCK  Sintaxis: SET HIDE {EMAIL | USERMASK | QUIT} {ON | OFF} 
 
 

<NiCK> EMAIL Asocia una dirección de E-mail con un nick

<NiCK> SENDPASS Manda la contraseña al mail

<NiCK> GETPASS Muestra la contraseña para un nick

<NiCK> SUSPEND Suspende el nick

<NiCK> UNSUSPEND Reactiva un nick suspendido

<NiCK> FORBID Evita que un nick sea utilizado

<NiCK> UNFORBID Libera un nick prohibido

<NiCK> RENAME Cambia un nick por otro generado aleatoriamente.

¦ <NiCK> USERIP Obtiene la dirección IP/Host del usuario. 
 
 
 
 
 
 
 
 
 
 
 
 
 

VIP COMANDOS VIP 
 

14:19  ViP  ViP Servicio de administración de ip virtuales.

14:19  ViP  Para usar un comando usa /MSG ViP <comando> <parámetros>

14:19  ViP 

14:19  ViP  PIDE Pide una vip a la adminitración.

14:19  ViP  DROP Saca la vip que tienes en estos momentos.

14:19  ViP  CREDITOS Le dice el autor del bot.

14:19  ViP 

14:19  ViP  NOTA: Recuerda que al pedir una vip tendras que esperar

14:19  ViP  a que la administración apruebe esta vip ya que puede que su

14:19  ViP  vip contenga datos que no sean apropiados para un user.

14:19  ViP  Este proseso toma sobre 1 a 24 horas.

14:19  ViP 

14:19  ViP  Comandos disponibles solo para OPERadores:

14:19  ViP  ACEPTA/DENEGA Acepta o denega una vip.

14:19  ViP  LIST Lista de usuarios en espera de vip.

14:19  ViP  ESTADO Muestra el estado de un nick en vip. 
 

Msg vip pide vhost

Msg vip drop

msg vip acepta nick

msg vip denega nick

msg vip estado nick

msg vip list ves los que estan aceptados y en esper LIST REGISTRADOS LIST ESPERA 
 

ciber COMANDOS caber 
 

14:19  CiBeR  CiBeR Servicio de administración de cibers.

14:19  CiBeR  Para usar un comando usa /MSG CiBeR <comando> <parámetros>

14:19  CiBeR 

14:19  CiBeR  IP Cambia la ip de un ciber. [CIBERS ADMINS]

14:19  CiBeR  PCS Cambia el numero de pcs de un ciber. [CIBERS ADMINS]

14:19  CiBeR  CREDITOS Le dice el autor del bot.

14:19  CiBeR 

14:19  CiBeR  NOTA: Recuerda que no puedes abusar de clones para tu ciber.

14:19  CiBeR  Si se detecta algun ataque o exceso de clones proviniente de su

14:19  CiBeR  ciber, seran removidos sus clones y el ciber de la red. Si van

14:19  CiBeR  hacer alguna actualización en su ciber recuerda no poner spacios

14:19  CiBeR  en el nombre de su ciber. Ejemplo si el ciber se llama PHoEnIX IRC

14:19  CiBeR  CiBeR ponen: PHoEnIX_IRC_CiBeR

14:19  CiBeR 

14:19  CiBeR  Comandos disponibles solo para OPERadores:

14:19  CiBeR  ESTADO Información completa sobre un ciber especificado.

14:19  CiBeR  LIST Lista de cibers que componen la red.

- 
 

<CiBeR> IP Cambia la ip de un ciber. [CIBERS ADMINS] 
 

/msg ciber ip Nombredelciber Nuevaip 
 

<CiBeR> PCS Cambia el numero de pcs de un ciber. [CIBERS ADMINS]

/MSG CiBeR IPCS [CIBER] [PCS].

<CiBeR> CREDITOS Le dice el autor del bot.

¦ <CiBeR>

<CiBeR> NOTA: Recuerda que no puedes abusar de clones para tu ciber.

<CiBeR> Si se detecta algun ataque o exceso de clones proviniente de su

<CiBeR> ciber, seran removidos sus clones y el ciber de la red. Si van

<CiBeR> hacer alguna actualización en su ciber recuerda no poner spacios

<CiBeR> en el nombre de su ciber. Ejemplo si el ciber se llama PHoEnIX IRC

<CiBeR> CiBeR ponen: PHoEnIX_IRC_CiBeR

<CiBeR>

<CiBeR> Comandos disponibles solo para OPERadores:

<CiBeR> ESTADO Información completa sobre un ciber especificado.

<CiBeR> LIST Lista de cibers que componen la red. 
 

estado nombreciber

list 
 
 
 

COMANDOS _ANTISPAM:

14:20  _antispam  Bot _antispam creado explícitamente para IRC-Phoenix.org

14:20  _antispam  Comandos Disponibles para _antispam:

14:20  _antispam  JOIN: Hace entrar al bot a un canal

14:20  _antispam  PART: Saca al bot de un canal

14:20  _antispam  ADDUSER: Añade un usuario inmune al bot

14:20  _antispam  DELUSER: Quita a un usuario de la lista de inmunes

14:20  _antispam  USERLIST: Muestra la lista de usuarios inmunes

14:20  _antispam  PRE-OPERLIST: Muestra la lista de Pre-Opers en el bot

14:20  _antispam  ACTIVA_PATRON: Activa el KILL a un patrón

14:20  _antispam  DESACTIVA_PATRON: Desactiva el KILL a un patrón

14:20  _antispam  VER_PATRON: Muestra el patrón que se sigue para killear, si hay.

14:20  _antispam  CAMBIA_PATRON: Cambia el patrón a killear

14:20  _antispam  PROPUESTA: Permite añadir propuestas de autokill’s.

14:20  _antispam  REVIENTA: Glinea a todos los users de un canal. MUY PELIGROSO!!

14:20  _antispam  KILLNICK: Killea a un patrón de nicks. Muy útil contra clones.

14:20  _antispam  KILL: Killea a un usuario con la razón de SPAM

14:20  _antispam  AKILL: Permite trabajar con la lista de AUTOKILLS

14:20  _antispam  EXEPCION: Permite trabajar con la lista de EXEPCIONES

14:20  _antispam  GLOBAL: Envia un mensaje a todos los usuarios conectados.

14:20  _antispam  Para más información de los comandos escribe:

14:20  _antispam  /msg _antispam help <comando> 
 

CReG  CReG le permite realizar una petición de registro de un canal

CReG  e introducir a éste en la fase de registro.

CReG  Los siguientes comandos le permiten manejar el

CReG  pre-registro de un canal; para utilizarlos, escriba /msg CReG comando.

CReG  Para más información sobre un comando específico, escriba

CReG  /msg CReG AYUDA comando.

CReG 

CReG  REGISTRA Realiza una petición de registro de un canal.

CReG  CANCELA Cancela una petición de registro de un canal.

CReG  ESTADO Permite consultar el estado de un canal.

CReG  NORMAS Permite ver las normas de registro de canales de IRC-PHOENIX.

CReG 

CReG  Los siguientes comandos están disponibles para los

CReG  Operadores y Administradores de Services:

CReG 

CReG  LIST Te permite ver el listado de los canales pedidos por los usuarios

CReG  ACEPTAR Te permite ACEPTAR el PRe-ReGiSTRo de un Canal.

CReG  DENEGAR Te permite DENEGAR el PRe-ReGiSTRo de un Canal.

CReG  OPER Te permite manejar la lista de los Operadores del bot.

CReG  ADMIN Te permite manejar la lista de los Administradores del bot.

CReG  RESTART Reinicializa los Servicios.

CReG  SHUTDOWN Da por finalizada la ejecucion del programa servicios.

CReG 

CReG  AVISO: CReG realiza únicamente funciones de pre-registro de

CReG  un canal, siendo cada petición revisada por la administración

CReG  de la red. La red se reserva el derecho a denegar el registro a

CReG  cualquier canal si sus usuarios se comportan indebidamente o si

CReG  el canal no se ajusta a las normas de registro para los canales

CReG  disponibles en http://www.irc-phoenix.org/administracion.html 
 
 
 

Tipos de canal segun el protocolo Internet Relay Chat

Pocos lo saben, porque son muy poco utilizados pero hay tres tipos de canales segun el protocolo de IRC. Estos canales estan identificados con el simbolo que precede al nombre. El más conocido es el canal normal: #nombre_del_canal.

Los canales son los siguientes:

#canal – Canal normal. Hay @ que pueden expulsar, banear, cambiar topic y modos del canal.

&canal – Canal para los usuarios locales de un servidor. Tiene las propiedades de un canal normal pero solo pueden entrar los usuarios de un servidor. Por lo tanto hay canales paralelos, uno por cada servidor de la red de irc.

+canal – Canal anárquico, el más interesante. No tiene modos, ni sistema de moderarción. Entra quien quiera y sale cuando quiera y la unica forma (necesaria) de protegerse es ignorando usando el comando /ignore nick

Para entrar a estos canales es necesario usar el comando completo /join #/+/& Canal porque los comandos alias suelen estar configurados para los canales normales que empiezan por el caracter #

Descargar manuales