Estoy ejecutando una configuración de prueba (actualmente 2.4.0.beta4) en casa en un mini-PC local con Ubuntu 16.04 LTS. La instalé utilizando la excelente guía de instalación de 30 minutos. Sí tiene un FQDN. El envío de correos electrónicos a través de una bandeja de entrada de mi proveedor de servicios de Internet con SMTP en el puerto 587 y autenticación simple ha funcionado sin problemas durante más de un año.
Acabo de darme cuenta de que no he recibido notificaciones por correo electrónico durante algún tiempo, como “nueva versión disponible”. Al verificar Admin > Correo electrónico > Omitidos, veo que todo recibe un
550-Bad HELO: localhost.localdomain does not exist - Please see RFC 2821
Al revisar el buzón, esto podría haber comenzado con la versión 2.4.0.beta2. Pero también podría deberse a algún cambio de política en mi proveedor de servicios de Internet alrededor de la misma época (finales de julio de 2019). No estoy seguro de por dónde empezar. ¿De dónde proviene este localhost.localdomain? Durante la instalación solo tuve que editar app.yml y esto muestra mi FQDN correctamente en DISCOURSE_HOSTNAME:
Nunca había oído hablar de Mailgun. ¿Te refieres a mailgun.com, el “Servicio de API de correo transaccional”? Para que tengas una idea de mi nivel de conocimientos: sé vagamente qué es una API, pero no sabría cómo usar una. Sin embargo, podría intentar usar SMTP para enviar a otra bandeja de entrada en un proveedor de servicios de internet diferente. Informaré aquí mañana.
Mailgun te proporcionará las credenciales SMTP si te registras. Apuesto a que podrás averiguarlo simplemente siguiendo sus instrucciones durante el registro.
@itsbhanusharma, @jtbayly ¡Gracias! Acabo de lograr enviar un mensaje de prueba a través de Mailgun. Así que el problema fue una nueva política en el servidor SMTP de mi proveedor de servicios de internet. Es posible que siga usando Mailgun.
He realizado más investigación, ya que no puedo usar Mailgun para nuestro foro de producción.
En la cabecera de los correos electrónicos que llegan a través de Mailgun, todavía veo:
Received: from localhost.localdomain
HELO es el primer comando en el diálogo SMTP (fuente).
Debería ser algo como:
HELO discourse.mydomain.tld
Algunos servidores SMTP, como Postfix, tienen una opción para verificar esto contra la dirección IP del cliente. localhost.localdomain se resuelve a la dirección IP del servidor SMTP; probablemente esté en su archivo de hosts. Parece que los proveedores de servicios de Internet (ISP) están habilitando esto en su lucha contra los spammers.
Funciona con Mailgun porque Mailgun no ejecuta esta verificación. Pero aún así es un “HELO incorrecto”.
Para comparar, envié un correo electrónico usando un cliente de correo (Sylpheed) en el mismo sistema. Esto funciona, incluso con la bandeja de entrada de mi ISP, y parece usar:
HELO HL80L
HL80L es el nombre de mi red local. Aún no es un FQDN, pero al menos no aparece como algo obvio y falso para el servidor de mi ISP.
Así que quizás esto sea algo que necesite ser mejorado. Pero aclaración: no soy un experto en SMTP.
Por cierto, lo volví a hacer funcionar a través del buzón de mi proveedor de servicios de Internet, colocando un MTA intermedio como relay. Es una aplicación basada en Postfix en mi NAS. Esta utiliza HELO mydomain.tld
Voy a revisar si rompimos algo durante el cambio a Debian 10 o la actualización a Rails 6. Mientras tanto, configurar DISCOURSE_SMTP_DOMAIN en app.yml debería funcionar. Supongo que deberíamos usar por defecto el valor de DISCOURSE_HOSTNAME si el dominio SMTP no está configurado explícitamente.
¡Gracias, @gerhard! DISCOURSE_SMTP_DOMAIN no estaba presente en mi app.yml, pero respiré hondo, lo agregué y, efectivamente, eso funcionó. Ahora puedo usar el buzón de mi proveedor de servicios de internet (ISP) nuevamente. En el extremo receptor, encuentro en la cabecera:
Received: from XXXXXXX.cable.dynamic.v4.ziggo.nl ([XX.XX.XX.X] helo=mydomain.tld)
by smtp7.mnd.mail.iss.as9143.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1)
Mientras tanto, aprendí que tanto la RFC 2821 como su sucesora RFC 5321, sección 4.1.4 establecen lo siguiente:
Un servidor SMTP PUEDE verificar que el argumento del nombre de dominio en el comando EHLO corresponda realmente a la dirección IP del cliente. Sin embargo, si la verificación falla, el servidor NO DEBE rechazar un mensaje por ese motivo. La información capturada en el intento de verificación es para fines de registro y trazabilidad. Cabe señalar que esta prohibición solo se aplica a la coincidencia del parámetro con su dirección IP; consulte la Sección 7.9 para una discusión más amplia sobre el rechazo de conexiones entrantes o mensajes de correo.
Pero muchos MTAs, como Postfix y Exim, parecen tener aún una configuración opcional para hacerlo. Es posible que los administradores estén activando esta opción en la batalla continua contra el spam.
