Postfix Spam Filter · 13 min read · Nov 14, 2025
Filtro de Spam de Postfix usando Ubuntu Dapper, MailScanner, SpamAssassin, Razor, Pyzor, DCC y ClamAV - Página 3
2.3 Configuraciones Anti-Spam de Postfix
Notas preliminares:
Cuando un cliente (una computadora que intenta enviarnos correo) se conecta a Postfix y comienza una sesión de comunicación, Postfix registra información sobre esa sesión. Antes del punto en el que Postfix acepta correo de esa sesión para su entrega, tenemos la opción de evaluar la sesión y rechazar el correo estableciendo algunas restricciones en main.cf. Este enlace ilustra lo que sucede durante una sesión SMTP típica: http://helpdesk.islandnet.com/pep/smtp.php. Las restricciones a continuación ayudan a evitar algo de spam y prevenir que nuestro sistema se convierta en un relay abierto. Estas restricciones hacen que algunos correos sean rechazados por Postfix justo en la “puerta principal”. Esto ahorrará recursos del sistema porque el correo no ingresará a nuestro sistema y, por lo tanto, no será escaneado por MailScanner (y posteriormente por SpamAssassin). Esto es bueno y malo. Ahorra recursos del sistema, pero también no te permite ver el correo rechazado. Todo lo que verás es una o dos entradas de registro de Postfix diciendo esencialmente “Hola, un servidor de correo llamado ‘xxxxxxxx’ en la dirección IP X.X.X.X intentó enviar algo de correo, pero rompió la regla XYZ, así que lo rechacé”. Ahora, esto podría haber sido spam (los spammers a menudo no siguen intencionalmente los RFC para lograr sus objetivos), pero si era un correo “legítimo”, digamos de un cliente cuyo departamento de TI simplemente ha configurado incorrectamente su servidor de correo (sucede), podrías tener algunas plumas revueltas que manejar.
Si deseas permitir que TODO el correo dirigido a nosotros entre por la puerta principal, y por lo tanto permitir que MailScanner/SpamAssassin maneje todo el control de spam dentro del sistema, necesitarías modificar un par de configuraciones a continuación. Personalmente, encuentro que una combinación de control anti-spam de Postfix y SpamAssassin es la mejor. Al menos necesitas asegurarte de no deshabilitar el control anti-relay predeterminado incorporado en Postfix ( smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination).
La configuración a continuación es en realidad muy conservadora, permitiendo que la mayoría de los correos electrónicos entren por la puerta principal para que MailScanner y SpamAssassin tengan su oportunidad. Para mí, (de manera segura) rechaza aproximadamente el 35% del correo destinado a mis usuarios, así que creo que estas configuraciones son bastante valiosas. Recomiendo este enfoque para comenzar. Agregar restricciones adicionales aumentará la probabilidad de rechazar correos electrónicos válidos de computadoras mal configuradas. Si decides agregar/eliminar permisos/restricciones en el futuro, hazlo uno a la vez y date tiempo suficiente para evaluar el efecto del cambio. Sugiero encarecidamente que realmente tengas un buen entendimiento de cómo funcionan estas restricciones antes de hacer cambios en las entradas a continuación. Entre otras cosas, equivocarse en esto podría rechazar correo legítimo y/o causar que nos convirtamos en un relay abierto. Ten en cuenta que las restricciones no siempre restringen, algunas también permiten.
Si deseas obtener una mejor comprensión de estas configuraciones, buenos recursos son http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt, http://www.postfix.org/SMTPD_ACCESS_README.html, http://www.securitysage.com/antispam/, el algo desactualizado (2001) http://www.mengwong.com/misc/postfix-uce-guide.txt, y este excelente libro. Notarás que solo uso un par de las mismas configuraciones que estas, así que esta configuración no es en absoluto tan restrictiva. Ten en cuenta que SpamAssassin y MailScanner entrarán en la imagen un poco más adelante, y nos proporcionarán opciones mucho más flexibles y configurables para reconocer y manipular spam.
2.3.1 smtpd_helo_required
Haz que cualquier servidor de correo conectado realice un “apretón de manos” smtp adecuado y anuncie su nombre. Los RFC de Internet requieren esto, así que nosotros también lo hacemos.
postconf -e "smtpd_helo_required = yes"Prefacio: Las etapas de restricción de Postfix son las siguientes, y se procesan en el siguiente orden:
smtpd_client_restrictions
smtpd_helo_restrictions
smtpd_sender_restrictions
smtpd_recipient_restrictions
smtpd_data_restrictionsSolo vamos a colocar entradas en las últimas tres etapas de restricción. Las etapas de restricción se procesan en este orden independientemente del orden listado en main.cf.
2.3.2 smtpd_sender_restrictions
Esta etapa de restricción restringe qué direcciones de remitente acepta este sistema en los comandos MAIL FROM: (el remitente del sobre). Colocaremos tres pruebas (restricciones) en esta etapa de restricción.
Una etapa de restricción contiene una lista de restricciones (pruebas). Típicamente, las pruebas se evalúan como DUNNO, REJECT o OK. DUNNO significa “No sé qué hacer, deja que la siguiente prueba decida”. REJECT simplemente rechaza el correo. OK significa que no se realizan más pruebas en esta etapa de restricción, las pruebas continúan con la siguiente etapa (si la hay). Las pruebas de tipo Reject* típicamente se evalúan como REJECT o DUNNO. Las pruebas de tipo Permit típicamente se evalúan como OK o DUNNO, y las pruebas de tipo check__access pueden realizar una variedad de acciones. La ilustración muestra la lógica básica.
Sesión SMTP
|
V
etapa de restricción-------------
prueba ---------------REJECT->
| \
| DUNNO
| \
| V
| siguiente prueba------REJECT->
| | \
OK OK DUNNO
| | \
| | V
V V
siguiente etapa de restricción------->2.3.2.1 check_sender_access
Ver http://www.postfix.org/access.5.html. Aquí pedimos a Postfix que compare el remitente del sobre con las entradas en una base de datos /etc/postfix/sender_access y actúe sobre esas entradas si se encuentra una coincidencia. También definimos qué acción se toma allí (OK, DUNNO, REJECT, etc.) en una base de datos de remitente por remitente. Si el remitente no está listado en el archivo, la prueba se evalúa como DUNNO, y se realiza la siguiente prueba. Proporcionaré ejemplos un poco más adelante. Un uso de este archivo es colocar una lista de remitentes (direcciones de correo electrónico, dominios, direcciones de red, etc.) de los cuales no deseamos recibir correo (bloquearlos). También tendremos la capacidad de bloquear remitentes en MailScanner y SpamAssassin, pero ahorrará recursos si los bloqueamos aquí. También utilizaremos este archivo para permitir que remitentes específicos omitan las siguientes dos pruebas en esta etapa de restricción. Si les damos un OK aquí, no se realizan más pruebas en esta etapa de restricción, las pruebas continúan en la siguiente etapa de restricción ( smtpd_recipient_restrictions). Ten en cuenta que si colocáramos esta configuración en la etapa de restricción smtpd_recipient_restrictions antes de la prueba reject_unauth_destination, y le diéramos a alguien el OK allí, la prueba reject_unauth_destination ubicada allí sería omitida. Esto sería malo porque cualquiera a quien le diéramos el OK podría usar nuestro servidor como un relay abierto. Las restricciones de acceso se evalúan en el mismo orden en que las listamos, y si se encuentra una coincidencia influirá en cómo (si) se evalúan más restricciones.
2.3.2.2 reject_non_fqdn_sender
Rechaza cuando la dirección de correo del remitente del sobre no está en el formato adecuado. Recuerda, el “remitente del sobre” es lo que el servidor de correo emisor da en la línea “MAIL FROM:” durante la sesión SMTP, no la línea de encabezado “From:”. “Joe” no está permitido para enviarnos correo (porque no podemos responder a “Joe”), pero “[email protected]” es al menos una dirección de correo electrónico. Si el remitente no es rechazado en este punto, esta prueba se evalúa como “DUNNO”.
2.3.2.3 reject_unknown_sender_domain
Rechaza cuando la parte del dominio del remitente del sobre no tiene ningún registro DNS “A” o “MX”. Esta configuración rechaza aproximadamente el 35% del correo que llega a mi servidor de correo. Es común que los spammers usen un nombre de dominio falso para no tener que lidiar con la reacción de correos rechazados. También es importante para nosotros no llenar nuestra cola con avisos de rebote que nunca se pueden entregar debido al hecho de que el dominio del remitente ni siquiera existe. Si el dominio del remitente tiene un registro “A” o “MX”, esta prueba también se evaluará como “DUNNO”. En ocasiones, verás en un informe que alguien de quien deseas recibir correo ha sido rechazado por esta configuración. Una posible causa de esto es cuando los remitentes legítimos utilizan deliberadamente nombres de dominio falsos para que no les respondas. Aquí es donde la lista de acceso de remitentes resulta útil. Puedes darles un OK allí, y esta prueba será omitida.
Ahora para implementar estas tres restricciones:
postconf -e "smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/sender_access, reject_non_fqdn_sender, reject_unknown_sender_domain"2.3.3 smtpd_recipient_restrictions
Las restricciones de acceso que el servidor SMTP de Postfix aplica en el contexto del comando RCPT TO:. Esto se refiere al “destinatario del sobre” que es lo que el cliente dio en la línea “RCPT TO:” durante la sesión SMTP, no la línea de encabezado “To:”. smtpdrecipient_restrictions es otra etapa de restricción que contiene una lista de restricciones específicas. Otras etapas de restricción que se evalúan antes de smtpd_recipient_restrictions son smtpd_client_restrictions, smtpd_helo_restrictions y smtpd_sender_restrictions (en ese orden). Las restricciones que normalmente irían en estas etapas de restricción anteriores pueden alternativamente colocarse en smtpd_recipient_restrictions. Por lo tanto, algunas personas prefieren colocar todas las smtpd*_restrictions que normalmente irían en etapas de restricción anteriores en smtpd_recipient_restrictions (en el orden adecuado) y dejar las etapas anteriores sin configurar (vacías). En nuestro caso, es más seguro usar smtpd_sender_restrictions y smtpd_recipient_restrictions. Veamos esas restricciones específicas (pruebas) que colocamos en smtpd_recipient_restrictions:
2.3.3.1 permit_mynetworks
Permite que las máquinas listadas en “mynetworks” omitan el resto de las pruebas en esta etapa de restricción (permit = OK). En otras palabras, sale de esta etapa y se prueba en la siguiente etapa (smtpd_data_restrictions). Debido a que permit_mynetworks se coloca antes de reject_unauth_destination, esto significa que las máquinas en $mynetworks pueden reenviar correo a cualquier dominio. Sin esto, solo podríamos enviar correo a nuestros propios dominios. Si la dirección IP del remitente no está listada en $mynetworks, la prueba se evalúa como “DUNNO” y continúa a la siguiente prueba (reject_unauth_destination).
2.3.3.2 reject_unauth_destination
Esto, junto con permit_mynetworks, se utiliza para el control de reenvío. Esta configuración, en esencia, significa que el correo destinado a cualquier dominio para el cual no hemos configurado nuestra máquina para aceptar correo será rechazado. En nuestro caso, Postfix utilizará la configuración (o tabla) relay_domains que configuramos anteriormente para determinar cuáles son esos dominios. Ver http://www.postfix.org/postconf.5.html#reject_unauth_destination para más detalles. Si el dominio está listado en relay_domains, esta prueba se evalúa como “DUNNO” y la sesión se permite continuar a la siguiente prueba (si la hay). Al igual que “mynetworks”, esta configuración es extremadamente crítica. Al colocar permit_mynetworks directamente delante de reject_unauth_destination, nos aseguramos de que podemos enviar correo a dominios que no sean el nuestro, pero solo aceptaremos correo dirigido a nosotros desde computadoras fuera de nuestra red, así que permit_mynetworks y reject_unauth_destination trabajan en equipo.
2.3.3.3 reject_unauth_pipelining
Rechaza a los remitentes masivos que intentan usar pipelining para acelerar la entrega, sin verificar si se admite primero (no RFC, común entre los spammers).
Ahora para implementar estas tres restricciones:
postconf -e "smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unauth_pipelining"2.3.4 smtpd_data_restrictions
Restricciones de acceso opcionales que el servidor SMTP de Postfix aplica en el contexto del comando SMTP DATA:. Al igual que smtpd_recipient_restrictions, esta es una etapa de restricción.
2.3.4.1 reject_unauth_pipelining
Repito esta configuración en smtpd_data_restrictions ya que no siempre es efectiva cuando se coloca en smtpd_recipient_restrictions. La incluyo en smtpd_recipient_restrictions ya que me gusta colocarla antes de cualquier servidor de políticas. Ten en cuenta que solo hay un par de restricciones que hacen buen uso de smtpd_data_restrictions.
postconf -e "smtpd_data_restrictions = reject_unauth_pipelining"2.3.5 Archivos de control de filtrado de contenido de Postfix:
http://www.postfix.org/header_checks.5.html - /etc/postfix/header_checks y /etc/postfix/body_checks
Estos archivos enumerarán ciertas “cadenas” de texto y le dirán a Postfix qué hacer con el correo si encuentra estas cadenas en los encabezados de correo o en el cuerpo del mensaje. Los archivos de muestra ya están creados para nosotros, con comentarios que explican qué poner en ellos. Puedes editarlos a tu gusto. Ten en cuenta que estos archivos requieren el uso de “formato de expresión regular”. “regexp” es algo que querrás aprender para vivir en el mundo *nix. Consigue un libro o investiga sobre ello en la red en algún momento. Para un ejemplo de un archivo header_checks elaborado de alguien con actitud, echa un vistazo a http://www.geekounet.org/filters/header_checks. Pero no sigas esto ciegamente, ¡es solo un ejemplo! Aquí hay un ejemplo de un archivo body_checks: http://www.securitysage.com/files/body_checks. Valdría la pena que revisaras http://www.securitysage.com/guides/postfix_uce.html cuando tengas un momento de ocio. Específicamente http://www.securitysage.com/antispam/hedchek.html y http://www.securitysage.com/antispam/bodchek.html. Recomiendo no hacer un gran número de cambios en ninguna parte de Postfix sin darte tiempo suficiente para evaluar los efectos. Como una tortuga, ve despacio, vive mucho.
2.3.5.1 header_checks & body_checks
Vamos a poner estos dos en main.cf. header_checks es requerido porque nos permite mantener todo el correo electrónico entrante para que MailScanner haga su trabajo:
postconf -e "header_checks = pcre:/etc/postfix/header_checks"
postconf -e "body_checks = pcre:/etc/postfix/body_checks"Edita header_checks:
vi /etc/postfix/header_checksAgrega esta línea al archivo header_checks, sin ella MailScanner no funcionará:
/^Received:/ HOLDTen en cuenta que no tenemos que postmapear tablas de tipo pcre. Permanecen como texto plano y Postfix las utiliza “tal cual”.
También podrías configurar mime_header_checks y nested_header_checks junto con header_checks y body_checks. Si te vuelves demasiado creativo con el filtrado de contenido en Postfix (usando header_checks y body_checks), puede tener un impacto significativo en el rendimiento.
2.3.5.2 /etc/postfix/sender_access http://www.postfix.org/access.5.html
Hemos referenciado este archivo en smtpd_sender_restrictions. Usamos este archivo para verificar el remitente justo en la puerta principal. En este archivo, enumeraremos ciertos remitentes/dominios/rangos de direcciones IP para un manejo especial. A continuación se presentan ejemplos falsos, crea los tuyos como lo consideres adecuado. Por favor, lee /etc/postfix/sender_access para más información. Aunque podrías usar este archivo para varios propósitos, considerando la forma en que lo hemos configurado en smtpd_sender_restrictions, sugiero usarlo para bloquear remitentes o permitir que ciertos remitentes omitan las pruebas restantes en smtpd_sender_restrictions.
vi /etc/postfix/sender_access#Ejemplo de archivo de mapa de acceso de remitentes
[email protected] 550 No MLM gracias
allspam.tld 550 El spam no es aceptado aquí
badguy.net REJECT
[email protected] REJECT
newsletter-favorite-lug.org OK
my-really-l337-test-domain.com OKDado que esta es una tabla hash, necesitas postmapearla como de costumbre:
postmap /etc/postfix/sender_access2.3.6 Última mirada a la instalación de Postfix
Revisa los cambios:
less /etc/postfix/main.cfVerifica el contenido del archivo en busca de errores y repara si es necesario. Inicia Postfix:
postfix startVerifica que Postfix responda:
telnet 127.0.0.1 25Deberías ver:
220 [tuFQDNaquí] ESMTP Postfix (Ubuntu)presiona [enter] un par de veces; luego escribe quit para salir.
Si no responde de esta manera, abre otra ventana de terminal y detén Postfix postfix stop. Asegúrate de haber ejecutado newaliases y todos los comandos postmap anteriores. Verifica todas las configuraciones en main.cf y master.cf. Hay un buen documento sobre la solución de problemas de Postfix en http://www.postfix-book.com/debugging.html pero ten en cuenta que nuestro sistema no está listo para reenviar correo en este momento (terminará en la cola).
Cada vez que realices cambios en master.cf o main.cf o en tablas de datos, la mayoría (no todas) de las veces, es necesario que recargues Postfix con:
postfix reloadAhora que tenemos una configuración básica de Postfix, http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall y http://www.postfix.org/BASIC_CONFIGURATION_README.html son buenos lugares para obtener una mejor comprensión de algunas de las configuraciones que utilizamos y en este punto estos READMEs tendrán más sentido.
Por defecto, nuestro Postfix se ejecuta en chroot. Si no sabes lo que eso significa, no importará mucho en este momento. Te dejo investigar lo que significa chroot en algún momento posterior. Algunos de los archivos del sistema que Postfix necesita para funcionar correctamente fueron copiados a la cárcel chroot de Postfix (/var/spool/postfix) durante la instalación. En ocasiones, los archivos originales se modificarán, y Postfix se quejará de que la copia que tiene no es la misma que la original. Cuando esto sucede, puedes copiar manualmente el/los archivo(s) de los que Postfix se ha quejado a la cárcel chroot, o simplemente podemos ejecutar un script que se proporciona con el código fuente de Postfix (llamado LINUX2) que volverá a copiar todos los archivos que Postfix necesita a donde los necesita.
cd /usr/local/src/postfix-2.3.3/examples/chroot-setup
postfix start
chmod +x LINUX2
cp LINUX2 /usr/bin
LINUX2
cd
postfix checkEsto hace que el script LINUX2 sea ejecutable, lo copia a un directorio en nuestro camino, y luego lo ejecuta. LINUX2 generalmente resolverá cualquier problema o inconveniente con Postfix si ves algún error en los registros con Postfix accediendo a archivos de configuración o directorios.
Recibe nuevas publicaciones en tu bandeja de entrada.
No spam. Cancela la suscripción en cualquier momento.