Hai già provato le procedure di risoluzione in questa discussione e nelle altre correlate?
Aggiungi una riga al tuo app.yml:
DISCOURSE_SMTP_DOMAIN: [il FQDN del tuo server]
Quindi, in /var/discourse, esegui ./launcher rebuild app
discourse-doctor potrebbe continuare a segnalare errori, ma i messaggi di prova inviati dalla console di amministrazione dovrebbero funzionare e il flusso normale delle email dovrebbe riprendere.
Se ciò non funziona, ti preghiamo di farcelo sapere, poiché significa che c’è qualche altro aspetto che non è ancora stato individuato.
Hai ragione, discourse-doctor continua a fallire per me.
Penso di aver riavviato Discourse in precedenza invece di ricostruire, il che probabilmente spiega perché la modifica non ha avuto effetto. Grazie @Syonyk!
Sembra chiaro che localhost sia sempre errato, ma che la maggior parte dei server SMTP ignori quel valore, quindi finora non ha avuto importanza.
I 3 punti in cui smtp_domain appare in https://github.com/discourse/discourse risalgono tutti a oltre 2-7 anni fa. Mi chiedevo se forse qualche libreria abbia iniziato a inviare localhost per qualche motivo.
Penso che la soluzione migliore, nonostante le preoccupazioni di @Falco, sarebbe correggere effettivamente il problema in un punto come questo
Indipendentemente dal fatto che il consenso sia quello di continuare a inviare localhost nonostante sia in contrasto con le RFC, è necessario correggere il task rake come descritto sopra. Ah, e sono io a aver scritto quel codice. Ma, aspetta. Vedo che action_mailer.smtp_settings['domain'] può essere vuoto. Quindi immagino che
per ora, almeno. Penso che si debba usare il domain se esiste e mantenere il comportamento attuale (ma errato?) di usare localhost se discourse_smtp_host non è definito.
Esito a aggiungerlo a discourse-setup, poiché funziona per quasi tutti così com’è ed è una domanda in più piuttosto confusa da fare. (E sto per aggiungere una domanda per notification_email, quindi se non stiamo attenti inizierà a sembrare quello che ricordo del kernel Linux di un paio di decenni fa.)
Ho appena ricevuto una segnalazione per questo problema e posso confermare che la correzione funziona. La nostra istanza, normalmente a basso volume, ha registrato un’esplosione in Sidekiq, apparentemente a causa di lavori di digest in ripetuti tentativi di retry.
Pensavo che Google avesse introdotto nuovi limiti sull’utilizzo, dato che il messaggio di errore corrisponde a quello che pubblicano per i rifiuti legati a DoS.
Ma, aspetta. Vedo che 
