[opensuse-es] Proteccion anti-spam
Buenos Días De antemano muchas gracias por las respuestas.
Las herramientas de colaboración (Razor, Pyzor, DCC...) y los tests de red (listas negras) de SA hacen eso mismo... a su manera :-).
Voy a leer la documentación de las herramientas que me comentas, pero a primera vista me parece que el correo spam seguira siendo analizado por el sistema antispam es decir consumira recursos de cpu, y bueno no dudo que clasifique una gran cantidad de mensajes como spam de forma existosa, lo que no quisiera es que el se dedicaran recursos para analizar los mensajes que es lo que me esta pegando por la gran cantidad de spam que me llega, Seria conveniente bloquearlo desde antes, es decir al nivel de postfix para que ya no sea analizado este correo por el sistema. Y como bien lo comentan, todo lleva a implementar varias algunas herramientas de forma enlazada, alguien quien me clasifique el spam que me esta esta llegando(spamassassin) un sistema de verifique la concurrencia de spam de un mismo sitio en base a lo que reporta el assassin y alguien que le indique a posfix que no aceopte correo de un lugar especifico.
Otra opción... usar el "greylisting" de Postfix.
Revisare "greylisting" :-) Gracias por tu ayuda. Saludos y buen día.! -- Instituto de Ingeniería de la UNAM Coordinación de Sistemas de Cómputo Área de Sistemas Unix/Linux --------------------------------------------------------------------- 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 27/02/08, Instituto de Ingenieria Área de Sistemas Unix/Linux escribió:
Seria conveniente bloquearlo desde antes, es decir al nivel de postfix para que ya no sea analizado este correo por el sistema.
Postfix puede bloquearlo... revisa los parámetros de configuración que permite "smtpd_client_restrictions". Tienes varios para rechazar a equipos que estén en las listas negras que definas (reject_rbl_client y derivados) y algunas opciones más disponibles para afinar su uso y que no resulte tan agresivo. Pero no lo recomiendo, salvo que lo tengas "muy pulido" o el nivel de mensajes de spam que te llegan sea realmente elevado.
Revisare "greylisting" :-)
Pues no lo he probado, pero esta opción me parece más razonable que la anterior. 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 Content-ID: <alpine.LSU.1.00.0802272344240.24795@nimrodel.valinor> El 2008-02-27 a las 13:04 -0600, Instituto de Ingenieria Área de Sistemas...:
Las herramientas de colaboración (Razor, Pyzor, DCC...) y los tests de red (listas negras) de SA hacen eso mismo... a su manera :-).
Voy a leer la documentación de las herramientas que me comentas, pero a primera vista me parece que el correo spam seguira siendo analizado por el sistema antispam es decir consumira recursos de cpu, y bueno no dudo que clasifique una gran cantidad de mensajes como spam de forma existosa, lo que no quisiera es que el se dedicaran recursos para analizar los mensajes que es lo que me esta pegando por la gran cantidad de spam que me llega, Seria conveniente bloquearlo desde antes, es decir al nivel de postfix para que ya no sea analizado este correo por el sistema.
Pero no tienes más remedio que dedicar recursos a analizar el correo, muchos quizás: es el mejor sistema. Si te dedicas a bloquear correo directamente con algún criterio como el servidor del que proviene, puede ocurrir que bloquees correo que te interese sin querer. No sería la primera vez que una lista negra de bloqueos liste a servidores como, por ejemplo, telefonica, o incluso, suse, y que en cambio, de deje pasar correo basura porque todavía no se sabe que viene de ahí. El spamassassin suele ser más justo, al valorar varios criterios distintos
Y como bien lo comentan, todo lleva a implementar varias algunas herramientas de forma enlazada, alguien quien me clasifique el spam que me esta esta llegando(spamassassin) un sistema de verifique la concurrencia de spam de un mismo sitio en base a lo que reporta el assassin y alguien que le indique a posfix que no aceopte correo de un lugar especifico.
Mmmm... conectar el spamassassin con el postfix... no he visto eso.
Otra opción... usar el "greylisting" de Postfix.
Revisare "greylisting" :-)
http://en.wikipedia.org/wiki/Greylisting Greylisting (sometimes spelled graylisting) is a method of defending electronic mail users against e-mail spam. A mail transfer agent using greylisting will "temporarily reject" any email from a sender it does not recognize. If the mail is legitimate, the originating server will most likely try again to send it later (see disadvantages), at which time the destination will accept it. If the mail is from a spammer, it will probably not be retried, and spam sources which re-transmit later are more likely to be listed in DNSBLs and distributed signature systems such as Vipul's Razor. http://en.wikipedia.org/wiki/Sender_Policy_Framework In computing, Sender Policy Framework (SPF) is an extension to the Simple Mail Transfer Protocol (SMTP). SPF allows software to identify and reject forged addresses in the SMTP MAIL FROM (Return-Path), a typical nuisance in e-mail spam. SPF is defined in Experimental RFC 4408. http://www.postfix.org/anvil.8.html The Postfix anvil(8) server maintains statistics about client connection counts or client request rates. This information can be used to defend against clients that hammer a server with either too many simultaneous ses- sions, or with too many successive requests within a con- figurable time interval. This server is designed to run under control by the Postfix master(8) server. http://en.wikipedia.org/wiki/DomainKeys DomainKeys is an e-mail authentication system designed to verify the DNS domain of an e-mail sender and the message integrity. The DomainKeys specification has adopted aspects of Identified Internet Mail to create an enhanced protocol called DomainKeys Identified Mail (DKIM). This merged specification is the basis for an IETF Working Group which guided the specification toward becoming an IETF standard. The DKIM standard was issued in May 2007. The DomainKeys draft was also issued under "historical" status at the same time. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHxevktTMYHG2NR9URAubbAJ4s8VzVPyUkqSp67UDtjHoB2oxnZQCfXR+2 S1c97Nj2biHXAUi7GKHLwAA= =wq8i -----END PGP SIGNATURE-----
participants (3)
-
Camaleón -
Carlos E. R. -
Instituto de Ingenieria Área de Sistemas Unix/Linux