[opensuse-es] opinion para encontrar filtro de correo adecuado
Hola a todos, despues de probar con el body_check y con header_check, descubri que no es una buena solucion para lo que quiero conseguir, es por ello que les pido su opinion al respecto, quiza ustedes tengan una mejor idea, asi que hago la pregunta de manera general: 1. el objetivo es lograr que solo los correos que provienen de internet, sean analizados y los correos que se envien entre los usuarios locales, puedan circular libremente. 2. el analisis para los correos que vienen de internet, debe permitir hacer lo siguiente: -debe redireccionar a otra cuenta todos los correos que en el cuerpo tengan palabras como "palabra1", "palabra2" con la finalidad de ser analizados y reenviados a sus destinatarios. -tener una lista de dominios externos, que no deben ser analizados por el filtro y que circulen libremente sin percanses ni modificaciones. Tengo al postfix trabajando en conjunto con Amavis +spamassassin + Cyrus +... Estuve viendo la posibilidad de hacerlo con procmail com me comento Josep, pero no tengo la menor idea de como separar los entrantes de los salientes, pues si lo miro del punto de vista del encabezado de los correos que se generan dentro de mi LAN y que todos tienen en comun por ejemplo es Received: from [192.168.4.32] (unknown [10.10.10.10]) by mail.midominio.com.pe (Postfix) with ESMTP id 980EA20D0E3; Wed, 4 Apr 2007 22:40:42 -0500 (PET) y lo que tienen en comun es (unknown [10.10.10.10]) pues como les comente en hilos anteriores, pueden tomar la cuenta de uno de mis usuarios usando servicios de "enviale este articulo a un amigo" que hay en muchas paginas web. Espero sus comentarios. Saludos JCarlos --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 7/04/07, Juan Carlos Bravo Celis escribió:
despues de probar con el body_check y con header_check, descubri que no es una buena solucion para lo que quiero conseguir, es por ello que les pido su opinion al respecto, quiza ustedes tengan una mejor idea, asi que hago la pregunta de manera general:
¿Qué es lo que quieres conseguir, cuál es el objetivo final? A veces es más sencillo obtener la solución de una forma global que ir resolviendo los problemas uno a uno.
1. el objetivo es lograr que solo los correos que provienen de internet, sean analizados y los correos que se envien entre los usuarios locales, puedan circular libremente.
Postfix permite hacer esa distinción (inspección del contenido de los mensajes, cabeceras...), además de explicar cómo hacerlo. Para ello utiliza "header_checks / body_checks": http://www.postfix.org/BUILTIN_FILTER_README.html#remote_only Con ésto se consigue que sólo los mensajes que vienen de fuera sean analizados e inspeccionados. Nota: al no analizar los correos internos no es posible evitar el mal uso del servidor de correo entre los propios usuarios.
2. el analisis para los correos que vienen de internet, debe permitir hacer lo siguiente:
-debe redireccionar a otra cuenta todos los correos que en el cuerpo tengan palabras como "palabra1", "palabra2" con la finalidad de ser analizados y reenviados a sus destinatarios.
Con "body_checks" es posible hacerlo. Se analiza el contenido del correo y se ejecuta una redirección a otra cuenta en el caso que se estime oportuno: http://www.postfix.org/header_checks.5.html Nota 1: esto implica que se lea el contenido de los correos de los usuarios lo cual no siempre es deseable o no siempre está permitido. Nota 2: la inspección del contenido que hace Postfix internamente no permite excepciones ni listas blancas de usuarios a los que no les afecte, es decir, se inspeccionan todos los correos sin excepciones.
-tener una lista de dominios externos, que no deben ser analizados por el filtro y que circulen libremente sin percanses ni modificaciones.
Aquí está el problema. Si se analizan los servicios utilizados (postfix, amavisd-new, spamassassin, clamav y cyrus): - Cyrus no entra en juego porque sólo te permite realizar acciones de filtrado y clasificación en el servidor (mediante sieve) una vez que el mensaje ya ha llegado a su destinatario y eso no es lo que quieres. - SA y amavisd analizan todo, local y remoto, luego tampoco podría servir. - A Clamav sólo le interesan los virus. Queda Postfix, que sí puede distinguir entre local y remoto pero que en cuestiones de análisis de contenido del mensaje permite dos opciones: 1) Usar la inspección interna (body_checks) que permite actuar sólo ante correos remotos pero que afecta a todos los usuarios / dominios sin distinciones 2) Crear un filtro personalizado que: - Realice un análisis del cuerpo de los mensajes para que busque los términos indicados (palabra 1, palabra 2) y ejecute la acción deseada (redireccionar) sólo en correos remotos. - Discrimine entre unos usuarios y otros (¿dominios distintos o usuarios distintos?) para que a unos se les aplique el análisis del cuerpo del mensaje y a otros no. - Vuelva a inyectar el correo a Postfix para que lo pase a amavisd-new. http://www.postfix.org/FILTER_README.html Otra opción podrían pasar por la gestión de la segunda instancia de Postfix lo cual permite un mayor control en el uso de ambas (por ejemplo, utilizar filtros o reglas distintas en cada una de ellas según dominios o según su uso): http://advosys.ca/papers/postfix-instance.html P.S. Cuando se tiene problemas con un servidor en concreto (dominio, dirección o rango ip, remitente) lo más efectivo es bloquearlo directamente (siempre que sea posible) para que no pueda conectar con el servidor o servicio que se está viendo afectado. Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 07/04/07, Camaleón
El 7/04/07, Juan Carlos Bravo Celis escribió:
despues de probar con el body_check y con header_check, descubri que no es una buena solucion para lo que quiero conseguir, es por ello que les pido su opinion al respecto, quiza ustedes tengan una mejor idea, asi que hago la pregunta de manera general:
¿Qué es lo que quieres conseguir, cuál es el objetivo final? A veces es más sencillo obtener la solución de una forma global que ir resolviendo los problemas uno a uno.
1. el objetivo es lograr que solo los correos que provienen de internet, sean analizados y los correos que se envien entre los usuarios locales, puedan circular libremente.
Postfix permite hacer esa distinción (inspección del contenido de los mensajes, cabeceras...), además de explicar cómo hacerlo. Para ello utiliza "header_checks / body_checks":
http://www.postfix.org/BUILTIN_FILTER_README.html#remote_only
Gracias Camaleon, esto es lo que andaba buscando, me has hecho el hombre mas feliz, te daria un beso si estuvieras cerca jejeje (cerca=Lima-Peru) esto me va a dejar dormir este fin de semana, ya el lunes que regrese al trabajo podre mejorarlo, pues ya logre hacer que los correos internos no pasen por el filtro de body_check ni de header_check. el unico problema ahora es que los correos entrantes, que si son analizados por estos filtros, no son analizados por amavis, ni spamassassin, pero si los internos...este tema lo revisare el lunes, que este con la mente relajada. Saludos y gracias JCarlos --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 7/04/07, Juan Carlos Bravo Celis escribió:
esto me va a dejar dormir este fin de semana, ya el lunes que regrese al trabajo podre mejorarlo, pues ya logre hacer que los correos internos no pasen por el filtro de body_check ni de header_check.
Los filtros de términos o palabras causan más problemas que los que se intentan solucionar, es una "solución descafeinada". Si lo que quieres es evitar esos mensajes que están recibiendo tus usuarios a través de un formulario de un servidor web, ese tipo de filtro (inspección del contenido del mensaje) no es la solución.
el unico problema ahora es que los correos entrantes, que si son analizados por estos filtros, no son analizados por amavis, ni spamassassin, pero si los internos...este tema lo revisare el lunes, que este con la mente relajada.
Olvida los filtros, rechaza desde el principio al equipo que te está enviando esos mensajes. Postfix es tu primer arma y tiene opciones para estas cosas. Por ejemplo, puedes probar con "smtpd_sender_restrictions" junto "check_sender_access" para rechazar la conexión del servidor. Si tienes un patrón de ataque (la conexión viene siempre del mismo equipo, mismo remitente, misma dirección IP o rango) tienes más opciones de bloqueo. Los filtros de palabras pueden venir bien en el caso de que las conexiones sean aleatorias, falsas (utilice un equipo zombie para llevar a cabo el ataque) o provengan de varios equipos, ante lo cual sólo te queda como patrón el propio mensaje (aunque también es posible que el contenido del mensaje pueda variar). Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-04-07 a las 20:50 +0200, Camaleón escribió:
El 7/04/07, Juan Carlos Bravo Celis escribió:
¿Qué es lo que quieres conseguir, cuál es el objetivo final? A veces es más sencillo obtener la solución de una forma global que ir resolviendo los problemas uno a uno.
Eso es lo importante.
Postfix permite hacer esa distinción (inspección del contenido de los mensajes, cabeceras...), además de explicar cómo hacerlo. Para ello utiliza "header_checks / body_checks":
http://www.postfix.org/BUILTIN_FILTER_README.html#remote_only
Con ésto se consigue que sólo los mensajes que vienen de fuera sean analizados e inspeccionados.
A mi me parece peligroso basarse en este tipo de filtros. Son de todo o nada.
Nota: al no analizar los correos internos no es posible evitar el mal uso del servidor de correo entre los propios usuarios.
2. el analisis para los correos que vienen de internet, debe permitir hacer lo siguiente:
-debe redireccionar a otra cuenta todos los correos que en el cuerpo tengan palabras como "palabra1", "palabra2" con la finalidad de ser analizados y reenviados a sus destinatarios.
Eso me parece una idea terrible: te pone en el papel de CENSOR del correo. Los filtros deben ser únicamente automáticos, ninguna persona debe ver el correo salvo su destinatario. El administrador del correo no debe ni olerlo. Si ocurre algo, el administrador es el culpable. Si alguien se entera de algún secreto y se publica, el administrador es el culpable. Si alguien hace algo malo, se descubre y le despiden, el administrador es el culpable. Si alguien hace algo malo y no se descubre, el administrador es el culpable. Si se pierde un correo importante, el administrador es el culpable. Juan, te lo digo en serio: niégate en redondo, y si no hay más remedio, pide la orden por escrito con una exclusión de responsabilidad.
-tener una lista de dominios externos, que no deben ser analizados por el filtro y que circulen libremente sin percanses ni modificaciones.
Aquí está el problema. Si se analizan los servicios utilizados (postfix, amavisd-new, spamassassin, clamav y cyrus):
Sigo insistiendo en que lo mejor es dejar el análisis a las herramientas que están diseñadas para ello: amavis-new (y spamassassin). Sí es posible excluir del filtro los internos, lo he visto por ahí (dependiendo del punto donde insertes el amavis). Y tiene características de listas blancas para excluir o puntuar menos a determinados dominios. Empieza por /usr/share/doc/packages/amavisd-new/README_FILES Mucho más: http://www.postfix.org/docs.html
P.S. Cuando se tiene problemas con un servidor en concreto (dominio, dirección o rango ip, remitente) lo más efectivo es bloquearlo directamente (siempre que sea posible) para que no pueda conectar con el servidor o servicio que se está viendo afectado.
Para eso está el fichero "access" del postfix. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGGCDstTMYHG2NR9URArOIAKCGmx6NOcltbJCeFB/3y8IBzGgO6ACghe7S RbDBT9bJ+RNny60hWPNVlPc= =IsIE -----END PGP SIGNATURE-----
Estuve viendo la posibilidad de hacerlo con procmail com me comento Josep, pero no tengo la menor idea de como separar los entrantes de los salientes, pues si lo miro del punto de vista del encabezado de los correos que se generan dentro de mi LAN y que todos tienen en comun por ejemplo es
Received: from [192.168.4.32] (unknown [10.10.10.10]) by mail.midominio.com.pe (Postfix) with ESMTP id 980EA20D0E3; Wed, 4 Apr 2007 22:40:42 -0500 (PET)
y lo que tienen en comun es (unknown [10.10.10.10])
... continuando con la opción PROCMAIL ..... :-) En realidad tienes más cabeceras. Puedes filtrar el correo interno por el "From:" Una manera simple sería analizar solo que el dominio del "From:" se correspondiera con el tuyo. Evidentemente el "From:" es falsificable :0B: * ! ^From:.*@midominio.com * palabra1 /dev/null :0B: * ! ^From:.*@midominio.com * palabra2 /dev/null Estas reglas harían que si un mensaje NO viene de MIDOMINIO y tiene la palabra1 se borrara. Si no la tuvieran pasaría a la siguiente palabra2, y si existe se borraría. Si no hubiera más palabras ni más reglas PROCMAIL acabaría y el mensaje iría a la cola normal No es necesario hacer una regla para cada palabra. Se pueden poner todas en una misma regla: * ^palabra1|^palabra2 En lugar de borrar se puede enviar a una carpeta de spam, ... y/o enviar un correo de rechazo .... Por ejemplo borrar y correo de rechazo :0B * ! ^From:.*@midominio.com * palabra1 * !^FROM_DAEMON * !^X-Loop: postmaster@dominio.com { :0Whc: noexe.lock | (formail -t -r -I"Subject: Rejected mail: Recipient refusal" \ -I"From: postmaster@dominio.com" \ -A"X-Loop: postmaster@dominio.com" ; cat /etc/rejected.txt) | $SENDMAIL -t :0: /dev/null } El texto del rechazo estaría en "/etc/rejected.txt. Creo que lo tienes comentado en un mensaje mío anterior. Para evitar la falsificación del "From:" puedes usar reglas más sofisticadas que el nombre del dominio. Por ejemplo el campo "Received:" Si el mensaje se ha entregado directamente, es decir viene de tu red local, (en general) solo tendrá un campo "received:". El que va del ususario que envia al propio servidor de correo. Si el mensaje proviene de otro servidor tendrá lógicamente más de un campo "received: Del ususario a su servidor y, al menos, un segundo que irá de ese servidor remoto que hará la entrega al tuyo. En base a esto se puede establecer un contador para distinguir correo local de correo remoto. si contando los "received:" el número es mayor de uno se trata de un correo externo. :0 *$ 2^0 ^Received:.* * ! ^From:.*@midominio.com * palabra /dev/null Tienes un manual muy denso y completo con _casi_ toda la potencia de PROCMAIL en: http://pm-doc.sourceforge.net/pm-tips-body.html P.D. Las reglas de este mensaje pueden no funcionar "a la primera" y hay que afinarlas. P.D.2. Los experimentos hay que hacerlos con gaseosa y a ser posible sin mojar nada. -- Salutacions - Saludos, Josep M. Queralt
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-04-08 a las 13:57 +0200, Josep M. Queralt escribió:
El texto del rechazo estaría en "/etc/rejected.txt. Creo que lo tienes comentado en un mensaje mío anterior.
Enviar un correo de rechazo cuando el orginante es un espamer que usa una dirección falsa empeora el problema, porque probablemente estás enviando el rechazo a un inocente. Además, obliga a tu propio servidor a procesar un correo más, el de rechazo - que a su vez puede ser rechazado originando otro correo hacia tí. Los rechazos han de hacerse el postfix. Un rechazo dentro del propio postfix no genera un correo en tu servidor: simplemente el servidor que te está intentando enviar es rechazado en su intento de conexión con una causa (configurable), y es ese servidor rechazado el que se encuentra con la carga de generar el correo de rechazo al remitente, no tú. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGGN70tTMYHG2NR9URAi4TAJ4uZ0hvCmhJtEBeqc1WiAQWJ9OM+ACeKylW x7y1s1tJ18w2r4zx/tW8J60= =NwXe -----END PGP SIGNATURE-----
El texto del rechazo estaría en "/etc/rejected.txt. Creo que lo tienes comentado en un mensaje mío anterior.
Enviar un correo de rechazo cuando el orginante es un espamer que usa una dirección falsa empeora el problema, porque probablemente estás enviando el rechazo a un inocente. Además, obliga a tu propio servidor a procesar un correo más, el de rechazo - que a su vez puede ser rechazado originando otro correo hacia tí.
Simplemente era un ejemplo más de la potencia que se le puede dar a PROCMAIL. No es obligatorio ni generar una autorespuesta ni tampoco, como también indicaba, mandarlo a /dev/null. En el ejemplo se añade un header "X-Loop" para evitar que se forme un bucle y con ello la segunda "objeción" que pones. El ejemplo del "X-Loop" también puede servir para añadir el "X-Disclaimer" por el que preguntaba, algunos mensajes antes J.C. Bravo. -- Salutacions - Saludos, Josep M. Queralt
El 8/04/07, Josep M. Queralt escribió:
... continuando con la opción PROCMAIL ..... :-)´
¿Cómo configuras Postfix para que trabaje con Procmail, Amavisd-New, SA, ClamAV y Cyrus? Sieve* es un lenguaje de filtrado sencillo pero que tiene algunas ventajas: - Viene integrado con Cyrus. - Permite trabajar directamente sobre cada usuario de forma independiente. - Ponerlo en marcha es relativamente sencillo. - Es un filtro de servidor. - Puede ser gestionado por los propios usuarios para que creen sus propias reglas. Sieve permite la creación** y gestión de reglas que realizan acciones determinadas sobre los mensajes según lo especificado. Por ejemplo, es posible enviarlos a un directorio de spam (del mismo usuario) si en la cabecera del correo SA lo ha clasificado como tal, con lo cual evitas que el correo vaya a la bandeja de entrada del usuario y siempre puede verlo si tiene configurada una cuenta de tipo IMAP. También permite redireccionar el mensaje a otro destinatario*** según distintos criterios, pero Sieve sigue siendo un filtro de "contenido", y para este caso en concreto no creo que sea la opción más conveniente. * http://rfc.net/rfc3028.html ** http://www.fastmail.fm/docs/sieve/index.html *** http://rfc.net/rfc3028.html#p21 Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 8/04/07, Josep M. Queralt escribió:
... continuando con la opción PROCMAIL ..... :-)´
¿Cómo configuras Postfix para que trabaje con Procmail, Amavisd-New, SA, ClamAV y Cyrus?
Está en uno de los mensajes anteriores de mi "postulación" por PROCMAIL. :-) mailbox_command=/usr/bin/procmail Aunque también puede usarse un fichero ".forward" que llame a procmail si se quiere reservar el comando de Postfix para otro filtro. El contenido del ".forward" sería: "|/usr/local/bin/procmail" SpamAssassin puede ejecutarse mediante la primera regla del filtro de ProcMail: :0fw | /usr/bin/spamassassin En lugar de SA la llamada puede hacerse a spamc o spamd. Mediante el marcado que se utilice en SA podrían construirse a continuación reglas para redirigir el correo sospechoso de SPAM Por ejemplo: :0: * ^X-Spam-Status: Yes /dev/null # si se borra o /carpeta_de_spam) si se revisa Pero creo que por ese camino me desvío de la pregunta inicial
Sieve* es un lenguaje de filtrado sencillo pero que tiene algunas ventajas:
- Viene integrado con Cyrus.
Procmail viene "de serie" con la distribución. No hay que instalar nada nuevo.
- Permite trabajar directamente sobre cada usuario de forma independiente.
Adicionalmente PROCMAIL puede trabajar simultaneamente a nivel de servidor. Es decir permite filtrar a nivel global, para todos los usuarios y simultaneamente a cada uno de estos de forma individual.
- Ponerlo en marcha es relativamente sencillo.
Sip, "sencillo" es un concepto relativo. :-)
- Es un filtro de servidor.
También
- Puede ser gestionado por los propios usuarios para que creen sus propias reglas.
Procmail tambien, pero no se si eso es bueno. :-)
Sieve permite la creación** y gestión de reglas que realizan acciones determinadas sobre los mensajes según lo especificado.
Idem para PROCMAIL, con la ventaja de poder utilizar comandos del sistema.
También permite redireccionar el mensaje a otro destinatario*** según distintos criterios, pero Sieve sigue siendo un filtro de "contenido", y para este caso en concreto no creo que sea la opción más conveniente.
En principio pienso que a J.C. Bravo lo único que debería importarle era filtrar los insultos que provenían de una determinada Web. Para eso yo pienso que si es indicado el uso de ProcMail, o de Sieve, el cual, por cierto no he tenido la oportunidad de probar. Al indicar más funcionalidades como el "X-Disclaimer" yo pienso que si es indicado el uso de Procmail. De todas maneras, y para volver al inicio del tema, yo pienso que la forma más directa de acabar con el problema es, como ya se le indicó al JC Bravo, bloquear la IP del servidor de correo del sitio "insultante". -- Salutacions - Saludos, Josep M. Queralt
El 8/04/07, Josep M. Queralt escribió:
Está en uno de los mensajes anteriores de mi "postulación" por PROCMAIL. :-)
mailbox_command=/usr/bin/procmail
Con el uso de Cyrus se tiene configurado, generalmente "mailbox_transport = cyrus", pero si le dices a Postfix que al final le entregue el correo a Procmail supongo que tendrás que decirle a Procmail que lo entregue Cyrus ¿en algún fichero de configuración de Procmail?
SpamAssassin puede ejecutarse mediante la primera regla del filtro de ProcMail:
:0fw | /usr/bin/spamassassin
En lugar de SA la llamada puede hacerse a spamc o spamd.
Pero usa Amavisd-New, que engancha con SA y ClamAV, supongo que procmail también llamar a Amavisd, pero eso conlleva modificar toda la configuración del sistema de correo.
Procmail viene "de serie" con la distribución. No hay que instalar nada nuevo.
Con la configuración actual de Juan Carlos el uso de procmail se complica. Los correos tienen que llegar de Postfix a Procmail, luego Amavisd-New (SA y ClamAv) a Postfix y a Cyrus, es un follón. Si no utilizara Cyrus podría utilizarse Procmail como transporte final.
Adicionalmente PROCMAIL puede trabajar simultaneamente a nivel de servidor. Es decir permite filtrar a nivel global, para todos los usuarios y simultaneamente a cada uno de estos de forma individual.
Sigo sin ver en este esquema que dices dónde está Cyrus, que es el destino final del mensaje.
En principio pienso que a J.C. Bravo lo único que debería importarle era filtrar los insultos que provenían de una determinada Web.
Eso no suele ser conveniente, sencillamente porque depende del administrador leer los mensajes y re-enrutarlos de nuevo, por no hablar de falsos positivos.
Para eso yo pienso que si es indicado el uso de ProcMail, o de Sieve, el cual, por cierto no he tenido la oportunidad de probar.
El uso de procmail en este esquema y con los servicios que tiene configurados no me queda claro.
De todas maneras, y para volver al inicio del tema, yo pienso que la forma más directa de acabar con el problema es, como ya se le indicó al JC Bravo, bloquear la IP del servidor de correo del sitio "insultante".
Completamente de acuerdo. Es la opción más limpia, la más sencilla y la más efectiva. Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-04-08 a las 19:21 +0200, Camaleón escribió:
:0fw | /usr/bin/spamassassin
En lugar de SA la llamada puede hacerse a spamc o spamd.
Pero usa Amavisd-New, que engancha con SA y ClamAV, supongo que procmail también llamar a Amavisd, pero eso conlleva modificar toda la configuración del sistema de correo.
Complicado y no recomendable. El amavis está diseñado para procesar el correo bastante antes del reparto a los usuarios, y procmail está pensado para ser el repartidor a los usuarios. No combina bien. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGGStMtTMYHG2NR9URAiocAJ9Oa35Thiw07Nu7RGeK/Mbhqv2a5ACgiVU6 SL1zcOY/6UXaLR2bRDLdBLI= =jQ0h -----END PGP SIGNATURE-----
Pero usa Amavisd-New, que engancha con SA y ClamAV, supongo que procmail también llamar a Amavisd, pero eso conlleva modificar toda la configuración del sistema de correo.
Complicado y no recomendable. El amavis está diseñado para procesar el correo bastante antes del reparto a los usuarios, y procmail está pensado para ser el repartidor a los usuarios. No combina bien.
Precisamente eso es lo que le decía a Camaleon. Amavis actúa desde Postfix, es decir antes de que entre en acción Procmail, por lo que no tendría que haber ningún problema de combinación. :-) De todas maneras, como estoy de vacaciones mi consejo era el inicial: Que banee la IP del servidor de correo del web "insultante" y se acabó el problema al menos temporalmente. Además, igual con los días que llevamos discutiendo, ya los responsables administrativos de los sitios afectados han llegado a un acuerdo y el webmaster de la emisora de radio ya ha puesto, diligentemente, los filtros correspondietes en el formulario.... ... o quizá a prohibido mandar correo al servidor de JC Bravo. :-) -- Salutacions - Saludos, Josep M. Queralt
El 8/04/07, Josep M. Queralt escribió:
Está en uno de los mensajes anteriores de mi "postulación" por PROCMAIL. :-)
mailbox_command=/usr/bin/procmail
Con el uso de Cyrus se tiene configurado, generalmente "mailbox_transport = cyrus", pero si le dices a Postfix que al final le entregue el correo a Procmail supongo que tendrás que decirle a Procmail que lo entregue Cyrus ¿en algún fichero de configuración de Procmail?
Salgo del supuesto de que te refieres a Cyrus como servidor IMAP. Tengo la suerte de no administrar servidores con IMAP :-) ... y la desgracia, pues de tener que contestar sin fundamento práctico. Habría una primera opción que ya apuntaba en mi mensaje anterior y que sería usar ".forward". Creo que eso evitaría tener que tocar la configuración de Postfix. La segunda opción sería a mi entender más elegante pero entraría de lleno en el problema que planteas, cual es poner "patas arriba" toda la configuración del sistema de correo. 1.- Establecer en el "master.cf" de Postfix una nueva linea indicando como transporte Procmail 2.- Cambiar en el "main.cf" de Postfix el transporte y establecerlo en procmail mailbox_command = /usr/bin/procmail mailbox_transport = procmail ... si supone que el transporte ya no es Cyrus. 3.- Establecer en el fichero global (el del servidor en "/etc/procmailrc") de procmail que entregue el correo a Cyrus cuando finalice el procesado de mensajes: DELIVERTO="/usr/bin/cyrus/bin/deliver" Imagino que eso debe suponer tocar alguna cosa más en el filtro "maestro" pero tendría que hacerlo funcionar y no voy a montar un IMAP para contestarte con más detalle. 0:-)
Pero usa Amavisd-New, que engancha con SA y ClamAV, supongo que procmail también llamar a Amavisd, pero eso conlleva modificar toda la configuración del sistema de correo.
Pienso que Amavis "engancha" generalmente con Postfix mediante el uso de "smtpd" que se define en el "main.cf" de Postfix. Dicho en otras palabras, quien llama a Amavis-new es Postfix y se ejecutaría lógicamente antes de entrar en Procmail. Es más Amavis recibe el correo de Postfix a través del puerto 10025 y lo "reinyecta" al mismo Postfix por el 10024. Todo eso ocurre _antes_ de entrar en Procmail Alternativamente y dado que Procmail es capaz de ejecutar comandos y recoger el resultado de los mismos, se podría prescindir de Amavis y ejecutar _directamente_ el antivirus. Eso sería incluso más lógico, dado que esa es, en realidad, la tarea que ejecuta Amavis. (llamar a un antivirus y recoger su resultado). es decir, con procmail se podría prescindir del uso de Amavis. En cuanto al uso de ClamAV por las mismas razones que las expuestas en el párrafo anterior no hay ningún inconveniente en llamarlo desde ProcMail. Es más en la propia configuración de ClamAV ya está prevista esta posibilidad. Simplemente con ClamAV instalado, desde Procmail se usarías esa regla para llamarlo: :0 * multipart * !^X-Virus-Scan: | /usr/local/sbin/trashscan Seguidamente se filtraría el contenido: :0: * ^X-Virus-Scan: Suspicious /dev/null # se borra o se cambia la linea para marcar y entregar o enviar a carpeta de cuarentena
Con la configuración actual de Juan Carlos el uso de procmail se complica. Los correos tienen que llegar de Postfix a Procmail, luego Amavisd-New (SA y ClamAv) a Postfix y a Cyrus, es un follón. Si no utilizara Cyrus podría utilizarse Procmail como transporte final.
En realidad solo se complica por el uso de Cyrus, aunque pienso que eso se podría obviar sejecutando procmail mediante el fichero ".forward". De todas maneras eso habría que testearlo.
Sigo sin ver en este esquema que dices dónde está Cyrus, que es el destino final del mensaje.
no lo veías porque no lo había puesto. en este mensaje si está: DELIVERTO="/usr/bin/cyrus/bin/deliver"
El uso de procmail en este esquema y con los servicios que tiene configurados no me queda claro.
Se puede. :-)
De todas maneras, y para volver al inicio del tema, yo pienso que la forma más directa de acabar con el problema es, como ya se le indicó al JC Bravo, bloquear la IP del servidor de correo del sitio "insultante".
Completamente de acuerdo. Es la opción más limpia, la más sencilla y la más efectiva.
... es que nos encanta complicarnos la vida. Borro todo lo dicho y escrito. Se banea la IP y asunto (y el hilo) concluido. -- Salutacions - Saludos, Josep M. Queralt
El 8/04/07, Josep M. Queralt escribió:
Salgo del supuesto de que te refieres a Cyrus como servidor IMAP.
No exclusivamente. Cualquier servidor pop3 y/o imap4 como destino final del correo que trabaje con usuarios locales y remotos.
Tengo la suerte de no administrar servidores con IMAP :-) ... y la desgracia, pues de tener que contestar sin fundamento práctico.
En tu configuración, yo también dejaría fuera amavisd-new, porque si procmail puede llamar a SA y a ClamAV no le veo utilidad alguna amavisd-new, salvo perder tiempo y recursos. El objetivo debe ser siempre reducir el tiempo de procesamiento en cada correo. Sin amavisd-new, el recorrido del mensaje sería Postfix que lo envía a Procmail (SA + ClamAV) el cual añade las cabeceras correspondientes del resultado de ambos análisis (antispam y antivirus), analiza el contenido del mensaje y lo pasa finalmente al servidor pop3 / imap4. Los correos que contengan las palabras "x" definidas como no admisibles ejecutarían las reglas de procmail y serían desviados a otra cuenta de correo u otro directorio.
Habría una primera opción que ya apuntaba en mi mensaje anterior y que sería usar ".forward". Creo que eso evitaría tener que tocar la configuración de Postfix.
Pero el fichero .forward ¿funciona con todo tipo de usuarios (locales y remotos) o sólo con usuarios locales? ¿O es un fichero genérico para todos? Por lo que comentas, procmail parece muy potente y versátil, no dudo de que pueda trabajar bien con Cyrus (o cualquier servidor de correo pop3 / imap4), ajustando la configuración de todos los componentes que entran en juego. Si el servidor pop3 / imap4 no admite el filtrado por medio de sieve, es una opción a tener en cuenta. Lo bueno de sieve es que no afecta el esquema de la entrega y recepción de correos que se tenga definido, actúa sólo con el servidor pop3 / imap4 dejando a un lado la configuración del mta o el mda. Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-04-08 a las 21:38 +0200, Camaleón escribió:
Pero el fichero .forward ¿funciona con todo tipo de usuarios (locales y remotos) o sólo con usuarios locales? ¿O es un fichero genérico para todos?
Es un fichero por cada usuario en su home. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGGVr+tTMYHG2NR9URAv++AJ4i/1+r71rEPjBQx1xrLA6m2XvX2ACfRP8y csrbOIpSGB9M1TL1parSfPw= =pMPZ -----END PGP SIGNATURE-----
El 8/04/07, Josep M. Queralt escribió:
Salgo del supuesto de que te refieres a Cyrus como servidor IMAP.
No exclusivamente. Cualquier servidor pop3 y/o imap4 como destino final del correo que trabaje con usuarios locales y remotos.
No, o al menos no con el POP3 que yo uso: qpoper No tengo que poner ninguna orden en especial. acabado el proceso el correo va a qpoper si no ha sido fltrado.
Sin amavisd-new, el recorrido del mensaje sería Postfix que lo envía a Procmail (SA + ClamAV) el cual añade las cabeceras correspondientes del resultado de ambos análisis (antispam y antivirus), analiza el contenido del mensaje y lo pasa finalmente al servidor pop3 / imap4. Los correos que contengan las palabras "x" definidas como no admisibles ejecutarían las reglas de procmail y serían desviados a otra cuenta de correo u otro directorio.
Exacto.
Habría una primera opción que ya apuntaba en mi mensaje anterior y que sería usar ".forward". Creo que eso evitaría tener que tocar la configuración de Postfix.
Pero el fichero .forward ¿funciona con todo tipo de usuarios (locales y remotos) o sólo con usuarios locales? ¿O es un fichero genérico para todos?
Tienen que ser usuarios del sistema, tienen que tener su propio $HOME Si tengo claro que procmailrc puede ejecutarse tanto a nivel local como a nivel del servidor desde "/etc/procmailrc". No tengo claro que para ejecutar procmail pueda hacerse lo mismo con el fichero ".forward"
Por lo que comentas, procmail parece muy potente y versátil, no dudo de que pueda trabajar bien con Cyrus (o cualquier servidor de correo pop3 / imap4), ajustando la configuración de todos los componentes que entran en juego.
Entre mis vicios conocidos además de la nicotina, la cafeina y la horchata, también están WEBMIN y Procmail. Por cierto, Procmail puede configurarse a nivel global desde WebMin y a nivel de usuario desde USERMIN. :-)
Si el servidor pop3 / imap4 no admite el filtrado por medio de sieve, es una opción a tener en cuenta.
No conozco sieve así que es dificil comparar. :-)
Lo bueno de sieve es que no afecta el esquema de la entrega y recepción de correos que se tenga definido, actúa sólo con el servidor pop3 / imap4 dejando a un lado la configuración del mta o el mda.
Sip, eso evita quebraderos de cabeza. -- Salutacions - Saludos, Josep M. Queralt
Hola a todos, les cuento como me fue con este tema, particularmente, concuerdo con ustedes de que los filtros totalitarios, no son muy buena idea, dada la situacion en que me encontraba, procedi hacer lo siguiente: 1. lo primero que hice fue bloquear las direcciones de correo y numeros IP de donde provenian los ataques, esto con la sugerencia de Carlos, de poerlo en el access, no siendo una solucion al problema, puesto que buscaron nuevas direcciones y paginas web, que les permitieran generar el ataque. 2. Esto no habria sido un problema, si fuese un ataque de spam o algo parecido, el lio es que hacian parecer que lo enviaba un usuario de correo, digamos jbravo@midomino.com y con el contenido, dañaba la honorabilidad de muchas personas y en algunos casos atentaba contra la dignidad e integridad de otros usuarios, por lo que el bloqueo de los correos usando el access no brindaba una solucion adecuada. 3.Siguiendo los consejos de Josep, busque una posible solucion con procmail, pero como comento Camaleon, lo que me complicaba este tema es que uso Cyrus como servidor IMAP, y se me complico la existencia, pero de revisar la documentacion de procmail, descubri que puede usarse para automatizar ciertos procesos, como sacar algun dato de los correos y ponerlo en una base de datos, esto es algo que tendre presente para un proyecto que tengo en mente. 4. Descartado procmail, por que me complicaba un poco lo de cyrus, busque una solucion por el lado de los headers y el body check, pues analizando los correos que queria bloquear, pude encontrar varios puntos en comun, como palabras y que todos al final, hacian referencia a una pagina web que recomendaban (tambien cambiante), esto funciono para bloquear los correos con esas caracteristicas, pero tambien me genero un gran dolor de cabeza por que para no perder los correos me vi obligado a redirigirlo a una cuenta de cuarentena y luego reenviarlo a su destinatario original, pero el body_check tambien se ejecutaba para los correos locales, que al final agrandaba el dolor de cabeza. 5. Finalmente, con lo que comento Camaleon sobre crear otra instancia de postfix para separar el correo local de los entrantes, pude liberarme del correo local y preocuparme solo de los entrantes, despues de mostrarle a mi Jefe los efectos de hacer estos cambios, en una semana segun evaluacion, ya no existira esa cuenta de cuarentena, y nadie tendra que mirarla y reenviar el correo a su destinatario original, por lo que solo usare el body check y el access,y a muchos usuarios se restringira el envio de correos a direcciones que no sean locales, esto como optimizacion del servicio de correo, para que se usen con los fines que la Empresa espera que se usen . Todavia no he podido hacer que el amavis analise los correos tanto entrantes como locales, solo analiza los locales, quiza necesite otra instancia de amavis, pero para ello tengo algo de tiempo. Solo me queda enviarles mi agradecimiento por sus comentarios y por su tiempo. Gracias a Todos. Saludos JCarlos --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-04-09 a las 23:45 -0500, Juan Carlos Bravo Celis escribió:
Hola a todos, les cuento como me fue con este tema, particularmente, concuerdo con ustedes de que los filtros totalitarios, no son muy buena idea, dada la situacion en que me encontraba, procedi hacer lo siguiente:
1. lo primero que hice fue bloquear las direcciones de correo y numeros IP de donde provenian los ataques, esto con la sugerencia de Carlos, de poerlo en el access, no siendo una solucion al problema, puesto que buscaron nuevas direcciones y paginas web, que les permitieran generar el ataque.
Si van cambiando a nuevas páginas web no te servirá ni la IP ni la dirección remitente, puesto que cambian. Es más, eso tiene pinta de ser un ataque intencionado, y frente a la ingenuidad del atacante no hay mucho que puedas hacer, porque cambiará de técnica para evitar los bloqueos.
2. Esto no habria sido un problema, si fuese un ataque de spam o algo parecido, el lio es que hacian parecer que lo enviaba un usuario de correo, digamos jbravo@midomino.com y con el contenido, dañaba la honorabilidad de muchas personas y en algunos casos atentaba contra la dignidad e integridad de otros usuarios, por lo que el bloqueo de los correos usando el access no brindaba una solucion adecuada.
Me he topado con uno, en Australia, que dicen que en algunos de los departamentos con los que trabaja se rechazan automáticamente los correos sin firma criptográfica pkcs - los que se generan via autoridad certificadora. Si el remitente figura ser interno, una solución criptográfica os funcionaría.
4. Descartado procmail, por que me complicaba un poco lo de cyrus, busque una solucion por el lado de los headers y el body check, pues analizando los correos que queria bloquear, pude encontrar varios puntos en comun, como palabras y que todos al final, hacian referencia a una pagina web que recomendaban (tambien cambiante), esto funciono para bloquear los correos con esas caracteristicas, pero tambien me genero un gran dolor de cabeza por que para no perder los correos me vi obligado a redirigirlo a una cuenta de cuarentena y luego reenviarlo a su destinatario original, pero el body_check tambien se ejecutaba para los correos locales, que al final agrandaba el dolor de cabeza.
Eso lo podrías haber hecho con el amavis-new/spamassassin sin niguna complicación, que están diseñados para eso. Basta crear tus propias reglas que añadan puntuaciones al aparecer ciertas webs o palabras clave. En /usr/share/spamassassin/25_uribl.cf están una serie de listas dinámicas de bloqueo de webs en el texto de los correos: si un correo menciona una web, la que sea, se mira en la lista dinámica, y se le añaden puntos. Hay una manera de añadirlos a una lista blanca (uridnsbl_skip_domain), pero no veo la negra. Pero te lo puedes inventar como bloqueo de una frase arbitraria, como ya te puse el ejemplo: añades puntuación para cada frase prohibida, y con varias que coincidan, fuera.
5. Finalmente, con lo que comento Camaleon sobre crear otra instancia de postfix para separar el correo local de los entrantes, pude liberarme del correo local y preocuparme solo de los entrantes,
El amavis-new trabaja precisamente con los entrantes, sin hacer nada. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGG57RtTMYHG2NR9URArrSAKCJb4c9/LtmG4jlfMAKs1j/U35AYQCfeHau JPszK5SQgCNxum8rzc5a8c8= =MQiS -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-04-08 a las 20:27 +0200, Josep M. Queralt escribió:
Alternativamente y dado que Procmail es capaz de ejecutar comandos y recoger el resultado de los mismos, se podría prescindir de Amavis y ejecutar _directamente_ el antivirus. Eso sería incluso más lógico, dado que esa es, en realidad, la tarea que ejecuta Amavis. (llamar a un antivirus y recoger su resultado). es decir, con procmail se podría prescindir del uso de Amavis.
Es más conveniente hacerlo mediante amavis, porque está pensado para eso y no hay que trabajarselo. Por ejemplo, si un correo tiene una docena de destinatarios en el mismo servidor, cuando el correo llega a procmail ya está dividido en doce correos individuales y tendría que procesarlo doce veces. En cambio, con amavis se analiza antes de que se separen las copias, y se hace una unica vez. Pero, si alguno de los receptores dice que quiere recibir los virus, que le encanta comerselos con patatas al alioli, pues no hay problema: se le incluye en la lista de "virus lovers" y el amavis (después de saber que es un virus) lo bloqueará a todo el mundo salvo al bicho raro, que se lo enviará. Un tratamiento similar puede recibir el spam. Y esas características individuales de cada usuario pueden guardarse en una base mysql, lo cual es bastante interesante para un servidor. Conseguir un tratamiento similarmente cómodo con el procmail, que aunque es potentísimo no se pensó para eso, pues no es tan fácil. Cada herramienta tiene su uso óptimo.
... es que nos encanta complicarnos la vida.
Borro todo lo dicho y escrito. Se banea la IP y asunto (y el hilo) concluido.
Cierto. Pero en este caso, el caso del correo de un servidor establecido, mejor que prohibir la IP se prohibe el remite - y hay un remite común en todos ellos:
Return-Path:
(el envelope-from) Ese es el que hay que cerrar, y es una chorrada hacerlo en el "access" del postfix haciendo que se le llene el buzón de rebotes al responsable de ese servidor, sin que el postfix tenga más que carraspear más ligeramente. Además, funcionará aunque cambie la IP o venga por un camino intermedio. No se trata de un servidor malvado, sino de un mal uso de un servidor legítimo - pienso - así que no es probable que cambie el remite pronto. Y el rechazo puede incluir una nota breve del motivo que le saldrá en el log al servidor culpable. Y si tratara de contactar alguien de ese servidor directamente, podría hacerlo. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGGUtctTMYHG2NR9URAo4EAJsE3naO+FtADJApVza617H5AuHnigCgkH3W Nq8Zv8XfdxSQZm2Zc7OI5os= =DtKS -----END PGP SIGNATURE-----
participants (4)
-
Camaleón -
Carlos E. R. -
Josep M. Queralt -
Juan Carlos Bravo Celis