Configuración de servidores de retransmisión SMTP para aplicaciones heredadas

Configuración de servidores de retransmisión SMTP para aplicaciones heredadas

Muchas organizaciones mantienen aplicaciones heredadas que no soportan autenticación modernaa ni TLS, pero necesitan enviar correos confiables. Un servidor de retransmisión SMTP (SMTP relay) actúa como puente: recibe mensajes desde la app y los entrega al exterior cumpliendo políticas de seguridad y deliverability. En esta guía técnica y práctica explico arquitectura, configuración típica con Postfix, buenas prácticas de seguridad (TLS, SPF/DKIM/DMARC), pruebas y monitoreo.

¿Por qué usar un servidor de retransmisión para apps heredadas?

Las aplicaciones antiguas suelen usar funciones de envío locales (por ejemplo mail() en PHP antiguo, módulos SMTP sin autenticación o sockets directos). Esto provoca problemas:

  • Bajas tasas de entrega por falta de autenticación y reputación.
  • Imposibilidad de usar TLS o cifrado adecuado.
  • Difícil cumplimiento de políticas de seguridad corporativas.

Un relay central resuelve esto permitiendo que la app se comunique con un host interno confiable y el relay gestione autenticación, cifrado y reglas de entrega.

Arquitectura recomendada

Diseña la topología pensando en seguridad y escalabilidad:

  • Relay interno (zona privada) que acepta conexiones desde la IP/Subnet de las apps heredadas.
  • Relay saliente que autentica ante el proveedor de correo o entrega directa con buena reputación.
  • Separación de funciones: filtrado (antispam/AV), signing (DKIM) y entrega.
  • Registro y monitorización centralizados.

Puedes implementar todo en un único servidor para entornos pequeños o distribuir funciones en varios hosts para alta disponibilidad.

Configuración práctica: Postfix como servidor de retransmisión

Postfix es una opción estable y ampliamente documentada para un SMTP relay. Los pasos clave son:

1) Aceptar conexiones solo desde las aplicaciones

Restringe quién puede enviar correo al relay para evitar ser usado como open relay.

# /etc/postfix/main.cf
mynetworks = 127.0.0.0/8, 10.0.0.0/24  # incluir la red de las apps heredadas
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination

2) Usar relayhost para entrega saliente

Si vas a relutar todo a un proveedor de correo (smart host), configura:

# /etc/postfix/main.cf
relayhost = [smtp.proveedor.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = may
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

El archivo /etc/postfix/sasl_passwd contendrá las credenciales (protege con permisos 600 y ejecuta postmap /etc/postfix/sasl_passwd).

3) Forzar TLS y comprobar certificados

Para máxima seguridad, configura TLS estricto si tu smart host lo soporta:

smtp_tls_security_level = encrypt
smtp_tls_verify_cert_match = hostname

Si entregas directamente a MX de destino, mantén may y monitoriza la negociación TLS para evitar fallos de entrega.

4) Firmado DKIM y cabeceras

Genera claves DKIM y firma mensajes salientes en el relay. Para esto suelen usarse herramientas como OpenDKIM conectadas a Postfix. El relay es el lugar idóneo para insertar cabeceras que la app heredada no puede generar.

DNS y reputación: SPF, DKIM y DMARC

Configurar correctamente DNS es crítico para deliverability:

  • SPF: incluye el IP o el hostname del relay en el registro TXT (v=spf1 ip4:1.2.3.4 include:relaydomain -all).
  • DKIM: publica la clave pública en DNS y firma desde el relay.
  • DMARC: define la política de rechazo/monitorización para tu dominio.

Estas tres capas evitan que correos legítimos terminen en SPAM y protegen la reputación del dominio.

Seguridad adicional y buenas prácticas

  • Autenticación entre la app y el relay: si la app no soporta SASL, restringe por IP y utiliza mTLS o IPSec entre host y relay cuando sea posible.
  • TLS con certificados válidos: automatiza renovación con Let\’s Encrypt cuando el relay expone servicio público.
  • Registro y alertas: centraliza logs (rsyslog/ELK/Graylog) y crea alertas por colas largas o reintentos.
  • Limitación de tasa: aplica throttling para evitar picos que afecten reputación.
  • Filtrado de contenido: evita que la app envíe adjuntos peligrosos o spam masivo; integra antivirus y reglas de contenido.

Para minimizar la superficie de ataque, mantén el servidor actualizado y aplica principios de mínimos privilegios.

Pruebas y validación

Valida el funcionamiento paso a paso:

  • Conecta desde la IP de la app: telnet relay.ip 25 o openssl s_client -starttls smtp -crlf -connect relay:587.
  • Revisa logs de Postfix en tiempo real (tail -f /var/log/mail.log).
  • Envía correos de prueba y comprueba cabeceras para ver DKIM y SPF en resultados.
  • Usa herramientas externas para analizar deliverability y listas negras.

Monitoreo y operaciones

Los puntos que debes monitorear continuamente:

  • Tamaño y antigüedad de la cola de correo.
  • Tasas de entrega, bounces y errores temporales.
  • Reintentos y mensajes diferidos.
  • Alertas de listas negras o bloqueo por parte de proveedores.

Automatiza la rotación de logs y backups de configuraciones para recuperaciones rápidas.

Casos reales y soluciones a problemas comunes

Aplicación que solo envía desde localhost sin autenticación

Solución: instala un relay en la misma VLAN y permite solo 127.0.0.1 o la IP privada. El relay añadirá DKIM y enviará vía smart host.

Rechazo por falta de TLS en el smart host

Solución: habilita smtp_tls_security_level = encrypt y asegúrate de que el relay tenga CA actualizada; utiliza certificados de Let\’s Encrypt para endpoints públicos.

Necesidad de balanceo o alta disponibilidad

Implementa múltiples relays detrás de un VIP o balanceador y sincroniza colas o usa enrutamiento DNS con prioridades. Para proxys SMTP en borde, la documentación de NGINX sobre mail proxy puede ser útil cuando integras autenticación y TLS en el borde.

Seguridad y cumplimiento

Aplica controles según el riesgo del contenido transmitido. Revisa las recomendaciones de seguridad para aplicaciones y servicios de red: OWASP ofrece guías para proteger flujos y evitar exfiltración de datos en servicios de correo (OWASP).

Resumen y checklist para producción

Antes de pasar a producción, asegúrate de:

  • Limitar acceso al relay por IP/subnet o mediante mecanismos de túnel seguro.
  • Habilitar TLS y, si es posible, mTLS para conexiones críticas.
  • Configurar SPF, DKIM y DMARC correctamente.
  • Implementar registro, alertas y pruebas automáticas de envío.
  • Auditar rendimiento y reputación del dominio regularmente.

Conclusión

Un servidor de retransmisión SMTP bien configurado permite a aplicaciones heredadas continuar operando sin sacrificar seguridad ni deliverability. La clave reside en restringir el acceso, forzar cifrado cuando sea posible, firmar mensajes en el relay y mantener controles operativos (monitoreo, cuotas y actualizaciones). Implementando Postfix (u otra solución robusta) como relay, junto con SPF/DKIM/DMARC y certificados válidos, obtendrás una solución escalable y segura que protege la reputación del dominio y garantiza la llegada de tus correos. Para configuraciones avanzadas y ejemplos de proxys en el borde puedes revisar la documentación de NGINX, para certificados automáticos la documentación de Let\’s Encrypt y para prácticas de seguridad general visita OWASP.

Tags: