La explicación es fácil: se invoca a procmail con los parámetros ${sender} ${recipient} y luego ejecutar el envío desde el filtro usando “$@” como destino, se pasa entre los argumentos el primer parámetro, el sender, y por tanto también a él le llega copia del mensaje.

Obsesionado, he buscado durante horas y horas la manera de recortar la lista de argumentos desde dentro del procmailrc, pero no he sido capaz, ni dentro de los filtros ni de forma global. Si alguien lo consigue, aunque sea ya por mero desafío, que lo diga heheh

Finalmente, mi amigo fr3nd me ha hablado de Amavisd, y acostumbrado a MIMEDefang no me ha sido difícil de implementar. La verdad es que lleva en producción todo el día y de momento va bastante bien.

Las instrucciones mínimas son las siguientes:

1) Instalar amavisd

2) Editar el fichero de configuración (/etc/amavisd.conf)

3) Modificar el contenido de las siguientes líneas para personalizarlo con el dominio principal de la máquina:

$mydomain = 'somesite.net'
$myhostname = 'boxname.somesite.net'

4) Leer el resto de la configuración para acabar de ajustar los parámetros deseados (tamaño máximo de correos enviados, política por defecto ante virus y spam, sistemas de filtrado antivirus…)

5) Modificar el master.cf para añadir un transport con el filtro:

# Amavisd
smtp-amavis unix -      -       y       -       2  smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o disable_dns_lookups=yes
-o max_use=20

127.0.0.1:10025 inet n  -       n       -       -  smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=reject_unauth_pipelining
-o smtpd_end_of_data_restrictions=
-o mynetworks=127.0.0.0/8
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0

6) Modificar el main.cf para añadir el socket de comunicación con Amavis:

# Amavisd
content_filter = smtp-amavis:[127.0.0.1]:10024

7) Lanzar amavis (avamisd start) y reiniciar postfix

Cabe decir que a mí personalmente no me gusta la idea de eliminar el spam antes de entregarlo, pero es cuestión de ahorro de ancho de banda, uno de los bienes más preciados a nivel mundial, y de los más altamente cotizados en el mercado del hosting español (y nos quejamos de la gasolina…)

EL roblema radica en que, siendo usuarios físicos basta con poner un fichero .procmailrc en cada home, que compruebe si el mensaje está tageado como spam, y entonces lo borre. Ahora bien, siendo usuarios virtuales (mapeados en mysql) la cosa cambia y el fichero de filtrado se lee por defecto de /etc/procmailrc (en FreeBSD como es el caso, /usr/local/etc/procmailrc).

No es que eso suponga un problema, pero el caso es que no he sabido encontrar por ahí la manera de pasar el filtro primero a Spamassassin, luego dejar caer el mensaje en procmail (spamc -e, prueba superada) para que siga la ejecución del transport, y finalmente de procmail pasarlo al binario sendmail de postfix. Este último paso es el que me mataba.

Bien, pues he encontrado la solución, y la dejo aquí por si a alguien le sirve. Seguro que a muchos usuarios de VHCS les será útil :-)

En el transport he incorporado el filtro de procmail en el lugar del binario de sendmail, que invoco después desde el procmailrc. Queda así (master.cf):

spamassassin unix -     n       n       -       -       pipe
user=nobody argv=/usr/local/bin/spamc -f -e
/bin/procmail -m /usr/local/etc/procmailrc ${sender} ${recipient}

Después, el procmailrc que dejo por defecto es este:

FROM="<$1>"

:0
* ^X-Spam-Status: Yes
/dev/null

:0
! -f $FROM "$@"

Recogiendo las direcciones de orígen y destino del entorno, todo el problema se resuelve. Ahora bien… la sintaxis no es muy deducible, y en el site oficial de procmail la documentación no brilla precisamente por su abundancia.

Por otro lado, en los ejemplos de Spamassassin recomiendan filtrar por la cabecera X-Spam-Level, pero eso significa que para aumentar o disminuir el nivel a partir del que hay que borrar, es necesario editar el procmailrc y añadir o quitar asteriscos a la puntuación. Filtrando por status sólo hay que poner la puntuación en el local.cf de Spamassassin y relanzar el demonio.

Y eso es todo :-)

Bueno, en realidad es algo muy muy sencillito de hacer, pero por si acaso a alguien le interesa lo explico aquí.

Primero hay que instalar el software de Bind en la máquina cliente, que tiene las herramientas necesarias para generar las claves de actualización de zonas. Una vez instalado hay que crear una clave para la zona que se quiere actualizar (una para cada zona, eso es obvio):

dnssec-keygen -a HMAC-MD5 -b 128 -n HOST ivanhq

“ivanhq” es el nombre de la clave que yo voy a crear, lo llamo así para saber qué zona actualiza, pero podría llamarse “dnskey” sin ningún problema. Esto genera dos ficheros, un .private y un .key, ni que decir tiene cuál es el público y cual el privado… el público servirá para ponerlo en la configuración del servidor, el privado no debe moverse del cliente.

Es conveniente guardar los ficheros de las claves en algún directorio que guarde relación con Bind. Yo los he puesto aquí:

mkdir /var/bind/tsig
mv Kivanhq* /var/bind/tsig/
chown -R 0066 /var/bind/tsig

Después debe modificarse el fichero de configuración de named en el servidor (named.conf). Debe incorporarse la key pública del cliente, para decirle al servidor que acepte sus updates.

key ivanhq {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
secret "agCr8JkmLKsgFuSw==";
};

El contenido de “secret” es la clave pública, que está contenida en el fichero .key y se puede ver con un simple “cat”. Esto se puede poner al principio del archivo, antes de la declaración de zonas.

Después debe modificarse la declaración de la zona que se va a actualizar, para permitir la actualización desde la “key ivanhq”:

zone "ivanhq.net" {
type master;
allow-update{
key ivanhq;
};
file "/etc/namedb/ivanhq.net.db";
};

Una vez hecho esto debe reiniciarse el servidor named, y ya se puede actualizar el nombre desde el cliente, por línea de comandos:

nsupdate -k /var/bind/tsig/Kivanhq.+157+25718.key

Esto lee de la entrada de consola, y ahora debemos especificar lo que debe hacer en la zona:

update delete micasa.ivanhq.net
update add micasa.ivanhq.net 60 IN A 111.222.333.444

Es necesario pulsar Enter 2 veces al final para que el servidor reciba la señal de EOF y haga efectivos los cambios en la zona. La dirección IP dinámica va en el lugar de “111.222.333.444″. Y ya está.

Yo he hecho un pequeño script que saca mi dirección IP pública, y lo ejecuto desde el cron una vez por minuto. También he encontrado problemas en la actualización si el cliente y el servidor están descompasados en tiempo… de modo que es bueno pensar en sincronizar las máquinas con ntp contra algún servidor de time (hora.rediris.es, por ejemplo).

EDICIÓN: vaya… este post es prácticamente un duplicado del que ya escribí en su día explicando cómo hacerlo en FreeBSD. No me había dado cuenta :(