y como le digo al amavis-new, que tengo instalado y andando conel postfix en
mi suse 9.1 que me rechace el spam?
lo pregunto porque diariamente me llegan un monton.
como puedo configurar el amavis-new tambien para eso?
me puedes(podeis) ayudar?
gracias
----- Original Message -----
From: "Carlos E. R."
El 2004-10-16 a las 10:18 +0200, Camaleón escribió:
Carlos E. R. wrote:
Puedes eliminar previamente los virus, usando amavis_new, por ejemplo.
¿Qué tiene el amavis-new que todo el mundo lo utiliza?
:)
Que es nuevo :-p
No, simplemente que es lo que el suse 9.1 trae "de fábrica". Combina la funcionalidad del amavis (detección de virus) y del SA. Se llama desde el propio postfix (o sendmail). Rechaza cualquier correo que contenga ejectuables, aunque vengan dentro de un fichero zip. Ya con eso, no hace falta detectar virus, puesto que los virus por narices son ejecutables. Sin embargo, se puede habilitar la detección de virus (más tiempo de proceso). Y además, también mira el spam - pero como lo hace globalmente, los filtros bayesianos no pueden funcionar tan bien.
La ventaja es que al juntar las dos cosas, SA y amavis, el proceso es más rápido, es una unica sesion perl, imagino.
Sin embargo, yo le tengo deshabilitada la parte de SA, para dispararla como usuario y afinar el filtro bayesiano (soy yo sólo en ésta máquina).
Bueno, y cuando hagan el SA 3, que no se si ha salido ya, todavía irá más rápido.
Desventaja (y gorda): que el amavis-new no trae documentación de usuario. Si, vale, el fichero de configuración está ampliamente comentado. No me vale, eso es totalmente comprensible sólo por programadores. No hay documentación con ejemplos y motivaciones de hacer una cosa u otra.
No tengo nada en contra de él, pero siempre me ha gustado utilizar la menor cantidad de programas posibles, así los errores son más sencillos de detectar (al final no sabes si el que falla es el filtro de amavis, postfix o SA).
No es tan complicado. Y o bien amavis o amavis-new hay que ponerlo, para quitar virus: y el amavis-new es muy eficaz en eso. El yast (en 9.1) te inserta el amavis bastante bien, y por defecto es como un tamiz muy tupido, quizás demasiado.
Puedes también inventar una regla que le de algunos puntos negativos a esas direcciones, en vez de 100. Sabes que puedes definir reglas locales para el SA.
Muy complicado. :-)
Yo tengo alguna, para quitar algunos que se me colaban.
Se puede inventar una regla que detecte si ha sido enviado por el servidor de terra - el SA tiene reglas para el yahoo, por ejemplo. Ahora, date cuenta que gente como yo envia con el from de terra, pe, pero sin usar para nada a terra, por lo que esa regla te diría que mi from es falso.
Habría que ver como hace el SA para detectar los falsos yahoo, e imitarlo con terra.
Carlos, SA lo puede hacer sin necesidad de reglas. Simplemente configurando los parámetros de "whitelist_from_rcvd" junto con "trusted_networks". Pero es que no sé qué valores poner en "trusted_networks"...
No se que hacen esos parámetros, así que no opino de momento.
[...]
Mail::SpamAssassin::Conf(3)
whitelist_from_rcvd addr@lists.sourceforge.net sourceforge.net Use this to supplement the whitelist_from addresses with a check against the Received headers. The first parameter is the address to whitelist, and the second is a string to match the relay's rDNS.
This string is matched against the reverse DNS lookup used dur ing the handover from the untrusted internet to your trusted network's mail exchangers. It can either be the full hostname, or the domain component of that hostname. In other words, if the host that connected to your MX had an IP address that mapped to 'sendinghost.spamassassin.org', you should specify "sendinghost.spamassassin.org" or just "spamassassin.org" here.
Note that this requires that "trusted_networks" be correct. For simple cases, it will be, but for a complex network, or if you're running with DNS checks off or with "-L", you may get better results by setting that parameter.
e.g.
whitelist_from_rcvd joe@example.com example.com whitelist_from_rcvd *@axkit.org sergeant.org
Mmm. La primera entrada es el "From", y la segunda debe encajar con el DNS inverso del relay, el que figura en el received del intercambio entre tu red (confiable) e internet (no confiable). Eso exige que trusted_networks esté bien puesto.
trusted_networks ip.add.re.ss[/mask] ... (default: none) What networks or hosts are 'trusted' in your setup. Trusted in this case means that relay hosts on these networks are considered to not be potentially operated by spammers, open relays, or open proxies. DNS blacklist checks will never query for hosts on these networks.
If a "/mask" is specified, it's considered a CIDR-style 'netmask', specified in bits. If it is not specified, but less than 4 octets are specified with a trailing dot, that's considered a mask to allow all addresses in the remaining octets. If a mask is not specified, and there is not trailing dot, then just the single IP address specified is used, as if the mask was "/32".
Examples:
trusted_networks 192.168/16 127/8 # all in 192.168.*.* trusted_networks 212.17.35.15 # just that host trusted_networks 127. # all in 127.*.*.*
This operates additively, so a "trusted_networks" line after another one will result in all those networks becoming trusted. To clear out the existing entries, use "clear_trusted_networks".
If you're running with DNS checks enabled, SpamAssassin includes code to infer your trusted networks on the fly, so this may not be necessary. (Thanks to Scott Banister and Andrew Flury for the inspiration for this algorithm.) This inference works as follows:
o if the 'from' IP address is on the same /16 network as the top Received line's 'by' host, it's trusted
o if the address of the 'from' host is in a reserved network range, then it's trusted
o if any addresses of the 'by' host is in a reserved network range, then it's trusted
O sea, que aquí debes poner por lo menos tu propia red privada, y creo que la IP de tu puerta a internet, la de la maquina que corre el servidor de correo externo.
Vale.
Pues yo lo que te decía es que ésta prueba dará falso, por ejemplo, para cualquier correo privado que yo te pudiera mandar, por ejemplo, porque como yo envio con mi propio postfix, y nunca uso el relay de mi proveedor, la resolución inversa del recieved que te llegue en modo alguno será la de mi from.
Y tampoco lo va a ser para aquellos que tengan varias direcciones, y la envien a traves de un relay con autentificación, porque en ese caso el from no es el del servidor que te envia. Puede suceder que en algunos casos de y en otros no, para la misma persona, si anda con un portatil, pe.
No lo veo claro.
Además, como le da una puntuación de -100, no hay opción a que otras reglas trabajen, se convierte en la única regla.
Los dns detectan muchas spams, es cierto, y al menos usándolos dentro del SA es más justo que usarlo en el psotfix (si lo activas en el postfix, gente como yo los bloqueas).
No creo que los tiros vayan por ahí. Entiendo (según la documentación de SA) que para que SA pueda identificar que un correo ha salido del servidor del que dice pertenecer, tiene que verificar (utilizando la resolución de nombres de los registros MX) que efectivamente es así. Por ejemplo, recibo muchos correos con virus (.zip) que dicen que son de "usuario@terra.es" pero si analizas las cabeceras del correo ves que ha salido de una IP de ADSL de Telefónica. Vamos, que de Terra nada.
Claro, pero eso es lo que te digo que pasaría con cualquier correo mio. Aunque arriba diga tiscali, no he usado el smtp de tiscali, y en realidad la IP es de teleline, alias terra.
Si lo que te preocupa son los zips, pon el amavis-new, y te los quita todos. Sólo entran los de datos, o con password.
Si yo tengo en "whitelist_from_rcvd" configuradas las direcciones de *@terra.es solamente, ese correo me pasa como bueno (-50 bayes), pero si se tuviera bien configurada, además, la opción de "trusted_networks", SA se daría cuenta de que ese correo no puede ser bueno porque la cabecera está falseada, y no proviene de Terra, por lo que le afectaría la puntuación normalizada.
No creo que esta opción tenga relación alguna con el bloqueo de IP en listas negras, o de rangos de direcciones, eso es otro tema, que por supuesto, no pienso activarlo.
Es que hay dos maneras de usar las listas negras. Si lo usas en el postfix, es que no llegan a enviarte el correo, el postfix les deniega la conexión. En ese caso, todos los que usemos linux en casa con postfix/sendmail tenemos altas posibilidades de no entrar.
La otra manera es que sea el SA quien lo verifique. En ese caso, el correo entero ya está en tu sistema cuando se analiza, por lo que el SA le pasa toda la batería de pruebas de la que dispone, y el RBL es simplemente una prueba más.
Lo que pretendo es que a las direcciones que están en la lista blanca provengan de los servidores de correo a los que pertenecen. En caso contrario, que se les aplique las reglas bayesianas convenientes.
Ah. Mmm. ¿Seguro que se les aplican el resto de reglas? Si es así... Mmm, puede estar bien... :-???
Mmmm. Ten en cuenta que en cuanto el SA tiene un tiempo, empiezan a colarse algunos más que antes, y hay que actualizarlo.
No hay problema. Puede ser entrenado cada x tiempo.
:)
Efestivamente :-)
-- Saludos Carlos Robinson
-- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com