Luego de consultar expertos en esta materia, programadores de varias ramas y profesores dimos con la respuesta al dilema y la plasmamos en este post.
Solución:
Solución 1:
Antes de pasar a mi sugerencia, quiero comentar un poco algo que te dijo tu proveedor:
Received: from mail.com ([94.130.34.42]) by smtp-27.iol.local with SMTP id itOWeYZ6O42IFitOWe35TR; Tue, 13 Feb 2018 03:54:09 +0100
Este no es indicar que el DNS inverso para 94.130.34.42 es (o era) mail.com. Más bien, indica que el cliente SMTP envió mail.com en su HELO (o EHLO) línea. (Un servidor de correo bien configurado habría rechazado esta conexión por completo, pero eso depende de Swisscom, no de usted…) Esta línea no indica ninguna entrada DNS inversa. Si lo hiciera, habría aparecido entre paréntesis. Por ejemplo:
Received: from mail-io0-f197.google.com (mail-io0-f197.google.com [209.85.223.197])
En este caso, el primer nombre de host es como se identificó el servidor de correo en su EHLO. El segundo nombre de host es el DNS inverso registrado en el momento en que se realizó la conexión.
La sección 4.4 de RFC 5321 explica el formato de la línea Recibido: con una gramática formal.
En su caso, no se registró ningún DNS inverso. Dado que su dirección IP tiene un registro PTR, esto puede deberse a que no lo buscaron o a que hubo una falla temporal en el DNS.
Ahora, parece que ejecuta un servicio de alojamiento web y tiene numerosas aplicaciones web. Si uno de estos se ve comprometido, puede comenzar a enviar spam. Éstos a menudo establecen conexiones directas con servidores de correo remotos buscando sus registros MX y conectándose al puerto 25, como si en realidad fueran un servidor de correo, en lugar de entregar el correo a la cola de correo local o un servicio de correo autenticado en los puertos 587 o 465. como lo hacen las aplicaciones web legítimas.
Una forma de detener esto es implementando una regla de firewall que evita las conexiones salientes en el puerto 25 a menos que el usuario sea el usuario del servidor de correo. Por ejemplo:
iptables -I OUTPUT -m owner ! --uid-owner postfix -m tcp -p tcp --dport 25 -j REJECT
Las aplicaciones web ya no pueden entregar correo directamente a servidores SMTP remotos, sino que deben usar la cola de correo local o un servicio de correo autenticado.
Solución 2:
Hoy en día, tratar de hacer su propio servidor de correo es, en su mayor parte, una batalla perdida y es mejor encontrar un servicio asequible. Una vez dicho esto..
-
Mire sus registros yendo al proveedor que lo bloqueó y vea si puede encontrar algo sospechoso. Es posible, y sucede a menudo, que alguien olvide que se suscribió a tu newsletter y te marque como spam. Luego, dependiendo del proveedor, puede ingresar en la lista negra del proveedor aunque no haya hecho nada malo.
-
Separe los envíos masivos de todos sus otros correos electrónicos en dos servidores.
-
Mantenga registros durante semanas como mínimo y mejores meses. Así que cada vez que pasa algo, investigas.
-
Verifique sus registros diariamente para situaciones similares de cualquier proveedor y mírelo diariamente, o más rápido. En el momento en que se bloquee y si sigue intentando enviar, puede empeorar. Puede pasar de un bloqueo temporal a un bloqueo permanente… a ser reportado a una lista negra.
-
No estoy seguro de cómo lo implementan, pero una cosa que sé que hacen muchos proveedores para los servicios de correo saliente es que en el momento en que un proveedor/IP bloquea un correo electrónico, no se intenta enviar ningún otro correo electrónico. Lo ideal es que quieras algo así. Debido a que el segundo se bloquea, enviar más solo agravará el problema.
Recuerda que puedes dar difusión a este escrito si te fue de ayuda.