Chat-Latino.es

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-hispano.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-Hispano.

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 Hispano, 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-hispano.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-hispano.org para el registro de un canal comercial o a
info@irc-hispano.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-Hispano 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-Hispano 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.
Una lista completa está disponible en

http://www.irc-hispano.org/admin/canales.html#suspension.

El suspend no será perpetuo a no ser que infrinja frontalmente las normas
De Irc-Hispano (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-hispano.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 hispano, 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.