Publicado inicialmente por
jack2
Lo primero es habilitar el greylisting, disminuye inmediatamente los spam que reciben tus usuarios, lo segundo es establecer una efectivas RBL y finalizando spamassassin
Si te refieres al orden en el que *implementar* estos servicios en tu sistema, estoy de acuerdo. Pero si te refieres al orden en que se hagan las comprobaciones una vez tengas todo implementado, difiero. Me explico: los controles "RBL" es mejor hacerlos
antes del greylisting, porque de otro modo la base de datos del greylisting se llena de mierda con tripletas (helo, from, to) que luego vas a rechazar igualmente con el RBL.
Así para aclarar, yo os recomiendo encarecidamente el uso de algo tipo policyd-weight en vez de RBLs directamente. La única diferencia es que el primero realiza un puntaje a partir de múltiples listas y comprobaciones sobre IP, rango, helo, etc (todo cosas que implican muy poca carga para el server). Luego se toma la decisión en base al puntaje, de modo que un solo "fallo" (aparecer en una blacklist por ejemplo) no descalifica automáticamente al emisor. Si usas RBLs directamente eres mucho mas propenso a rechazar servidores que por algún motivo puntual han caído en una blacklist en concreto.
Pues parece una buena combinación para frenar el SPAM, seguramente nos tocará hacer algo así, lo que tengo que buscar de tal manera de que integrarlo en más de 20 Servidores con Cpanel no me sea un año de trabajo.
Creéis que montar un par de servidores de correo Externos y conectarlos al Cpanel puede ser buena idea ?
Totalmente. Y si es en dos proveedores distintos mucho mejor (a veces hay bloqueos extraños entre redes, así que teniendo dos entradas por proveedores distintos te ahorras lidiar con eso).
La implementación no es trivial. No sé cómo lo tiene montado mirill, pero yo (que estoy desviado hacia postfix) lo iría montando de la siguiente forma:
1. Implementación inicial de postfix en un servidor frontend:
1.1 Necesitas una forma de consultar *todos* tus dominios en backend, así como a qué servidor hay que entregar cada uno. Esto lo tienes que hacer por cojones, y debería sincronizarse automáticamente cuando cambie algo en los servidores cpanel. Se vale desde un cron guarro que corra cada 5 minutos hasta usar los hooks de cpanel para controlarlo. Usar ese mapa (dominio -> servidor interno) mediante las variables "relay_domain" y "relay_transport" de postfix.
1.2 Necesitas una forma de verificar qué direcciones son correctas y cuales no. Para empezar, no me rompería la cabeza y activaría la
address verification que incluye postfix. Con esto postfix comprobará las direcciones simulando un envío contra el servidor final donde está el dominio, pero sin entregar nada. Los resultados se cachean.
1.3 Probar que funciona correctamente hasta aquí. Primero manualmente (telnet y metiendo un mail apelo) y luego cambiando el MX de un dominio poco importante o de pruebas que tengas.
2. Implementación de postgrey. Es realmente sencillo y no necessita personalización alguna ni conocer nada de los servidores backend. La única pega es que los primeros envíos de (servidor, from, to) tardaran unos 5-10 minutillos en llegar. A partir de ahí la tripleta queda cacheada y los siguientes envíos llegan instantaneos.
3. Implementación de policiyd-weight. Tampoco necesitas saber nada concreto de los servidores backend. Aunque las comprobaciones las hará *antes* del greylisting, digo de implementarlo después porque tiene un pequeño problema: vas a tener que mantener una whitelist. Me explico, hay unos cuantos admins inútiles por el mundo. Algún día, policyd-weight (o cualquier otro software que rechace por malformaciones de helo, checkeo de RBLs y demás) rechazará un correo porque el servidor remitente está mal configurado. Pero tu cliente querrá ese correo, y te llamará y se quejará de que no recibe de X persona. Puedes responder que el remitente tiene el servidor de correo mal configurado, pero el administrador inútil del remitente responderá que a otra gente si le llegan sus correos. Total, que al final o les metes en whitelist o perderás un montón de tiempo y esfuerzo convenciendo a tu cliente, al remitente, y al admin del remitente que el problema es que ellos tienen el server mal configurado.
4. Implementación de amavisd-new (que incorpora spamassassin). Esto lo dejo para el final porque es lo más peliagudo de todo.
4.1 Primero, te recomiendo que implementes *before queue* filtering (en postfix, que lo configures como smtpd_proxy_filter en vez de content_filter). De este modo, postfix no acepta ni rechaza el correo hasta que amavis da el OK (o REJECT). Esto es muy importante porque de otro modo, cuando el antispam rechaza un correo, deberías rebotarlo para que el remitente sepa que no ha llegado, o guardarlo en una cuarentena donde el cliente pueda descubrirlo. El problema es que la mayoría de spams son de remitentes inválidos y/o falsos, así que la mayoría de veces rebotarías correos a gente que no los ha enviado. Eso se conoce como "backscatter", y haría que tu servidor perdiera reputación rápidamente. Por otro lado, la solución de la cuarentena no es muy buena tampoco, porque es complicado darles acceso a los clientes. Teniendo amavis en modo *before queue*, simplemente puedes rechazar los correos spam y es al servidor remoto a quien le toca notificar a su usuario de lo que ha pasado, quitándote tu el marrón de encima.
4.2 Amavis también necesita conocer la lista de dominios internos, puesto que sólo añade cabeceras y puntúa diferente cuando los mails son "entrantes" a tus sistemas que cuando son "salientes" (porque el antispam se puede usar para correos salientes también, aunque tu no lo hagas). Esto se especifica con "local_domains_maps".
4.3 Finalmente, queda el tema del filtro bayesiano, que es la parte más conocida de cualquier sistema antispam. El problema es que hay que entrenarlo. Idealmente debes preparar alguna forma para que los usuarios puedan entrenarlo (marcando como spam correos que les han entrado y viceversa). Realiza un poco de investigación sobre las posibilidades, pero ya te digo desde ahora que ninguna es sencilla y da para un post entero.
Ale, aquí está mi mini-guía para montaje de un servidor frontend filtrador de spam. Esto no es
para nada completo, pero indica los pasos mínimos para tener un sistema funcional de este tipo. Si hay palabros extraños que no conocéis, buscadlos en google porque se refieren a algo que debéis conocer si os metéis en este tinglado.
Si no estáis de acuerdo en algo o tenéis dudas sobre el por qué de alguna cosa, comentadlo y lo hablamos