-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hola Santiago :)) On Monday 28 July 2003 20:26, Santiago Vila wrote: > Victor Calzado Mayo escribi�: > > Aqu� surge el tema de siempre, �qui�n debe ser el censor? �debe el > > usuario medio ser consultado? �tengo derecho como administrador de un > > servidor de correo a decidir eso?... > > Como administrador de un sistema por cuenta ajena tienes la obligaci�n > de respetar el contrato que tengas con tus clientes. En el fondo esa > es toda la obligaci�n que tienes. >
Lo siento pero tengo que coincidir con Cesar, tengo la obligaci�n de dotar a mis usuarios de todo lo que necesiten para poder discriminar el SPAM con facilidad y si ellos lo solicitan evitar que lo reciban, pero lo siento como adminstrador de un sistema de correo me debo a mis usuarios. > Como administrador de tu propio sistema, t� fijas las reglas. Como suelen > decir en news.admin.net-abuse.email continuamente, "my server, my rules". > Claro y si me en mi casa me usan para enviar spam me forro a ostias. :)) > > Sin entrar a valorar pol�ticas de empresa, que son de lo mas variopinto y > > siempre salpicaran nos encontramos, desde mi punto de vista, ante un tema > > complicado, la capacidad de tomar decisiones t�cnicas que consideramos > > �ptimas (o sub�ptimas o como quieras definir algo que falla pero falla > > poco) que afectan a nuestros usuarios y que pueden suponerles molestias, > > desde mi punto de vista no se trata de convivir con el spam pero tampoco > > se trata de eliminar todo lo que un filtro en un servidor ( sea de la > > naturaleza que sea ) considere como malicioso. > > El correo rechazado a trav�s del uso de una lista de correo no se "elimina" > (que ser�a el equivalente a enviarlo a /dev/null). Se rechaza en el momento > de la transacci�n SMTP y el remitente es notificado, que es algo muy > distinto. > Cuando eres un usuario medio el mensaje a tus ojos suele resultar igual de cr�ptico. Y cuando se trata de la imagen de tu peque�a empresa pagar por otros es simplemente intolerable. > > > El spam es, simple y llanamente, un robo de ancho de banda, tiempo de > > > CPU, almacenamiento de disco y tiempo humano. Si dejamos que los > > > espameadores nos roben todo eso, entonces habr�n ganado ellos, no > > > nosotros. > > > > Sin duda, pero cuando tu consigues pararlo el da�o ya est� hecho, es como > > parar un ataque de negaci�n de servicio por agotamiento de ancho de banda > > en el gateway de una red, alentador pero totalmente in�til a efectos > > pr�cticos. > > No, *no* es como parar un ataque de denegaci�n de servicio. El protocolo > SMTP junto con el uso de una lista de bloqueo hace que si un mensaje > se rechaza por su procedencia, el mensaje en s� ni siquiera se > transmite, por lo tanto, s�, hay un ahorro de recursos. > Correcto, pero aunque suene a perogrullada el SPAM siempre llega en �ltima instancia de una fuente fiables, los spammers viven de los errores de los dem�s es cierto, pero nadie deber�a pagar por un error puntual con un castigo ejemplar, en especial cuando somos juez y parte... > > A veces resulta m�s f�cil conseguir que Aznar diga algo inteligente > > que salir de una de esas listas, [...] > > En eso estamos de acuerdo, pero no estoy defendiendo a *todas* las > listas de bloqueo. Estoy diciendo que es incorrecto rechazarlas > *todas* solamente porque *algunas* no funcionen bien. > correcto, y rectificado :)) > > que se han acabado saliendo de madre, sin ir m�s lejos algunas > > consideran que los dominios .es deben ser tratados con cautela > > simplemente porque la gente de red.es no ha considerado oportuno > > instalar un servidor de whois, si en cierta manera es algo > > reclamable pero... �lo es por el usuario medio? > > En la medida en que puedas "votar con los pies" contratando el servicio > con otro proovedor que no tenga ese problema, s�, es "reclamable". > > Y si (caso extremo) te rechazan los mensajes por ser de un determinado > pa�s o alguna condici�n similar, entonces a quien tienes que reclamar > es a los pol�ticos para que hagan leyes antispam que no permitan que > tu pa�s sea un para�so de impunidad para los espameadores. Todo es > "reclamable" en cierto sentido. > ya para bien o para mal :)) > > > Creo de verdad que la responsabilidad en la lucha contra el spam no > > > deber�a recaer exclusivamente sobre el que recibe correo. > > > > Hummmmmmmmmmmmm, y �qu� hay del derecho a recibir exclusivamente el > > correo que yo quiera recibir? o �alguien en su enorme sabidur�a > > decidir� de nuevo por mi entre lo que es SPAM y lo que no? no se, yo > > sigo sin ver claro que un CENSOR tenga ese derecho. > > Al contrato me remito. Si t� contratas con tu proovedor que quieres > recibir todo el spam que te llegue y ellos ponen una lista negra que > rechaza correos de proxys abiertos, por ejemplo, puedes reclamarles > por incumplimiento de contrato. > > Eso s�, considero que lo m�nimo que deber�a hacer un proovedor es decirle > a su cliente qu� listas de bloqueo est� usando para el correo entrante. > Entre otras cosas, pero la idea de marcar los mensajes seg�n su "spamicidad" me parece excelente. > > [...] > > Es evidente que un open relay debe ser castigado [...] > > Bravo, al menos estamos de acuerdo en algo :-) Un matiz: Cuando un > sitio decide rechazar correo de relays abiertos no es para "castigar" > a nadie, es simplemente "autodefensa" para evitar sobre todo el da�o > propio de recibir basura de relays abiertos. > > De todas formas hoy en d�a los espameadores prefieren los proxys > abiertos, son m�s dif�ciles de rastrear (es decir, sabes de qu� proxy > abierto procede un mensaje, pero no sabes qui�n lo controla). > Sea cual sea el problema no es que alguien que haga algo malo provoque rechazo, sus vecinos de red en muchas ocasiones son castigados por igual... > > [...] > > Sinceramente si lo que pretendemos es ahorrar ancho de banda y > > garantizar que llega poco spam > > El spam es un problema muy complejo para el cual no existe "LA" > soluci�n. Lo que existen son muchas cosas distintas que se pueden > hacer, a menudo combinadas. No tiene mucho sentido decir "esto no > funcionar�, hagamos esto otro", a menos que uno est� dispuesto a > convencer a todo el mundo para que haga eso otro. > Si es cierto, pero en el fondo cuando me obligas a respetar un sin fin de listas, algunas absurdas, bajo pena de que si no lo hago puede que no consideres amigable mi correo me estas obligando a jugar al juego que tu quieres.. > > rescatemos el VRFY de las mazmorras, > > apliquemos firma digital a los mensajes y generemos sistemas de > > confianza que premien o castiguen en base a criterios comunitarios y > > s�lo aplicables a las personas de esa comunidad, es decir pepito > > griyo rechaza un correo mio que mar�a griyo puede haber decidido > > aceptar porque considera ( y espero que nadie interprete mal esto ) > > que pepito si deber�a leer esos anuncios para alargase el pene y que > > el llama SPAM... ;-)))) > > Lo que dices ya se est� haciendo en cierto sentido. Mucha gente > critica las listas de bloqueo porque ven en ellas una "autoridad > centralizada" para decidir qu� correos se aceptan y qu� correos no, > pero es que hay montones de listas distintas y los administradores > tienen una libertad enorme para elegir entre ellas, de forma que si > una lista es efectiva, mucha gente la usar�, y si otra lista genera > demasiados falsos positivos, poca gente la usar�. En la medida en que > cada administrador usa un conjunto distinto de listas (a veces creando > listas propias), el problema del spam *ya* se est� combatiendo de una > forma distribuida y no centralizada. Si, es cierto, pero si te has fijado mi "pajilla mental" supone que el usuario puede discriminar por si mismo Vamos que en el fondo no tiene sentido discutir cuando es evidente que todos opinamos lo mismo en el fondo, pero bueno, el respeto al usuario individual, el gasto en recursos, todo tiene un precio, cada uno valora que es m�s importante, pero en una "race condition" como la generada entre los que lo env�an y los que lo reciben considero que las listas de IPs s�lo eliminan el SPAM "amateur" mientras que los verdaderos profesionales se las siguen apa�ando, los filtros se han convertido en una barrera a sortear ( por desgracia parece que est�n en ello, html con referencias , jpgs con el contenido del spam... ) que puede resultar efectiva porque en el juego del gato y el raton jugado de t� a t� el gato y el rat�n se hacen m�s fuertes al mismo tiempo (digamos que a ese juego se juega en tiempo real) y las listas desde mi punto de vista suponen un juego por turnos en el que unos y otros intentan anticiparse al rival y responden despu�s de acciones concretas, las acciones tomadas a priori, sobretodo cuando son p�blicas, resultan en estos juegos de estrategia poco efectivas y suelen afectar m�s al inocente que al spammer, que nos guste o no no debemos olvidar, que es un aut�ntico profesional con amplios conocimientos de protocolos, sistemas y listas de filtrado, me explico gr�ficamente, si tu y yo jugamos una partida de risk y t� est�s obligado a anunciar tus movimientos con 4 turnos de antelaci�n y a cordinarte con otros 10 jugadores y yo juego por mi cuenta, ataco y retrocedo deprisa.... �no crees que ser�a un dificil rival a pesar de poder estar en desventaja? :/ No al SPAM eso est� claro, pero dotando al usuario de los m�todos para que el mismo lo evite, ya sea marcando los mensajes y dici�ndole como distinguirlos, poniendo a su disposici�n filtros bayesianos y documentaci�n para configurarlos en su sistema, pero que sea el el que se conciencie, si el SPAM deja de ser "leido" deja de ser rentable, mientras un 2% , un 1% lo que sea suponga un simple click seguir� siendo un problema, no hace falta pensar en el boom de los banners y su posterior desaparici�n simplemente porque todo el mundo los ignoraba. Que conste que no pretendo insinuar nada pero la educaci�n suele ser m�s efectiva que el castigo, m�s a�n cuando el castigo suponga que algunos inocentes se consideren justas v�ctimas de una guerra en busqueda de un fin mayor y m�s noble. Un saludo Victor - -- Lo que la naturaleza no da.... O'reilly & Associates no lo prestan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/JqLrEzqHF8R72ekRAljHAJ9zfuKkiz0Tbe6UrQEc60yaLStTOgCgnVw1 eh6tX42GWlL1RjrxoVPnE1I= =Bnft -----END PGP SIGNATURE-----
