Hola lista, alguien me podría facilitar archivos de configuración en los que tengan funcionando el Sendmail con el Spamassassin y Procmail. Los necesitaría como guía para ver si puedo hacer funcionar el Sendmail con el Spamassin y el Procmail. El sendmail ya lo tengo funcionando, me falta que se pueda hacer filtrado de los spams y reenvío hacia otra carpeta con el procmail. Desde ya muchas gracias por su colaboración.
El 2005-05-16 a las 11:22 -0500, Fabián Calle escribió:
Hola lista, alguien me podría facilitar archivos de configuración en los que tengan funcionando el Sendmail con el Spamassassin y Procmail. Los necesitaría como guía para ver si puedo hacer funcionar el Sendmail con el Spamassin y el Procmail.
El sendmail ya lo tengo funcionando, me falta que se pueda hacer filtrado de los spams y reenvío hacia otra carpeta con el procmail.
Cuando yo usaba el sendmail, que lo ajustaba el Yast, el procmail estaba incluido: en cuanto definías un .procmailrc en tu $HOME ya tiraba. El siguiente paso, poner el sendmail, es muy sencillo, y lo tengo así incluso ahora con el postfix: :0fw | /usr/bin/spamc :0 a * ^X-Spam-Status: Yes $HOME/Mail/in_spam Sólo tienes que habilitar el servicio spamd durante el arranque. La carpeta de spam puede ser esa o la que quieras. También puedes hacer otra regla que si el nivel de spam es más de doce, que lo borre directamente. -- Saludos Carlos Robinson
On Mon, 16 May 2005 11:22:32 -0500
Fabián Calle
El 2005-05-18 a las 09:21 +0200, Josep M. Queralt escribió:
Para hacer trabajar "spamassassin" junto a "procmail" es necesario poner las siguientes lineas en la cabecera del fichero ".procmailrc" (el fichero de reglas de procmail)
:0fw | /usr/bin/spamassassin
(si se usa webmin esas dos líneas ya se añaden automáticamente a la cabecera de ".procmailrc"
Pues muy mal por webmin, porque esa manera es muy pesada, tiene que cargar el interprete perl para cada uno de los mensajes. Substituye la segunda linea por: | /usr/bin/spamc
#Rechazar correo con mensaje #El fichero de bloqueo reject.lock en dir raiz del ususario #rejected.txt contiene el texto del mensaje de devolución #X-Loop se usa para que no entre en un bucle infinito
Rechazar correo cuando se sospecha que pueda ser spam puede ser un error grave: estás confirmando al posible spammer que tu dirección es correcta y recibe.
#Anti Spam por direcciones
:0: * (^To:.*info@dominio.com|^To:.*contact@dominio.com|^To:.*sales@dominio.com) /dev/null
Esto es mucho más eficaz ponerlo en un filtro del servidor smtp. En el caso del postfix, en el fichero access, en el caso del sendmail, no recuerdo. Haciendolo antes del "data" el correo no llega ni a entrar.
#Anti SPAM por temas # :0B: examinar solo el cuerpo del mensaje
Arriesgado, en mi opnión - aparte de que los spammers cometen faltas de ortografía a propósito para evadir esos tests simples. Prefiero dejárselo al SA.
#Anti SPAM por host
:0: * 1^0 ? formail -x"Received:" | egrep -is "dialsprint\.net"
Mmmm... y si recibes un correo legítimo que ha pasado por alguno de esos servidores, pues te lo cargas también...
# Anti VIRUS por remitente o tema
:0: * ^From:.*support@microsoft.com /dev/null
Lo mismo, en el postfix o sendmail es más rápido.
:0D: * ^Subject:.*Re: hi /dev/null
Se nota que no tienes amigotes que te saludan así :-p
# Anti Virus por ficheros adjuntos # "rejected.txt" contiene el mensaje de devolución #X-Loop impide el bucle infinito #noexe.lock es el fichero de bloqueo en la raiz del usuario
:0B * ^Content-.*name=.*\.(exe|pif|bat|xls|scr)
Eso hay una regla muy buena para el header_check del postfix. Más rápido. El sendmail debe tener equivalentes. Pero has demostrado que hay muchas maneras de hacer las cosas en Linux :-) -- Saludos Carlos Robinson
On Wed, 18 May 2005 13:19:44 +0200 (CEST)
"Carlos E. R."
El 2005-05-18 a las 16:04 +0200, Josep M. Queralt escribió:
robin1.listas> | /usr/bin/spamc
Dependerá del nombre que tenga SpamAssassin en el sistema.
No. Son programas distintos. spamc es un programita pequeño en C que dialoga con el demonio spamd, el cual se encarga de precargar el spamassassin con antelación (y descargarlo cada n veces). Lo que se evita con eso es tener que cargar el spamassassin completo, junto con el interprete perl, cada vez que el procmail interpreta la linea: | /usr/bin/spamassassin y ganar considerablemente en velocidad. Esto es de las pocas cosas que explica su documentación: | SpamAssassin Daemon | =================== | | The purpose of this program is to provide a daemonized version of the | spamassassin executable. The goal is improving throughput performance | for automated mail checking. This document is a brief synopsis of how | spamc/spamd work, and how to use them effectively.
robin1.listas> Rechazar correo cuando se sospecha que pueda ser spam puede ser un error robin1.listas> grave: estás confirmando al posible spammer que tu dirección es correcta y robin1.listas> recibe.
En algún lugar de mi mensaje ponía que ese fichero ".procmailrc" era solo un ejemplo.
Tienes razón en que rechazar es confirmar en el caso del "spam", sin embargo en este ejemplo lo que se hace es rechazar correo con un texto de respuesta. No es para las clasificaciones de "spam" pero puede ser util para decirle a alguien que deje de escribir porque sus correos van directos a la basura.
Si, eso puede ser. Pero hay queal menos pasar el filtro SA antes.
robin1.listas> > #Anti Spam por direcciones robin1.listas> > robin1.listas> > :0: robin1.listas> > * (^To:.*info@dominio.com|^To:.*contact@dominio.com|^To:.*sales@dominio.com) robin1.listas> > /dev/null robin1.listas> robin1.listas> Esto es mucho más eficaz ponerlo en un filtro del servidor smtp. En el robin1.listas> caso del postfix, en el fichero access, en el caso del sendmail, no robin1.listas> recuerdo. Haciendolo antes del "data" el correo no llega ni a entrar.
Hasta donde yo llego, SMTP es el correo saliente de un sistema, el que un usuario envía. PROCMAIL se utiliza para el correo ENTRANTE, es decir para el que el usuario recibe.
Correcto... a medias. Pero se te olvida un detalle: al recoger el correo con fetchmail (que es lo habitual) este le pasa el correo recogido al sendmail/postfix para que lo distribuya a donde sea. Es el servidor SMTP el que llama al procmail - a no ser que se haya configurado el fetchmail para que se lo salte y enganche directo al procmail. Por tanto, los filtros en el postfix (o sendmail) también actúan en el correo entrante recogido desde cuentas pop3/imap. Por otra parte, en una maquina con nombre verdadero en internet (IP fija), el correo entra habitualmente directo al servidor SMTP. El servidor SMTP sirve tanto para correo entrante como saliente, aunque un usuario simple lo use sólo como saliente.
Precisamente en el .prcmailrc de ejemplo, la primera regla que se estableció fue que se ejecutara SpamAssassin, por lo que todas las demás solo se aplican en función del resultado de la primera.
Es verdad, pero estaba antes de las variables, lo cual es muy raro e hizo que no lo viera: :0fw | /usr/bin/spamassassin MAILDIR=$HOME/ PATH=/usr/bin:/bin LOGFILE=$HOME/procmail.log VERBOSE=no COMSAT=no SENDMAIL=/usr/sbin/sendmail Lo habitual es hacerlo en un par de reglas en cascada (y justo detrás de las variables): :0fw | /usr/bin/spamc :0 a * ^X-Spam-Status: Yes $HOME/Mail/in_spam o /dev/null, pero yo no lo aconsejo: entre otras cosas, el spam recibido sirve para entrenar el filtro bayesiano - aparte de que el SA se puede equivocar. En todo caso, pueden archivarse los que tengan un valor entre 5 y 12 (pe), y tirarlos por encima de 12.
robin1.listas> > #Anti SPAM por host robin1.listas> > robin1.listas> > :0: robin1.listas> > * 1^0 ? formail -x"Received:" | egrep -is "dialsprint\.net" robin1.listas> robin1.listas> Mmmm... y si recibes un correo legítimo que ha pasado por alguno de esos robin1.listas> servidores, pues te lo cargas también...
Si, si alguno de los "Received" pasa por algun host spamer acaba en la papelera.
Pero es que alguno de esos hosts no son puramente spammers, yo he visto direcciones de esas en la lista de SuSE inglesa.
robin1.listas> > # Anti VIRUS por remitente o tema robin1.listas> > robin1.listas> > :0: robin1.listas> > * ^From:.*support@microsoft.com robin1.listas> > /dev/null robin1.listas> robin1.listas> Lo mismo, en el postfix o sendmail es más rápido.
Hablamos de correo entrante, no del saliente
Correcto, entrante. Me remito a lo que dije antes.
robin1.listas> > :0D: robin1.listas> > * ^Subject:.*Re: hi robin1.listas> > /dev/null robin1.listas> robin1.listas> Se nota que no tienes amigotes que te saludan así :-p robin1.listas>
Si, muchos, la mayoría son de la familia "Sober" y "Netsky" :-)
La mayoría :-) Pero tengo alguno de carne y hueso que lo ha hecho alguna vez.
P.D. Al igual que con spamassassin se puede establecer el filtro para para dar puntuaciones y solo enviar a /dev/null cuando se sobrepasa una determinada puntuación.
Francamente, el SA es menos trabajo que todo eso.
P.D. 2 No solo puede enviarse a /dev/null, ya que también puede enviarse el mensaje que cumpla determinada condición a la carpeta o buzón de correo que se desee.
Que combiene hacerlo, para entrenar al bayes, y por si pone como spammer a alguno que no lo es. -- Saludos Carlos Robinson
On Wed, 18 May 2005 19:55:43 +0200 (CEST)
"Carlos E. R."
participants (3)
-
Carlos E. R. -
Fabián Calle -
Josep M. Queralt