Aunque no hayan oido mas hablar de este proyecto, en realidad esta funcionando bien… para mi. Creo que soy el unico que lo usa. Aun asi, al ser un servicio abierto, y yo un noob, ya tuve mi primer problema con el spam.

Antes de continuar, hago referencia al post de Luis Carlos Pando en su post de Tu blog necesita un «Respondiendo a». Me parece una excelente idea, pero no he tenido mucho tiempo para idear una solución adecuada para mi forma de trabajo, asi que si, creo que vendría bien una forma llamativa de indicar que este post es parte de algo mas grande. por lo que hago mi primer borrador aquí:

Este Post pertenece al proyecto Channel2RSS

Puedes encontrar todos los artículos en orden cronológico en la etiqueta Channel2RSS

 

Introducción

La verdad es que me confie por la paz que da no hacerse autobombo. Con un proyecto gratuito el problema es que la gente abuse, pero si nadie sabe de el, nadie puede abusar. Esa era la teoria, pero como nadie lo usa, tampoco nadie me avisa si hay un problema. Y asi, desde julio hasta agosto mi servidor de correos ha estado enviando montones de mails a diferentes cuentas inexistentes, pero de servidores reales, al punto de que empezaron a rebotar los mensajes. Entonces, me di cuenta de que algo iba mal.

1522 mensajes de rebotes… Y a saber cuantos mensajes realmente habran llegado a su destino. Pero vamos analizando la situacion poco a poco.

Hace unos días, mi servidor de correo se convirtió en el enemigo número uno de Gmail, Microsoft y Proofpoint. Había lanzado Channel2RSS, un servicio experimental en PHP para suscribirse a feeds de canales de Telegram por correo. Todo funcionaba de maravilla hasta que unos bots descubrieron mi formulario de suscripción.

¿El resultado? Un ataque masivo de Subscription Bombing / Mailbombing. Los bots registraban miles de correos reales por segundo. Mi servidor Postfix empezó a escupir correos sin control, saturando los límites de los proveedores y destruyendo la reputación de mi IP en cuestión de horas.

Si estás administrando tu propio servidor de correo (en mi caso, un VPS en DigitalOcean que también uso para Delta Chat), aquí te cuento detalladamente cómo identifiqué el problema, los errores de novato que cometí y cómo blindé la infraestructura por completo.

Analizando los destrozos

Mi primera reaccion al entender la gravedad del asunto, fue, intentar apagar mi servicio. Pero mi servicio es php en nginx, asi que no lo puedo apagar sin cierta ceremonia. En el apuro, lo primero que se me ocurrio fue revisar la base sqlite y borrar todos los correos desconocidos y eso hice. como 869 correos desconocidos registrados en mi servicio, pero eso no freno el ataque.

Al revisar la cola de correo con el comando mailq, me encontré con cientos de rebotes duros (Hard Bounces) y bloqueos temporales. Estos fueron los síntomas de que la IP estaba en la lista negra:

• Gmail (Error 550-5.2.1 / 450): The user you are trying to contact is receiving mail at a rate that prevents additional messages from being delivered. (Google congeló la recepción de los usuarios atacados).
• Proofpoint (Error 554 5.7.0): Blocked – see https://proofpoint.com… (Bloqueo total en redes corporativas).
• Cloudmark CSI & Comcast: Bloqueos automáticos por comportamiento sospechoso y ráfagas masivas.

La Falacia del Superviviente en los Logs

Al principio pensé: «Bueno, los logs solo muestran los correos que rebotaron, el contenido es solo arte, no es tan grave». Grave error. Estaba ante la falacia del superviviente: los logs solo mostraban los aviones que regresaron dañados (los rebotes). A saber cuántos miles de correos no deseados sí lograron pasar, provocando que los usuarios marcaran mi IP como Spam.

Blindando mi código

Mi código inicial tenía dos fallas críticas de seguridad: registraba el correo inmediatamente en la base de datos (SQLite3) disparando un mail de bienvenida al instante, y concatenaba las variables directamente en el string de la consulta (vulnerable a Inyección SQL).

Para solucionarlo sin implementar Captchas molestos que arruinan la estética de la web, apliqué dos capas de protección:

1. El Honeypot Invisible (Trampa para bots)
Los bots rellenan todos los campos que encuentran en el HTML. Añadí un campo de texto oculto mediante CSS. Si el formulario llega con ese campo lleno, sé con certeza que es un bot y mato la ejecución silenciosamente.

<!-- Campo real -->
<input type="email" name="user_email_real" required>

<!-- Campo Honeypot (Trampa) -->
<div style="display:none !important; tab-index:-1;" aria-hidden="true">
<input type="text" name="email" value="" autocomplete="off">
</div>

2. Migración Estricta a Doble Opt-In y Consultas Preparadas

Modifiqué el backend para hacer tres cosas:

• Usar Prepared Statements con SQLite3 para erradicar la inyección SQL.
• Guardar al usuario en la base de datos con un estado = ‘pendiente’.
• Cambiar el correo de bienvenida por un correo de verificación con un token único (confirmar.php?clave=…).

El script que envía la newsletter ahora tiene un filtro estricto: solo envía correos a registros cuyo estado = ‘confirmado’. Si un bot ataca, la ejecución muere en el Honeypot; y si logra pasar, solo se enviará un único correo de confirmación que el dueño real ignorará, impidiendo que el bot use mi servidor para bombardear a nadie.

