Discusion para las distintas tecnicas antispam
Miguel Oyarzo <[EMAIL PROTECTED]> wrote: > At 22:33 26-05-2006, Horst von Brand wrote: > >Miguel Oyarzo <[EMAIL PROTECTED]> wrote: > > > >[ ... ] > >> 2) Listas RBL: mediante la consulta a una base de datos publica permite > >> identificar servdores SMTP acusados de SPAM o con algun tipo de problema > >> de configuracion protencialmente peligrosa. > > > >> Pricipal problema: (i) Al usar RBL podemos estar bloqueando, sin querer, > >> miles de servidores SMTP de empresas e ISPs fidedignos, si las direciones > >> MX de estos ultimos caen (por inexperiencia probable) en estas listas > >> publicas. Se dice que es un problema del otro server, pero es uno el que > >> activa ese filtro. > >Si no son capaces de administrar sus MTAs como la gente, no quiero hablar > >con ellos. > pienso q esa es *mala_politica* o es muy radical :) > En algunos ambitos laborales se pierde la pega por pensar asi. No el mio (y dada esta lista, supongo que el tuyo tampoco...). > hay que tratar de comprender a los que les cuesta el lenguaje o que no > saben /aun/ sus reglas. Y seguir teniendo que sufrir sus tonteras por siempre? Hay limites... si despues de decirles con peras y manzanas 4 o 5 veces como comportarse no atinan... > Supongo que la compatibilidad una de las razones de porque los sistemas > operativos arrastran tanto codigo viejo, El mio, muy poco... y /activamente/ se esta eliminando lo que es "codigo viejo" todo el tiempo. > o los equipos de comunicaciones > pueden conectarse a mas de una norma. Porque conforman a la /norma/, no porque todo el mundo y su abuelita les permiten hacer las cosas de cualquier manera. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 From [EMAIL PROTECTED] Thu Jun 1 11:05:35 2006 From: [EMAIL PROTECTED] (=?ISO-8859-1?Q?Germ=E1n_Po=F3_Caama=F1o?=) Date: Thu Jun 1 11:05:35 2006 Subject: dominios IDN y sendmail In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> On Thu, 2006-06-01 at 08:57 -0400, Miguel Oyarzo wrote: > > Estimados, > > Configure un dominio IDN y resuelve sin problemas, pero > sendmail no me recibe mensajes cuya cabecera tenga tildes. > Alguna configuracion especial o parche conocido? > Es recomendable forzar el sistema? > > Se que segun RFC-822 no se deberia, pero que hay al respecto? El RFC 822 está obsoleto. Lo reemplaza el 2822. -- Germán Poó-Caamaño http://www.ubiobio.cl/~gpoo/ Concepción - Chile
Discusion para las distintas tecnicas antispam
At 22:33 26-05-2006, Horst von Brand wrote: >Miguel Oyarzo <[EMAIL PROTECTED]> wrote: > >[ ... ] >> 2) Listas RBL: mediante la consulta a una base de datos publica permite >> identificar servdores SMTP acusados de SPAM o con algun tipo de problema >> de configuracion protencialmente peligrosa. > >> Pricipal problema: (i) Al usar RBL podemos estar bloqueando, sin querer, >> miles de servidores SMTP de empresas e ISPs fidedignos, si las direciones >> MX de estos ultimos caen (por inexperiencia probable) en estas listas >> publicas. Se dice que es un problema del otro server, pero es uno el que >> activa ese filtro. > >Si no son capaces de administrar sus MTAs como la gente, no quiero hablar >con ellos. pienso q esa es *mala_politica* o es muy radical :) En algunos ambitos laborales se pierde la pega por pensar asi. hay que tratar de comprender a los que les cuesta el lenguaje o que no saben /aun/ sus reglas. Supongo que la compatibilidad una de las razones de porque los sistemas operativos arrastran tanto codigo viejo, o los equipos de comunicaciones pueden conectarse a mas de una norma. Saludos, Miguel Oyarzo Austro Internet Punta Arenas
Discusion para las distintas tecnicas antispam
Miguel Oyarzo <[EMAIL PROTECTED]> wrote: > Abro la discusion de los distintos metodos antispam existentes a la fecha > y sus problemas asociados (para los que le interese los sistemas de > correos > > Descip% y problemas asociados: > > 1) Spamassassin: Filtro que evalua el contenido de un mensaje de correo y > segun la puntuacion obtenida lo marca como spam o no. Hay varias herramientas basadas en el mismo principio. > Principales defectos: (i) El mecanismo de evaluacion es muy conocido y > los spammers se las arreglan para enviar correos cortos, poco > formateados, con palabras codificadas o solo con URL que llaman objetos > HTML, entre otros (ii) A veces se marcan correos fidedignos lo que lo > vuelve un sistema poco confiable. Es extremadamente confiable con entrenamiento personalizado... pero eso es muy caro (un par de MiB para cada usuario, a procesar para cada (!) mensaje), ademas que solia colgarse feamente (100% CPU en loop, maquina solo recuperable via Big Red Switch). > 2) Listas RBL: mediante la consulta a una base de datos publica permite > identificar servdores SMTP acusados de SPAM o con algun tipo de problema > de configuracion protencialmente peligrosa. > Pricipal problema: (i) Al usar RBL podemos estar bloqueando, sin querer, > miles de servidores SMTP de empresas e ISPs fidedignos, si las direciones > MX de estos ultimos caen (por inexperiencia probable) en estas listas > publicas. Se dice que es un problema del otro server, pero es uno el que > activa ese filtro. Si no son capaces de administrar sus MTAs como la gente, no quiero hablar con ellos. El problema es que la cobertura es parcial (si tanto), y hay una latencia notoria en inscribir a los spammers. > (i) Si eres proveedor SMTP para tus clientes (con smtp_auth y todo) y > estos usan conexiones ADSL, o dial-up en general, es MUY probable que la > mitad de ellos siempre esten llamando por no poder pasar mensajes de > correo (los IPs dinamicos de los ISPs tradicionales estan siempre en > listas negras por diversas razones). Situancion complicada de explicar > algunas veces. En VTR solian simplemente cortar SMTP hacia afuera... > 3) Grey-List: Sistema que retrasa en X minutos la entrada de un mensaje > de correo a nuestro servidor MX. Se supone que un servidor remoto SMTP > no estandar o adulterado no intentará reenviarnos el mismo mensaje si > este fue retrasado una vez (en teoria). Algunos spammers han logrado saltarse esto (no se si usan MTAs propios, o mas fuertemente se aprovechan de relays abiertos). > Principal problema: Aun que nuestro GREY-LIST le diga al SMTP server > remoto que envie el mensaje unos cuantos minutos mas, el servidor remoto > lo encolara No conozco ningun MTA que haga otra cosa... y hay que recordar que esto es para el /primer/ mensaje de la serie que viene de alla. > y lo despachara segun su configuracion local (y no la > sugerencia de GREY-LIST). Nadie nunca dijo que email es tiempo real duro... > Servidores de grandes ISP u otras empresas > pueden tener colas de varias horas. Eso significa un MTA exageradamente sobrecargado alla. Not my problem si no tienen idea como configurar un FallbackMX o similar... > Produce un problema grave de > oportunidad para los 1eros mensajes que provengan desde allá. (existe una > lista blanca al interior de GREY-LIST, pero es manual) Y? > De las 3 anteriores le otorgo mayor eficiencia a Grey-List, a pesar de > los retrasos dificiles de explicar a los usuarios. He comprobado que > filtra mucho mas que los anteriores y es muy confiable. > Me falta alguna otra tecnica que este al nivel de las anteriores o que > las haya superado? Estan las "brillantes" ideas de SPF y afines: Inscribes en DNS los MTAs legitimos para tu dominio, un MTA remoto que sepa de esto no aceptara correo "desde tu dominio" que viene de otras maquinas. Falla miserablemente porque /yo/ tengo que mantener rigurosamente al dia la configuracion para que (algunos pocos) /otros/ no reciban spam falsificado como de mi direccion... y basta enviar spam "desde" alguno de los millones de dominios que no usan esto para saltarse esto. Ademas, esta patentado por MSFT (o asi). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From [EMAIL PROTECTED] Fri May 26 22:38:29 2006 From: [EMAIL PROTECTED] (Horst von Brand) Date: Fri May 26 22:38:40 2006 Subject: Discusion para las distintas tecnicas antispam In-Reply-To: Your message of "Thu, 25 May 2006 00:19:22 -0400." <[EMAIL PROTECTED]> Message-ID: <[EM
Discusion para las distintas tecnicas antispam
El 24/05/06, Miguel Oyarzo<[EMAIL PROTECTED]> escribió: [ varios comentarios...] > Me falta alguna otra tecnica que este al nivel de las anteriores o que las > haya superado? > > Cualquier comentario o aporte bienvenido mmm... la utilizacion de las listas-blancas, o sea, el servidor de correo solamente recibe los mensajes de los dominios a los cuales uno realmente desea recibir. no es tan absurdo como parece... estoy justo en estes dias configurando un servidor asi para una empesa, hasta el momento existen ~ 120 dominios/direcciones de correo en la lista-blanca y ahora estamos trabajando para generar un sistema que automaticamente incluya el dominio/direccion de correo en las lista-blancas basado en los destinatarios de los correos enviados por el usuario de la empresa. mmm.. por cierto, es una empresa mediana de ~ unos 50 usuarios. y el otro que olvidaste mencionar es la utilizacion de SPF, no es exactamente una tecnica anti-spam... pero ayuda un poco en la eliminacion del correo basura...el malo de este metodo es que no todos configuran sus DNS para la utilizacion del SPF. esto era. salu2. -- -- Victor Hugo dos Santos Linux Counter #224399
Discusion para las distintas tecnicas antispam
Estimados, Abro la discusion de los distintos metodos antispam existentes a la fecha y sus problemas asociados (para los que le interese los sistemas de correos Descip% y problemas asociados: 1) Spamassassin: Filtro que evalua el contenido de un mensaje de correo y segun la puntuacion obtenida lo marca como spam o no. Principales defectos: (i) El mecanismo de evaluacion es muy conocido y los spammers se las arreglan para enviar correos cortos, poco formateados, con palabras codificadas o solo con URL que llaman objetos HTML, entre otros (ii) A veces se marcan correos fidedignos lo que lo vuelve un sistema poco confiable. 2) Listas RBL: mediante la consulta a una base de datos publica permite identificar servdores SMTP acusados de SPAM o con algun tipo de problema de configuracion protencialmente peligrosa. Pricipal problema: (i) Al usar RBL podemos estar bloqueando, sin querer, miles de servidores SMTP de empresas e ISPs fidedignos, si las direciones MX de estos ultimos caen (por inexperiencia probable) en estas listas publicas. Se dice que es un problema del otro server, pero es uno el que activa ese filtro. (i) Si eres proveedor SMTP para tus clientes (con smtp_auth y todo) y estos usan conexiones ADSL, o dial-up en general, es MUY probable que la mitad de ellos siempre esten llamando por no poder pasar mensajes de correo (los IPs dinamicos de los ISPs tradicionales estan siempre en listas negras por diversas razones). Situancion complicada de explicar algunas veces. 3) Grey-List: Sistema que retrasa en X minutos la entrada de un mensaje de correo a nuestro servidor MX. Se supone que un servidor remoto SMTP no estandar o adulterado no intentará reenviarnos el mismo mensaje si este fue retrasado una vez (en teoria). Principal problema: Aun que nuestro GREY-LIST le diga al SMTP server remoto que envie el mensaje unos cuantos minutos mas, el servidor remoto lo encolara y lo despachara segun su configuracion local (y no la sugerencia de GREY-LIST). Servidores de grandes ISP u otras empresas pueden tener colas de varias horas. Produce un problema grave de oportunidad para los 1eros mensajes que provengan desde allá. (existe una lista blanca al interior de GREY-LIST, pero es manual) De las 3 anteriores le otorgo mayor eficiencia a Grey-List, a pesar de los retrasos dificiles de explicar a los usuarios. He comprobado que filtra mucho mas que los anteriores y es muy confiable. Me falta alguna otra tecnica que este al nivel de las anteriores o que las haya superado? Cualquier comentario o aporte bienvenido Miguel Oyarzo O., Austro Internet S.A. Punta Arenas
