Construyendo un Anti-SPAM Gateway. Parte 2 (Buenas prácticas)
En la primera parte se explicaba como instalar paso a paso nuestro Anti-SPAM Gateway con Postfix. En esta segunda parte vamos a ver como mejorar el comportamiento de nuestro servidor con unas buenas prácticas, lo que permitirá controlar el flujo de correos que pasarán por nuestro Gateway.

Estas buenas prácticas se basan en varios parámetros que se declaran en el fichero main.cf, permitiendo controlar errores entra la comunicación cliente -> servidor. Los pasos que vamos a seguir durante este artículo son los siguientes:
- Agregar parámetros en main.cf
- Probar parámetros.
Agregar parámetros en main.cf
Con los parámetros que vamos a configurar vamos a intentar que nuestro Anti-SPAM Gateway se adapte a las diferentes RFCs que normalizan el funcionamiento del servicio SMTP.
El primer parámetro que vamos a configurar es la obligación que tiene el cliente en comenzar introduciendo HELO/EHLO para realizar un envío correctamente. Para ello ejecutamos los siguientes comandos como usuario root:
vi /etc/postfix/main.cf
smtpd_helo_required = yes
Ahora vamos a ampliar las opciones en el parámetro smtpd_recipient_restrictions, decir que estas opciones pueden ir separadas por comas o espacios; y recalcar que la lectura de sus opciones se realizan en orden de principio a fin, por lo que es importante conocer que opciones estamos configurando para no tener un funcionamiento inesperado.
Para conocer mejor estas opciones las vamos a definir y explicar para saber como se va a comportar nuestro servidor. Estas opciones son:
- reject_unknown_sender_domain -> Rechaza la solicitud cuando MAIL FROM tiene en su dirección un dominio no existente.
- reject_unknown_recipient_domain -> Rechaza la solicitud cuando RCPT TO tiene en su dirección un dominio no existente.
- reject_unauth_pipelining -> Rechaza la solicitud cuando el cliente envía comandos SMTP antes de tiempo sin saber que Postfix soporta command pipelining. Esto detiene a programas de correo masivo que usan command pipelining para acelerar entregas.
- reject_invalid_hostname -> Rechaza la solicitud cuando el cliente proporciona en el HELO/EHLO un FQDN inválido.
- reject_non_fqdn_helo_hostname -> Rechaza la solicitud cuando el cliente proporciona en el HELO/EHLO un FQDN que no existe.
- reject_non_fqdn_sender -> Rechaza la solicitud cuando la dirección en MAIL FROM no cumple FQDN.
- reject_non_fqdn_recipient -> Rechaza la solicitud cuando la dirección en RCPT TO no cumple FQDN.
Una vez que conoces el cometido de cada una de las opciones, únicamente falta introducirlas en nuestro fichero main.cf. Ejecutamos los siguientes comandos como root para efectuar los cambios:
vi /etc/postfix/main.cf
smtpd_recipient_restrictions =
reject_unknown_sender_domain
reject_unknown_recipient_domain
permit_mynetworks
reject_unauth_destination
reject_unauth_pipelining
reject_invalid_hostname
reject_non_fqdn_helo_hostname
reject_non_fqdn_sender
reject_non_fqdn_recipient
permit
Para que los cambios tomen efecto tenemos que recargar nuestro Postfix, para ello ejecutamos el siguiente comando como root:
postfix reload
Una vez recargada la configuración de Postfix, vamos a seguir probando cada una de las opciones para conocer como afectan.
Probar parámetros
A continuación vamos a probar cada una de las líneas introducidas en el fichero main.cf. Para ello vamos a seguir el orden en el que se han introducido.
- smtpd_helo_required = yes
En esta primera prueba vamos a conectar a nuestro servidor desde un equipo cliente y vamos a introducir todos los comandos necesarios para enviar un correo electrónico pero sin introducir el parámetro inicial helo/ehlo dominio. Para ello ejecutamos los siguientes comandos desde un cliente:
telnet IP_ANTISPAM 25
mail from:test@test.com
- reject_unknown_sender_domain
Ahora vamos a comprobar como devuelve un error cuando introducimos un dominio no válido en el MAIL FROM. Hay que tener en cuenta que este parámetro también afecta a las redes locales declaradas en mynetworks, ya que este se encuentra antes del parámetro permit_mynetworks. Para ello nuevamente ejecutamos los siguientes comandos:
telnet IP_ANTISPAM 25
ehlo test.com
mail from:user@test.invalid
rcpt to:user@example.com
- reject_unknown_recipient_domain
Ahora se va a rechazar el envío porque el dominio va a ser inválido en el RCPT TO, recalcar también que este parámetro afecta también al envío desde las redes declaradas en mynetworks. Nuevamente ejecutamos los siguientes comandos:
telnet IP_ANTISPAM 25
ehlo test.com
mail from:user@test.com
rcpt to:user@example.invalid
- reject_invalid_hostname
Ahora vamos a introducir en el comando HELO/EHLO un dominio con caracteres no válidos. Ejecutamos los siguientes comandos:
telnet IP_ANTISPAM 25
ehlo .
mail from:user@test.com
rcpt to:user@example.com
- reject_non_fqdn_helo_hostname
En la siguiente prueba vamos a introducir en el comando HELO/EHLO un dominio no válido. Para esto ejecutamos los siguientes comandos:
telnet IP_ANTISPAM 25
ehlo test
mail from:user@test.com
rcpt to:user@example.com
- reject_non_fqdn_sender
Ahora vamos a comprobar como bloqueamos los correos que no proporcionan un FQDN válido en el MAIL FROM. Ejecutamos los siguientes comandos:
telnet IP_ANTISPAM 25
ehlo test.com
mail from:user
rcpt to:user@example.com
- reject_non_fqdn_recipient
En esta última prueba vamos a comprobar como se rechazan correos que no cumplen con FQDN en el RPCT TO. Ejecutamos los comandos mostrados a continuación:
telnet IP_ANTISPAM 25
ehlo test.com
mail from:user@test.com
rcpt to:user
Con estas pruebas comprobamos el funcionamiento de todos los parámetros configurados. Se recomienda que cuando se realicen cambios no se hagan más de tres y realizar pruebas, ya que si realizamos todos los cambios de una vez no podremos saber por donde nos falla nuestro servidor.
Quería hacer una mención, en estos momentos que termino el artículo disfruto de ver ganar la selección nacional de mi país la semifinal a Alemania, esperamos que el próximo domingo seamos campeones del mundo ganando a Holanda. Hasta otra entrega amigos.
Google+
















