¿Has probado los pasos de resolución en este hilo y en los otros relacionados?
Agrega una línea a tu app.yml:
DISCOURSE_SMTP_DOMAIN: [el FQDN de tu servidor]
Luego, en /var/discourse, ejecuta: ./launcher rebuild app
Es posible que discourse-doctor siga informando errores, pero los correos de prueba desde la consola de administración deberían funcionar y el flujo normal de correo debería reanudarse.
Si eso no funciona, por favor repórtalo, porque entonces hay algún otro aspecto que aún no se ha descubierto.
Parece claro que localhost siempre es incorrecto, pero la mayoría de los servidores SMTP ignoran ese valor, por lo que no ha importado.
Los 3 lugares donde aparece smtp_domain en https://github.com/discourse/discourse tienen más de 2-7 años. Me preguntaba si tal vez alguna biblioteca comenzó a enviar localhost por alguna razón.
Creo que la mejor solución, a pesar de las preocupaciones de @Falco, sería arreglar esto en algún lugar como
Independientemente de si el consenso es seguir enviando localhost a pesar de que va en contra de los RFCs, entonces es necesario corregir la tarea rake como se describió anteriormente. Oh, y soy yo quien escribió ese código. Pero, espera. Veo que action_mailer.smtp_settings['domain'] puede estar vacío. Así que supongo que
por ahora, al menos. Creo que debería usar el domain si existe y usar el comportamiento actual (¿pero incorrecto?) de usar localhost si discourse_smtp_host no está definido.
Me resisto a agregar esto a discourse-setup, ya que funciona para casi todos tal como está y es una pregunta más bastante confusa de hacer. (Y estoy a punto de agregar una pregunta para notification_email, así que si no tenemos cuidado, empezará a parecerse a lo que recuerdo que era hacer el kernel de Linux hace un par de décadas.)
Acabo de ser notificado sobre este problema y puedo confirmar que la solución funciona. Nuestra instancia, que normalmente tiene un volumen bajo, también explotó en Sidekiq, aparentemente debido a trabajos de digest que se reintentaron muchas veces.