Error: cli_hex2str(): Malformed hexstring: This ClamAV version has reached End of Life!

1 comentario

Ayer, 15 de Abril de 2010, terminó el soporte para las versiones de ClamAV inferiores a la 0.95 y por tanto, si es vuestro caso, os aparecerá un mensaje de esta forma:

Error: cli_hex2str(): Malformed hexstring: This ClamAV version has reached End of Life!

He aquí una guía rápida para solucionar el problema (bajo CentOS, para otras distribuciones el proceso es similar):


wget http://downloads.sourceforge.net/clamav/clamav-0.96.tar.gz
tar zxf clamav-0.96.tar.gz
cd clamav-0.96
./configure
make
make install
service clamd restart
cd /usr/sbin
cp clamd clamd.bak
ln -s /usr/local/sbin/clamd clamd
cd /etc
cp clamd.conf clamd.conf.bak
ln -s /etc/clamd.conf clamd.conf
chown qscand:qscand /var/log/clamav/clamd.log
service clamd restart
qmailctl stop
qmailctl start

De esta forma queda solucionado el problema. Espero que os ayude.

Etiquetas:

Desactivar Auto-White-List (AWL) en SpamAssasin

Dejar un comentario

La característica de AWL consiste, de forma resumida, en que los remitentes que han estado alguna vez debajo por el umbral de SPAM van pasando a formar parte de una lista blanca para que la próxima vez sean puntuados como tales (esto en realidad es más complejo pero la idea es esa).

El tema es que este sistema no siempre es efectivo ya que aquellos spammers que utilizan la técnica de email spoofing poniendo de remitente al mismo destinatario consiguen colar bastantes sobre todo si no se hacen comprobaciones de rDNS o no se tienen establecidas políticas de comprobación de los registros SPF para el dominio remitente (que en el caso que hablamos sería el mismo que el destino).

Es por eso que se puede preferir no contar con este sistema y para desactivarlo basta con editar el fichero /etc/mail/spamassassin/v310.pre y comentar o eliminar la siguiente línea:

loadplugin Mail::SpamAssassin::Plugin::AWL

Después de ello hay que reinciar el servicio de spamassassin:

service spamassassin stop
service spamassassin start

Etiquetas: , ,

Efecto 2010 en el SpamAssassin

Dejar un comentario

Me resultó sospechoso que varios correos “no-spam” habían sido marcados esta mañana como spam. Indagué en las cabeceras y vi una regla que puntuaba un 3,2 y que no la había visto nunca aparecer: FH_DATE_PAST_20XX – The date is grossly in the future.

Por el nombrecito de la regla enseguida pensé en un “efecto 2010″ y miré el resto de emails de hoy no marcados como spam y efectivamente aparecían puntuados con esta regla. También los de ayer y hasta el día 1. Los del día 31 no.

La solución es darle un cero a esta regla en el fichero de definición de reglas: /etc/mail/spamassassin/local.cf de esta forma:

score FH_DATE_PAST_20XX 0

y luego reiniciar el spamassassin:

service spamassassin stop
service spamassassin start

Luego buscando información en Google he visto otras formas de solucionarlo.

Etiquetas: , , ,

Utilidad de los registros SPF para evitar SPAM

Dejar un comentario

Un escenario muy común en los sistemas de correo es tener un servidor relay externo que es el que envía realmente los correos.

El spoofing con direcciones de correo ajenas es una técnica muy común entre los spammers

El spoofing con direcciones de correo ajenas es una técnica muy común entre los spammers

Esto a veces puede suponer un problema porque algún sistema receptor interprete que se está haciendo spoofing (falsificación) de nuestras direcciones de correo al comprobar que el que el servidor que envía (relay) no coincide con nuestro dominio.

Para dar crédito a nuestro relay permitiendo que envíe con nuestras direcciones de correo podemos crear un registro SPF (Sender Policy Framework) en nuestro dominio.

Eso se hace añadiendo un registro TXT a la zona DNS de una de las siguientes formas:

Una primera forma es comprobar mediante resolución inversa que la ip desde la que se envía coincide con la del dominio otrodominio.com según el registro PTR del mismo:

@ 10800 IN TXT "v=spf1 ptr:otrodominio.com ~all"

De esta forma nuestro propio dominio le está indicando a los servidores destino que una máquina de otro dominio está autorizada a enviar emails con nuestro dominio como parte derecha de la dirección de correo sin que ello se considere una falsificación.

También podemos utilizar include para delegar la comprobación del registro spf a otro dominio/subdominio:

@ 10800 IN TXT "v=spf1 include:servidorelay.otrodominio.com ~all"

Y también podemos especificar algo como:

@ 10800 IN TXT "v=spf1 mx mx:otrodominio.com ~all"

En este caso le estamos diciendo a los servidores destino que el mx del dominio otrodominio.com está autorizado a enviar emails con nuestro dominio en la parte derecha de las direcciones de correo.

Pero una de las formas más utilizadas es indicar un rango de IP’s autorizadas a realizar estos envíos y esto se haría de la forma:

@ 10800 IN TXT "v=spf1 ip4:213.71.94.72/31 ip4:211.72.94.75/31 ~all"

Para más información: http://es.wikipedia.org/wiki/Sender_Policy_Framework

Etiquetas: , , , , ,