enviando...
Estupendo tu articulo como siempre, al hilo de los servidores de correo quisiera preguntarte una cosa.
estamos planteando en mi empresa montar un servidor de correo dedicado y estamos dudando si ponerlo linux o exchange, el tema es que necesitamos controlar los mensajes que entran y sobre todo los que salen, sabes cual es la mejor solucion?
gracias
Gracias Oscar,
Podrías montar dos servidores, como muestra este artículo uno que se encargue de pasarela tanto entrada como salida (sería un Linux) y como “almacenaje” podrías montar un Exchange. Si todos tus clientes son Windows y usas Microsoft Outlook vas a disponer de una buena integración entre cliente-servidor.
En Exchange tienes la opción de activar el “Centro de Seguimientos”, donde aparece todo lo que llega y sale de Exchange. Además también en la pasarela dispones de los logs y los demás servicios que vayas montando para asegurar tanto la entrada como salida.
Además si usas clientes móviles con su Blackberry y optas por montar un servidor RealMail, de forma obligatoria necesitas usar Exchange.
Un saludo y ya me cuentas.
un pequeño dato para las pruebas:
si están realizando las pruebas por telnet desde la red que esta en “mynetworks’ cuando hagan las pruebas de todas las opciones que están después de “permit_mynetworks” les va a dejar mandar el correo, Esto pasa justamente porque postfix va leyendo (como dice en el tutorial) en órden las reglas. Y al aceptar esa regla deja pasar el correo.
Simplemente hay que probarlo desde otra red, o poner “permit_mynetworks” al final para que sea la última regla que controla. (me parece que esto no genera problemas)
nuevamente muy bueno el tuto y saludos!.
Hola nuevamente Gilgamezh,
Gracias por tu comentario, dicha puntualización la hago en la primera parte del artículo, donde comento que para hacer las pruebas hay que hacerlas fuera de un equipo de la red o eliminar la red local en el parámetro mynetworks dejando únicamente 127.0.0.1/8
Gracias por tu comentario, en breve seguiremos ampliando nuestro AntiSPAM
es verdad, se me pasó :)
saludos y gracias
Jejejejeje,
No pasa nada Gilgamezh, siempre sirve de ayuda cualquier comentario, porque seguramente que alguna persona no pase por el primer artículo si ya tienen su sistema montado y van directamente a las buenas prácticas.
Espero seguir leyéndote por aquí, saludos.
[...] nuestra segunda entrega se proporcionaban ciertos parámetros como buenas prácticas para mejorar el rendimiento y [...]