Configuración Avanzada de Postfix

Aquí venía el gran dilema: para mitigar ráfagas masivas, la recomendación estándar es aplicar un límite de velocidad (Throttling) global en Postfix (default_destination_rate_delay). Sin embargo, yo uso mi servidor con Delta Chat. Delta Chat funciona sobre SMTP/IMAP y necesita inmediatez (estilo WhatsApp). Si limitaba Postfix globalmente, destruiría la experiencia de mi chat.

La Solución: Throttling selectivo por transporte

Postfix permite crear «carriles de velocidad» independientes basados en el remitente. Configuré el servidor para que todo lo enviado por la newsletter vaya lento, mientras que Delta Chat sigue viajando a máxima velocidad.

En /etc/postfix/master.cf, definí un nuevo transporte al final del archivo:

newsletter-lento unix - - n - - smtp

En /etc/postfix/main.cf, asigné reglas de velocidad exclusivas para ese carril

newsletter-lento_destination_rate_delay = 10s 
newsletter-lento_destination_concurrency_limit = 2 
sender_dependent_default_transport_maps = hash:/etc/postfix/sender_transport

Creé el archivo /etc/postfix/sender_transport para mapear el correo de la app al carril lento:

channel2rss@interlan.ec newsletter-lento:

E indexé el mapa con sudo postmap /etc/postfix/sender_transport y reinicié el servicio.

Profesionalización de la Infraestructura (rDNS / PTR Simétrico)

Al intentar limpiar mi reputación en Cloudmark, su sistema rechazó la solicitud con este mensaje: The IP Address appears to match a generic or default pattern.

Mi IP resolvía directamente al dominio raíz (interlan.ec.). Para los filtros modernos, esto parece una configuración casera o automatizada. Los estándares de internet (RFC) dictan que un servidor de correo debe tener un subdominio dedicado (un FQDN como mail.interlan.ec).

Hacer el cambio no rompió absolutamente nada de mis scripts de PHP ni de Delta Chat, ya que solo es un cambio de nombre a nivel de máquina:

• DNS: Creé un registro de tipo A para mail apuntando a la IP de mi VPS.
• DigitalOcean: Cambié el nombre del Droplet (Rename) a mail.interlan.ec. Esto hace que DigitalOcean actualice el registro inverso PTR (rDNS) de forma automática.
• Postfix: Modifiqué la directiva en main.cf a myhostname = mail.interlan.ec y reinicié.

Ahora la relación es simétrica y profesional: si consultas la IP te devuelve el subdominio, y si consultas el subdominio te devuelve la IP. Al cumplir con este estándar, los filtros quitan los bloqueos con total facilidad.

Conclusiones

Administrar tu propio servidor de correo es un superpoder, pero requiere responsabilidad. Con estas medidas, pasé de tener una IP quemada a una infraestructura blindada:

• Los bots mueren en la primera línea gracias al Honeypot.
• Postfix dosifica los envíos masivos protegiendo la reputación ante Gmail.
• Delta Chat sigue funcionando de manera instantánea.
• La configuración DNS quedó impecable ante los ojos de los grandes proveedores.

La verdad esto fue horroroso y requirió bastantes mas cambios de los que he registrado aquí. He escrito un ChangeLog mas detallado en la pagina misma del proyecto, pero lo transcribiré aquí tambien:

9 de agosto de 2026

• Migración del sistema de suscripción de la newsletter a un flujo estricto de Doble Opt-In.
• Creada la página confirmar.php para procesar y activar los tokens de verificación de nuevos usuarios de forma segura.
• Implementación de la protección Honeypot invisible en el formulario de registro para mitigar ejecuciones automáticas de spambots sin afectar la experiencia del usuario con Captchas tradicionales.
• Se corrigió la vulnerabilidad de Inyección SQL en el backend del formulario de suscripción y en el Webhook principal mediante la implementación de consultas preparadas (Prepared Statements) con SQLite3.
• Configuración de Throttling selectivo por transporte en Postfix. Se crearon carriles de velocidad separados: los envíos masivos de la newsletter se dosifican en cola lenta para proteger la reputación del servidor, mientras que los servicios de mensajería instantánea (Delta Chat) siguen operando a máxima velocidad sin restricciones.
• Profesionalización de la infraestructura DNS del servidor. Se migró el rDNS (registro PTR) de la IP del dominio raíz (interlan.ec) hacia un subdominio completamente cualificado (mail.interlan.ec), logrando una configuración simétrica perfecta y limpia ante los filtros de Cloudmark, Proofpoint y Gmail.
• Corrección de un error menor en las plantillas HTML donde se duplicaba la palabra «inter» en la URL de desuscripción dinámica.

TODO

• Hacer el deslistado manual en la consola de Cloudmark CSI una vez que expire el tiempo de caché de sus servidores DNS locales.
• Dar de alta el dominio en Google Postmaster Tools para monitorear la reputación de la IP y la tasa de spam tras el ataque.
• Vigilar los logs de Postfix (mail.log) durante los próximos 7 días para verificar que los códigos de error 554 y 450 desaparezcan por completo.

Curiosidades

• El ataque de Mailbombing fue tan masivo que los spambots lograron que una IP limpia terminara bloqueada por corporativos de Canadá en menos de unas horas. Al final, lo que parecía un problema de entrega masiva terminó salvando el código de tres agujeros de seguridad enormes. ¡No hay mal que por bien no venga!