El el trabajo usamos ISPConfig como gestor de paneles de alojamiento. En los servidores de nuestros clientes lo instalamos también, porque por el momento es la opción libre más completa y funcional a nivel de integración de servicios.
Todo funciona perfecto, salvo que hoy un cliente me ha reportado un fallo bastante importante: los emails enviados entre usuarios de un mismo dominio llegaban marcados como SPAM.
El problema…
Al hacer las pruebas, he comprobado que efectivamente el report de SpamAssassin señalaba lo siguiente:
Content analysis details: (6.4 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.5 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
[87.221.36.208 listed in zen.spamhaus.org]
1.6 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address
[87.221.36.208 listed in dnsbl.sorbs.net]
3.2 HELO_LH_HOME HELO_LH_HOME
0.1 RDNS_DYNAMIC Delivered to trusted network by host with
dynamic-looking rDNS
1.0 AWL AWL: From: address is in the auto white-list
En el ejemplo se ve como SpamAssassin busca la IP de mi despacho (dinámica) en varias blacklists. Es lo que no alcanzo a entender… el relay se hace a través de un MTA autenticado, ¿por qué SA busca la IP de orígen? ¿No deberia basarse en la IP del MTA?
En las cabeceras del mensaje se lee lo siguiente
Received: from wrk1.sdv.home (wrk1.sdv.home [127.0.0.1])
by wrk1.sdv.home (8.14.0/8.14.0) with ESMTP id m32BTkIg029558
for ; Wed, 2 Apr 2008 13:29:54 +0200
Received: from mail.sysdivision.com [64.22.103.200]
by wrk1.sdv.home with POP3 (fetchmail-6.3.8)
for (single-drop); Wed, 02 Apr 2008 13:29:54 +0200 (CEST)
Received: from localhost by sdv1.sysdivision.com
with SpamAssassin (version 3.2.1);
Wed, 02 Apr 2008 13:29:18 +0200
La primera línea responde a mi workstation y evidentemente apunta a localhost porque así lo defino en mi /etc/hosts.
La siguiente línea es la del MTA una vez que recibe el mensaje, y la última es el servidor entregando el mensaje al agente de delivery. En este caso Postfix lo filtra con procmail, quien finalmente lo mete en el buzón (Maildir).
Lo que no entiendo es: si el relay está autenticado, SpamAssassin debería fijarse en la dirección del MTA que procesa el mensaje, no en el MUA que lo escribe y lo envía.
La solución…
Bueno, en cualquier caso es evidente que cmo mi despacho tiene una IP dinámica cualquier RBL lo marcará como Spam. Así, el truco está en deshabilitar la consulta a RBL’s desde SpamAssassin (ya la tengo hecha directamente desde Postfix).
En el caso de ISPConfig se debe configurar en el siguiente fichero (parto en dos líneas por problema de espacio):
/home/admispconfig/ispconfig/tools/
/spamassassin/etc/mail/spamassassin/local.cf
Añadir al final la siguiente línea
skip_rbl_checks 1
Entonces queda otro problema, éste último más raro si cabe: SpamAssasin sigue marcando los mensajes como Spam. En este caso el report ya no incluye los checks de RBL:
Content analysis details: (4.3 points, 3.5 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.7 HELO_LH_HOME HELO_LH_HOME
0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60%
[score: 0.4950]
0.1 RDNS_DYNAMIC Delivered to trusted network by host with
dynamic-looking rDNS
0.4 AWL AWL: From: address is in the auto white-list
EL test HELO_LH_HOME, para el que existe muy poquita documentación, busca en la cabecera el orígen del mensaje, para saber si proviene de una red trusted o no. En la configuración de Postfix pueden establecerse las redes trusted, pero claro no voy a confiar en direcciones externas a mi red local, eso sería tanto como hacer un relay promiscuo.
Bien pues eso se arregla en Postfix, haciendo que añada una línea a las cabeceras, diciendo que el relay está autenticado. De esa forma SpamAssassin no hará caso del untrusted relay.
Añadir la siguiente línea al fichero /etc/postfix/main.cf:
smtpd_sasl_authenticated_header = yes
Después de reiniciar Postfix, todo irá bien 
NOTA: Este proceso no soluciona el mismo problema cuando se usa TLS. Para ese caso, echar un ojo a este patch, que parece que arregla la papeleta pero no es demasiado recomendable porque destruye el histórico de las cabeceras Received:
Espero con esto salvar alguna vida (yo casi la pierdo tirándome a la vía del tren :-D)
Serveralias en lighttpd
Archivado en Networking, Linux | 
No hay comentarios » 
| 
Hace cosa de 1 año empecé a leer por Internet para comprarme un iphone. Decían que para después de verano de 2007 ya estaría en España (y con UMTS…), pero llegados al 2008 sigue sin aparecer.
Esto es una vergüenza. Y que nadie diga nada es todavía más vergonzoso si cabe.